deployed on distributed hybrid multi-cloud applications (GraalVM, Quarkus, etc.) Similar directions are being adopted by other development platforms, in particular .Net.

Finally, for some families of enterprise software component products, some standardized specifications have been emerging driven by various organizations. Those relevant for PLM interoperability are Enterprise Workflow System, Enterprise Service Bus, Enterprise Horizontal Portal, Product Data Management Systems or Enterprise Directories.

## Conclusion on the Platforms

Here we are facing the same issue than for models and standards: many platforms aiming at supporting interoperability are available on the shelves and are effectively in used. However, due to the competition on the market, they are competing and most of the time incompatible or closed, being voluntarily or not. Indeed, providing open and interoperable solutions may go against business strategy, e.g. for protecting intellectual property and know how, or for making the clients captive. When selecting the strategy to deliver open and interoperable solutions based on standards, the issue may come from the quality of standards or from their effectiveness for actually support the expected interoperability.

As such difficulty is not new, and as there is an actual need for interoperability, we may expect that the topic has been addressed by the research community. Here come the research initiatives related to interoperability

### 2.3.4 - Research Initiatives related to the interoperability topic

First, considering that the interoperability topic is cross domain and strategic, we may expect that some European Projects addressed it and made publicly available some results with as outcome some available solutions on the shelves in order to contribute to the Europe competitiveness.

Typing "Interoperability" as a research term on the database of European Research projects [18] in April 2021 returns 2157 results. As stated previously, interoperability is to be defined in the context of the kind of systems or domains which are considered. Hence combining the research with terms reflecting our domains of interest: "enterprise", "Product Lifecycle Management", "System Engineering", "Semantic", "IoT", "Virtual Manufacturing" and "Cyber Physical", we obtained the following results:

<table><caption>Table 10: Statistic for European Research projects dealing with interoperability per topics</caption><tr><td>Enterprise and Interoperability</td><td>226</td></tr><tr><td>Interoperability and Product Lifecycle Management</td><td>8</td></tr><tr><td>Interoperability and System Engineering</td><td>20</td></tr><tr><td>Interoperability and Semantic</td><td>354</td></tr><tr><td>Interoperability and IoT</td><td>171</td></tr><tr><td>Interoperability and Virtual Manufacturing</td><td>1</td></tr><tr><td>Interoperability and "Cyber Physical"</td><td>85</td></tr></table>
These results should be analysed with care, as it is based on a syntactic and quite simple
search. However, it reflects that Interoperability is a topic which has been motivating many
research projects over the years, in combination with successive topics. Those associated with
"semantic", "enterprise" and "IoT" and "Cyber Physical" are numerous. We have less
projects concerning System Engineering, Virtual Manufacturing or Product Lifecycle
Management.

For going deeper in the analysis of what these projects delivered, an important issue comes
from the fact that very often, all the results are not made publicly available, and that the
publicly available deliverables don't remain available a long time after the end of the projects.
In addition, projects are often delivering huge number of documents which are not easy to
exploit, or prototypes which are not of an industrial quality, i.e. they are not suited for being
used in the enterprise without an industrialisation phase. Such industrialisation phase often
doesn't occur when dealing with interoperability, in particular because the issues are not only
related to technologies.

However, it was possible to assess the results and the way of working of several projects
which delivered some valuable outcome and return on experience.

The three following projects are such identified research projects, belonging to research clusters, which are related to the interoperability of Technical Enterprise Application and address particular important viewpoints: [The Advanced Information Technology in Design and Manufacturing ], [IDEAS] and [DBE].

**The Advanced Information Technology in Design and Manufacturing** (ESPRIT Project 7704 1996) initiative (AIT) aimed at European manufacturing users of information technology building a consensus among on their future requirements as applied to the design and manufacturing processes, reaching agreement on these requirements with the IT vendors and initiating the necessary IT-related R&D in order to meet these long-term needs. It was expected that this heavy orientation towards 'user-pull' will have a strong influence in shaping the future direction of advanced IT developments for the manufacturing sectors involved in the project. It led to the creation of a cluster of projects, involving the members of the Advanced Information Technology for Design and Manufacturing (AIT) consortium formed in the autumn of 1993 by 17 European automotive and aerospace companies. According to the requirements defined during the AIT pilot phase, AIT-IP capitalises on emerging object oriented concepts such as those defined by the STEP and OMG committees. AIT-IP proposed further to implement a platform supporting integration business cases found today in the design, engineering and manufacturing processes of AIT partners. Several other projects, such as RISESTEP, relied on the framework defined by the AIT project (4 400 000 Euros)

European Research for Enterprise Application Interoperability was initiated with the **Interoperability Development for Enterprise Application and Software** (IDEAS), with many programs since then implementing this roadmap and relying on the Network of Excellence Interop and associated European Virtual Laboratory for Enterprise Interoperability (I-VLab). This initiative aims at developing networked research with critical mass in the Enterprise Interoperability (EI) domain and associated domains (Future Internet and Enterprise Systems Applications). Created in March 2007 as an AISBL (Association Internationale Sans But Lucratif) under Belgian law, I-VLab co-ordinates more than 30 institutions from 11 countries (including China) and over 150 researchers. About 22 research projects are concerned, run during the 6th or 7th European Research Framework Programs and H2020 (http://interop-vlab.eu/deliverables/)
**Digital Business Ecosystem** (DBE) [(Grant agreement ID: 507953) started in November 2003 and ended in January 2007 is an FP6-IST project with an overall budget of € 13 903 024 ( cf. https://cordis.europa.eu/project/id/507953 ). DBE aimed at providing Europe with a recognized advantage in innovative software application development by its SME industry, launching a disruptive technology paradigm for the creation of a digital business ecosystem for SMEs and software providers thus improving their value network. An open-source distributed environment will support the spontaneous evolution, adaptation and composition of software components - which also embed business rules - and services allowing SMEs, that are solution and e-business service providers, to cooperate in production of components and applications adapted to local business needs. This can only be achieved with a vision leading to a paradigm shift: the complexity of distributed software production and the new forms of networked business require a multi-disciplinary approach based on biology, physics and social sciences mechanisms and models. DBE transposes from living organisms mechanisms like: evolution, adaptation, autonomy, viability, introspection, knowledge sharing, selection, and will lead to emergence of novel architectures and technologies, business processes and knowledge. The DBE aimed at changing the way SMEs and EU software providers use and distribute their products and services. The DBE is based on the key finding that with such an evolutionary and self-organising system Europe could harness the complexity of software production and its SME software industry could regain competitiveness. [1] reports the results of the initiative.

Analysing these projects, in addition to those that Airbus contributed to in order to deal with the expected interoperability; we didn't identify projects delivering valuable results which led to industrialisation of solutions supporting effective preparation and building of continuous operational interoperability required for PLM. We also identified serious limitations for research projects as being a way to address these issues, related to practices and rules put in place which prevent to produce effective outcome.

## 2.4 - Limitations

Despite the many legacy reference models, standards, dedicated technologies and research activities, successfully preparing and building continuous operational PLM interoperability at an acceptable cost, considering increasingly rapid changes in organizational and technological contexts, remains a challenge.

It is true in particular when willing to rely on PLM standards. [RISESTEP] and [SAVE] demonstrated the feasibility of sharing digital mock-up units widespread within heterogeneous applications distributed in networked enterprises by relying on a combination of manufacturing data exchange standard and distributed software standard. However the results were never applied or industrialized. [IDEAS] and [ATHENA] partners received the assessment of these results in order to solve the problem and were proposed a way to deal with dynamic and heterogeneous requirements engineering when dealing with interoperability for enterprise applications. However they didn't succeed in addressing it.

Analysing the reason for these failures pointed out the importance but also limitations of the current legacy interoperability standards and associated frameworks. If not associated in an appropriate way, they are not ensuring the operational continuous interoperability of technical enterprise applications within virtual enterprise at an acceptable price. Heterogeneous relevant legacy solutions, being standards or frameworks, are to be federated, aggregated, combined, configured, completed and sometimes improved in order to reach the seamless interoperability objective.
For the PLM purpose, interoperability is to be addressed in a holistic way, considering not the problem at the scale of the enterprise but at the scale of interacting digital business ecosystems and domains of knowledge. Indeed, the adoption of a PLM approach involves many disciplines and stakeholders which have to collaborate relying on accurate processes and methods.

In addition, the concerned disciplines are those associated to domains involved in the lifecycle of enterprise applications and their infrastructures, such as knowledge representation by ontology, software engineering, enterprise modelling and finally product data exchange, sharing and long term preservation.

As most of interoperability solutions, being models, standards or technical platform for are partial solutions and were not designed in order to be combined, their joint usage is quite challenging and requires a new innovative approach for enterprise technical applications interoperability within the virtual enterprise. The related performed state of the art and state of the practices demonstrated that this need wasn't addressed, or only partially, by overlapping, redundant and incompatible solutions not designed for addressing the long term data retention needs coupled with a mastered change process which prevent the disruption of operations, the accelerated obsolescence of the used solutions or the inefficient collaboration when relying on model based and computer aided approaches.

It was the motivation for developing and proposing the Federation of Interoperability Framework (described in chapter 3), as a way to continuously and pragmatically address the encountered issues through successive research, standardization and research projects contributing to a shared vision for PLM interoperability, and keeping track of the various issues which were already addressed and of those which were never addressed a satisfactory way. It relies on identified independent legacy enablers to be used jointly - here stands the idea of federation - and aims at unleashing the identified brakes, being scientific gaps, anti-patterns, bad practices or common behaviours.

The identified issues come from the analysis of the operational, standardization and research context when willing to achieve the expected interoperability for PLM or digital collaboration within and between manufacturing organizations. Table 11 provides the list identified issues which have been continuously collected following Federation of Interoperability Frameworks approach.

<table><thead><tr><td>ID</td><td>Designation</td><td>Description</td></tr></thead><tbody><tr><td>I-01</td><td>Multiple formalisms and non-preservation of the semantic</td><td>Multiple formalisms and non-preservation of the semantic between applicative components but also engineering artefacts when using model driven approach leads to poor communication between systems and loss of data</td></tr><tr><td>I-02</td><td>Break with legacy system</td><td>New paradigms are leading to breaks with legacy systems and creation of silos</td></tr><tr><td>I-03</td><td>Multiple dissociated boundaries</td><td>Virtualization leads to multiple dissociated boundaries for the different concerned systems: organizational, decisional, knowledge domain and technological system</td></tr></tbody></table>
<table><tr><td>I-04</td><td>Non alignment of identifications, decompositions and types</td><td>Non alignment of representations of a same real thing within different interconnected systems, in terms of identification, decomposition and typing makes data exchange and sharing difficult.</td></tr><tr><td>I-05</td><td>Application development logic</td><td>Application Development logic when systematically using Commercial Off-The-Shelves leads to "black box" which is going against applications interoperability and reduces the level of maturity of enterprises.</td></tr><tr><td>I-06</td><td>Cost to establish and maintain interoperability</td><td>The cost for establishment and maintenance of interoperability are too important with current practices, architectures and non-flexible technologies.</td></tr><tr><td>I-07</td><td>Diverging interest concerning interoperability</td><td>Diverging interests concerning stakeholders concerned by enterprise applications interoperability is going against the adaptation of relevant solutions.</td></tr><tr><td>I-08</td><td>Non flexible and reconfigurable solutions</td><td>Non flexible and reconfigurable solutions components are too often used.</td></tr><tr><td>I-09</td><td>Babel syndrome</td><td>Babel syndrome is not considered enough</td></tr><tr><td>I-10</td><td>Closed solutions</td><td>Closed solutions are going against interoperability.</td></tr><tr><td>I-11</td><td>Standards oriented according a single viewpoint</td><td>The standards are often oriented according to a single viewpoint, which is going against a global solution.</td></tr><tr><td>I-12</td><td>Standards oriented according a single type of model</td><td>Standards are often oriented according to a single type of model (information, service or process), which is going against a global solution.</td></tr><tr><td>I-13</td><td>Interoperability considered too late</td><td>Interoperability is considered too late, leading to overcost.</td></tr><tr><td>I-14</td><td>Important cost of creation of ontology for semantic mediation</td><td>Important cost of creation of ontology for semantic mediation is often not considered by researchers.</td></tr><tr><td>I-15</td><td>Complexity</td><td>Complexity of the systems concerned by PLM is challenging when willing to achieve interoperability</td></tr><tr><td>I-16</td><td>Sliding of formalism usage</td><td>As soon as formalism is created to cover such or such phase of lifecycle of application, a trend exists to use this formalism for the following phases of the lifecycle, leading to multiplication of languages and technological silos. We call it "sliding of formalisms" usage.</td></tr></table>
<table><tr><td>I-17</td><td>Impact of COTS parameterization</td><td>Impact of Commercial Off-The-Shelves parameterization during deployment and exploitation phase is most of the time not considered, while operational interoperability concerns only applications used in operational environments and not software products.</td></tr><tr><td>I-18</td><td>Legacy components not considered by conceptual frameworks</td><td>Most of the innovative model driven approaches proposed by research are not considering reuse of legacy implemented solutions and operational application, which imply retro-engineering and retro-conceptualization</td></tr><tr><td>I-19</td><td>Missing or insufficient governance of standards</td><td>For numerous organizations, there is missing or insufficient governance of standards</td></tr><tr><td>I-20</td><td>Graphical and textual languages</td><td>The drawback of graphical formal languages and their association with textual languages without conceptual alignment leads to inappropriate and useless sets of emerging standards.</td></tr><tr><td>I-21</td><td>Federation of systems</td><td>Federation of managed resources being controlled and filtered by several heterogeneous systems is not addressed by interoperability research.</td></tr><tr><td>I-22</td><td>Data exchange: not only translation but transposition</td><td>Data exchange is too often considered as simple translation while it requires transposition within several contexts using different independent sets of business rules.</td></tr><tr><td>I-23</td><td>Numerous incompatible and coexisting frameworks</td><td>Several incompatible and coexisting frameworks dealing with or impacting interoperability lead to technological silos.</td></tr><tr><td>I-24</td><td>Secured collaboration</td><td>Too often interoperability is considered as decoupled from security. However any interoperability solution should be coupled with security solutions in order to be usable in operation. Interoperability should also consider the impact of heterogeneous security policies between collaborating partners and of heterogeneous adopted security solutions</td></tr><tr><td>I-25</td><td>Controlled access to information and data</td><td>Too often, solutions provided for interoperability consider open solutions allowing exporting or publishing data for an application, but not the means for controlling and tracing who is accessing which data and information. It is an issue when considering constraints related to the protection of the intellectual property, the protection of personal data or the export control.</td></tr></table>
<table><caption>Table 11: Interoperability issues</caption><tr><td>I-26</td><td>Dynamic networked organisation</td><td>Too often, interoperability is addressed for a one to one application collaboration, when it should be addressed in a more holistic way as collaboration in a dynamic network of interconnected applications, used in networked enterprises and realized by software systems distributed in interconnect networks of machines.</td></tr><tr><td>I-27</td><td>Process interoperability issue related to synchronicity</td><td>A problem for interoperability between running instance of processes is to be able to synchronize activities in terms of provided outputs from the activities of one process being awaited and expected as inputs from activities of another process, with the appropriate sequences.</td></tr><tr><td>I-28</td><td>Assessment of PLM standards and Testability of their implementation</td><td>Enterprises don't know how to specify interoperability from the business cases they have to support, making it impossible to plan testing and to qualify their collaboration chains.</td></tr><tr><td>I-29</td><td>Cross life cycle interoperability involving production and support</td><td>Most of the time, Interoperability for Product Lifecycle management is not addressed simultaneously and holistically by design office, production and customer support, leading to silos preventing the expected interoperability, within companies and within standardisation activities</td></tr><tr><td>I-30</td><td>Silos between Production and Design offices</td><td>Design offices and Production are not considering the Product from the same perspective, creating silos between PLM related solutions and standards.</td></tr><tr><td>I-31</td><td>Flat semantic models not suited for modular modelling of composite systems</td><td>Semantic web technologies are not supporting properly the ability to deal with modular modelling of composite systems, as relying mainly on classes, properties and individuals. It is consequently not suited when willing to address structural interoperability</td></tr><tr><td>I-32</td><td>System models not suited for semantic preservation</td><td>Containments, being for structuring models (modules, packages) or for modelling systems (model element as container) are depicting implicit links without the ability to associate any business semantics concerning the relation between the container and the elements it contains</td></tr></table>

Some of the issues are quite obvious, well known and already described within the literature.

Some are particularly important when dealing with the PLM interoperability topic.

It is the case for:

1. The preservation of the semantic when using multiple formalisms, being for exchange of data between applications or for the chain of tools used in a model driven approach (I-01)

2. The multiples dissociated organisational, knowledge domains, applicative or technical boundaries which are usually not considered together (I-03)
3. The non-alignment of identifications, decompositions and types resulting from the previously mentioned boundaries, but also from the multiple viewpoints of the different stakeholders with their particular viewpoints and concerns (I-04)

4. The application development logic which very often doesn't ensure interoperability by design (I-05)

5. The sliding of formalism usage from their original phase of the life cycle of software system development to usage in operation. It is the case for conceptualisation languages which are used for Knowledge Management Systems or of modelling languages which are becoming executable in Business Operational Environments (I-16)

6. The impact of COTS parameterization, which is usually insufficiently considered. The interoperability to be considered is the one between applications, which results from the deployment in a specific business and computing context. Such deployment requires parameterization which constraints usage and behaviour of the software systems realizing the applications. It means that achieving operational interoperability is not only on the hand of software vendors, but also the concern and the responsibility of the support functions of the enterprise in charge of the governance, specification and usage of the application components and of the data assets (I-017). The fact that legacy components are not considered by conceptual interoperability frameworks. Most of the frameworks are considered standalone, without considering that other frameworks were used for legacy systems, or that several frameworks may be used within a company or within the extended enterprise. So these frameworks don't respond to the need of mastering the evolutions or the heterogeneity (I-18)

7. The non-alignment between textual and graphical representations for several visual modelling languages. Graphical representations only provide views on the actual models, and are not suited for being interpreted by computers. So any information provided by a visual representation must be an explicit part of the underlying model and of its computable representation, which is most of the time textual when dealing with data exchange in order to be also readable and interpretable by people. In the reverse, visual representations should not induce false interpretation of the underlying model. This is not the case for several standardized languages or for visual modelling solutions implementing these languages

8. The insufficiently considered federation of systems when having to deal with PLM interoperability. Each organization having to share product and process data with a PLM context being autonomous, techniques and approaches for the integration of applications and software are inappropriate but often used (I-21). In the approach proposed by the Federation of Interoperability Framework, the issues are not necessarily scientific gaps requiring research activities for the progress of the State of the Art, but also some practices leading to non-interoperability and having to be solved by improving the state of the practice. If both the state of the art and the state of the practice have to be addressed jointly, some particular issues have been the starting point of dedicated research projects, thesis or research activities which contributed and will contribute to the evolution of the State of the Art.

9. The preservation of the semantic (I-01) was initially addressed by the thesis "Interoperability of Enterprise Technical Applications", with a proposed innovative approach: the Extended Hypermodel for Interoperability [20] [P27], described in Chapter 4, and then regularly improved in order to address its limitations.
10. Data exchange implying not only translation but transposition (I-22) was raised during the SEINE project aiming at specifying a PLM Hub based on open PLM standards. It is illustrated in Figure 11. When considering , for a given product, its structure defined in the Product Data Management (PDM) system of an Original Equipment Manufacturer (OEM), and an equipment provided by a Sub Contractor of level 1, which is by itself a product defined in a dedicated Product Data Management B, the decomposition tree of the equipment within the Original Equipment Manufacturer's Product Data Management system is a view of the equipment tree within his specific context resulting from a transposition and not only from a language translation. It implies several operations such as export in a neutral language (operations 1-2), fusion with transposition in the Original Equipment Manufacturer context in the neutral language (operation 3) and then import/export operation with translation between the neutral language and the language of the Product Data Management system A (operations 4-5). So Product data exchange can't be reduced to a simple language to language translation. In the research project SEINE, the neutral language was the one of the Application Protocol 214 ("Core data for automotive mechanical design processes") Reference Model (RM) of the STEP standard.

<figure><img src="image_15.png" /><figcaption>Figure 13 Data exchange implying not only translation but transposition</figcaption></figure>

11. Decoupling of security and interoperability (I-24) motivated the work performed for the CRESCENDO project, and was extended in IMAGINE. The description of proposed security features is part of Chapter 3.

12. Interoperability, which is too often addressed for one to one application collaboration (I-26), was mainly addressed by IMAGINE and led to considering standardized application protocols as a Dynamic Manufacturing Network protocol. This is described in chapter 4. IMAGINE also addressed the issue (I-30), by studying how to assess and test combined
usage of standards dealing with Enterprise-Factory integration and those dealing with
Product Data Interchange (SIP and [20]).

13. Process interoperability issues related to synchronicity (I-27) motivated the thesis "A formal framework for Process Interoperability in Dynamic Collaboration Environments" with as scientific outcome several research articles on the proposed formal framework and contribution to IMAGINE and SIP.

14. Missing approach for the assessment of PLM standards and Testability of their implementation was observed in several PLM Hub projects (<u>Phenix</u> and <u>BoostAerospace</u>), and identified (I-28).

It is a major issue when expressing the interoperability needs and specifying the expected
solutions precisely enough for

1) Driving the implementation of standard based services and interfaces with clear and detailed enough specifications;

2) Being able to defined and plan tests of unitary solution components and of integration tests between the applications realized with these solutions.

Performed state of the art and state of the practice demonstrated that no accurate methodology was available for supporting accurate assessment of PLM standards for supporting required end to end collaboration processes for PLM within a networked organisation, and for specifying properly what is expected from vendors of solutions, and consequently for planning and realizing unitary and integration tests. As a consequence, vendors are interpreting and redefining requirements in a way that doesn't correspond to the expectations and leading to non-interoperability. This issue motivated the launching of the Standard Interoperability research projects, with as research outcome the Interoperability Testbed and related scientific articles. This is developed in chapter 5.

**2.5 - Conclusion**

In the considered business context, i.e. manufacturing domain taking advantage of
information and communication technologies and the Internet, interoperability is mandatory
for supporting PLM, continuously evolving model based practices, and more and more
connection between the products and the systems supporting them at each phase of the
lifecycle of the products.

After defining precisely what is the required interoperability between technical enterprise
applications for PLM and reviewing the various legacy enablers resulting from important and
continuous research efforts, the actual needs for preparing and building the expected
continuous operational interoperability at an acceptable price are far from being covered, as
demonstrated by the various interoperability issues which have been continuously collected
and addressed by the research activities described in chapter 1.

Within an evolving environment where complexity is continuously growing, interoperability issues have been collected, pointing out the need for an innovative strategic and holistic long term approach combining the legacy interoperability enablers a federated way and the governance of the research and standardisation activities in order to achieve the targeted interoperability.

The Federation of Interoperability Frameworks is such an approach. It is described in the
following chapter.
# Chapter 3 - Federation of Frameworks

## 3.1 - Proposed Federated Interoperability Framework Motivation

The Federation of Interoperability Frameworks (FIF) that I proposed aims at preparing and building a continuous operational PLM interoperability at an acceptable price, despite the continuously changing context for Business practices and Information and Communication Technologies.

The approach was proposed after assessing the outcome of research projects addressing Interoperability of Enterprise Application (in particular ATHENA and IDEAS) and PLM interoperability (in particular RISESTEP and SAVE) addressing the exchange and sharing of digital mock up units within the extended enterprise based on joint usage of open standards for distributed software systems and for manufacturing data exchange and sharing.

By federating legacy interoperability standards, models and platforms, the proposed approach allows a digital business ecosystem collaborating on a given product to prepare and build the expected continuous interoperability between the applications supporting the development processes of this product.

The performed state of the art and state of the practices demonstrated that this need wasn't addressed - or only partially - by overlapping, redundant and incompatible solutions not designed for addressing the long term PLM needs, such as long term data retention with semantic and context preservation.

Another motivation for this approach is to identify actual scientific gaps which are to be addressed in order to achieve the expected interoperability, and to be able to integrate and to validate the proposed component solutions in the context where they have to be delivered, deployed, integrated, tested and used as part of global framework and working environment, while decommissioning the deprecated parts which are not of use anymore.

For such a reason, the approach includes the support of innovative processes allowing to define, to design and to generate collaborative platforms which will be required for communication, experimentation and demonstration of the business cases to be supported for research, standardization and operational PLM projects. The experimental platforms include an operational PLM working environment, but also all the capabilities for developing and sustaining this environment for long term duration, going beyond the duration of each research project duration or life duration of the used components.

## 3.2 - Federation of Interoperability Frameworks Principles

The interoperability enablers considered are those defined by ATHENA, i.e. Enterprise modelling, Ontology, Model Driven Architecture and Service Oriented execution platform. They are extended by the relevant open international standards related to PLM and contributing to the interoperability it requires. The considered standards distributed per domains are given by the Table 9. It is considered that mature open standards are those which come with both freely available and open source implementations of industrial quality - what we call a commodity on the web - and Commercial of the Shelves (COTS) products. As a consequence, Open Source is also considered as an interoperability enabler, as it contributed to building the maturity of an open standard [P28].
The Federation of Interoperability Frameworks consists in:

1. Qualifying the expected ideal system relying on the legacy Interoperability models

Considering the different legacy models for interoperability, the characterization of an ideal collaborative PLM system, which can be considered as an Ultra Large Scale System, is the following:

<table><caption>Table 12: federated usage of Interoperability models</caption><thead><tr><th>Characterization of ideal collaborative system</th></tr></thead><tbody><tr><td>NC3A: Seamless exchange of information</td></tr><tr><td>LISI: distributed information systems</td></tr><tr><td>OIM: collaborative organizations</td></tr><tr><td>LCIM: semantic integration</td></tr><tr><td>MITRE: semantic integration with loosely couple technologies and asynchronous communication</td></tr><tr><td>IMM(s): adaptive and continued interoperability with evolutionary decision, information and physical systems; mature selected architectures of references</td></tr></tbody></table>

2. Identifying the causes of non-interoperability, called brakes as they prevent the establishment of the expected continuous operational interoperability. It includes but it is not restricted to scientific gaps. A list of interoperability brakes, which is extensible by nature if willing to take into consideration the continuous evolution of business practices and technologies, is provided in table 11.

3. Identifying the interoperability principles to be applied: in order to respond to the set of identified issues which prevent to obtain an effective interoperability of technical enterprise applications within an eBusiness environment, a set of principles are to be defined for defining the interoperability framework to be applied in a mature digital business ecosystem. For PLM interoperability, 10 principles were identified which have to be considered in the "Interoperability of Technical Enterprise Interoperability thesis", depicted in Figure 14.

<figure><img src="image_16.png" /><figcaption>Figure 14: Federation of Interoperability frameworks principles</figcaption></figure>

4. Identifying the scientific gaps to be solved in a way that the proposed innovative solution can be integrated within the FIF, responding to the interoperability needs in a holistic way as part of a global solution.

The Federation of Interoperability Frameworks has been defining principles to be considered when dealing with PLM. It includes:
a) the usage of a holistic model driven approach based on "projection" of enterprise models on service oriented execution platforms;

b) the reuse and continuous transformation of legacy applications, technologies and standards;

c) the systematic reuse of standards based software components available as commodities on the web, and of formal business models of reference;

d) the systematic inclusion of the standards in a model driven engineering approach leading to project models on execution platforms;

e) the support of bidirectional model transformations which are required due to the continuous evolution of each application environment and consequent iterative projects;

f) the usage and aggregation of the different relevant architectures of reference for the operational execution platforms and their modelling and development environments;

g) the usage of graphical representations aligned conceptually with the formal language dedicated to modelling, for handling the complexity of the considered systems of systems and supporting the communication between the different stakeholders and automates;

h) the usage of reference models based on generic standardized meta-models;

i) the shared usage of appropriate standardized generic processes for establishment of collaborative infrastructures;

j) the consideration through governance activities of lifecycle and evolutions of the used enabling standards.

For continuous improvements, extensions, adaptations and innovation, the FIF approach is iterative and the FIF was designed in order to be evolutionary. The adopted iterative approach is described in the next section.

## 3.3 - Federation of Interoperability Frameworks on long term

FIF aims at addressing interoperability needs for PLM, i.e. continuous interoperability on a long term duration exceeding the lifetime of used Information and Communication Technologies and the lifetime of the organization and of their processes for developing a product. It also means that many disciplines and industrial domains are concerned; leading to a complexity and to a functional coverage exceeding what can be addressed by a single project, in particular if willing to address all the identified issues. However, the enterprise application interoperability community is considering that interoperability requires adoption of a holistic approach. In addition, the interoperability standards, the models and platforms the FIF is federating have their own durations of life which are to be considered, even if quite longer than those of organisations and Information & Communication Technologies.

For all these reasons, the Federated Interoperability Framework was designed having in mind a continuous long term activity, which consists in successive research, standardization and operational projects covering together the full innovation cycle from the first new idea to the operational usage and to the best shared best practices at an international level. The approach is also a modular approach, allowing delivering results from ideation to standardization, with successive deliverables and reusable solution components (standard, software solution component, application component, business process, methodology, etc.) which can be aggregated together and reconfigured dynamically according to a changing context. It should also support deprecation of some components and replacement by alternative solutions.

Doing so, it allows to mimic the situation of an actual enterprise digital working environment which is continuously transformed and to study principles and approaches for continuous reconfiguration and evolution of a working environment within a changing context.
The resources allocated to the projects being limited compared to those allocated to the industrial projects. Hence the combination of enterprise modelling, service oriented execution platform and model driven engineering relying on free open source solutions based on open standards allows to define and to generate automatically experimental collaborative platforms quicker and with less resources, in order to support the research and the demonstration of its results. With the FIF approach, cPlatform can be reused, improved, extended and adapted for each project. Using the FIF approach allowed to produce successive versions of the cPlatform, each being dedicated to specific functional topics, interoperability aspects, PLM phases or discipline. Each participation to a project aimed at addressing an identified critical interoperability brakes, at contributing to the state of the art concerning some interoperability topics and at assessing, extending and improving the Federated Interoperability Framework.

Despite the changes and the long term period, the approach remains the one initially defined despite the continuous changes of used technologies and context of usage. Such evolutionary nature, with ability to incremental changes and low cost, preserving interoperability, is what is expected for PLM interoperability. This evolutionary nature plus other expected qualities can be demonstrated by considering the successive projects where it has been applied. They were the opportunity to apply and to demonstrate research results within a continuous innovation cycle, with a continuous adaptation of the FIF to the successive emerging interoperability needs and challenges associated to the evolution of the Computer Aided Product Development practices and of associated secured digital collaboration.

Figure 15 provides a timeline of the successive projects which contributed to the development of the FIF, with the successive versions of the cPlatform. It also indicates the thesis on Interoperability [20] and the assessment of usability of the Federated Interoperability Framework for Virtual Manufacturing (VM) and Cyber Physical Systems (CPS). If considering the business context as depicted in chapter 2 and this timeline, it demonstrates that the projects, relying on the FIF, were able to cover the successive innovative transformations of the manufacturing industry, from replacement of handmade drawings by computer aided drawing to the usage of digital twins with cyber physical systems.

<figure><img src="image_17.png" /><figcaption>Figure 15: FIF and cPlatform timeline</figcaption></figure>

Figure 16 indicates the successive PLM standards and related technologies which have been considered by the research related to the FIF before 2009. Table 9 provides all the standards
which have been used, analysed or assessed by projects using the Federation if
Interoperability Frameworks from 1997 to 2021. It demonstrates that the projects, relying on
the FIF, were able to cover the evolution of PLM standards based on the successive
interoperability related technologies as each project was able to deliver results improving both
the state of the practice and the state of the art concerning PLM standards based
interoperability.

<figure><img src="image_18.png" /><figcaption>Figure 16: PLM standards timeline</figcaption></figure>

If considering the Information & Communication Technologies used for producing the
cPlatform required for each project, the FIF provided the approach for the continuous
evolution, improvement and extension of the cPlatform for adaptation to the evolving context.
This can be demonstrated by comparing the successive architectural definitions of the
cPlatform described in the next sections.

3.3.1 - cPlatform Version 0

The initial version of the cPlatform was created during the ATHENA project, in order to
respond to some identified risks concerning the availability of a demonstrator to use, exploit
and extend after the end of the project. Such a situation was faced in previous projects
(RISESTEP, SAVE) with as a consequence to restart from scratch all the prototyping already
performed, leading to an important waste of time and resources when willing to focus on the
main research topic. In addition, the technical choices made by solution providers were not
aligned with the business expectations and requirements, in particular for the requirement
related to the usage of PLM standards providing application protocols, or for the usage of
standardized interfaces for distributed applications or systems.

So the idea was, relying on ATHENA principles and enablers, to produce an experimental
platform for Networked Product Development, i.e. development of a Product by a network of
organisations. The building blocks identified are open source free software products implementing relevant open standards and of sufficient quality for building easily a demonstrator. This is illustrated by Figure 17.

By relying on the Java implementation of the Common Object Request Broker Architecture Component Model [CCM], the idea was to use an application server on top of which the business logic, derived from PLM standards, will be deployed using a model based approach. CPlatform version 0 was more a specification than an actual platform.

<figure><img src="image_19.png" /><figcaption>Figure 17: cPlatform v0 architectural description</figcaption></figure>

### 3.3.2 - cPlatform version 1

The cPlatform version 1 was produced after assessing in the project OpenDevFactory how to take advantage of an open source free Model Driven Architecture generation platform, AndroMDA, supporting generation of business logic on top of an application server supporting the Enterprise Java Beans (EJB) specifications. Universal Description Discovery and Integration (UDDI) components and LDAP components were removed, and an Enterprise Service Bus was added, as illustrated in Figure 18.
<figure><img src="image_20.png" /><figcaption>Figure 18: cPlatform v1 architectural description</figcaption></figure>

In terms of model driven approach, the application protocols to be supported were used to derive the business logic in the MDA platform, including business objects and Creation/Remove/Update/Delete service for people.

It generates automatically the user interface, object model, interaction sequences with the user, persistence in a database and remote access through web services for other applications. Figure 19 reflects how the model logic was created in AndroMDA, including front end use cases, business services and business objects. It also describes the targeted execution platform: a single application server node, the organisation of business logic model and what is derived from the in terms of platform independent model and finally the application platform connected to a PLM collaborative hub through an enterprise service bus.
<figure><img src="image_21.png" /><figcaption>Figure 19: cPlatform v1 Business Logic and Execution Platform</figcaption></figure>

Fig 17 illustrates how an interaction diagram, using a modeling profile called BPM4STRUTS, was derived from a BPMN process describing usage of the PLM. From this derived model, it was possible to generate the screens and the navigation between screen for running the described process

<figure><img src="image_22.png" /><figcaption>Figure 20: cPlatform v1 model generated interactions</figcaption></figure>
### 3.3.3 - cPlatform version 2

An important feedback from business concerning the proposed solutions was related to insufficiently considered security for being able to collaborate over the web. Indeed, ATHENA partners considered that the security was not inside the scope of the research project. Secured collaboration was addressed through the Crescendo project, in order to address the issue I-24. The required infrastructure was virtualized on a physical machine on the Internet (Machine as a service), where several virtual machines were deployed in order to simulate a multi-server architecture, in order the cPlatform to be deployed out of the private information systems (back end) of the collaborating organizations (Figure 21).

<figure><img src="image_23.png" /><figcaption>B-Virtual Physical architecture</figcaption></figure>

<figure><img src="image_24.png" /><figcaption>C-Immersion within architecture of the virtual collaborating ecosystem - example</figcaption></figure>

<figure><img src="image_25.png" /><figcaption>Figure 21: cPlatform v3 virtualization</figcaption></figure>

An Enterprise Portal Server was used to virtualize the collaborating organization, hiding the actual distribution of systems realizing the applicative components realizing the enacted services. The proposed architecture addressed the security:

1) at the physical layer, by using secured machine as a service plus the operating system secured communication capabilities such as firewall and appropriate network parameterization

2) at the business layer through role based access to the applicative and informational resources supported by an enterprise horizontal portal supporting portlets open standards (cf. Table 9), and connected through and Enterprise Services Bus implementing enterprise service bus open standards to the different servers realising the applicative services (Figure 22). The
access rules between the layers had to be aligned according to the security policy to be applied.

<figure><img src="image_26.png" /><figcaption>Figure 22: cPlatform v3 virtualization</figcaption></figure>

### 3.3.4 - cPlatform version 3

In order to address the issue 26, the cPlatform V3 extended the previous one, by providing complementary functional and applicative building blocks related to management of the Dynamic Manufacturing Network services, which aims at defining the profiles of each enterprise partners being member of the collaborative networks, in terms of delivered services and supported application protocols for exchanging or sharing product and process data.

The cPLM workflow was the object of the development of a complementary demonstration component, SharkIne, dealing with the interoperability of processes in terms of synchronisation of collaboration points between private processes of each partner to be connected for an effective collaboration. This was based on the master thesis "A formal framework for Process Interoperability in Dynamic Collaboration Environments". Figure 23 provides the applicative architectural view of this version of the cPlatform, while Figure 24 completes this view with the used open standards and the functionalities delivered by the additional components.
<figure><img src="image_27.png" /><figcaption>Figure 23: cPlatform v3 applicative architectural description</figcaption></figure>

A complementary component aiming at supporting data integration based on semantic web standards was added to the previous version of the platform. The function of this component is to integrate heterogeneous data hosted by the different application servers in order to be consumed by the DMN services.

<figure><img src="image_28.png" /><figcaption>Figure 24: cPlatform v3 applicative with used open standards</figcaption></figure>

There was no progress in terms of Cloud infrastructure or concerning the adopted model driven approach for this version of the cPlatform.
### 3.3.5 - cPlatform version 4

When applying the results of the ATHENA project on operational projects related to PLM harmonization, a missing approach for the assessment of PLM standards and testability of their implementation was identified (I-28).

The cPlatform V4 (Figure 25) extended the previous version providing complementary services in order to be able to assess a PLM standard.

It was done first by checking that the collaborative process which implements this standard is accurate for the support of the business needs.

It is performed by enacting this process in a collaborative process orchestrator which distributes the tasks between the business actors and the different application components implied in the collaboration scenario.

In this phase, application components are realized by open components of reference generated in order to implement the standard in full compliance for a targeted level of compliance.

They can be available on the shelves, or generated automatically using a model based approach. During the process, test data sets and business scenarios are produced and stored, which will be reusable when willing to test actual COTS or applications which will replace one or several reference component in order to test if it can play the same role in the collaboration digital process, demonstrating its compliance to the standard but also its ability to cover the targeted collaboration scenarios previously formalized and validated by the business.

<figure><img src="image_29.png" /><figcaption>Figure 25: cPlatform v4 architectural description with test services and repositories</figcaption></figure>

The automated generation of reference components reuses (Figure 26) the model based approach defined by the FIF, projecting the business logic defined by the PLM standards on execution platforms. In this new version, the technical infrastructure and the organizational
contexts are also modelled, relying on ArchiMate and extending the DMN profiles as defined in IMAGINE. They will be used in order to generate automatically the targeted infrastructure and parameterization of role based access to applicative services and data relying on virtualisation technologies.

<figure><img src="image_30.png" /><figcaption>Figure 26: cPlatform v4 Model based approach</figcaption></figure>

In terms of building blocks, the virtualization solutions for the business context is the same as in the previous version in terms of horizontal enterprise portal, and was extended with a machine and network virtualization system (realized with Proxmox as free and open source system) for virtualization of the machines and of the network (Figure 27).

Compared to the previous version, usage of Cloud technologies was extended, with the potential usage of a cluster of physical machines, and the ability to define a distributed network of networks simulating actual interconnected information systems across several companies, with the possibility of implementing the security policies of each of them. This is particularly important if willing to assess the impact of heterogeneous security policies on interoperability.
<figure><img src="image_31.png" /><figcaption>Figure 27: cPlatform v4 Architectural view of virtualisation solution</figcaption></figure>

**3.4 - Analysis and conclusion**

The fact that the considered projects were able by using the FIF approach to produce these successive versions of the cPlatforms - supporting the evolving needs and context to be covered for PLM interoperability - demonstrates the evolutionary nature of the FIF and the accuracy of the proposed approach.

The adopted architectural principals support reusability, and allow the easy reconfiguration and extension of the platform in order to support the various business and technical scenarios to be considered in the various research projects where the FIF has been used. They also supported the establishment of the continuous interoperability required by PLM at an acceptable price.

By combining 1) a model based approach for projection of business logic on top of an execution platform 2) usage of open source free components implementing open standards 3) the ability to model and to simulate the collaboration context and to reuse the different produced components over the time, the approach demonstrated to be cheaper and effective for a given project and on long term than approaches based on proprietary solutions, business models for data exchange or sharing protocols provided by vendors. As an illustration, the SAVE project, with a duration of 26 months and a budget of several millions of Euros allows to produce a demonstration without reusable prototypes for 14 business objects. Using the FIF approach and cPlatform during the SIP project, only a few weeks were needed for developing
a demonstrator and a testbed for more than 900 objects, with reusable components for testing applications in context or software product solutions in terms of interoperability.

Further assessments have been performed in order to apply the FIF and to extend the cPlatform for supporting the assessment of PLM standards related to Virtual Manufacturing, Cyber Physical Systems and Industrial Internet of Things [P00].

All the interoperability issues mentioned in Table 13 were addressed simultaneously, by combining the different enablers and selecting the appropriate interoperability solutions in combination.

<table><caption>Table 13: Federation of Interoperability Frameworks outcome</caption><tr><td>Associated publications</td><td>P00, P27_37</td></tr><tr><td>Related Projects</td><td>RISESTEP, SAVE, IDEAS, ATHENA, CRESCENDO, IMAGINE, SIP, OpenDevFactory, SEINE</td></tr><tr><td>PhD and master 6 student supervised</td><td>Malik Khalfallah, PhD, Emna Moones PhD, Olivier Demarez, David Hasson, Jonas Martin, Ludovic Duchemin, Sophie Gatoux</td></tr><tr><td>Demonstrators</td><td>cPlatform, JawIne, SharkIne, ArchiMagIne, STEP Mapper, Software Factory, etc</td></tr><tr><td>Addressed Interoperability Issues</td><td>I-02, I-08, I-10, I-13, I-14, I-18, I-21, I-23, I-24, I-25</td></tr></table>

However, many interoperability issues are not addressed by Federation of Interoperability Frameworks itself, and are requiring complementary improvement of the state of the art.
# Chapter 4 - Semantic Preservation

## 4.1 - The problem

Using the PLM standards for exchanging, sharing and archiving the manufacturing Product & Process between applications, or using the model based approach with the successive bidirectional transformations from Computer Independent Model to Execution platforms, an identified issue constituting and actual research gap is related to semantic preservation and data loss (I-01).

Indeed, due to the fact that used languages don't have the same expressivity and don't rely on the same paradigms (e.g. object oriented language versus procedural language) or terminology (a same concept can be expressed by different terms), it is consequently not possible to establish a one to one equivalence between all the modelling constructs of the languages from which bidirectional transformation can be implemented. As a result, some data are not translated and consequently lost during the considered processes. Figure 28 illustrates this issue for exchange of data between applications through a neutral model and during model transformations starting from an application protocol formalized with the Express language to the UML language for application design to Java and XML for implementation of application components and operational data exchange.

<figure><img src="image_32.png" /><figcaption>Figure 28: Data loss illustration in PLM and Model Driven Engineering processes</figcaption></figure>

So the goal is to find an innovative way for preventing or mastering the data loss and preserving business semantic between the models used by the different platforms, being conceptualization, design, development or execution. It should also preserve the business semantic between the different applicative components used inside a single application, such as database, application server or presentation server, or several federated applications. This issue is a key issue because it is not possible to obtain pragmatic interoperability by applying previously defined principles, if the semantic preservation is not insured.

As a constraint, it should make it possible to use jointly legacy standardized languages and interoperability frameworks, being at conceptualization, modelling, design, development or execution phases. In addition, when using a model driven approach, it should be possible to trace, to link and to make coherent the different representations of used business concepts and
objects, between the different digital artefacts produced during the lifecycle of an application. Usual bindings and mappings, proposed by the different communities, are far from being sufficient: they don't avoid loss of information and they are restricted by technological silos, incompatible paradigms and organizational boundaries.

## 4.2 - The proposed innovative approach

The innovative proposal for addressing this problem is the extended hypermodel for interoperability. The starting point for extended hyper models is to consider that, for a given business concept, it does not matter for the user if it is formalized with such or such formal language. We have simply different representations of the same concepts or of the same things, using heterogeneous languages which are used with different intentions and for different purposes: data exchange, reasoning, design, programming, etc. For example, considering the “person” concept, it could be formalized within different environments based on heterogeneous languages, such as respectively the Unified Modeling Language (UML) for software design, the Ontology Web Language (OWL) for description relying on descriptive logic available for smart agent on the Semantic Web, the eXtended Markup Language (XML) for serialization of documents or EXPRESS for defining schemas used for application protocols. The used modelling constructs will be respectively a UML class, an OWL class, an XML entity and an EXPRESS Entity, with eventually different names and identifiers. But whatever the used language and construct, it remains a representation of the same concept, a person.

The idea is then to consider that it should be possible to capture the fact that this concept, modelled using such a Modeling construct within an environment, is modelled using such other modelling construct within another environment. In addition, as it still remains the same concept, a “person”, used formalism should be as transparent as possible concerning the business semantic, as interpreted by people. Referring [21] which provides clear distinction between conceptual information models and concrete instantiation models, the idea is to consider that within a model driven approach, concrete models are those used for conceptualization, design, development and execution. The glue remains the conceptual model, which will ensure the semantic preservation.

The term “hypermodel” is used within the work described by [22] and which led to software freely available on the web, “Hypermodel”33. This tool allows working on a model formalized as an XML schema, within an UML environment, and possible annotation using OWL. The same concept is “multi-represented”: it can be considered an XML entity or a UML class. It is represented as an UML class within dynamically created UML diagrams. The term “hypermodel” is also used in research related to model based learning [23] [24] and is defined as a combination of aspects of open ended exploratory tools with content-specific text and multimedia. “Hypermodel” tool is mixing heterogeneous interactive representations both textual and visual of the same subject. So a hyper-model can be considered as a multi-representation of the same model, using different formalism and media, but preserving the semantic.
"Hypermodel" as defined by [22] is limited to only three languages, which are all dealing with entities and informational viewpoints. It was not developed in order to address interoperability of enterprise applications. As the intent is to extend it to other languages and modelling constructs (services, processes) with as specific purpose PLM interoperability, the derived concept was called "Extended Hypermodel" for interoperability.

The approach considers grounds. A **ground** is a concrete environment where a model is formalized. It is constituted by a set of configured versioned software components, which ensure conformance with a given standard (versioned) providing one of the formalisms we want to consider within the hypermodel.

The approach considers landscapes. A **landscape** is a set of grounds. The landscape of a given standard is the set of available grounds enabling usage of this standard (versioned), and with appropriate conformance. The landscape of a hypermodel is the set of environments, related to the standardized languages considered by the hypermodel, which are allowing traveling of hypermodels without data loss.

The approach considers models of products and associated processes, often adopting the system paradigm. A model of a system is a description or specification of this system and its environment for a certain purpose. A model is often presented as a combination of drawing and text. The text may be in a modelling language or in a natural language.

The approach also considers that the hypermodels should be formalized using a suited mathematical representation when willing to study and to characterize different combinations of languages. Hyper-graphs were chosen. A hyper-graph is "a generalization of a graph, where edges can connect any number of vertices. Formally, a hyper-graph H is a pair H = (X,E) where X is a set of elements, called nodes or vertices, and E is a set of non-empty subsets of X called hyper-edges or links..."

While graph edges are pairs of nodes, hyper-edges are arbitrary sets of nodes, and can therefore contain an arbitrary number of nodes. However, it is often useful to study hyper-graphs where all hyper-edges have the same cardinality: a k-uniform hyper-graph is a hyper-graph such that all its hyper-edges have size k. (In other words, it is a collection of sets of size k.) So a 2-uniform hyper-graph is a graph, a 3-uniform hyper-graph is a collection of triples, and so on... Unlike graphs, hyper-graphs are difficult to draw on paper, so they tend to be studied using the nomenclature of set theory rather than the more pictorial descriptions (like 'trees', 'forests' and 'cycles') of graph theory."

A hypermodel (HM) is consequently represented as a hyper-graph, providing a multi-representation of a model using the different standardized modelling language implied within a community governing interoperability of its applications.

XM is the set of concrete constructs, specific to the formalisms aggregated by the hypermodel, allowing to model a concept or to represent a real thing. Each business concept and each real thing is represented by a subset of XM, which is a hyper-edge of the hypermodel. The subset contains all the nodes representing the concept or the real thing.
Figure 29 describes the different hyper-edges based on generic descriptive business concepts (associated to a colour), derived from ontology modelling concepts: class, property and individual. Each hyper-edge is grouping nodes which are used to represent the business concepts or real thing for a given formalism (associated to a form).

A generic descriptive business concept is a concept that is suited for providing a simple description of the real world by persons which are not computer scientists.

<figure><img src="image_33.png" /><figcaption>Figure 29: basic hyper-edge of an extended hypermodel</figcaption></figure>

It is expected that it will be possible to concretely formalize an extended hypermodel within several grounds, and to transfer an extended hypermodel from one ground to another without information loss, through an accurate set of transformation based on standardized data exchange and transformation. It is what is called a hypermodel "travelling", i.e. the ability to change place while remaining the same, like illustrated by Figure 30.
<figure><img src="image_34.png" /><figcaption>Figure 30: Hypermodel traveling between grounds</figcaption></figure>

As willing to avoid development of a new modelling language for extended hypermodels and associated grounds, legacy platforms belonging to the several federated grounds should be able to process them, being for edition, validation, completion or other automated usage. In other words, it should be possible for an extended hypermodel to be multi-represented within all the grounds constituting the landscape of the hypermodel. As a consequence, the hypermodel will be constituted of hyper edges for classes, of hyper edges for properties and of hyper edges for individuals. Between the representations of an individual in a given ground, a “same as” relation exists, each being typed according to the modelling construct used in this ground, as illustrated in Figure 31.

<figure><img src="image_35.png" /><figcaption>Figure 31: graphical representation of hyper-edges representing relationships between modelling concepts</figcaption></figure>
Once the different generic constructs have been defined, the next step will be to establish the equivalence between the different languages of the considered landscape in order to support the model driven engineering process. Once validated on several ground, it will be possible to defined different operations in order to ensure the travelling between environments.

From an existing model formalized with one language, we can realize the completion of the hypermodel by generating representation for the other languages.

From a hypermodel, we can validate that all asserted representations are correct and complete.

To make a model travel, it should be exported, transposed (file syntax and formalism changed) and then imported. For most of legacy tools, the export, transposition and translation will have to be developed.

In some cases, grounds will not provide a way to capture how the model is represented within the other grounds. In such a case, traveling will be performed by means of bidirectional translations. In such a case, it should be done on models using only the constructs for which equivalence exists, in order to avoid loss of data.

The proposed approach has been applied and assessed for the relevant standards to be considered for PLM Interoperability within the Manufacturing ecosystems, with a particular focus on European Aeronautic, Defence and Space community (Table 9).

It has been applied to data, service and process modelling languages for conceptualization, design and execution used in the successive versions of the cPlatform and covering the different business, functional and technological scopes of the research projects and activities contributing to the development of the Federation of Interoperability Frameworks, relying on the same way to represent the extended hypermodel usage context, illustrated by Figure 32. The business working environment is represented with a modelling platform through a set of Business models which federate conceptual business models based on business standards, and consider federated organizations, their applications and the underlying execution platforms realizing the applications. The models are used to generate business logic components which are deployed and enacted on the collaborative product development platform (cPlatform). By using an extended hypermodel for interoperability, each deployed component encompasses the various representations which were used to generate it, and can be queried in order to regenerate these models with supported bi-directional model transformation without data loss and with semantic preservation.
<figure><img src="image_36.png" /><figcaption>Figure 32: Extended hypermodel usage context</figcaption></figure>

Three particular relevant languages have been considered for their relevance for the proposed approach:

1) the Ontology Web Language which was designed for producing ontology on the web in order to contribute to the development of the Semantic Web, which aimed at improving the syntactic web. It is an open standard with available implementations of references, open source or Commercial of the shelves. It supports annotations and consequently platforms implementing OWL can be used as grounds for interoperability. In addition many communities have been producing knowledge representation of their domain relying on OWL. So OWL is quite relevant in the conceptualization phase of an application, but also for any application in operation publishing its data in a knowledge base relying on Semantic Web and Linked Data standards

2) the Unified Modeling Language is an open and de facto standard for software system design and meta modelling, with many open source and Commercial of the shelves implementations. It supports annotations, so it is accurate for producing hypermodels. Finally, many UML modelling platforms are based on the Model Driven Architecture defined by the Object Management Group, and can then support Model Engineering approach considering Computer Independent Model which capture the business logic, the Platform Models which capture the underlying software and hardware architecture are defined, the Platform Independent Models allowing to capture the definition of an application within the business context, and the Platform Specific Model which contextualize the application definition for the realization of the targeted execution platform, and support the automated generation of software components and their deployment on actual operational technical environment. This approach fits with the standardized enterprise architecture modelling approaches and languages aiming at defining the working environment of enterprises.

3) Java and associated development platforms. Java is one of the most used languages, and it was designed for supporting the develop everywhere and deploy anywhere objective. In
addition, the Java Development Platform provides implementation of the standards for
applications servers, with a separation of concerns between the business logic and applicative
technical services. It also supports annotations and is consequently accurate for the
hypermodel approach.

It means that relying on some on the shelves technologies which are open and de facto
standards, the innovative hypermodel approach for interoperability can be applied.

## 4.3 - Demonstrations, results and Limitations

Several demonstrators have been produced, standalone or integrated in the cPlatform, which
were also used for assessing the approach and allowed to identify some limitations.

Figure 33 illustrates the application with Eclipse Europa and EMF Papyrus as UML 1.4 ground, and Protégé 3.3 with Jambalaya and Pellet as OWL 1.1 ground, where STEP Application Reference Models (ARM) and Application Integrated Model(AIM) were imported relying on a dedicated EXPRESS/P21 transformation to OWL. As a result, we obtained ARM and AIM hypermodels allowing to generate automatically components to be deployed on the cPlatform for assessing this PLM standard and testing its implementations.

<figure><img src="image_37.png" /><figcaption>Figure 33: Extended hypermodels in UML and OWL grounds</figcaption></figure>

During the experimentations, it was demonstrated that the approach works pretty well, as soon
as dealing with flat models, like semantic graphs of models relying on the Part 21 data
description language which is a part of STEP.

It was also applied within the scope of the new STEP architecture, with the introduction of the
usage of SysML for describing, aggregating and making consistent the Application Activity
Models, Application Reference Models, Application Integrated Models and Integrated
Resource Models of the standard. In particular it is possible to propose a SysML alternative
representation of an activity model in IDEF0, preventing data loss but also preserving
semantic and usage intent. Translation can be done bi-directional way. It has been successfully extended to ArchiMate 3.1 and UML2.4.

<figure><img src="image_38.png" /><figcaption>Figure 34: SysML alternative representation of an activity model in IDEF0²</figcaption></figure>

However, several issues have been identified from the experimentation which led to new innovative proposals for improving the extended model for interoperability.

Firstly, having to consider system engineering and system modelling within a PLM context, a product is usually an assembly of components, each assembled part having its own definition and representations as a model artefact, realized by data.

It is also a system of interest, which is to be considered in different environments: market, design office, production, support and operating environments.

It implies to be able to model complex systems and the way they are composed, but also to be able to deal with all the model artefacts which have to be produced following the appropriate PLM collaboration processes.

As a consequence, the standardized system modelling languages and platforms support both the ability to provide the representation of a composite system - relying on composition and composite diagrams with representations of connected parts - and the ability to deal with composite (modular) representation of a system relying on modules, packages and associated composite data serialization.

In both cases, we are relying on containers, where no explicit links exist between a container and the elements it contains.

So it means that it is not possible to derive an explicit semantic graph capturing the exact semantic of the relations between the contained elements and the container, except “is

<footnote n="2">² https://www.linkedin.com/pulse/equivalent-idef0-sysml-models-dr-nicolas-figay/</footnote>
contained” and “contains” which reflects more the structure of the model than the structure of
the modelled system (I-31). As a consequence, we also can’t derive hyper-nodes for the
extended hypermodel for interoperability from such models and data structures.

Secondly, the ability to aggregate and compose models of the parts implies an agreement on the way to decompose the models, including the different levels of granularity to consider between the partners. It is one of the identified interoperability brakes. The extended hypermodel for interoperability is focussing on the semantic interoperability for flat semantic graphs (I-32), and can’t due to the previous limitation be a solution for unleashing this brake.

## 4.4 - Hyper-models mixing Modular Composite Models and Semantic Graphs

A way to extend the FIF in order to address the two first issues was proposed in [P01], relying on modelling over UML2/SysML and introducing mereotopology<fnref n="3" />.

Usage is illustrated with a comprehensive use case combining Manufacturing 4.0 and PLM (Product Lifecycle Management) of the future.

The idea is to be able to take advantage of the structural features of a UML modelling platform (modularisation, structural decomposition relying on packages) when modelling with any other modelling language which doesn't have such structural features (e.g. ArchiMate).

This provides a way for extending the hypermodel for interoperability in order to deal also with structural interoperability.

For a given domain specific language, we can use both produce the models for being able to model over UML2/SysML on a system modelling grounds based on these standards, and derived an ontology in OWL2 in order to be able to take advantage of semantic web grounds based on semantic web standards.

It means that we can make travel a model realized with a Domain Specific Language (DSL) between system engineering grounds and semantic web grounds, preserving the semantic of the DSL but being to take advantage of the functionalities and services which can be provided by these two technology families.

For UML/SysML2, this concerns in particular the modular and composite modelling (Figure 35), which is not supported by OWL2 technologies.

For OWL2, this concerns in particular reasoning relying on descriptive logic or on business rules, which is not supported by UML/SysML2 technologies. The approach can be extended to other kinds of technologies and associated grounds, such as those related to data analytics, big data, artificial intelligence or graph related technologies (Figure 36).

<footnote n="3">³ In formal ontology, a branch of metaphysics, and in ontological computer science, mereotopology is a first-order theory, embodying mereological and topological concepts, of the relations among wholes, parts, parts of parts, and the boundaries between parts.</footnote>
<figure><img src="image_39.png" /><figcaption>Figure 35: ArchiMate over SysML for modular and multi-language composite modelling</figcaption></figure>

<figure><img src="image_40.png" /><figcaption>Figure 36: ArchiMate Derivation in OWL2 for Knowledge Base with reasoning support</figcaption></figure>
## 4.5 - Conclusion

The associated publication is [P27]. Some identified limitations have been addressed, in particular the limitation of using graphs when dealing with complex systems of systems [P01] and limitation of systemic approach when relying on virtualization [P23].

From the last developments and experimentations related to the extended hypermodel for interoperability, new interoperability needs emerged which are not yet addressed.

It is needed to make the rules and constraints associated with models to travel consistently between different grounds, without preventing interoperability or consistency between obtained results when using them with different reasoning or checking technologies. It is particularly important when considering the raise of both Model Based System Engineering technologies and Semantic technologies with reasoning engines. The link is also to be established with new graph related technologies and standards, for taking advantage of the capabilities they provide without creating technological silos.

It provides new opportunities to use, assess and extend the proposed approach.

An identified scientific gap was also identified, when willing to build a hypermodel for linking system modelling based on SysML or UML grounds, and enterprise modelling relying on ArchiMate 3.1 modelling grounds. It is related to combined usage of systemic and virtualization. This points out some limitations of usage of the paradigm underlying system modelling when willing to address PLM interoperability, as it leads to no preservation of a system boundary across the layers considered by enterprise modelling and the viewpoints of the different concerned actors. This issue, demonstrated in [P33], is to be addressed.

<table><caption>Table 14: Semantic preservation outcome</caption><tr><td>Associated publications</td><td>P01, P27, P23, P33</td></tr><tr><td>Related Projects</td><td>ATHENA, SIP</td></tr><tr><td>Demonstrators</td><td>Derivation of ontology from ArchiMate, ArchiMate over UML model, STEP Mapper</td></tr><tr><td>Addressed Interoperability Issues</td><td>I-01</td></tr></table>
# Chapter 5 - Dynamic Networking

This section presents the contribution to the State of the Art for PLM interoperability related to the Dynamic Manufacturing Networking, for enterprises constituting Dynamic Manufacturing Networks (DMNs).

## 5.1 - The problem

When willing to put in place PLM within the digital business ecosystem working around a given manufactured product, the alignment between the different functions of the enterprise (design office, production, support, logistic) and the alignment between the partners must be ensured concerning the cross organizational processes to put in place

1) with the accurate flows of digital artefacts between the partners, their private processes and the applications supporting these private processes

2) according to the role they are playing in the cross organizational processes: Original Equipment Manufacturer (OEM), equipment provider, sub-contractor, operator, support service provider, etc.

This is illustrated in the next figure with as an example of product an Aircraft, with as considered equipment engines and nacelles provided by various equipment suppliers, and as clients operating aircraft airline companies.

<figure><img src="image_41.png" /><figcaption>Figure 37: Dynamic Manufacturing Network for a given product</figcaption></figure>

Much of the time, organizations, being partners or functions, try to impose their processes, their internal standards and their tools to the others, depending on the balance of power between them. Considering PLM, it often leads to using the proprietary formats of the software products they bought and they try to impose on their partners. Unfortunately, such behaviour brings a lot of problems, such as inefficient collaboration and creation of silos
leading to non-interoperability. What explain such a situation is the growing complexity of the software products and their high pace of change, itself due to the quicker and quicker evolution of Information and Communication technologies. As a consequence, organizations have to face obsolescence of their applications, being under the pressure of the software vendors who don't support old solutions anymore - or at a very high price - or under the pressure of the competition, which continuously innovates relying on new processes, solutions and technologies.

Considering that the life duration of many industrial products is longer than the duration of life of software technologies, PLM processes have to insure Product & Process data exchange, sharing and long term retention despite the heterogeneity of the software solutions used by the supply chain partners (level 1 to n) and on a long time period.

Standardisation bodies aim at addressing such a need by providing neutral and open processes, protocols and formats. In order to ensure they are properly implemented by software solution providers, Implementation Forums have been put in place by Industry consortia for qualifying PLM solutions in terms of interoperability, i.e. ability to exchange or share data relying on these standards considering such or such collaboration scenarios.

However, PLM interoperability is not about software products, but about the capabilities of the members of collaboration for supporting the targeted collaboration processes, i.e. the availability of qualified internal processes, people and applications for participating in open standards based collaborations. Also, implementer forums are usually dedicated to the collaboration based on a single standard, and not on a set of standards required for covering the whole functional scope addressed by PLM when willing to address cross-lifecycle interoperability, which becomes more and more important, in particular when considering the current trends related to Virtual Manufacturing, Cyber Physical System, Digital Twins or Digital Threads.

Considering the state of the practice in industry and the state of the art, qualification of active resources according to a process is addressed more by production than by design. For state of the practice, it is reflected by the "Enterprise-Control System Integration" (ISA 95/ ISO/CEI 62264), which provides a model which includes the description of a process with the definition of the participant roles and the assignment of qualified actors, being people or machines.

[25] points out the approach defined by the IMAGINE research project, which aims at establishing a Dynamic Manufacturing Network (DMN) for which partners, products, end to end processes, and quality insurance are defined by the mean of a blueprint models, a blueprint model gathering the "modularize the knowledge needed to help manage enterprise resources, product lifecycle, supply chains, partners relationships, operational planning, manufacturing process execution, compliance regulation and compliance issue for the DMN. Blueprinting will provide "intelligence" and improved visibility for an integrated supply chain in a variety of ways, e.g. including the reduction of operating costs, providing valuable new or enhanced capabilities, increased regulatory compliance, and improved alignment of operations with business goals and metrics". Blueprint metamodel is aggregating several standards, including ISA 95 (Enterprise Factory Integration) and STEP AP 236 (STEP for Furniture).
## 5.2 - The proposed innovative approach

The proposed innovative approach consists in

1. Transposing the Dynamic Manufacturing Network blueprints approach from production - as the considered Dynamic Manufacturing Network is a network of factories - to the design office (Figure 38). The physical product is then replaced by the virtual digital product, i.e. the digital definition of the product relying on various representations and models. The factories are replaced by design offices.

2. To integrate the Dynamic Manufacturing Network blueprints approach as a part of the Federation of Interoperability Frameworks for PLM as an enabler for interoperability, and delivering associated cPlatform services closely related to the model based approach promoted by and the principles provided with the Federated Interoperability Framework

3. to extend the set of relevant PLM standards to be considered by including those related to enterprise - control system integration, in order to support better end to end processes between design offices and factories. It means that the cPlatform associated with the Federated Interoperability Framework should be extended with new application components based on open standards, in particular Manufacturing Execution Systems based on the “Enterprise-Control System Integration”.

<figure><img src="image_42.png" /><figcaption>Figure 38: DMN blueprint Transposition from Manufacturing to Design</figcaption></figure>

The partner blueprints capture the organizations which are members of the network, people which are members of the organizations, the end-to-end processes which are supported for a
given set of roles, and the qualification of the partner according to these processes. It captures unique capabilities in the Dynamic Manufacturing Network of a partner to play a given end-to-end process with a given role. It includes

a) the Company Background (contact information as member of the network)

b) People (person, groups)

c) Processes (end-to-end process they can participate to with a given role for a given product)

d) Qualifications (name of standards actually supported with regards to supported end-to-end processes)

The product blueprints are based on an engineering description of the Product Breakdown, very close to the engineering bill of material that will be used later in the life cycle of an industrial project for the production orders.

The breakdown of the aircraft is based on the STEP 242, and includes product definition information, and all the design activities and associated capabilities needed for performing changes on any configuration item. It includes assemblies, parts, sub-components, equipment, configuration items, associated documents, associated file formats, needed data processor, information coverage for each file.

More precisely, it includes

a) Resource Definition Information (kind of data & software resources needed for design activities)

b) Product Definition Information (resources & segments required to make the product definition)

c) Design Schedule Information: minimizes design time and costs, by proving a design facility with information regarding what to make, when, with which staff, and on which equipment.

d) Design Capability Information (applications, methods & tools).

The end-to-end processes blueprints are Enterprise workflow models based on the XML Process Description Language for Enterprise Workflow Systems, with extension concerning qualification of expected resources based on ISA95 (Enterprise Factory Integration).

It formalizes the end-to-end processes supported by the PLM Hub:

a) Plan tasks related to change process activities (It establishes plans for the whole change activities described as follow)

b) Issue change (provide/collect issues about the product),

c) Request change (investigate how change issues can be addressed with involvement of all the concerned stakeholders)

d) Order change (order to realize the change and update consequently product data in the Product Data Management system referential)

e) Provide required data (required for being able to perform the change)

The quality assurance blueprints are capturing expected quality of end-to-end processes, of the used standards, of the actual process participants and of the Manufacturing PLM hub in terms of secured transportation process and in terms of data transformation process. It structures a collection of metrics for measuring quality of processes and associated participants for product data exchange and sharing
a) End-to-end process models (conformance class of all participants and information coverage of any information flow make possible to play the process without information change)

b) Actual process participants: all the process participants have the expected conformance class for playing one or several roles in the end-to-end process

c) Secured transportation process (all security constraints are fulfilled all along the process and all along the network)

d) Data transformation process (data transformation between specific and standardized format doesn't change the information or make it possible to be exchanged or shared).

The end to end cross organisational processes considered are the configuration management process under the control of the change management process, plus the Technical Data Package exchange.

The main concerned actors are

1) PLM Hub operators, who will have to develop, operate and maintain the collaborative infrastructure, based on the cPlatform and supporting the DMN methodology

2) Dynamic Manufacturing Network member: a Dynamic Manufacturing Network member who wants to enter the collaborative environment, to collaborate through the hub for one or several products and playing one or several roles in a set of cross organizational processes. Different sub-categories exist for Dynamic Manufacturing Network members:

a. System integrator: company specialized in bringing together component subsystems into a whole and ensuring that those subsystems function together. Usually, the sub-components are purchased by the integrator and retailed under that purchasing company's brand name. E.g. An Airbus is sold with a SNECMA engine under the Airbus name, when the original engine manufacturer (OEM) is SNECMA. Notes that an Original Equipment Manufacturer can also be an integrator, selling components of the engine which are manufactured by other companies.

b. Original Equipment Manufacturer (OEM): the OEM manufactures products or components that are purchased by another company who will integrate it in an integrated product that will be sold under this company's brand name (e.g. SNECMA, Aircelle)

c. One PLM Hub cross organizational process participant: role associated to an orchestration model of cross-organisational process, enacted on a PLM Hub. The participant can be a person, an organization or an application. The participant is usually abstract for a process model (e.g. Integrator, Original Equipment Manufacturer), and concrete when the process model is enacted (e.g. Airbus, SNECMA for the Engine of the Airbus 380 product)

In such a context, several processes are considered.

The first process to be considered is related to the PLM Hub management, and is named P0. It is subdivided in P0-1 for the set-up of the PLM Hub, P0-2 for operating the PLM Hub and P0-3 for managing changes in the PLM hub.

P0-1 consists in designing, deploying and making the cPlatform accessible to the aeronautic community over the web
P0-2 consists in operating the PLM hub, and providing support to any partner willing to enter the DMN, collaborate and eventually leave the DMN.

P0-3 consists in managing changes in the PLM Hub, as making the cPlatform evolve in terms of realization components, functionality or cross organizational processes to add or to change in the portfolio of processes supported by the cPlatform. The other processes to consider are those related to the DMN.

Collaboration processes are:

P1 - On boarding: this is the on boarding process, and is related to all the activities required to enter the DMN, including connection of legacy front-end applications to the PLM Hub.

P2 - Enactment: As soon as properly connected to the hub with appropriate implementation of standardized product and process data exchange protocols and service contract interface, the partners are ready to collaborate, running instances of the cross organizational processes connected to their own specific processes, being internal or dedicated to extended enterprise.

P3 - Leaving: If willing to leave the DMN as collaboration is not needed anymore, or because the partners want to collaborate through another PLM Hub, the process P3 is related to leaving the Dynamic Manufacturing Network. It consists in disconnecting applications from the PLM hub and removing all the blueprints of the leaving partner from the cPlatform Dynamic Manufacturing Network repositories and databases.

The demonstration has been achieved through

1) prototyping of a PLM Hub extended with Dynamic Manufacturing Network functionalities, relying on the legacy previous version of the cPlatform and applying the principles and approach developed with the Federated Interoperability Framework

2) experimentation by running collaboration scenarios on top of the living laboratory obtained through the enactment of the cPlatform on the Cloud. It included the registration of new company on the cPlatform plus the modelling and enactment of a cross organizational Technical Data Package, relying on two components extending respectively an open source enterprise workflow modeller and an enterprise workflow system engine based on open standards of the Workflow Management coalition (JaWine and SharKine)

3) modelling of a DMN relying on Enterprise Modeling based on the ArchiMate modelling language, and then derivation of the workflow processes on an Enterprise Workflow System including modeller and engine extended with Dynamic Manufacturing Network features. A dedicated ArchiMate modelling client was developed as an Enterprise Portal portlet with a controlled access to the different views of the Dynamic Manufacturing Network filtered by mean of roles and predefined viewpoints

## 5.3 - Analysis and Conclusion

What was demonstrated is

1) the relevance of the Federation of Interoperability Frameworks approach for preparing and building continuous operational interoperability at an acceptable cost in a changing environment by relying on the cPlatform, which was easily reconfigured and extended with Dynamic Manufacturing Network functional and applicative components
2) The accuracy of the approach for qualifying the members of a Dynamic Manufacturing Network and for progressively extend and improve the set of collaborative cross organisational processes which can be run by the Dynamic Manufacturing Network members

3) the relevance of using the ArchiMate Enterprise Modeling language as a way to aggregate the different Dynamic Manufacturing Network blueprint templates in order to give an holistic view of the Dynamic Manufacturing Network state, including members of the Dynamic Manufacturing Network collaborating for a given product typed according their role and the parts or configuration items they are working on, the processes they are participating to - cross organizational or private-, the applications supporting these processes and the technology realising these applications. It corresponds to what is called a Dynamic Manufacturing Network within the Federation of Interoperability Framework context.

The obtained results from this experiment were

1) The proposal of a new and innovative concept, the Dynamic Manufacturing Network within the scope of Federation of Interoperability Frameworks, suited when willing to deal with PLM interoperability and for extending the FIF and associated cPlatform. The related scientific publications are P05, P07 and P14;

2) the opportunity for studying the introduction of manufacturing production standards in the set of PLM standards to be used for cross lifecycle interoperability supporting end to end processes including design office and production;

3) the opportunity for assessing the extended hypermodel for interoperability by including ArchiMate models as one of the representations to consider for a Product or of a Dynamic Manufacturing Network;

4) business cases and a problematic related to process interoperability within a Dynamic Manufacturing Network, which was the opportunity to launch the thesis "A formal framework for Process Interoperability in Dynamic Collaboration Environments";

5) through introduction of ISA 95 (Enterprise Factory Integration) standard, the opportunity for defining business cases and a problematic related to PLM interoperability relying on ISA 95 and to launch the thesis "Proposal of a methodological approach of multi-level interoperability in a collaborative PLM environment";

6) the opportunity to study impact of autonomous networks underlying the cPlatform, through a collaboration with LAAS and two PhD students;

7) the opportunity to start investigating PLM interoperability needs for virtual manufacturing, Cyber Physical Systems and Digital twins.

In terms of limitations of the results, what came out from their assessment is

1) when considering the FIF extended with the Dynamic Manufacturing Networking, an important issue is still not addressed, concerning the missing approach for assessing if a standard is relevant to support a given process and for derivation of the test plan for qualifying applications or software products.

2) no open source implementation of reference exists at this stage for ISA 95. It raises the question of interoperability of standards which are not mature enough.

3) the way the cPlatform deals with cloud and virtualisation is reaching some limits being for managing living labs based on the cPlatform, or considering the emerging Cloud infrastructure as a service
The FIF extended with the Dynamic Manufacturing Networking, and the associated version of the cPlatform, provided an excellent starting point for addressing the scientific gap related to missing test based approaches and for extending the scope of PLM interoperability to applications and standards supporting production and the collaboration with design or support. It was addressed through the SIP project, and the related scientific contribution, the PLM Interoperability Testbed, is developed in the next section.

<table><caption>Table 15: Dynamic Networking outcome</caption><tr><td>Associated publications</td><td>P00, P01, P02, P03, P04, P10, P12, P15, P16, P17, P18, P19, P21, P22, P23, P25, P29, P36</td></tr><tr><td>Related Projects</td><td>IMAGINE</td></tr><tr><td>1 PhD supervised and collaboration for supervision of 2 others PhDs</td><td>Malik Khalfallah, Code Diop and Aymen Kamoun.</td></tr><tr><td>Demonstrators</td><td>cPlatform with extension for DMN based on SharkIne, JaWine and ArchiMagine</td></tr><tr><td>Addressed Interoperability Issues</td><td>I-21, I-26</td></tr></table>
# 6 - The PLM Interoperability Testbed

## 6.1- The problem

Considering the Return on Experience (REX) from IMAGINE and PLM harmonization program at Airbus, some difficulties were encountered concerning the deployment and effective usage of PLM standards within a DMN, the identification of business value from using a PLM standard, the ability to assess the alignment of a given PLM standard with the targeted collaboration or the ability to specify how standards have to be implemented by software solution providers in a way they can be tested as the realization of an application of a DMN. It constitutes an important brake to be addressed when willing to prepare and to build continuous operational interoperability based on open PLM standards at an acceptable price.

Indeed, considering both the state of the art and the state of the practice, no relevant approach exists for addressing such a need, but only partial solutions addressing a subset of the needs.

It is in particular the case of the best practices produced and applied by the European Telecommunications Standards Institute (ETSI) for solving the challenge of interoperability [36].

> "It concerns the specification and validation of base standards and the development of test specifications related to the technologies considered by the ETSI. The techniques are pragmatic (for example, validation of standards through interoperability events) as well as technical (for example, the use of languages ... to define test scenarios). They have the added benefit that these techniques are applicable well beyond the world of standardization. Good practice started in standardization can be carried through into proprietary development processes. The ETSI experience is that the application of these best practices does indeed help to develop interoperable standards, which in turn leads to interoperable products."

However, it addresses more the interoperability at the technology layer while PLM interoperability concerns simultaneously organisational, applicative and technological layers. [28] Proposed a manufacturing B2B interoperability testbed, which was too closely related to XML technologies. In association with some standards such as the UML Model Language or the Business Process Modeling Notation, some Model Interchange Working Groups have been set up producing test data sets and testing campaigns for qualifying software products ability to interchange models. Many standards, in particular STEP, have been coming with parts dedicated to certify the conformance of software solutions. However, about no vendors accept to be certified, even if some of them accept to participate in the Implementor forum, driven by associations or institutes (GALIA, AFNET, PROSTEP, AIDIMA, NIST, etc.) and under the pressure of industry (Automotive, Aeronautic Automotive, Furniture, etc.). Here again, the focus is more on model interchange and technologies, and adopted practices are not model based.

Also, none of the identified practices are relying on a model based automated generation of the testbed platform itself, which will reproduce the environments where the software solutions will be deployed, connected, enacted, operated and used. Some partial solutions exist for automated deployment coming from DevOps.

> "DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality."
Once again, it concerns mainly software and the Information & Communication technology layer of the working environment of an enterprise. Software engineering also comes with test based development practices based on Continuous Integration, with the following workflow: running tests locally, compiling code in Continuous Integration and deploying a component from Continuous Integration. Continuous Integration solutions implement continuous processes of applying quality control.

It motivates the launching of the Standard Interoperability PLM (SIP) research project for defining an innovative approach unleashing this brake, following the principles defined by the FIF and contributing to the extension of the FIF related practices and enablers, with a new version of the cPlatform.

## 6.2 The proposed innovative approach

The proposed innovative approach aims at assessing standards and their implementations on top of an experimental test bed platform simulating a complex Dynamic Manufacturing Network at an acceptable price.

> "A testbed is a platform for conducting rigorous, transparent, and replicable testing of scientific theories, computational tools, and new technologies... The term is used across many disciplines to describe experimental research and new product development platforms and environments. They may vary from hands-on prototype development in manufacturing industries such as automobiles (known as "mules"), aircraft engines or systems and to intellectual property refinement in such fields as computer software development shielded from the hazards of testing live."

Considering the aeronautic industry, some specific testbeds are created for aircrafts called Iron Bird.

> "An iron bird is a ground-based test device used for prototyping and integrating aircraft systems during the development of new aircraft designs. Aircraft systems are installed into the iron bird so their functions can be tested both individually and in correlation with other systems. Some iron birds also include a flight deck so that testing can include pilot inputs and simulated flight profiles, and can be used in pre-flight pilot training. Others are used for testing of propulsion systems. Iron birds can also be used after aircraft certification for troubleshooting ongoing issues and for testing of proposed modifications prior to fleet integration."

The proposed innovative approach consists in making the analogy between a Dynamic Manufacturing Network and a complex system, such as an aircraft, and to extend the FIF and the cPlatform in order to be able to use the cPlatform as a testbed. The testbed will be used for prototyping and integrating PLM system components during their development as part of a Dynamic Manufacturing Network.

PLM components are installed into the testbed so their communication function based on standardized interfaces can be tested both individually and in correlation with the other application components. Testing can include users inputs and simulated collaboration, and can be used on training for PLM standards based collaboration. Testbed can also be used after deployment of PLM solutions for troubleshooting ongoing issues and for testing of proposed modifications prior to deployment and integration in operation.
Following the FIF principles, the PLM interoperability testbed is an evolution of the cPlatform and of the DMN software factory aiming at supporting the new FIF proposed processes. These processes include the assessment of PLM standards relevance for the expected end-to-end collaborations and the specification of the PLM standards implementation by software solution providers in a way that supports continuous integration and testing within a Dynamic Manufacturing Network.

A first evolution of the cPlatform described in fig 22 consists in a functional extension of the cPlatform with

1) test services including transformation, quality control, service composition and data set generation

2) management system for test use cases, test scenarios and associated test data, which will be stored in a shared database.

These two extensions aim at supporting continuous integration and continuous quality checking of the different components of the working environment of a Dynamic Manufacturing Network. They are relying on legacy standard technical components of the previous version of the cPlatform.

A second evolution of the cPlatform infrastructure is related to the usage of virtualisation and cloud technologies which were identified as potential interoperability enablers, as it allows to simulate the actual working environment for complex multi-partners digital and secured collaborations at scale using limited resources in terms of machines. After assessing the various infrastructure virtualization technologies for machines and networks, in full alignment with the FIF approach, it led to the realization of a new version of the cPlatform with the architectural description provided by Fig 24.

A third evolution concerning the Dynamic Manufacturing Network software factory is related to a new joint usage of Model Driven Architecture with Enterprise Modeling. For making it possible to simulate various Dynamic Manufacturing Network and to configure the cPlatform for supporting the assessment of many standards for various collaboration scenarios, the Model Driven Architecture technologies coupled with Dynamic Manufacturing Network modelling using the standardized enterprise modelling language ArchiMate were identified as enablers for designing and realizing a Dynamic Manufacturing Network Software Factory. The defined approach is described in chapter 3.3 and illustrated by Fig 23.

While the information and service models are derived from PLM standards, both the business context to be reflected in the enterprise applications and the realisation infrastructure where they have to be run are generated from Dynamic Manufacturing Network blueprint templates in ArchiMate.
<figure><img src="image_43.png" /><figcaption>Figure 39: Two phases approach for the DMN Software Factory</figcaption></figure>

As automation is relevant only for well-defined and qualified components for a cPlatform, a two phase approach is adopted.

During the first phase, the components are deployed, configured and integrated manually, and represented as parametric DMN blueprint templates in ArchiMate.

Once validated and qualified, the manual process is automated and included in the DMN Software Factory automated process library. This is illustrated by Fig 35.

Step 1 consists in modelling the collaboration by means of DMN blueprints.

Step 2 consists in setting up the environment where the simulation will be simulated - also called infrastructure of the collaboration- as defined by the DMN. Doing so, the applied process will be captured and validated.

Step 3 consists in simulating the collaboration for testing the PLM standards. In the second phase, from the gained experience, modular model components will be derived from the initially produced DMN blueprints (Step 0) in order to be able to define a DMN by assembling (Step 1) these modules (also called LEGO components, due the analogy with LEGO parts).

The set up process will then be fully automated on the basis of the produced parametric models and of the tool chain put in place in order to support this automated process. This could be completed by usage of tools automating the generation of test data.

In terms of process, a three phases approach was defined for implementing a cross organizational collaboration between two partners within a DMN. Considered collaborations are defined the following way.

One partner plays the role of the Original Equipment Manufacturer (OEM) and the other plays the role of an equipment supplier. The collaboration to be realized by end to end
collaboration processes including the private processes of the OEM and of the supplier, interfaced by a standardized cross organizational collaborative process (SPc).

This last process consists mainly to exchange Work Request and Work result with the associated required information flows between applications supporting the private processes. The application of the OEM is called O, the one of the supplier is called S.

The information flows are realized by data exchange or sharing between the software systems realizing these applications, each software system being an instance of a software product. For O, it is product A. For S, it is product B. This is described by Fig 36.

We have then to consider that the collaboration will rely on the usage of a given standardized Application Protocol, APxx.

We are here generalizing the approach proposed by STEP, by considering that each application or software product can be categorized according to a given Conformance Classes (CC).

Hence, we can consider the conformance class of the OEM's application, CC(O), and the conformance class of the supplier's application, CC(S).

A conformance class aggregates subsets of an AP Reference Model, which depend on sets of assigned (applications) or implemented (software products) Unit of Functionalities.

The information and data flows to be implemented are the relevant ones for supporting the collaboration.

It is not required using all the concepts defined in an application protocol, but just the sufficient subset for covering the expected collaboration and for reflecting the distribution of functions to be performed between partners and applications for a given product component. It is the reason we consider the Information Coverage concept.

It is associated with each flow to implement between two applications. It is the subset of concepts in an application protocol needed for realizing this flow.

The interest of considering the Information Coverage comes from the fact it allows to precisely specify what needs to be implemented in terms of standardized exchange in order to cover just what is needed for supporting the collaborations to be supported, no more.

It means that implementation of the standardized interfaces by software vendors can be done progressively relying on a set of Standardized cross organizational collaborative processes (SPc) adopted by the members of a Dynamic Manufacturing Network or by a given digital business ecosystem mature in terms of interoperability.

It can also be very useful for specifying formally the different business cases and derived use cases to be realized for a collaboration.

In terms of process, it means that for a DMN blueprint, we have to define all the information flows between applications which are required to support a collaboration.

The Conformance class is to be defined for each application. The Information Coverage is to be defined for each flow.

The assessment of a PLM standard within a given DMN will consist in checking that
1) all the needed entity types to be used for defining exchanged artefacts are defined in the application protocol 2

2) the Information Coverage is included in the intersection of the Conformance Classes of the applications having to communicate. In addition, it will be possible to assess the global consistency of the Application Protocol usage in the DMN by querying the DMN repository, and to enforce the consistency by defining rules and constraints when defining the DMN templates for collaborations.

<figure><img src="image_44.png" /><figcaption>Figure 40: Standards Interoperability PLM methodology</figcaption></figure>

We can now start to describe the three phases for using the testbed for PLM collaboration in a DMN using a given Application Protocol.

**The first phase is the simulation phase.** It aims at validating that a standard responds to cross organizational collaborative process needs in terms of Product & Process data exchange between Original Equipment Manufacturer (OEM) and the members of the supply chain related to a given manufactured product. The goal here is not to test the actual applications of OEM and Suppliers, but the adherence of the standard with Product & Process data exchange needs. On Figure 40, the Dynamic Manufacturing Network blueprint model (light blue) for the targeted collaboration (blue) is represented. It includes Conformance Class of the applications, and Information Coverage of the information flows.
<figure><img src="image_45.png" /><figcaption>Figure 41: DMN collaboration blueprint template</figcaption></figure>

It will also be one element of a generic and shared portfolio of cross organization collaboration scenarios from which it will be possible to derive associated testing procedures, and test data sets, reusable for continuous integration. For this, the Dynamic Manufacturing Network blueprint, formalized by means of ArchiMate is used as the input of the Dynamic Manufacturing Network Software Factory. In this phase, each application is realized by means of an Applicative Reference Component, which is one of the LEGO building blocks of the Dynamic Manufacturing Network Software Factory.

**The second phase consists in testing actual software solutions**, within the role of Applicative Referenced Components used in the first phase. These components are replaced by applications or software systems to be tested. They can then be tested by replaying the testing scenarios, for unitary testing or integration testing. This testing phase for standard implementation validation will result in a set of qualified applications supporting the targeted collaboration process through the usage of the PLM standards. It is illustrated by Figure 41.
<figure><img src="image_46.png" /><figcaption>Figure 42: Testing actual solutions by replacing the Applicative Reference Components</figcaption></figure>

The third phase consists in monitoring interoperability of actual applications, by tracking issues and being able to take actions when non-interoperability is detected, or to deal with interoperability maintenance when some changes must occur. This is possible due to the adopted virtualisation approach, which allows to seamlessly connecting the actual application on the testbed. Consequently the test bed can be used as a monitoring solution to detect interoperability issues and to be able to address them very quickly. The Dynamic Manufacturing Network model is then used as a digital twin of the Dynamic Manufacturing Network. It is illustrated by Figure 42.

## 6.3 - Analysis and conclusion

The proposed approach has been used for assessing several PLM standards and testing some of their implementation, in close relationship with the PLM standardisation community and research community:

1) The “Enterprise-Control System Integration” standard (ISA95) for covering collaboration implying an Enterprise Resource Planning System and a Manufacturing Execution System. The demonstration was made through the PhD thesis of Emna Moones: “Proposal of a methodological approach of multi-level interoperability in a collaborative PLM environment” and was the opportunity for several scientific publications [P10][P18].

2) The “Managed model based 3D engineering” standard (STEP AP242), relying on implementation based several implementation technologies (XML Schema and Schematron
and EXPRESS on top of the Meta Object Facilities) and in order to assess the usage of the protocol for an actual business case implying Dassault Aviation.

3) The "Open Services for Lifecycle Collaboration" standard (OSLC) for assessing the maturity in terms of interoperability of the OSLC community.

4) The "Multidisciplinary Analysis and Design" standard (STEP AP209) for assessing the relevance of the proposed approach for simulation. It was the opportunity of a scientific publication [P13][P20]

5) The "Modelling and Simulation information in a collaborative Systems Engineering Context" standard (STEP AP243), in order to assess how to include service based approach in STEP

It demonstrated the applicability of the proposed approach for various PLM standards and Business cases, in particular when considering that all these assessments were performed on a two years period with very limited resources.

In terms of scientific results, the approach has been the opportunity for publishing several research papers, in particular [P00].

In terms of limitations of the results, we faced the limitation of the adopted modelling language, ArchiMate, in terms of modular modelling of composite systems and polyglot enrichment which are being addressed with the work on extended hypermodel for interoperability.

An important difficulty is related to the access to relevant data sets for building appropriate test scenarios and procedures. It is particularly true if considering the new trends related to Virtual Manufacturing, Industrial Internet of Things or Cyber Physical Autonomous Systems. These trends are bringing new challenges in terms of interoperability, due to the growing complexity of the underlying technologies and infrastructures.

<table><caption>Table 16: Interoperability testbed outcome</caption><tr><td>Associated publications</td><td>P00, P01, P02, P03, P04, P10, P12, P15, P16, P17, P18, P19, P21, P22, P23, P25, P29, P36</td></tr><tr><td>Related Projects</td><td>SIP</td></tr><tr><td>1 PhD supervised and collaboration for supervision of 2 others PhDs</td><td>Malik Khalfallah, Emna Moones</td></tr><tr><td>Demonstrators</td><td>DMN Software Factory, ARAS import/export with AP242, Quality checker on top of XML database, AP242 Quality Checker on top of Eclipse</td></tr><tr><td>Addressed Interoperability Issues</td><td>I-28</td></tr></table>
# Chapter 7 - Conclusion and perspectives

The interoperability required for the digital continuity in the Manufacturing Domain has been an important but challenging concern during the last 20 years, due to the rise of Information and Communication technologies which have been continuously changing the way of working or doing business. It is true in particular within the manufacturing industry with the successive innovative transformations from the Computer Aided Design in the 90's to the current usage of Digital Twins.

Various limitations exist for legacy interoperability solutions, being interoperability models of reference, integration platforms or open PLM standards. In particular, they are partial, fragmented, heterogeneous and overlapping solutions addressing some particular viewpoints, but they don't support the required holistic approach allowing to prepare and to build the expected continuous operational interoperability at an acceptable cost and for long time duration.

The first contribution is an original approach for the **Federation of Interoperability Frameworks and solutions**, allowing to select the relevant interoperability solutions and enablers and to use them jointly in order to unleash the identified interoperability brakes, which prevent to reach the expected continuous operational interoperability at an acceptable cost for PLM. Focussing on the cause and impact of non-interoperability, it provides a way to prepare - relying on governance -, and to build - relying on architecture best practices – the expected interoperability.

The second contribution is an original approach aiming at **semantic preservation** and at preventing data loss when having to translate data between languages used in the different communication chains to put in place being for PLM processes or for Model Based Approach used by the software factories used by the Federation of Interoperability Framework. It is based on the extension of the hypermodel concept for interoperability, which deal with multiple representations of a same thing for different usage. After relying on the usage of hypergraphs which can travel between the different grounds of the collaboration landscape, and allowing preserving the semantic of flat semantic graphs, it was extended in order to deal with modular representations of composite systems of systems through the proposal of using Domain Specific Language over open and standardized System Modelling languages.

The third contribution is an original approach aiming at building qualified dynamic networked organisations in terms of PLM interoperability, by **Modeling of the dynamic networking of companies collaborating for manufactured products**. This is based on blueprint templates allowing capturing the actual capabilities of a member of the network and to compare it with what is expected from any participant of a cross organisational process to be run in a collaborative PLM environment based on PLM standards.

The fourth contribution is an original approach aiming at assessing the PLM standards with a Dynamic Manufacturing Network and at testing their implementation relying on collaborative platforms with a PLM Hub. It relies on an approach for building **PLM interoperability test bench**, as a functional extension of a collaborative platform built for the Federation of Interoperability Frameworks and solutions.

However, all the brakes are not addressed, and both practices and emerging technologies bring new problems that require advancing the state of the art and supporting digital
transformation. Three short-term perspectives concern PLM interoperability in relation to the
Cloud, Artificial Intelligence (AI) and autonomous connected products.

1. **Collaborative PLM over Distributed and Heterogeneous Clouds**: Current cloud trends are leading to the increasingly frequent use of orchestrated containers for elastic solutions based on micro services. This brings new complexity, both in terms of technology and governance. Which standards are required, existing or to be developed, to be federated with those already identified to maintain PLM interoperability in digital ecosystems? One particular aspect is related to the impact of virtualization on the ability to prepare and build interoperability.

2. **Collaborative PLM and AI technologies**: Current trends in artificial intelligence, whether Deep Learning or Knowledge Bases, pose the question of publishing or upgrading data describing the products and associated processes towards these types of solutions. How to preserve the semantics and the interpretation context of the data to integrate them into a controlled chain of collaboration? A particular aspect is related to the ability to produce multiple representations of business rules exchangeable between technology platforms, such that the information produced by AI systems is consistent with the source data coming from PLM platforms.

3. **Extensive PLM test bench for autonomous connected products with digital twins**: current trends concerning "makers", in connection with the extension of open source to the hardware and with additive manufacturing processes, create an unprecedented new situation: complete products based on innovative technologies are made available off the shelf, with design models and manufacturing processes to build them quickly at very low costs, as perfect prototypes of new kind of products that need to communicate or interact with their environments. While being representative of the new complexity to be understood for these types of products, they are not subject to the constraints encountered for other industrial products concerning access to data, which are generally confidential or difficult to access. They are therefore the components of choice to constitute new types of test beds for the PLM interoperability to be established for autonomous connected systems and digital twins. The product design models can be reused to derive digital twins of these products, for their monitoring, configuration or remote control in the various contexts reflected by a collaborative PLM platform built according to the principles of the Federation of Interoperability Framework and solutions approach.

These subjects are likely to give rise to new interoperability problems, the resolution of which
will be done relying on the global approach defined with the Federation of interoperability
frameworks and solutions, making it possible to integrate research activities into shortened
cycles for innovation, for a better adaptation of enterprises to the new collaboration context
resulting from the evolution of information and communication technologies.
Bibliography

[1] « Digital Thread for Smart Manufacturing" project page, NIST, https://www.nist.gov/programs-projects/digital-thread-smart-manufacturing

[2] "Managing the Digital Thread in Global Value Chains", February 2020, CIMData
https://www.cimdata.com/en/resources/complimentary-reports-research/commentaries/item/13431-managing-the-digital-thread-in-global-value-chains-commentary

[3] Ford C., Colombi J., Graham S. and Jacques D. (2008) "A Survey on Interoperability Measurement", 12th ICCRTS "Adapting C2 to the 21st Century"

[4] "Interoperability and Portability for Cloud Computing: A Guide Version 2.0", OMG, December 2017,
https://www.omg.org/cloud/deliverables/CSCC-Interoperability-and-Portability-for-Cloud-Computing-A-Guide.pdf

[5] Morris E., Levine L., Meyers C., Place P. and Plakosh D. (2004) "Interoperability (SOSI): Final Report, April 2004"

[6] INAS Gabriel Leal, Wided Guédria, Hervé Panetto. Interoperability assessment: A systematic literature review.
Computers in Industry, Elsevier, 2019, 106, pp.111-132. ff10.1016/j.compind.2019.01.002ff. ffhal-01982217f

[7] Clark, T. and R. Jones (1999) "Organisational Interoperability Maturity Model for C2"

[8] Tolk A. and Muguira J. (2003) "The Levels of Conceptual Interoperability Model", Fall Simulation Interoperability Workshop Orlando, Florida

[9] Obstr L. (2009) "Ontologies & the Semantic Web for Semantic Interoperability", SICOP909

[10] Daclin N., Chen D. and Vallespir B. (2006), « Modèle de maturité pour l'interopérabilité des

[11] R. Rezaei, T.K. Chiew, S.P. Lee An interoperability model for ultra large scale systems Adv. Eng. Softw., 67 (2014), pp. 22-46, 10.1016/j.advengsoft.2013.07.003entreprises » at proceeding of « 6e journée STP, Valenciennes, 16-17 Novembre 2006 »

[12] NEHTA (2007), "Interoperability Framework v2.0", available at
http://www.nehta.gov.au/component/docman/doc_details/391-interoperability-framework-v20

[13] NIST Cloud Standards Roadmap at https://www.cloudwatchhub.eu/nist-cloud-standards-roadmap

[14] NIST Big Data Interoperability Framework, Volume 9,
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1500-10r1.pdf

[15] L'interopérabilité culturelle et l'interculturalité, Le modèle de Vifralie Reine Al Sahyouni Bou Fadel, Communication
Vol 34/1 2016, https://doi.org/10.4000/communication.6636 https://journals.openedition.org/communication/6636?lang=en

[16] European Interoperability Framework EIF
https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/solution/eif-toolbox/6-interoperability-layers

[17] Maxwell, E. (2006). Open Standards, Open Source, and Open Innovation: Harnessing the Benefits of Openness. Innovations: Technology, Governance, Globalization, 1(3), 119–176. doi:10.1162/itgg.2006.1.3.119

[18] CORDIS projects web site, https://cordis.europa.eu/projects

[19] Digital Business Ecosystems Leaflet by European Commission, https://op.europa.eu/o/opportal-service/download-handler?identifier=53e45e55-4bd2-42a4-ad25-27b339b051e0&format=pdf&language=en&productionSystem=cellar&part=

1. [201 "Interoperability of technical enterprise applications", N. Figay. Other [cs.OH]. Université Claude Bernard - Lyon I, 2009. English. (NNT : 2009LYO10242). (tel-00806072)

[21] Schenck D. And Wilson P. (1994), "Information Modeling – The EXPRESS Way", Oxford

[22] Calson D. (2006), « Semantic Models for XML Schema with UML Tooling»,http://xmlmodeling.com/papers/SemanticModelsForXSD, SWESE 2006 University Press, ISBN 0-19-508714-3, Chapter 2, p17-29

[23] Gobert G. (2005), "From Computer Based Manipulatives to Hypermodels", available at
http://isites.havard.edu/fs/docs/icb topic603902.files/Bilogica Chapter v10.pdf

[24] Horwitz H. (1995), "Linking Models to Data: Hypermodels for Science Education ». The High School Journal, 79(2), 148 - 156., 1995

[25] Jose Ferreira, Miguel Ferro de Beca, Carlos Agostinho, Maria Jose Nunez, Ricardo Jardim-Goncalves, Standard Blueprints for Interoperability in Factories of the Future (FoF), IFAC Proceedings Volumes, Volume 46, Issue 9, 2013, Pages 1322-1327, ISSN 1474-6670, ISBN 9783902823359, https://doi.org/10.3182/20130619-3-RU-3018.00427
# References of considered standards

The standards are those which have been considered by my research for assessment when having to prepare and build continuous operational interoperability for PLM, for manufacturing domain and more particularly Aeronautic, Space and Defence Industry. Some of them have been elected as relevant building blocks to be used using the Federation of Interoperability Frameworks approach.

<table><thead><tr><td>Acronym</td><td>Designation</td></tr></thead><tbody><tr><td>STEP</td><td>ISO 10303 Standard for the Exchange of Product model data</td></tr><tr><td>AP203</td><td>ISO 10303-203:(1994, 2005, 2011) Configuration controlled 3D designs of mechanical parts and assemblies</td></tr><tr><td>AP214</td><td>ISO 10303-214:(2001, 2003, 2010) Core data for automotive mechanical design processes</td></tr><tr><td>AP242</td><td>ISO 10303-242:(2014, 2020) Configuration controlled 3D designs of mechanical part and assemblies</td></tr><tr><td>STEPNC</td><td>AP238 2007 Application interpreted model for computerized numerical controllers</td></tr><tr><td>AP238</td><td>AP238 2020 Model based integrated manufacturing</td></tr><tr><td>EXPRESS</td><td>ISO 10303-11:2004-Part 11 Description methods: The EXPRESS language reference manual</td></tr><tr><td>EXPRESS-X</td><td>ISO 10303-14:2005 -Part14 Description methods: The EXPRESS-X language reference manual</td></tr><tr><td>SDAI</td><td>ISO 10303-22:1998-Part 22 Implementation methods: Standard data access interface</td></tr><tr><td>P21</td><td>ISO 10303-21:2016-Part 21 Implementation methods: Clear text encoding of the exchange structure</td></tr><tr><td>PDME</td><td>OMG's PDM Enablers v1.3, November 2000</td></tr><tr><td>ECO</td><td>ProSTEP recommendation: Engineering Change Order (ECO)PSI 3-2 (Draft) Version 0.9</td></tr><tr><td>ECM</td><td>ECM Recommendation Part 0 (ECM) Version 2.0, issued Aug. 2009<br>Replacements: Version 1.0 VDA 4965 – Part 0 Version 3.0, issued Jan. 2010 Replacements: Version 2.0</td></tr><tr><td>ISA95</td><td>ISO/IEC 62264 Enterprise-Control System Integration, the international version of ISA 95</td></tr><tr><td>MDA</td><td>OMG Model Driven Architecture</td></tr><tr><td>CORBA</td><td>OMG Common Object Request Broker Architecture</td></tr><tr><td>OMA</td><td>OMG Object Management Architecture</td></tr><tr><td>OSLC</td><td>OASIS Open Services for Lifecycle Collaboration</td></tr><tr><td>OPC UA</td><td>OPC Foundation Open Platform Communication Unified Architecture</td></tr><tr><td>QIF</td><td>ISO 23952:2020 Quality Information Framework</td></tr><tr><td>RAMI</td><td>EC PAS 63088:2017 Smart manufacturing - Reference architecture model industry 4.0</td></tr><tr><td>PERA</td><td>Purdue Enterprise Reference Architecture</td></tr><tr><td>NIST RM</td><td>Current Standards Landscape for Smart Manufacturing Systems</td></tr><tr><td>MT Connect</td><td>ANSI/MTC1.4-2018 MT Connect</td></tr><tr><td>ArchiMate</td><td>Open Group ArchiMate 3.1</td></tr><tr><td>OWL</td><td>W3C Ontology Web Language 2</td></tr><tr><td>WRM</td><td>Wfmc's Workflow Reference Model Workflow Management Coalition</td></tr></tbody></table>
<table>
  <tr>
    <td></td>
    <td>Document Number TC00-1003 Document Status - Issue 1.1</td>
  </tr>
  <tr>
    <td>XPDL</td>
    <td>XML Process Description Language</td>
  </tr>
  <tr>
    <td>BPSim</td>
    <td>Business Process Simulation Interchange standard</td>
  </tr>
  <tr>
    <td>BPMN2</td>
    <td>Business Process Model and Notation Version 2.0.2</td>
  </tr>
  <tr>
    <td>SPEM2</td>
    <td>Software &amp; Systems Process Engineering Metamodel Version: 2.0</td>
  </tr>
  <tr>
    <td>PDME</td>
    <td>Product Data Management Enablers Version 1.3, OMG, November 2000</td>
  </tr>
  <tr>
    <td>UAF</td>
    <td>OMG Unified Architecture Framework 1.1</td>
  </tr>
  <tr>
    <td>TOGAF</td>
    <td>The Open Group Architecture Framework 9.2</td>
  </tr>
  <tr>
    <td>ISO15288</td>
    <td>ISO/IEC/IEEE 15288:2015 Ingénierie des systèmes et du logiciel — Processus du cycle de vie du système</td>
  </tr>
  <tr>
    <td>S1000D</td>
    <td>International specification for technical publications using a common source database</td>
  </tr>
  <tr>
    <td>S2000M</td>
    <td>ASD/AIA S2000M – INTERNATIONAL SPECIFICATION FOR MATERIAL MANAGEMENT</td>
  </tr>
  <tr>
    <td>S3000L</td>
    <td>ASD/AIA S3000L International procedure specification for Logistic Support Analysis (LSA)</td>
  </tr>
  <tr>
    <td>S4000P</td>
    <td>ASD S4000P International specification for developing and continuously improving preventive maintenance</td>
  </tr>
  <tr>
    <td>S5000F</td>
    <td>AIA/ASD S5000F International specification for in-service data feedback</td>
  </tr>
  <tr>
    <td>S6000T</td>
    <td>ASD/AIA S6000T International specification for training analysis and design</td>
  </tr>
  <tr>
    <td>SX001G</td>
    <td>ASD/AIA SX000i International guide for the use of the S-Series Integrated Logistics Support (ILS) specifications</td>
  </tr>
  <tr>
    <td>SX000i</td>
    <td>ASD/AIA SX000i International guide for the use of the S-Series Integrated Logistics Support (ILS) specifications</td>
  </tr>
  <tr>
    <td>SX001G</td>
    <td>Glossary for the S-Series ILS Specifications, Issue 2.0, December 2018</td>
  </tr>
  <tr>
    <td>SX002D</td>
    <td>Common Data Model for the S-Series ILS Specifications, Issue 2.0, December 2018</td>
  </tr>
  <tr>
    <td>SX004G</td>
    <td>Unified Modeling Language (UML) model reader's guidance, Issue 1.0, August 2016</td>
  </tr>
  <tr>
    <td>SX005G</td>
    <td>S-Series ILS specifications XML schema implementation guidance, Issue 1.0, December 2017</td>
  </tr>
  <tr>
    <td>ReIF</td>
    <td>OMG Requirements Interchange Format 1.2</td>
  </tr>
  <tr>
    <td>JT</td>
    <td>ISO 14306:2017 Industrial automation systems and integration — JT file format specification for 3D visualization</td>
  </tr>
  <tr>
    <td>SCOR</td>
    <td>SCM Supply Chain Operation Reference Model</td>
  </tr>
  <tr>
    <td>RDF</td>
    <td>W3C Resource Description Framework 1.1 as a set of recommendations: Primer, Concepts and Abstract Syntax, XML Syntax, etc.</td>
  </tr>
  <tr>
    <td>JSON-LD</td>
    <td>JSON-LD 1.1 A JSON-based Serialization for Linked Data W3C Recommendation 16 July 2020</td>
  </tr>
  <tr>
    <td>SHACL</td>
    <td>Shapes Constraint Language (SHACL) W3C Recommendation 20 July 2017</td>
  </tr>
  <tr>
    <td>SKOS</td>
    <td>SKOS Simple Knowledge Organization System Reference W3C Recommendation 18 August 2009</td>
  </tr>
  <tr>
    <td>SPARQL</td>
    <td>SPARQL 1.1 Query Language W3C Recommendation 21 March 2013</td>
  </tr>
  <tr>
    <td>IRI</td>
    <td>IETF Internationalized Resource Identifiers (IRIs) January 2005 - rfc3987</td>
  </tr>
  <tr>
    <td>WSDL</td>
    <td>Web Services Description Language (WSDL) 1.1 W3C Note 15 March 2001</td>
  </tr>
  <tr>
    <td>SOAP</td>
    <td>SOAP Version 1.2 Part 0: Primer (Second Edition) W3C Recommendation 27 April 2007<br>SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) W3C Recommendation 27 April 2007<br>SOAP Version 1.2 Part 2: Adjuncts (Second Edition) W3C Recommendation 27 April 2007<br>SOAP Version 1.2 Specification Assertions and Test Collection (Second Edition) W3C Recommendation 27 April 2007<br>Simple Object Access Protocol (SOAP) 1.1 W3C Note 08 May 2000</td>
  </tr>
  <tr>
    <td>DOM</td>
    <td>Document Object Model (DOM) Level 3 Core Specification Version 1.0 W3C Recommendation 07 April 2004<br>Extended by UI Events W3C Working Draft, 04 August 2016</td>
  </tr>
  <tr>
    <td>XMLSchema</td>
    <td>W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes W3C Recommendation 5 April 2012<br>W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures W3C Recommendation 5 April 2012<br>XML Schema Part 0: Primer Second Edition W3C Recommendation 28 October 2004<br>XML Schema Part 1: Structures Second Edition W3C Recommendation 28 October 2004<br>W3C XML Schema Definition Language (XSD): Component Designators W3C Candidate Recommendation 19 January 2010</td>
  </tr>
</table>
<table><tr><td>Schematron<br>Relax NG</td><td>ISO/IEC 19757-3:2020 Technologies de l'information — Langages de définition de schéma de documents (DSDL) —<br>Partie 3: Validation basée sur des règles à l'aide de Schematron (revisions in 2006, 2016)<br>ISO/IEC 19757-2:2008 Technologies de l'information — Langage de définition de schéma de documents (DSDL) —<br>Partie 2: Validation de grammaire orientée courante — RELAX NG (revisions in 2003, 2006, 2008)</td></tr><tr><td>CORBA</td><td>Common Object Request Broker Architecture Version: 3.4 Publication Date: February 2021<br>3.4 February 2021 https://www.omg.org/spec/CORBA/3.4/<br>3.3 October 2012 https://www.omg.org/spec/CORBA/3.3/<br>3.2 October 2011 https://www.omg.org/spec/CORBA/3.2/<br>3.1.1 July 2011 https://www.omg.org/spec/CORBA/3.1.1/<br>3.0.3 March 2004 https://www.omg.org/spec/CORBA/3.0.3/<br>2.6.1 June 2002 https://www.omg.org/spec/CORBA/2.6.1/<br>2.5 September 2001 https://www.omg.org/spec/CORBA/2.5/<br>2.4.2 October 2000 https://www.omg.org/spec/CORBA/2.4.2/<br>2.3.1 October 1999 https://www.omg.org/spec/CORBA/2.3.1/<br>2.2 July 1998 https://www.omg.org/spec/CORBA/2.2/<br>2.1 September 1997 https://www.omg.org/spec/CORBA/2.1/<br>2.0 February 1997 https://www.omg.org/spec/CORBA/2.0/<br>1.2 December 1993 https://www.omg.org/spec/CORBA/1.2/<br>1.1 December 1991 https://www.omg.org/spec/CORBA/1.1/<br>1.0 August 1991 https://www.omg.org/spec/CORBA/1.0/</td></tr><tr><td>CCM</td><td>CORBA Component Model Version: 4.0 Publication Date: mars 2006<br>4.0 mars 2006 https://www.omg.org/spec/CCM/4.0/<br>3.0 mai 2002 https://www.omg.org/spec/CCM/3.0/</td></tr><tr><td>OMA</td><td>OMG's Object Management Architecture</td></tr><tr><td>MDA</td><td>Object Management Group Model Driven Architecture (MDA) MDA Guide rev. 2.0 OMG Document ormsc/2014-06-01<br>The MDA is supported by the Unified Modeling Language™ (UML®), the MetaObject Facility™ (MOF™), XML Metadata Interchange™ (XMI®), and the Common Warehouse Metamodel™ (CWM™). For details, view the MDA specifications page</td></tr><tr><td>BPMN</td><td>2.0.2 January 2014 https://www.omg.org/spec/BPMN/2.0.2/<br>1.2 January 2009 https://www.omg.org/spec/BPMN/1.2/<br>1.1 January 2008 https://www.omg.org/spec/BPMN/1.1/<br>1.0 March 2007 https://www.omg.org/spec/BPMN/1.0/</td></tr><tr><td>UML</td><td>OMG's Unified Modeling Language Version: 2.5.1 Publication Date: December 2017<br>2.5.1 December 2017 https://www.omg.org/spec/UML/2.5.1/<br>2.4.1 July 2011 https://www.omg.org/spec/UML/2.4.1/<br>2.3 May 2010 https://www.omg.org/spec/UML/2.3/<br>2.2 January 2009 https://www.omg.org/spec/UML/2.2/<br>2.1.2 October 2007 https://www.omg.org/spec/UML/2.1.2/<br>2.0 July 2005 https://www.omg.org/spec/UML/2.0/<br>1.5 March 2003 https://www.omg.org/spec/UML/1.5/<br>1.4 September 2001 https://www.omg.org/spec/UML/1.4/<br>1.3 February 2000 https://www.omg.org/spec/UML/1.3/<br>1.2 July 1999 https://www.omg.org/spec/UML/1.2/<br>1.1 December 1997 https://www.omg.org/spec/UML/1.1/<br>ISO/IEC 19505-2:2012 Information technology — Object Management Group Unified Modeling Language (OMG UML) — Part 2: Superstructure (revised in 2016)<br>ISO/IEC 19505-1:2012 Technologies de l'information — Langage de modélisation unifié OMG (OMG UML) — Partie 1: Infrastructure</td></tr><tr><td>MOF</td><td>OMG's Meta Object Facility Version: 2.5.1 Publication Date: octobre 2016<br>2.5.1 October 2016 https://www.omg.org/spec/MOF/2.5.1/<br>2.4.2 April 2014 https://www.omg.org/spec/MOF/2.4.2/<br>2.0 January 2006 https://www.omg.org/spec/MOF/2.0/<br>1.4 April 2002 https://www.omg.org/spec/MOF/1.4/<br>ISO/IEC 19502:2005 Information technology — Meta Object Facility (MOF) (revised in 2016)</td></tr><tr><td>XMI</td><td>OMG's XML Metadata Interchange Version: 2.5.1 Publication Date: juin 2015<br>2.5.1 June 2015 https://www.omg.org/spec/XMI/2.5.1/<br>2.4.2 March 2014 https://www.omg.org/spec/XMI/2.4.2/<br>2.1.1 December 2007 https://www.omg.org/spec/XMI/2.1.1/<br>2.0 May 2003 https://www.omg.org/spec/XMI/2.0/<br>ISO/IEC 19503:2005 Information technology — XML Metadata Interchange (XMI) (revised in 2016)</td></tr></table>
<table><caption>Table 17: Details of the standards considered for research on PLM Interoperability</caption><tr><td>WSRM</td><td>Web Services Reliable Messaging TC WS-Reliability 1.1 OASIS Standard, 15 November 2004<br>Schema for Features, Property, and Compositor constructs, v1.1, 2004-June-07<br>Schema for ServiceRefType v1.1, 2004-June-07<br>Schema for WS-Reliability Protocol Headers for SOAP 1.1 &amp; SOAP 1.2 protocols, v1.1, 2004-Aug-04<br>Schema for WSRM features and properties, v1.1, 2004-Aug-03<br>Errata for WS-Reliability v1.1 - CD 1 (April 2005)<br>Application Notes for WS-Reliability v1.1 - CD 1 (Reliability of Responses - March 2007)<br>Profile Template for WS-Reliability 1.1 Version1.0 CD 01 (April 2007)<br>Deployment Profile of Information Appliances Services for WS-Reliability 1.1 Version1.0 CD 01 - April 2007</td></tr><tr><td>BPSIM</td><td>Business Process Simulation Specification Document Number WFMC-BPSWG-2016-1 Document Status - Release December 21st, 20</td></tr><tr><td>JCR168</td><td>Portlet 1.0 SR-000168 Portlet Specification (Final Release) October 7, 2003</td></tr><tr><td>JCR286</td><td>Portlet 2.0 JSR-000286 Portlet Specification 2.1.0 (Close of Maintenance Review: 13 August 2015)</td></tr><tr><td>JCR 318</td><td>Enterprise Java Beans 3.0 SR-000318 Enterprise JavaBeans 3.1 Final Release Specification for Evaluation 3.1 Eval</td></tr><tr><td>JCR 5</td><td>SAX Java API for XML Parsing Version 1.0 Final Release</td></tr><tr><td>Open-SCA</td><td>Service Component Architecture Assembly Model Specification Version 1.1 Committee Specification Draft 09 /Public Review Draft 04 13 September 2011</td></tr><tr><td>USDL</td><td>Unified Service Description Language (Seems not to be a released specification)</td></tr><tr><td>SoaML</td><td>Service Oriented Architecture Modeling Language Version: 1.0.1 Publication Date: mai 2012</td></tr><tr><td>EMML</td><td>Enterprise Mashup Markup Language by Open Mashup Alliance (created in 2009, seems not active anymore since 2011)</td></tr><tr><td>OCCI</td><td>Open Cloud Computing Interface, set of open community-lead specifications from 2009 to 2016<br>GFD.221 - Open Cloud Computing Interface - Core describes the formal definition of the OCCI Core Model<br>GFD.222 - OCCI Compute Resource Templates Profile describes a profile for maximum interoperability and best practices<br>GFD.223 - Open Cloud Computing Interface - HTTP Protocol defines how to interact with the OCCI Core Model using the RESTful OCCI API<br>GFD.224 - Open Cloud Computing Interface - Infrastructure contains the definition of the OCCI Infrastructure extension for the IaaS domain. The document defines additional resource types, their attributes and the actions that can be taken on each resource type<br>GFD.226 - Open Cloud Computing Interface - JSON Rendering defines how to interact with RESTful OCCI API (see GFD.223) using a JSON rendering format.<br>GFD.227 - Open Cloud Computing Interface - Platform contains the definition of the OCCI Infrastructure extension for the PaaS domain. The document defines additional resource types, their attributes and the actions that can be taken on each resource type.<br>GFD.228 - Open Cloud Computing Interface - Service Level Agreements contains the definition of the OCCI Infrastructure extension for handling Service Level Agreements. The document defines additional resource types, their attributes and the actions that can be taken on each resource type.<br>GFD.229 - Open Cloud Computing Interface - Text Rendering defines how to interact with RESTful OCCI API (see GFD.223) using a TEXT rendering format for backwards compatible reasons.<br>From Open Grid Forum, An Open Global Forum for Advanced Distributed Computing management</td></tr><tr><td>CIMI</td><td>DMTF<br>DSP0263 2.0.0 Cloud Infrastructure Management Interface (CIMI) Model and RESTful HTTP-based Protocol An Interface for Managing Cloud Infrastructure"2016-07-27<br>DSP2027 2.0.0 Cloud Infrastructure Management Interface Primer 2016-08-04<br>ISO/IEC 19831:2015 Cloud Infrastructure Management Interface (CIMI) Model and RESTful HTTP-based Protocol - An Interface for Managing Cloud Infrastructure</td></tr><tr><td>EC2</td><td>de-facto standard Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides secure, resizable compute capacity in the cloud</td></tr><tr><td>CDMI</td><td>ISO/IEC 17826:2016 Information technology - Cloud Data Management Interface (CDMI) (Defines interoperability mechanisms for cloud storage systems)</td></tr><tr><td>OVF</td><td>Open Virtualization Format, published as ISO 17203<br>DSP0243 2.1.1 Open Virtualization Format Specification 27 Aug 2015<br>DSP0265 1.0.0 Profile to Enable Automated Deployment of OVF Packages 27 Jun 2013</td></tr></table>
# PLM Standardization related organizations

The organisation are those which have been considered as having a particular role concerning the considered standards, being for developing, governing or deploying them within the industry. They are stakeholders and members of the digital business ecosystem to be considered when willing to prepare and build continuous operational PLM interoperability on the expected long term duration.

<table><thead><tr><td>Organization Acronym, Name and Role</td><td>Standards considered for PLM Interoperability (c.f. Table 17 for details)</td></tr></thead><tbody><tr><td>ISO TC184 SC4 Industrial data<br>PLM related Role: Product & Process data exchange, sharing and long term archiving, including application protocols, framework and set of languages</td><td>STEP framework and Application Protocols including Application Activity Model in IDEF0, Application Reference Model and Application Integrated Model with ARM-AIM mapping EXPRESS, EXPRESS-X, SDAI, Part21</td></tr><tr><td>CIMDATA: one of the leading independent global strategic management consulting and research authority focused exclusively on PLM and the digital transformation it enables.</td><td>Provides reference definition for PLM</td></tr><tr><td>ISO TC 184 SC 5 Interoperability, integration, and architectures for enterprise systems and automation applications<br>PLM Related Role: Application protocols for Production System related to enterprise and product definition</td><td>IEC 62264:2013 (ISA95) with an activity model (diagram) and an information model</td></tr><tr><td>OMG MANTIS Manufacturing Technology and Industrial Systems<br>PLM related Role: Task force delivering standardized interfaces for Distributed Product Data Management and Modeling Systems</td><td>PDM Enablers, PLM Services: interface model for distributed systems</td></tr><tr><td>OASIS PLCS (2008-2017) Product Life Cycle Support<br>PLM related Role: Provided application protocol dedicated to through life support for product with as major activities 1) Manage information to support a product 2) Generate support solutions 3) Commission support system 4) Provide support.</td><td>PLCS: initially ISO 10303 part 239 recommended practices and Reference Data Libraries. Reintegrated in ISO SC4 TC184 since 2017</td></tr><tr><td>INCOSE International Council on Systems Engineering created in 1990<br>PLM Related Role: Life cycle of systems of interest and supporting systems</td><td>System Engineering Handbook<br>Contribution on various standards - ISO 15288, SysML</td></tr><tr><td>ASD STAN<br>Aeronautic, Space and Defence STANdardization created in 1970<br>PLM related Role: European aerospace industry Integrated Logistic Support standards</td><td>Standards (various models) for Integrated Logistic Systems: S1000D, S2000, S3000L, S4000P, S5000F, S6000T, SX001G, SX000i, SX002D</td></tr><tr><td>AIA Aerospace Industries Association, an American trade association representing manufacturers and suppliers of aeronautic, space and defence<br>PLM related Role: The AIA Business Technology Interoperability Committee (BTIC) establishes clear policy regarding common information exchange practices</td><td></td></tr><tr><td>ProSTEP German globally active industry driven independent association with 180 member companies from industry, IT and research. Creation in 1993<br>PLM related Role: Focuses on the digital transformation in product creation and production, through Implementor Forum and standard development support</td><td>ReqIF, JT and STEP benchmarks, AP242<br>Maintenance, Long Term Archiving<br>ECO ECM</td></tr><tr><td>NIST US National Institute of Standards and Technology, founded in 1901<br>PLM related Role: Interoperability testing, white paper, research, support of industry</td><td>NIST-SP 500-291 The NIST Cloud Roadmap SP 800-145<br>The NIST Definition of Cloud Computing<br>NIST Big Data Interoperability Framework</td></tr><tr><td>AFNET Association Francophone des utilisateurs du Net. Fondé en 1982<br>PLM related role: Implementor forum for STEP PLM<br>Support Industry for standardization and usage of standards</td><td>Support for development and implementation testing of AP242, AP239, JT</td></tr><tr><td>ASD SSG Strategic Standardization Group - Created in 2009<br>Role: Strategic Governance of PLM standards for ASD in Europe</td><td>Radar Chart for surveyed, promoted or to be developed standards for PLM inside the ecosystem</td></tr></tbody></table>
<table><caption>Table 18: PLM Interoperability related Standardization Organizations</caption><tr><td>Phenix PLM Harmonization for Enhanced Innovation and Excellence (2007-2014)<br>PLM related Role: Strategic Governance of PLM standards within the Airbus Group in alignment with ASD SSG.</td><td></td></tr><tr><td>ASCM Association for Supply Chain Management, created in 2019 - From APICS (1957) which merged with the Supply Chain Council (1996-2014)<br>PLM related Role: production and dissemination of standards for supply chain</td><td>SCOR</td></tr><tr><td>Open Group, a global consortium that seeks to "enable the achievement of business objectives" by developing "open, vendor-neutral technology standards and certifications, created in 1989<br>PLM related Role: standards for governance and planning of enterprise transformation</td><td>ArchiMate<br>TOGAF</td></tr><tr><td colspan="2">For Information and Communication technologies</td></tr><tr><td>W3C World Wide Web Consortium, an International community where Member organizations, a full-time staff, and the public work together to develop Web standards, created in 1994<br>PLM Related Role: producer of underlying technologies used for many PLM standards, in particular Linked Data, Semantic Web, Web Services, Electronic Documents.</td><td>OWL, RDF, SKOS, SPARQL, IRI, RDF Schema, JSON LD, SHACL<br>WSDL, SOAP<br>XML, DOM, XML Schema, Schematron, Relax NG</td></tr><tr><td>OMG Object Management Group, an international, open membership, not-for-profit technology standards consortium, created in 1989<br>PLM related Role: Production of specifications related to Architecture Framework, Middleware, Modeling Languages and Model Driven Architecture</td><td>CORBA, CCM, OMA, MDA, BPMN, UML, SysML, UAF</td></tr><tr><td>OPC Foundation Open Platform Communication Foundation, created in 1999<br>PLM related Role: Open Platform used for Virtual Manufacturing</td><td>OPC-UA</td></tr><tr><td>OASIS Organization for the Advancement of Structured Information Standards created in 1993<br>PLM Related Role: Definition of various eBusiness, Manufacturing and Product Lifecycle Management standards</td><td>BPEL, ebXML, XACML, MQTT, oData, OSLC, PPS<br>SOA-RA, SAML, TOSCA, UDDI, WSRP</td></tr><tr><td>Wfmc Workflow Management Coalition (1993-2019)<br>PLM related Role: Standardization of Workflow System model of reference and protocols for exchange, sharing and simulation</td><td>WSRM, XPDL, BPSIM</td></tr><tr><td>JCP Java Community Process<br>PLM related Role: specifications for the Java Platform</td><td>JCR 168 (Portlet 1.0), JCR 286 (Portlet 2.0), JCR 220 (Enterprise JavaBeans 3.0), JCR 5 (SAX)</td></tr><tr><td>DMTF Distributed Management Task Force creates open manageability standards spanning diverse emerging and traditional IT infrastructures including cloud, virtualization, network, servers and storage<br>PLM related Role: IT infrastructure for PLM over the cloud</td><td>CIMI, OVF</td></tr><tr><td>CIMDATA present itself as the leading independent global strategic management consulting and research authority focused exclusively on PLM and the digital transformation it enables.</td><td>PLM glossary</td></tr><tr><td>GALIA Groupement pour l'amélioration des liaisons dans l'industrie automobile. Au-delà de la mise à disposition de standards et de l'organisation de formations, GALIA propose d'autres services : audit et conseil, homologation de solutions</td><td>Livre Blanc sur le standard d'échanges de données mesure (version française)<br>White Paper on the measurement data exchange standard (English version)</td></tr><tr><td>AIDIMA enjoys a great prestige to national and international level, so much in Europe as in the remainder of the world, especially United States, Canada, Japan and Latin America. It forms part of the Commission of Technology and Innovation of the European Union of the Furniture (UEA), and heads various European projects of innovation, also as diverse European working parties of normalization. AIDIMA is member founder of the European Association of Technological Institutes of the Furniture (EURIFI), Company that has presided</td><td>Contributor to STEP AP236, also called FUNSTEP</td></tr></table>