Model Driven Interoperability for System Engineering

Abstract

To keep up to date, manufacturing enterprises need to use the latest results from the ICT sector, especially when collaborating with external partners in a supply chain and exchanging products and data. This has led to dealing with an increasing amount of heterogeneous information exchanged between partners including machines (physical means), humans and IT in the Supply Chain of ICT Systems (SC-ICTS). In this context, interoperability management is becoming more and more critical, but paradoxically, it is not yet fully efficiently anticipated, controlled and accompanied to recover from incompatibilities issues or failures. This paper intends to present how enterprise modeling, enterprise interoperability and model driven approaches can lead, together with system engineering architecture, to contribute to developing and improving the interoperability in the SC-ICTs. Model Driven System Engineering Architecture (MDSEA) is based on Enterprise Modeling using GRAI Model and its extensions. It gives enterprise internal developments guidelines, but originally, MDSEA is not the considering interoperability that is required between partners when setting a collaboration in the frame of SC-ICTS. As a result, the MDSEA, extended with interoperability concerns, led to the design of the MDISE (Model Driven Interoperability System Engineering) framework, which capitalizes on the research on enterprise interoperability. To finish, some proposals are made to extend the Model System Tool Box (MSTB) and the use of MDISE for Cyber Physical System (CPS) that are relevant components of SC-ICTS.

1. Introduction

Traditional manufacturing companies are entering the digital age either internally or when they need to collaborate [1]. The ICT (Information and Communication Technology) sector is faced with an increasing amount of information exchanged between partners through machines (physical means), people/organization and IT in the context of business collaboration. Interoperability management is becoming increasingly critical, but it is not yet fully anticipated, controlled and effectively supported to recover from security problems or failures.

Enterprises decision-makers are faced by several questions when collaboration with partners within a supply chain process is required. Based on our experience as experts in enterprise and business modeling, with which we accompany companies in different projects. The most frequently received questions from companies are: What is the main objective of the collaboration? How to organize the collaboration? What interoperability barriers must be to overcome? What about focusing on the interaction with actors and humans? These questions clearly list the need of guidelines, methodology and expert support.

This paper intends to propose a model driven method that addresses interoperability in existing model driven methods. It recalls first how Enterprise Modeling transformed in Model Driven System Engineering Architecture (MDSEA) has contributed to pave the way from conceptual enterprise models to the implementation of systems in the enterprise. Then, it extends MDSEA to facilitate interoperability in the Supply Chain of ICT Systems (SC-ICTS). For that purpose, it elaborates the MDISE (Model Driven Interoperability System Engineering) that focuses on the vertical and horizontal interoperability model driven approach between enterprises while MDSEA remains focused on enterprise integration between internal domains (IT, Human/Organization, Physical Means) before connecting the different models. The paper concludes with some current development of the MDISE framework and method with ModelSystemToolBox (MSTB) that evolved in the frame of Interop-Vlab Task force. Finally, it gives some perspectives about the interest of MDISE in the frame of future Cyber Physical System (CPS) research works.

1.1. Problem Statement about Supply Chain Interoperability of ICT Systems

The supply chain is a system composed of organizations, people, activities, information, and resources involved in supplying a product or service to a consumer [2]. Physical Supply chain activities involve the transformation of natural resources, raw materials, and components into a finished product that is delivered to the end customer [3]. This work focuses on the ICT supply chain [4] (not the physical products themselves), which requires the management of data linked by computer components. In addition, on each link between ICT components, different types of resources are also involved, so different interoperability problems can arise. In the frame of Industry 4.0, a Cyber Physical System (CPS) [5] and its environment can be considered as relevant instances of SC-ICTS with the inherent needs of interoperability.

According to common definitions, supply chain management (SCM) is the management of the flow of goods and services and involves the movement and storage of raw materials, work-in-process and finished goods from the point of origin to the point of consumption. Here, we consider interdependent networks of goods or services, where ICT supply chain management is required to manage the channels and nodes for the delivery from source to end customers. To support services, SC-ICTS interoperability is widely recognized as a major concern for organizations [4] and companies [6]. More technically, SC-ICTS refers to data/information exchanges among ICT systems involved in physical supply chains or industrial systems. For instance, Tianbo Lu et al. [7] have defined an ICT Supply Chain as “the full set of actors included in the network infrastructure”. It includes end-users, policy makers, procurement specialists, systems integrators, network provider and software/hardware vendors that produce (big) data.

While they are booming, these systems face conceptual and technological barriers that can limit their adaption. The lack of interoperability is the cumulative effect of the increased sophistication of ICT, the scale of the information systems and the increasing speed and complexity of a distributed global supply chain. The lack of sufficient visibility and control throughout the ICT supply chain is making it increasingly difficult to understand the exposure of the enterprise and manage the interoperability associated with the supply chain. This, in turn, this increases the risk of miss-exploiting the supply chain through a variety of means, including materials, products, data and cyber physical resources and processes.

The authors in Reference [8] identified a demand for supply chain interoperability guidance. However, the ICT supply chain discipline is in an early stage of development with diverse perspectives on foundational SC-ICTS definitions and scope, disparate bodies of knowledge, and fragmented standards and best practice efforts. Additionally, there is a need to identify the available and needed tools, technology, and research related to ICT supply chain interoperability and better understand their benefits and limitations.

In brief, the SC-ICTS are not yet fully standardized or even well-defined. Yet, potential supply chain participants attempt to find or define terms, definitions, characterizations of the collaboration, but frequently fail to identify and evaluate current and SC-ICTS-related standards and practices (need, scope, and development approach). In consequence, a methodology that list models, tools, technology, and techniques useful in securing the building of ICT supply chain is still wanted. For that purpose, this paper will acclaim to join efforts with methodology to improve the efficiency of SC-ICTS interoperability based on a model and an approach to answer Industry 4.0 needs due to the hybrid/heterogeneous composition of CPS, they are interesting candidate nodes for this SC-ICTS approach.

1.2. Methodological and Technical Approach

According to the objective of identifying a list of models, tools, technology and techniques useful in building consistent and interoperable ICT supply chain, this section recalls components about enterprise modelling, interoperability and MDSEA, which contribute to building a Model Driven Interoperability for Systems.

1.3. Enterprise Modeling with GRAI Model

Enterprise modeling (EM) is the abstract representation, of an enterprise with its structure, the various functions, the processes, the information, the resources (physical and human), the management, the relationships with the environment (customers and suppliers) and all activities required to produce industrial products or services. The goal of EM is to represent (based on models) a system as it stands and improve its performances or to follow the evolution of the enterprise. Additionally, the relation of EM and integration domain has been considered [9].

Enterprise modelling concepts in industrial environment were developed, starting at the end of 1970′s, mainly in USA by the Department of Defense (DoD), in order to improve the competitiveness of the industry that seems at this period to be behind the competitiveness of the Japanese industry. A second reason was the more and more use of Information Technology (IT) in manufacturing and the appearance of a new way to design Manufacturing Systems: CIM (Computer Integrated Manufacturing). The DoD launched several projects in cooperation with industrial companies such as Boeing, General Electric, Westinghouse, IBM, Hughes Aircraft, Softech Inc, etc. One of the first formalisms developed to represent a part of EM concept in this new approach was the IDEF method (Integrated DEFinition) (IDEFx) [10], for which a series of formalisms were proposed. Among them: IDEF0 to represent functions and activities with a simple syntax and a hierarchical decomposition from a global representation of the enterprises to a detailed representation, IDEF1 to represent information and IDEF 3 to represent the logic of process execution, which can be used to develop a simulation tool.

At the same time, in Europe, the GRAI (Group of Research in Automation Integration) of the University of Bordeaux developed the GRAI (Graph with Results and Activities Interrelated) and also the GRAI model [11] to represent the manufacturing based on System Theory [12,13,14], the Theory of Hierarchical Multilevel System [15], which allows the decentralizing of the decision-making and to increase the reactivity, the Organization Theory [16,17], the Discrete event systems [18,19], and the Production Management Concepts [20,21]. Three subsystems are defined: physical (Figure 1 (transformation of purchased items and information in products or services), decisional (to control the physical system (Figure 1)) and information (to manage the creation and the exchange of information (Figure 2)). This research work was completed by a cooperation with the industry to validate the concepts: Télémécanique Electrique (in Nice) and Merlin Gerin (in Grenoble (today both in Schneider Electric), and Crouzet (in Valence) in order to improve the performances of workshops; SNECMA (today Safran) in Le Creusot to design a Flexible Manufacturing System (FMS), AMRI (near Bordeaux) to design a FMS and other companies such as Suez to improve the management of water distribution, Airbus Toulouse to improve the performance of a composite workshop, etc. In the last four years, the GRAI model and method have been extended to be applied in the domain of Services, but also to develop integrated solutions in the three domains: Information Technology (IT), Physical System and Organization/Human System called MDSEA (Model Driven System Engineering Architecture (see Section 3.4). At the same time, other methods appear, one major one is CIMOSA [22], which was developed in the late 1980’s. Additionally, IEM [23] and ARIS [24] have been largely used.

1.3.1. GRAI Model and GRAI Formalisms

The previous section focused on the main theories that have supported the creation of the GRAI model. This section describes the structure of the basic model and the formalisms to describe the enterprise.

The previous concepts allow us to consider the enterprise as a complex system that can be split up into two entities (Figure 1):

• the Physical System or controlled system (also called the transformation system) which produces the products or/and the services.
• the Decisional System (Control System) that controls the Physical System.

This systemic view introduces the concept of control loop. In Figure 2, the Information System is added to manage all the information.

Currently, GRAI Model uses various formalisms to graphically represent the components of a manufacturing system: physical, decision, and information.

Concerning the modeling of activities, two formalisms are selected: IDEF0 and Extended Actigram star: (EA*). In IDEF0 (Figure 3) there are four types of flows:

• Input, that represents the flow of entities which will be transformed.
• Output, that represents the flow of entities which have been transformed.
• Control, that represents the conditions or circumstances that govern the transformation (objectives, constraints…).
• Resource, that represents the resources required to perform the transformation.
• Extended Actigram Star (EA*) formalism is in line with IDEF0 and IDEF3 to facilitate the transformation of models from bottom Business Specific Model (BSM) level to Technology Independent Model (TIM) level [25]. The other GRAI formalisms are:
• Global level for the control using GRAI Grid formalism (Figure 4).
• Detailed level for the control using GRAI Nets formalism derived from EA* (Figure 5).

The GRAI grid is a formalism which represents the Decisional Sub-System. It is a matrix in which functions, decision levels, decision centers and decision links are identified as follow:

• The functions are represented vertically; a function includes a set of activities that contributes to the same purpose.
• The decision levels for these functions are represented horizontally and define the temporality of the decisions. The criteria of decomposition are the Horizon and the Period of time.
• Each cell represents a decision center, i.e., intersection between a function and a decision level.
• The decision frames represent the hierarchical links between decisions and includes all information for decision-making (objective, decision variable, constraint, and criteria).

GRAI nets (Figure 5) give the detailed description of the various activities in each decision center identified in the GRAI grid. By using GRAI nets, the result of one discrete activity can relate to the support of another discrete activity. With GRAI nets, four fundamental elements are to be identified:

• To do or to decide (activity name),
• Initial state (main input of an activity),
• Supports (information, decision frame, methods, and materials),
• Results (results of an activity).

The formalism used to describe the Information System is Entity/Relationship modeling proposed by UML (Figure 6). It describes the information structure in coherence with the decisional system.

Several IT tools have been developed to support the description of formalisms. The last one is the ModelSystemToolBox (MSTB), as described in Section 5.1.

1.3.2. BPMN

At more technical level, Business Process Modeling and Notation (BPMN 2.0) [26] language can be used. It is more complex to use than EA* but offers a wider range of detailed process modeling concepts. It is formalized in XML format, making model transformation easy. In addition, BPMN allows the representation of human and technical resources that are required in model driven approaches representation principles. BPMN has the advantage of providing a metamodel developed by the Object Management Group (OMG) that facilitates its implementation. Finally, it prepares the transition to the lower levels on the IT aspect thanks to its interoperability with many BPM IT platforms, thus allowing the deployment and semi-automatic transformation for the execution of BPMN processes.

1.3.3. Other Formalisms for Information System Design

With a more technical view of information systems than BPMN, the Open Group Architecture Framework (TOGAF) and Architecture-animate (Archimate) models can be used to capture other views at a more technical level. [27,28]. In details, the enterprise architecture frameworks TOGAF and ARCHIMATE propose different layers from business level to application level to design the Information System of organization. TOGAF with its ADM cycle highlights a step by step methodology to migrate towards a new information system consistently. It does not propose any languages and relies on existing ones and adapted such as UML. ARCHIMATE proposes different models at each layer (motivation, business, application, and technology) in addition to its framework. Let us note that the Archimate specification can be used with TOGAF to build expected models. While the languages proposed and deployed in these frameworks are fully adapted to develop an information system that meet enterprise expectations, they allow for the representations of different points of view but often in a less accurate way than a language fully dedicated and developed for a particular point of view. Some points of view are not considered by existing frameworks such as, for instance, the decisional and physical points of view. In addition, dedicated languages often go beyond the descriptive aspect and propose means to analyze and improve the system under study. This is the case, for instance, with the GRAI methodology that proposes formalisms (GRAI grid and GRAI networks) to model and analyze the decisional point of view of an organization.

1.3.4. Conclusions

Currently, EM is not used as expected in industrial world, particularly in Europe. It seems that in USA, the use is more important, certainly based on the influence of IDEFx. Education must be developed in this domain by elaborating examples based on the concrete experience with real cases. Another argument is the development of end-users-oriented and adapted IT Tools because they capture the knowledge on their own manufacturing system. For this purpose, the graphical modeling aspect and ease of use are very important. The last point is to link EM to other areas such as enterprise interoperability and the model-driven approach, which is the objective of what is proposed and presented in the following parts of this paper.

2. Interoperability

Enterprise Interoperability (EI) refers to the ability of interactions between enterprise systems. Numerous definitions co-exist [29,30,31,32]. Nevertheless, we can summarize and characterize EI from three main aspects:

• Heterogeneous systems that are not designed to work together. This aspect relates to the compatibility to make interfacing easier.
• Interaction allowing systems to perform collective activities in coherent way. This aspect relates to the interoperations i.e., a set of exchange, sharing of data, resources or activities.
• Independence and autonomy ensuring that systems are not deeply modified to collaborate. This aspect relates to remain autonomous (i.e., ability to collaborate while continuing its own operation and decision) and to keep being reversible (i.e., ability to go back to a previous organization or configuration).

The question of interoperability has been addressed by numerous initiatives for the last two decades. Primarily identified as a technical problem in information systems, interoperability is now studied from an organizational and a conceptual point of view [33,34,35,36]. It does not only focus on exchange and sharing of data, but also on resources or else between collaborative processes and can be structured into three main dimensions [37,38]. The combination of these three dimensions led to the Framework for Enterprise Interoperability [37], as shown in Figure 7.

2.1. Interoperability Concerns

This dimension includes the point of view to develop interoperability. Four levels are identified:

• The business level addresses the collaborative organization in terms of decision making, working methods or operation.
• The process level aims to connect internal processes and activities to build a collaborative process.
• The service level identifies various application or functions used in collaborative processes.
• The data level makes possible the exchange and sharing of heterogeneous data stemming from various data bases.

2.2. Interoperability Approaches

These approaches are defined by ISO 14258 [38] and highlight the way to develop interoperability. Three approaches are identified:

• The integration relies on the use of a common format through all collaborative organizations. It may concern the use of a standard in the form of a language or a modeling tool.
• The unification relies on the use of a “meta”-level to ensure the mapping between different formats used by organization. For this purpose, the use of a meta-model to map different domain specific language (e.g., semantic equivalence) is commonly used in Model Driven Engineering.
• The federation does not use a predefined single format or meta-model. All organizations get used to each other’s methods, data, and tools on the fly.

2.3. Interoperability Barriers

The barriers (also known as interoperability categories) are the problems of interoperability between the organizations. There are three types of interoperability problems:

• Conceptual barrier deals with the semantic and syntax of shared information [39]. It also includes the expressiveness of the information, i.e., its ability for expression (e.g., graphical modeling object rather than natural language).
• Technological barrier deals mainly with the compatibilities issues between application and Information Systems.
• Organizational barrier applies to the definition of responsibilities and authorization of involved actors. It also includes the authority, process, and regulatory aspects.

The combination of these three dimensions led to the Framework for Enterprise Interoperability [37], as shown in Figure 7.

According to ISO 11354-1 [31], and Chen and Daclin in Reference [37], beyond the structuration of the interoperability aspects, the framework allows to gather knowledge and solution to develop interoperability in organization. The integrated approach is the fastest approach to implement. From an historical perspective, it has been the first way to set up interoperability. However, it is the most constraining since each organization must adopt the same methods, models, or tool.

Nowadays, most developed solutions are unified. For instance, in the enterprise modeling domain, UEML (Unified Enterprise Modeling Language UEML) [40] and PSL (Process Specification Language) [41] languages support the interoperability between enterprise models and tools.

Lastly, the federated approach is little developed, but represents the most challenging approach and thatperfectly meets the enterprise interoperability requirements. The federated approach aims to develop full interoperability and is suitable for an inter-organizational environment (e.g., collaborative network organization). In the Enterprise Interoperability roadmap published by the European Commission [42], developing the federated approach for interoperability is considered to be one of the research challenges in the next years.

3. Model-Driven Approaches

3.1. Model Driven Engineering

The principles of Model Driven Engineering (MDE) emerged to face up the problem of growing complexity, multiplicity of platforms, need of interoperability and evolution to consider for software application design. The core principles are:

• The use of models (through modeling languages) as central object of the development process. Models allow to represent a system from different points of view/levels independently of any development or implementation. The principle of the model includes the notion of the meta-model and conformance as well.
• The use of model transformation to generate target model from source model. Several transformations are identified in MDE: exogenous (between different modeling domain) and endogenous (between the same modeling domain) as well as vertical (between different levels of abstraction) and horizontal (at the same level). The principles of the models’ transformations include the notion of mappings and transformation rules.

The principles of the MDE are synthetized in Figure 8.

3.2. Model Driven Architecture (MDA)

MDA is an initiative from the Open Management Group providing an approach to design and implement software [43] (Figure 9). It represents an implementation of the principles of the MDE defined previously and was launched in 2001. It provides a set of guidelines for the structuring of specifications, which are expressed as models. MDA is based on models, layers, and transformation from business models to implementation models. In that sense the MDA separate the business from the functional and lastly from the technical aspects for the development of an application. For this purpose, MDA relies on models defined at three levels, such as [44,45]:

• Computational Independent Model (CIM) includes business models that independent from any implementation or technology.
• Platform Independent Model (PIM) includes design models independent form any platform that represent the logical aspects.
• Platform Specific Model (PSM) includes the generated code that is executed onto a specific platform.

The transition from the CIM to the PSM via the PIM is based on transformations mechanisms following the principle of the MDE. The different layers of the MDA as well as the transformation are presented in the following figure [46].

3.3. Model Driven Interoperability (MDI)

Model Driven Interoperability (MDI) was developed by the Task Group TG2 of the Interop-NoE European Project to handle the interoperability problems from the enterprise models’ level to the technical level. The MDI provides a method relying on the Model Driven Architecture (MDA) approach [25]. The goal is to tackle the interoperability problem at each abstraction level defined in MDA and to use models’ transformations techniques to vertically link the different levels of abstraction or horizontally to ensure each model of the level interoperability (Figure 10). In the end, MDI allows for a complete follow from expressing requirements to the coding of a solution and a greater flexibility thanks to the automation of these transformations.

Interop-NOE TG2, with References [34,47], performed methodological experimentations, especially on the feasibility to transform GRAI models to UML between CIM and PIM levels. These works are additional to those performed within the ATHENA project to define UML profiles to consider Service Oriented Architectures at PIM level from conceptual enterprise models at CIM [48]. These results have been consolidated by the results in Reference [49] that proposed an interoperability transformation method from BPMN to UML in the context of service-oriented architecture.

The soundness of the methodology has been demonstrated, but without a full industrial scale validation fulfilment. In this frame only the ISTA3 project has demonstrated these concepts onto an industrial real-world significant application. The different methodological propositions were tested and refined by focusing on the model and its interoperability. It consisted of improving the flexibility of the MDI transformation process in the way of obtaining dynamic interoperability in the context of a federated approach.

3.4. Model Driven System Engineering Application (MDSEA)

Model-Driven Service Engineering Architecture, generalized and renamed as Model-Driven System Engineering Architecture (MDSEA) [50] (see Figure 11), is a recent engineering architecture proposed in the “servitization” domain and generalized in all kinds of production domains, such as the modeling context-based on Model Driven Interoperability (MDI) [25]. This architecture was developed in the MSEE project [51] (MSEE book, 2014) and used in the EC project BeinCPPS (www.beincpps.eu). The modelling of the components in the architecture is supported by the IT tool MSTB. The advantage of the MDSEA approach is to start from the concepts of a manufacturing system, which will be integrated in models to progressively overcome interoperability barriers.

MDSEA aims to refine and consider, regarding MDE, different views to be represented. MDSEA starts from an integrated and high-level modelling at Business Specific Model (BSM) level (Top BSM) with several integrated enterprise models. BSM Models can be based on GRAI (see Section 1.3) methodology and its formalisms. Let us note that not only the physical part (machines, people, etc.), but also the management part with the Decisional aspects is considered. The purpose of MDSEA is to model-various kinds of systems and support the development of its major components according to three domains: Information Technology (IT, i.e., software, device that handle data), Human/Organization (H/O, i.e., people that participates to the process and their organizational structure) and Physical Means (PM, i.e., machine or any physical tool). The transformations are supported by Model Transformation which is based on a sequence of Top-Down and Bottom-Up iterations: the more the progression towards the development of the solution, the more complementary and detailed information is necessary. One of the originalities of the approach is the transformation from one level to another level:

• From Business System Model (BSM) level (high-level abstraction adapted to the business point of view), to Technology Independent Model (TIM) level (technical point of view which is technology independent). From BSM models, it is necessary to extract the elements to design each of the three domains (IT, H/O, PM) to create three main categories of resources (Bottom BSM) (see “domain extraction”). Although these domains focus on specific type of resources, they are not completely independent and might overlap. For each domain, the model at TIM level is created by a transformation of the bottom BSM using Model Transformation.
• From TIM level to Technology Specific Model (TSM) level (detailed technical level resulting in the final development of components).

This approach starts with models that describe the function, the organization, the physical and the behavior of the desired data and processes exchange system at the business level to move then to TIM level. Nevertheless, the behavioral model needs to be enriched with the consideration of the data and processes exchange architecture. At TIM level the models will be run, and a first validation will be provided to the user. At TSM level, the behavior of the models will be extended by adding information about the architecture and different resource profiles. One novelty of the use of MDSEA is the use of feedback and validation arrows (green arrows and cycle loop in Figure 11) that comes from the bottom to the top to correct models that were considered invalid from a lower level due to the introduction of new constraints. Additionally, this ascendant information will be aggregated to form decision board making. It will be built from various indicators, taking their values from the operating level in digital companies. This methodology is implemented in the ModelSystemToolBox (MSTB), it was originally named SLMToolBOx in the MSEE project, as described in Section 5.1.

3.5. Modeling at the Different Levels of Abstraction

Based on the modeling levels just previously described, the methodology MDSEA proposed to associate relevant modeling languages at each level to represent confidently the existing system and the future service product and service system. To achieve this goal, the standards for process modeling are gaining importance, with several process modeling languages and tools available to enhance the representation of enterprise processes. To choose among the languages, the level of abstraction required is important.

The first specification step of a model to be established between two partners is crucial. At the BSM level, the modeling language must be simple to use, expressive and understandable by business-oriented users. Moreover, this (or these) language(s) must cover processes and decisions with coherent models. The choice is affected by the capacity of the language to propose a hierarchical decomposition (global view to detailed ones), which is especially required at this level. Indeed, business decision-makers often have a global view of the running system and need languages allowing this global representation with few high-level activities (physical process or decisional activities). This global view must be completed by more detailed activities models elaborated by the enterprise sector responsible. These models are connected to top level models in a hierarchical and inclusive way. These are the principles of systemic and system theory to consider selecting the languages. However, it is also obvious that the choice of modeling languages is subjective, depending on the experience of the languages’ practitioners and on their wide dissemination within enterprises.

As for process modeling at the business level (BSM), several languages exist. Extended Actigram* (EA*) presented in Section 3.1 was chosen to model processes at the BSM level due to its independence regarding IT consideration, its hierarchical decomposition and the fact that it can model three supported resources: material, human/organization and IT. It has been developed as an answer to previous issues encountered with IDEF0 regarding its interoperability with BPMN for example. It intends to capture business process models at a high semantic level, independently from any technological or detailed specifications. Service Oriented Modeling and Architecture principles [52], developed by IBM, were also considered, but these languages are more IT oriented and thus were far away from our industrial requirements.

At the TIM level, BPMN 2.0 is used because this language offers a large set of detailed modeling constructs, including IT aspects and benefits from the interoperability of many BPMN? IT platforms allowing for the deployment and automated transformation for the execution of BPMN processes. Moreover, BPMN also enables the representation of human and technical resources, which are required in the MDSEA principles of representation. BPMN also has the advantage to provide a meta-model developed by OMG, which facilitates the implementation of the language. It is also extensible with third party Metamodels, which is important and respects the OMG interoperability standards (e.g., Xmi).

In detail, GRAI approach is to be used by business representatives at BSM and BPMN at the TIM level. BPMN is used to be the backbone language between the business view and IT level. However, because the languages have different consideration and view on the system, it must be able to link them. In detail, the EA* models designed at BSM level need to be transformed into BPMN 2.0 models to obtain the coherent business process models at the TIM level.

3.6. Distributed Discrete Event Modeling and Simulation

The goal of distributed simulation is to optimize the use of resources, to work on remote resources and/or to reuse existing simulations, and more generally, systems, by interconnecting them. Distributed processing must guarantee interoperability, confidentiality, integrity, and temporal causal relations by using synchronization algorithms.

Distributed simulation is chosen to ensure the exchange of information between systems because it allows the processing of heterogeneous data coming from equally heterogeneous distributed systems without interpreting them. Moreover, it has mechanisms that allow the exchange of synchronized messages. It is only a means of conveying and orchestrating data exchange between systems, alternative to SOA. It is robust, executed at a low level. It can be expressed by discrete event models, such as DEVS [53] and completely explicit (synchronization algorithms; (Fujimoto, 2000)). The local execution (or simulation) and interpretation of the exchanged messages remain in charge of defining the behavior of the local SI and are not addressed in this study.

The High Level Architecture (HLA) [54] is a specification that defines a software architecture to create an overall software execution composed of simulations and distributed applications. This standard was introduced for the modeling and simulation of the Defense M&S Office (DMSO) of the US Department of Defense (DOD). The initial goal was the reuse and interoperability of military applications, simulations, and sensors/actuators in a real-world environment.

In the HLA standard, any participating application is called federated. Federates interact within an HLA federation (group of federates). The set of HLA definitions [55] led to the creation of a standard rated 1.3 in 1996, which evolved to HLA 1516 in 2000.

4. Contribution to a Framework and Method to Drive Interoperability within MDISE

The objective of MDISE is to more deeply use the MDSEA approach as a reconciliation facilitator between systems to interoperate in the frame of the supply chain while considering interoperability as a central concern regarding the three perspectives: Physical means, Organization/Human and IT.

While most of the modelling approaches focus on IT issues, the objective of the MDSEA is to better prepare human and organization domain, especially in the situation of data securities issues. The roles of each resource will be better described to have an appropriate reaction to interoperability barriers in the system. Additionally, the communication with machines, thanks to rising IoT, is one consideration of the models to be defined with MDISE. On the way back, validation or modification of models is introduced after having tested it at a lower level.

A very important new activity, valid for both MDSEA and MDISE, but never developed in previous version of MSTB, is the extraction of the elements from BSM TOP to prefigure interoperability issues to consider and design the IT, the Human/Organization and the Physical Means at BSM BOTTOM. MDSEA domain extraction included decisional aspects. MDISE is reusing the domain extraction from MDSEA. In addition, MDISE is considering the Horizontal and Vertical interoperability which is an extension of MDSEA. Interoperability between entities is clearly a core concern of MDISE. It also specifies modelling language for decisional modelling, expresses model transformation engine and simulation engine. As a conclusion, these propositions for MDISE will be implemented in the MSTB Evolved, presented in Section 5.

In more detail, according to Figure 12, a different approach can bridge the gap from one enterprise to another in terms of interoperability. The resources, including human, belong to different entities, profiles of knowledge and skills regarding process activity to be handled that might raise barriers at the frontier between the two enterprises. According to these profiles, a specific call for action can be proposed according to the capacity to handle technical and IT actions regarding the user profile.

• Nevertheless, no orchestration is done between process and participant of two distinct entities. Moreover, it cannot be set a common rigid hierarchical organization structure. The idea of the new MDISE is to better prepare and support resources (IT, Physical Means, human) in this situation to reach a better response time.
• Data are structured according to internal needs and logic, so that this specific structure cannot be easily passed to another participant in the B2B relationship. With the aim of reinforcing interoperability and confidentiality, the process at the frontier between enterprises can learn from good practices established in past similar situations.
• Another objective is the use of the simulation to validate scenarios before implementation of solution. It is essential to save time and budgets. In the previous projects, the simulation is mainly used to verify properties of process scenarios.

In MDISE, the interaction with humans will be better modelled and proposed as a serious game in the MSTB to train users and to improve the capacity to react to situations.

4.1. Vertical Decomposition: Towards Alignment from Business to Operational

Considering resource domains while modeling at the bottom BSM helps to anticipate how the different kinds of resources will be called, how they will interact with the other components of the system and how they will be used to perform the process. Nevertheless, it requires an extraction strategy by choosing appropriate methods and models to get their specificity properly.

Figure 12 shows the interest of such architecture that is to design and implement a service product and to produce a dedicated service system coherent with business service models, represented with enterprise models. Looking at TIM and TSM levels shows how the methodology differentiates three kinds of resources categorized into IT, Human and Physical Means. The reason is to tackle the different requirements of resources at the implementation stage of the service system. Then, the implementation of the resources detailed in the TSM model allows for the implementation of the service system and related service product through a set of services, i.e., a system in which the service provider (an enterprise inside a network, or in a cloud of service providers) is not directly identified by the customer, which can only remain interfaced with a service delivery. The service maintenance and decommission activities can be ensured by different companies in the network without direct identification by the customer. However, the virtual organization keeps the property rights on the services.

• About IT domain, several model languages exist. GRAI introduced at the beginning of the paper has demonstrated the capacity to tackle modeling aspect from the decisional perspective at the BSM level. At the lower level, UML can be used to describe more technical views.
• About Physical means, some physical models can help to better catch the behavior of machines used in the systems. It can include performance models as well as other expressed properties thanks to physical and mathematical models to be considered in this part of the model. This topic is being discussed in several interoperability projects (I-VLab (http://interop-vlab.eu/projects-i-vlab/)), including the DIH4CPS project [56].
• About human and organization, we believe that holacracy, which is decision-making distributed throughout a holarchy of self-organizing teams, can bring people to work together. The challenge is to catch and model holacracy systems.

It is important to mention that the service system represented at each level of MDISE remains the same system, but with details and including more or less implementation constraints. Nevertheless, after having described each category of resource with appropriate models, another challenge is to deal with the coupling of these models together. For this aim, interoperability plays the role of gluing them together.

Additionally, in Section 5.1, MDISE vertical decomposition will be implemented in MSTB Evolved as an open source tool extended to cover new category of models introduced in the next section. The new level of description introduced here will be considered as well, such as decisional models in addition to process models and human machine interaction in the interoperability management lifecycle. The service approach will keep driving this development [57].

4.2. Horizontal Alignment: Towards Interoperability for Better Collaboration between Service Network

Figure 12 shows the collaboration between two enterprises to produce a service. Collaboration between different entities can happen at different MDSEA abstraction levels (BSM, TIM, and TSM). The BSM models allow to represent the TO BE models of both entities and to align the interoperability of practices in terms of business process models and decision models. In MDSEA, interoperability is a key factor for enterprise collaboration. Enterprise models ensure not only interoperability of practices, but also between the human resources and IT systems supporting these practices.

• Business Service Model (BSM): BSM specifies the models, at the global level, describing the service running inside a single enterprise or inside a set of enterprises as well as the links representing cooperation between these enterprises. The models at the BSM level must be independent of the future technologies that will be used for the various resources and must reflect the business perspective of the service system. In this sense, it is useful, not only as an aid to understand a problem, but also it plays an important role in bridging the gap between domain experts and the development experts who will build the service system. The BSM level allows for the defining of the link between the production of products and the production of services.
• Technology Independent Model (TIM): TIM delivers models at a second level of abstraction independent from the technology used to implement the system. It gives detailed specifications of the structure and functionality of the service system, which do not include technological details. More concretely, it focuses on the operational details while hiding specific details of any technology to stay independent from any technology, used for the implementation. At TIM level, the detailed specification of a service system’s components is elaborated with respect to IT, Organization/Human and Physical means involved within the production of the service. It is important to mention that, in comparison to MDA or MDI or SOMA (Service Oriented Modeling and Architecture), the objective of MDSEA is not only IT oriented and then this requires enabling the representation of human and technical resources from the BSM level. At the TIM level, the representations must add some information in comparison to the BSM models.
• Technology Specific Model (TSM): TSM enhances the TIM model specifications with the implementation details of the system, i.e., how it will use a specific technology or physical means (IT applications, machine or a person) for delivering services in the interaction with customers. At TSM level, the models must provide sufficient details to develop software applications, hardware components, recruiting human operators/managers or establishing internal training plans, buying, and realizing machine devices. As for IT applications, a TSM model enhances a TIM model with technological details and implementation constructs that are available in a specific implementation platform, including middleware, operating systems and programming languages (e.g., Java, C++, EJB, CORBA, XML, Web Services, etc.). After the technical specifications given at TSM level, the next step consists in the implementation of the service system in terms of IT components (Applications and Services), Physical Means (machine or device components or material handling), and human resources and organization ensuring human related tasks/operations.

Initially, the interoperability models developed in the MDI focus on the principles of “mappings” to establish interoperability. In that sense, it implements the unified approach and requires the linking of concepts and relations of heterogeneous modelling languages, for example. This kind of approach is robust but time consuming, with a possibility of a partial overlapping of languages (e.g., one concept does not exist in both) requiring the extension of the languages and to develop transformation rules that can change if languages change.

Thus, this approach is completely relevant, especially for collaborative organization mid- and long-term-oriented, i.e., stable over time and for which the intensity of the collaboration tends towards cooperation and collaboration and an important level of integration, according to Reference [58].

In the frame of MDISE, the purpose is to extend the MDSEA and MDI principles to a federative approach to develop interoperability. This means to prevent, as much as possible, any common format or predetermined model, and each partner keeps its own organizational structure, business processes, tools, data format, etc.

To this end, the goal is to create an interoperability model to insert between organizations. This model aims to identify and allow interoperability independently of the models, organizational structure or physical means used by partners. This model can be initiated with known and simple but limited mappings (or any other basic mechanisms) to avoid reaching a unified or integrated approach. Thus, it must be built on the knowledge about the characteristic of partners without any (or at least strictly limited) modification or adaptation. These characteristics are the interfaces (I/O) requested for the collaboration (functional and/or physical), human resources, data, models, etc., allowing for the establishment of consistent interaction. Thus, the proposed interoperability model does not take any interest in the modelling language, organizational structure or physical means used by partners and does not aim to establish a strict mapping or equivalence between them. It aims to build a transient interoperability bridge based on the identification and the analysis of knowledge, constraints, and specific features stemming from partners. It should be noted that the principle to build a “centric interoperability model” approach to the “mutual adjustment”, mentioned in Reference [59], thus fits the federated approach of the interoperability framework.

Therefore, whether for the IT, the Human/organization or the physical means domain, this model can be considered in two ways:

• A “component mode” relying on Commercial Off-The-Shelf (COTS) sufficiently generic to be deployed in different organizations. These bricks are pre-existing basic models (or skeleton) from identified and known interoperability situations. These atomic COTS belong to a set and can be combined to provide a complex COTS to establish interoperability in specific situations. They cannot be modified and are used from identified characteristics and requirements of the collaboration such as the synchronization, integrity, quality, or quantity of data. For instance, the buffer is a well-known mechanism that can be used for the IT domain to allow a synchronization between two processes.
• An “emergent” mode relying on a model built on the fly for complex requirements and constraints making the direct use of “component mode” impossible. In this case, the model is based on rules allowing for the building of interoperability from scratch. These rules are built from the specificities of the collaboration in terms of IT, organization, or physical means. These primo rules set can be raised with other discovered rules. In that sense, the use of techniques from Artificial Intelligence (self-learning, process mining, data mining, etc.) is an important challenge for this approach. Moreover, an interoperability model highlighted in the emergent mode can become a COTS in the component mode if it appears regular in different collaborative organizations. Thus, the purpose of this mode is to be free from any components—once a component deployed for interoperability it cannot consider modification of organization—and make a dynamic adaption possible in the case of the modification of partners and entailed constraints on the collaboration. For instance, the short-lived ontology can be used for the interoperability of data in the IT domain, it uses an ontology valid for a limited duration. At the Human/Organizational level, the principles of the holacracy and its concepts of circles and roles can be considered, by way of an adaption for the interoperability purpose, to make different organizational structures (hierarchical, functional, matrix, etc.) interoperable. Thus, by identifying actors from both sides, the definition of rules could authorize the building of time bounded circles and allowing for a coherent interaction between persons without any modification of internal structures. For the physical means domain, take the example of a floppy disk. The principles are to build a set of data that physically describe the system. The description of the object can be based on physical data (e.g., dimension), which is data related to the business or stemming from an image analysis. From this step, other partners can anticipate the reception of the object and be prepared to exploit it.

Lastly, both modes, “component” and “emergent”, can be used in a complementary manner. The interoperability model can be initiated with existing components and continued with emergent ones if requested.

5. Implementing MDISE Framework and Method in MSTB Evolved

As an historical perspective, to operationalize the models from BSM to TSM [50], the work in Reference [60] proposed the frame of the EU FP7 Research Project MSEE “Manufacturing Service Ecosystem” ID 284860 (http://www.msee-ip.eu/). The authors of References [50] introduced the implementation of the SLMToolBox that is a service graphical modeler, model transformer, and simulation engine. Since then, SLMToolBox has been improved and renamed MSTB. This tool has been implemented as an Eclipse RCP service. In detail, it runs the transformation from service processes models designed by business users to BPMN models. Then, the BPMN models are transformed into DEVS models to simulate the behavior of the entire process model. Thus, MSTB aims at proposing a TO BE process oriented modeling framework to represent the architecture and data workflows that exist in the ICT supply chain at the TIM level of MDSEA.

Therefore, to meet the expectation expressed in the paper, an operationalization of MDISE to extend MSTB according to the MDISE methodology is under development. This will allow for the identification and modeling of the enterprise frontier that can be initially poorly compatible with the environment and potentially places the interoperability barriers in organizational relations, including managing multi-tenancy, multi-providers, and system/service continuity. In addition, it will make a methodology available to model the planning and execution to mitigate or avoid interoperability issues during the whole lifecycle, such as considering the evolution of ICT from both IT and OT points of views. Models will identify and highlight the need for interoperability. It will help users mitigate barriers to interoperability using models and simulations to manage exceptions and ensure business continuity. The objective is to prevent an ICT interoperability issues occurring during production or manage it with short business resilience duration. The new version of MSTB is called MSTB Evolved.

5.1. Models & Model Transformation in MSTB (BSM Level)

To show the usability and applicability of MDISE and MSTB Evolved in SC-ICTS, the methodology is detailed in this sub section. First, the conceptual workflows from the requirements established at level BSM are defined. Then, it prepares the technical works for the implementation of the information system.

5.2. Using GRAI Grid and Extended Actigram* at Top BSM

Among the different systems, complex systems (systems of systems, and eco systems) and organizations, the GRAI Grid focuses on modeling the decisional aspects of the management. The proposition in MDISE is to use the GRAI grid at the top of the BSM to define the coordination and interoperability of two enterprises, detailing the points where decisions can be made (decision centers) while participating and the information relationships among these. In the frame of MDISE, Models built using the grid allows for the analysis and design of how decisions are coordinated and synchronized at the frontier of two enterprises.

As for process modeling at the business level (top BSM), several languages exist. EA*, introduced in Section 1.3, and were chosen to model processes at the BSM level due to its independence regarding IT consideration, its hierarchical decomposition, and the fact that it can easily model three supported resources: material, human and IT. It was developed as an answer to previous issues encountered with other enterprise modeling languages regarding its capacity to represent interoperability [50]. However, EA* is chosen to capture business process models at a high semantic level, independently from any technological or detailed specifications in MDISE. Service Oriented Modeling and Architecture principles [61] developed by IBM were also considered, but these languages are more IT oriented and thus were far away from our requirements. EA* provide at top BSM a common and explicit graphical notation for business process modeling of enterprises interfaces within MDISE, so it fits business-oriented people requirements, who need to describe and communicate high level business processes involving enterprise resources with the help of a simple and explicit formalism. In comparison to other initiatives such as BPMN2.0, it relies on a reduce set of graphical objects and focus on the “business” aspects of enterprise processes. The accessible syntax of EA* facilitates the design of business process.

To recap, at the Top of BSM in MDISE, GRAI Grid and EA* facilitate the modeling of business process and decision at the interface of the enterprise with its environment, offering a scalable view of the decision and process modeled. This level is addressed to users responsible of the creation of the first model, businesspeople responsible of the management, and to technical developers responsible of the development of business process modeling tools. As a graphical modeling language, EA* and GRAI Grid provide business users and analysts standards to visualize business processes in an enterprise, and thus in a comprehensible way.

5.3. Domain Specific Languages at Bottom BSM

At the Bottom BSM, the approach needs to identify and catch different concepts related to the domains: IT, Human and Physical means. To capture these concepts, models can facilitate description and abstraction. However, it is required to keep a simple set of modeling notations comprehensible by business users. This methodology will drive the BSM concepts down to TIM still independently of technologies. The proposition provides models to express each domain. Even at BSM, models will have to consider input/output information coming from the workflow along the supply chain. To support stakeholders, this methodology will make a library of potential interoperability solutions available to handle them; they will be used to stress the models and simulate interoperability management scenarios to evaluate their interest.

According to Section 4, and at this MDISE stage, it is required to integrate domain specific models with a process-oriented way for each domain Human, IT and Physical means:

• At collaboration time, no orchestration is formalized between participant of two distinct entities and without any organizational structure between the enterprises. The idea of MDISE is to better train and support humans in this situation to reach a better response time in critical situations. The proposition takes advantage of holacracy structures and rules. Holacracy rules must be described by models. These models will provide a framework to help to customize the specific processes need for business process interoperability. The holacracy consists of four key tools: 1. Rationale, 2. Role, 3. Tension and 4. Meeting formats. These tools can be described with GRAI Net models introduced in Section 1.3.
• Each data used by stakeholders have specific structure that leads to semantic issues. The use of a short lived ontology concept [62] can tackle this barrier. Short lived ontology fits the federated Enterprise Interoperability approach highlighted in the EIF. It uses no common persistent ontology; the communication must be accommodated on-the-fly. In consequence, the ontology that structures the messages exchanged must be short-lived (i.e., non-persistent). EA* diagram from GRAI can be used with the notation of the ontology validity period and eventually rules to set and modify the validity.
• Finally, the physical means interaction processes that happen at the frontier between enterprises can be learned from good practices established in the past, in similar situations. Here, GRAI EA* models can be obtained from the process discovery approach to reveal interesting behavior from the legacy practice. For instance, process mining is an automated, data-driven AI technology that finds maps and documents of existing businesses tasks thanks to existing data.

5.4. Interface Process Model at TIM Level

This sub section focuses on the modeling of data workflows at the TIM level of MDISE. This task will select accurate language to the TIM level of modelling. These languages might be potentially specialized to clearly represent the data exchange. These data workflows will be derived thanks to the ATL model transformation from the bottom BSM conceptual models of Section 5.1. They will describe the data circulating from an operative level of ICT up to the decision department, as well as outside the enterprise along with other enterprise partners. The appropriate modelling language will allow for describing after the domain extractions of Section 4 data, handled both by human/organization with user devices, smart machines, and IT with M2M, at the technological independent level. It will also propose a methodology to transform these models inherited from the bottom BSM models proposed in Section 3.1. BPMN appears to be the most appropriate language due to its expressiveness, user-friendly description and large user community. It would be the basis, enriched with specific concepts related to data security.

According to the partners’ experiences and literature, the most appropriate domain patterns can be defined here. Among them, at the TIM level, BPMN 2.0 (introduced in Section 1.3.2) can be chosen to model the connection of the domains because it offers a large set of detailed modeling construct, including IT aspects and benefits from the interoperability of many BPM IT platforms allowing the deployment and automated transformation to the execution of BPMN processes. Moreover, BPMN also enables the representation of human and technical resources, which are required in the MDSEA principles of representation. BPMN also has the advantage to provide a meta-model developed by OMG, which facilitates the implementation of the language.

5.5. Interoperability Model Orchestration at TIM Run Time

According to previous works published in References [50], MDSEA was already instantiated to use the simulation to support decision-making. In this paper, the authors considered the supply chain context and looks for interoperability of different simulations derived from domain specific models of Section 5.1. According to Figure 13, the first step of the decision-making cycle is started by the decomposition of the decisions and the information (e.g., simulation needs and Performance Indicators (PIs) related to interoperability objectives) supporting those decisions. This step can be performed using decisional modelling methods such as GRAI Grid (see Section 3 description). Then, several simulation solutions should be selected according to the required information treatment (see (2) in Figure 13). For instance, in a manufacturing system, the decision at a strategic level can deal with the choice of handling correctly at the frontier between two enterprises the structure of data. Therefore, the simulation needs a distributed approach gluing together different simulations coming from different domain specific models. The solution intends to provide an overall mechanism to overpass interoperability barriers according to situations in the ICT supply chain domain for a given period.

As discussed in Section 3.4, the distributed simulation and HLA standard can be used to overcome these barriers. HLA is providing interoperability regarding data and time management. Then, the methodology can provide facilities the transformation of TIM workflow models into distributed discrete event models (e.g., HLA DEVS; FMI/FMU [63]) to support data exchange scenarios between domain specific simulations in order to dynamically observe the behavior of domain specific models coupled to orchestrate data exchange thanks to the run of these models. Practically, the methodology will propose a reference ICT model library to support a quick set up of the data exchange models according to the class of organizations that participate in the ICT supply chain. Of course, the library of dataflows models should include the features to integrate the main interoperability flaws and solutions described at the TIM level in the modelling and simulation data scenarios. The MSTB Evolved, will implement these models and simulation. MSTB Evolved is under development but has not been released yet by the international group of researchers. This work is done in the frame of TF2 Model Driven Interoperability, Engineering and Simulation of Interop V-Lab ([64], p. 2).

After the simulation, it is usually required to aggregate the results according to the same criteria of decomposition or enterprise layers (see (3) in Figure 13). In the above example, the information about data interoperability barriers should be classified and aggregated based on annual objectives of data reliability, category of barriers faced and fixed, overall cost of data security interoperability, etc. The simulation models enabling the “simulation-aided decision-making cycle”, can be the result of transforming physical subsystem models (e.g., ICT data processing models). The modelling work can be guided by ICT ecosystem techniques. The next step consists in connecting the conceptual models to the level that considers the architecture and the platform environment (e.g., IT/OT). Considering the structure of the ICT supply chain system described in Figure 13, each stakeholder receives information from partners or from physical subsystems. It forms several data processes.

In the data exchanged described previously, interoperability issues can occur, where it can be vital to prepare the ICT ecosystem to react, evolve and adapt. A simulation-aided decision cycle can be used to validate process behavior scenarios. We propose a lifecycle in Figure 13 to train ICT stakeholders facing different threat situations. Here, we emphasize on the importance of a modular structure, covering and connecting different enterprises faced to interoperability barriers. The use of simulation tools is a decision aid approach to keep business continuity and business resilience. Then, in ICT systems, it is not always possible to simulate the whole data process at the operational level due to the amount of information at runtime; thus, an abstracted scenario of interoperability cartography will be run in anticipation to observe the global behavior of the system in order to prevent business continuity breaks.

5.6. Physical Infrastructure Interoperability Model at TSM

The TSM level is performing a holistic and technical-oriented Interoperability Analysis, on all ecosystems SC-ICTS, including data workflows model of interconnected supply chains and based on Section 4. To do that, this task proposes to implement the Interoperability Assessment Method based on good practices requirements, on the compliance of all relevant regulations’ requirements like NIS, ISO 27001 series [65], including sectoral regulation such as ISO 21434 automotive regulation [66] and focusing on combined and sophisticated interoperability analysis.

This interoperability assessment methodology is adapted to such a complex ecosystem with interlaced business manufacturing processes and value networks. It includes stakeholder criticality assessment regarding their accountabilities, roles and accesses during production, supply chain, business continuity and crisis management, and multi-tenancy management. The aim of this level will be to ensure interoperability coherence regarding all interfaces and interdependencies present in this complex ecosystem at all OT and IT levels, i.e., from RTUs, PLC, DPC, SCADA, ICS, OT, to IT and Cloud, and at the interfaces between IT, OT, security and safety infrastructure in order to highlight ecosystem interoperability requirements.

This level will also propose a GAP analysis and deployment plan based on models defined in previous sections and available data. It will start from the identification of known potential technical issues in the ICT domain. Then, it will include the proposition of a list of prioritized actions according to issue categories described at the TIM level. The objective is to identify from the recent research some data interoperability threat description, and to anticipate reactions with the list of actions to recover. It will prepare the action of implementation according to models of anticipated interoperability issues. If the interoperability issues were not to be fully anticipated at the modeling time, the models can describe some interoperability exception handling and management that can be developed in implementation works. In that case, the resilience, to permit to keep ex-changing data in a degraded mode operation, will be described.

The interoperability evaluation et TSM principle is based on the comparison between the current situation (As-is Top BSM Model coming from Section 4.1), the projected situation (To-be bottom BSM Model from Section 4.1) and Interface Process Model at TIM Level (Section 3.4). It is prepared from previous level to identifying more quickly and efficiently the interoperability levers at TSM and actions to be carried out to eliminate this gap.

The impact assessment will lead to the choice of an appropriate action at the TSM level. The depth of analysis to be conducted will be driven by the data structure and workflow paths. Indeed, the understanding of the existing situation and especially the analysis of the gap and the levers to implement require the relevant use of methods and tools for diagnosis and problem-solving. This task will ensure to keep in sight the business level in the technical project and to prepare implementation works. The second phase will be performed to revise, upgrade and improve the results to refine the target architecture.

5.7. MDISE and MSTB Evolved for CPS

Cyber-Physical-Systems (CPS) combine digital and analog devices, interfaces, networks, computer systems, with the natural and artificial physical world. They are therefore an interesting area for experimenting with the conduct of SC-ICTS interoperability. Inherent combination of interconnected and heterogeneous behaviors of CPS falls naturally in the scope that needs interoperability in their ICT supply chains so it is a clear challenge for MDISE and MSTB Evolved.

MDISE support ICT interoperability processes modelling, workloads, and performances, as presented in Figure 14, that details CPS concepts within the MDISE approach. To facilitate and validate this user modelling step, the MSTB Evolved tool will support the user-friendly assessment of the AS-IS as well as the TO-BE models of CPS environment models according to GRAI models in MDISE. The tool will help to populate models with different data exchange scenarios. With that objective, a user interface will allow the setting of these data. Among the MSTB improvement, MSTB Evolved will propose an enhanced graphical user-friendly interface including a set of description components and annotation features to easily define the detail of the decisional model of the control system and data workflow models of the physical model and their potential interoperability threats in the ICT system.

MSTB Evolved will propose a library of model templates presenting classical activities of data exchange for CPS at the BSM top and bottom levels. For instance, the different category of connection between different types of actors will offer predefined components. Finally, MSTB Evolved will embed a model transformation engine that will facilitate the creation of the reference framework of Figure 14. In addition, the matching algorithms (Figure 14 blue arrows) regarding MSEE version will be revisited as well as a new version of the simulation engine (Figure 14 red arrows) will be proposed. The MSTB Evolved will be released as an open source tool to reach a broad adoption of a community of stakeholders. ROI for partners will be based on the customization of the tool, facilitated model building and training of future stakeholders.

6. Discussion

We proposed a guideline for interoperability modeling, model transformation, and simulation. This work will help the fine models setting for the simulation and following the runs of scenarios in MSTB of potential SC-ICTS TO-BE situations to anticipate and/or correct interoperability issues. The proposition is to give more than simulation results with some aggregated information as a decision support in terms of efficiency of interoperability handling management. In detail, the simulation will be used to run interoperability scenarios on the AS IS Models. Then, several anticipation models will be run to observe the efficiency of different interoperability plans anticipated and run to observe the gain of data interoperability. Some indicators will be implemented to observe and measure the interest of the TO-BE model proposition before going to the implementation phases at the TSM level.

The proposed extension of the Model Driven Interoperability is compatible with the concept of full interoperability based on federative approaches, loosely coupled organization and reversibility concept. The main expected benefit is to remain independent of the means used within the IT, human/organizational and physical means domains of partners. Another benefit for partners is to preserve their means by limiting the needs to strongly modify or change their means to interoperate. Conversely, the drawback is the impact of the federative approach onto the partners and the collaboration. First, from the horizontal perspective, the federative approach means to be efficient in terms of time and quality to build dynamically a model and to adapt it in case of modification from a partner. Indeed, when “something” is issued from a partner the developed interoperability must not disadvantage the collaboration in terms both of time and quality of services. Second, from the vertical perspective, the approach must be also effective to disseminate consistently the modification of higher level (BSM) toward lower levels (TIM and TSM). That means, if a new interoperability model is built, the consequences must be transmitted onto the lower models. For this purpose, mechanisms of dynamic verification and validation must be implemented at each level and between levels.

Lastly this approach fits in with the industry 4.0 principles. Especially, it takes an interest in the cyber physical system, data analysis and internet of things. Indeed, the building and the adaptation on the fly of an interoperability model depends strongly on the information collected, analyzed and treated acquired from each partner. MSTB will evolve to analyze and design of SC-ICTS and CPS. There is a challenge to keep MDISE aligned with latest development in Industry 4.0 Cyber physical System.

7. Conclusions

The paper presents a framework and a method to guide enterprises in interoperability design when they are involved in SC-ICTS. The contribution started by recalling enterprise modeling, interoperability concepts and model driven approaches. Then, based on MDSEA, it defines the model driven framework MDISE and methods dedicated to interoperability specification and conception in B2B situation. It details the different levels required to model interoperability. It starts by top BSM models where associated recommendations to use GRAI Grid models are proposed. Then, it proposes to perform a selection of domain to be represented and modeled at bottom BSM. Considering that the method needs resilience to be aware of the trends in both domains, to design a holistic and interoperable architectures based on specificity of Human/Organization, IT, and physical means. It drives the business requirements of the platform to the technical architecture. Then, as a transversal task, it proposes to design a conceptual high-level business-oriented interoperability simulation approach, focusing on data and services to be exchanged between domains in the platform.

In the second part, this work encourages modeling tools (such as MSTB) to evolve in order to describe dataflows models and architecture to be set up between enterprise partners at BSM and TIM. Guidelines are proposed to drive models between BSM and TIM to provide a Data Driven methodology. Then, some appropriate modeling recommendations to overcome interoperability issue of CPS handling both at design and run time at TIM level are described. At the end, a holistic business-oriented interoperability modelling toolset about the B2B relation in an SC-ICTS ecosystem, including potential interoperability needs has been described. It remains that metrics must be defined to attend and validate interoperability models derived along the approach.