Benoit Loger
email: benoit.loger@imt-atlantique.fr

Guillaume Massonnet
email: guillaume.massonnet@imt-atlantique.fr

Fabien Lehuédé
email: fabien.lehuede@imt-atlantique.fr

Alexandre Dolgui
email: alexandre.dolgui@imt-atlantique.fr

Stefan Minner
email: stefan.minner@tum.de

Burakhan Sel
email: burakhan.sel@tum.de

Robust inventory management under joint demand and lead time uncertainty

Keywords:

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Today, the growing importance given to the reactivity of production systems and service level places the efficiency of supply systems at the centre of companies' concerns. Among the various factors influencing the performances of supply systems, the impact of different sources of uncertainty has been the focal point of many research work for many years. Most of the existing works consider uncertain demand or delivery lead time. Although some works are interested in the integration of these two sources of uncertainty [START_REF] Ben-Ammar | Supply planning and inventory control under lead time uncertainty : a literature review and future directions[END_REF], these works are most often based on restrictive assumptions : 1) demand and lead time distributions are assumed to be known 2) discrete lead time are approximated by mean of continuous distributions 3) autocorrelation of demand and dependencies between these two sources of uncertainty are ignored. In many real-world problems, uncertain demand follow autocorrelation patterns, and in some cases, the lead times are influenced by the demand of previous periods. Indeed, a succession of high demand leads to a saturation of suppliers and thus increases delivery lead time. In practice, not taking these correlations into account in procurement policies can lead to sub-optimal decisions and loss of efficiency.

Robust optimization approach

In supply problems, it is not uncommon for the classical models aiming to optimise the average performance of systems to be replaced by approaches allowing performance guarantees to be obtained. Although the first works in this direction date back to the 1950s [START_REF] Scarf | A min-max solution of an inventory problem Studies in the mathematical theory of inventory and production[END_REF], the recent development of Robust Optimisation ( [START_REF] Ben | Robust convex optimization[END_REF] and [START_REF] Bertsimas | The price of robustness[END_REF]) have led to the development and application of new approaches to supply management. [START_REF] Bertsimas | A Robust Optimization Approach to Supply Chain Management[END_REF] applied the approach of [START_REF] Bertsimas | The price of robustness[END_REF] to a singleproduct, multi-period supply problem with uncertain demand in single-and multi-echelon supply systems. Since then, a lot of papers have extended their works and studied robust approaches to inventory problems. [START_REF] Mamani | Closed-Form Solutions for Robust Inventory Management[END_REF] have extended this work using different uncertainty sets. However, these latest contributions focus mainly on product demand uncertainties. The problem of delivery lead time uncertainty has been little studied in a robust context. The work of [START_REF] Thorsen | Robust inventory control under demand and lead time uncertainty[END_REF] is the only one to propose a robust approach by considering uncertainties on the demand and the delivery lead time. Unlike the previous work, the robust model is solved using a column and constraint generation method, allowing us to obtain less conservative robust solutions. However, uncertainties in demand and delivery lead time are modelled by two separate uncertainty sets, ignoring possible dependencies between these two sources of uncertainty, and the demand is supposed to be i.i.d. over the different periods.

Contribution and initial results

Our work focuses on developing robust models and the definition of uncertainty sets that allow the integration of demand and delivery lead time uncertainties. We consider a periodic review inventory model for a single product over a finite planning horizon when demand backlogging is allowed. The obtained robust model defines the quantity to order at each period and is solved with a constraint and column generation algorithm. The objective function minimizes the sum of unit ordering costs, holding costs, and backlogging costs over the planning horizon. We study the impact of different correlation assumptions on the proposed robust solutions (demand autocorrelation, dependencies between demand and delivery lead time) and propose different approaches to incorporate these correlations into an uncertainty set that jointly controls demand and delivery lead time. The proposed solutions are evaluated and compared according to economic criteria such as worst and average costs as well as service level.


Hezam Haida

Nicolas Daclin
email: nicolas.daclin@mines-ales.fr

Gregory Zacharewicz
email: gregory.zacharewicz@mines-ales.fr

Guy Doumeing

Hezam Haidar
email: hezam.haidar@interop-vlab.eu

Guy Doumeingts
email: guy.doumeingts@ims-bordeaux.fr

Enterprise Modeling and Simulation

Keywords: Enterprise Modeling and Simulation Modeling and simulation, Enterprise modeling, Graph with Results and Activities Interrelated (GRAI), Business Process Modeling and Notation

Enterprise Modeling

Hezam Haidar, Nicolas Daclin, Gregory Zacharewicz, Guy Doumeingts.

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 [START_REF] Vernadat | Enterprise modeling and integration[END_REF].

Enterprise modeling 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: computer-integrated manufacturing (CIM). The DoD launched several projects in cooperation with industrial companies such as Boeing, General Electric, Westinghouse, IBM, Hughes Aircraft, and Softech Inc. One of the first formalisms developed to represent a part of EM concept in this new approach was the IDEF method (integrated definition) (IDEFx) [START_REF] Laamanen | IDEF standards[END_REF], 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 Group of Research in Automation Integration (GRAI) of the University of Bordeaux developed the graph with results and activities interrelated (GRAI) and also the GRAI model [START_REF] Doumeingts | How to decentralize decisions through GRAI model in production management[END_REF] to represent the manufacturing based on system theory [START_REF] Moigne | La théorie du système général. Théorie de La Modélisation[END_REF]12,13], the theory of hierarchical multilevel system [START_REF] Mesarovic | Theory of hierarchical, multilevel, systems[END_REF], which allows the decentralizing of the decision-making and to increase the reactivity, the organization theory [15,[START_REF] Simon | The organization of complex systems[END_REF], the discrete event systems [START_REF] David | Modeling of hybrid systems using continuous and hybrid Petri nets[END_REF][START_REF] Pun | Approche méthodologique de modélisation en vue de la maîtrise assistée de la production[END_REF], and the production management concepts [19,[START_REF] Hill | A decision support system for determining optimal retention stocks for service parts inventories[END_REF]. Three subsystems are defined: physical (Fig. 9.1 (transformation of purchased items and information in products or services)), decisional (to control the physical system (Fig. 9.1)), and information (to manage the creation and the exchange of information (Fig. 9.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 and Airbus Toulouse to improve the performance of a composite workshop. 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 Model-Driven System Engineering Architecture (MDSEA (see Sect. 3.3.4). At the same time, other methods appear, one major one is CIMOSA [START_REF]CIMOSA: open system architecture for CIM[END_REF], which was developed in the late 1980's. Additionally, IEM [START_REF] Mertins | user oriented enterprise models for organisational and IT solutions[END_REF] and ARIS [START_REF] Scheer | Architecture of integrated information systems (ARIS)[END_REF] have been largely used.

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 (Fig. 9.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 Fig. 9.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 (Fig. 9.3), there are four types of flows:

• Input represents the flow of entities which will be transformed.

• Output represents the flow of entities which have been transformed.

• Control represents the conditions or circumstances that govern the transformation (objectives, constraints …). • Resource 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 [START_REF] Bourey | Deliverable DTG2. 3 REPORT ON MODEL DRIVEN[END_REF]. The other GRAI formalisms are

• Global level for the control using GRAI grid formalism (Fig. 9.4) • Detailed level for the control using GRAI nets formalism derived from EA* (Fig. 9.5).

The GRAI grid is a formalism which represents the decisional subsystem. 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 include all information for decision-making (objective, decision variable, constraint, and criteria).

GRAI nets (Fig. 9.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 (Fig. 9.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 model system tool box (MSTB), as described in Sect. 5.1.

BPMN

At more technical level, business process modeling and notation (BPMN 2.0) (business process model and notation [START_REF]Business Process Model and Notation[END_REF] 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 simulation with many BPM IT platforms, thus allowing the deployment and semi-automatic transformation for the execution of BPMN processes.

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. [START_REF] Lankhorst | Enterprise architecture development and modelling-Combining TOGAF and ArchiMate[END_REF][START_REF] Vicente | Using ArchiMate and TOGAF to understand the enterprise architecture and ITIL relationship[END_REF]. 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 toward 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.

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 objective is to link EM to other areas like enterprise simulation and the model-driven approach as proposed in Sect. 3.5.

Modeling Enterprise 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 o 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 Sect. 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 the previous issues encountered with IDEF0 regarding its simulation 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 [START_REF] Bell | Service-oriented modeling[END_REF], 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 simulation 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 metamodel 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 simulation 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.

Driving Models to Simulation

Hezam Haidar, Nicolas Daclin, Gregory Zacharewicz, Guy Doumeingts.

Interoperability

According to ISO 11354, enterprise interoperability is the "ability of enterprises and entities within those enterprises to communicate and interact effectively". T structure the different concept of interoperability, ISO 11354 makes available a framework that provides a set of interoperability solutions relevant with the practitioners' requirements. Thus, this framework for enterprise interoperability relies onto three dimensions such as concerns, barriers, and approaches (Fig. 9.7). Interoperability concerns highlights the interoperability viewpoints, i.e., the levels in enterprises at which interoperability needs to be developed. Interoperability concerns include business level (ex. working methods, decision-making…), process level (collaborative business processes), service level (application deployed in collaborative processes), and data (shared and exchanged within the process and through application).

Interoperability approaches take the classical approaches proposed in ISO 14258: integration unification and federation. Integration encourages the use of a common format through all collaborative organizations (ex. use of BPMN 2.0 language to model processes). Unification relies on the use of a "meta"-level principles to ensure the mapping between different formats (ex. use of model-driven engineering approach). Federation promotes to develop mechanisms allowing to collaborative organization get used to each other's methods, data, and tools on the fly (no use of standard or any mapping).

The barriers represent the problems of interoperability that can occur between the organizations. Conceptual barrier deals with exchanged information (syntax and semantic problems) [START_REF] Adamczyk | Knowledge-based expert system to support the semantic interoperability in smart manufacturing[END_REF]. Technological barrier deals with the compatibilities issues between application and information systems. Lastly, organizational barrier deals with the definition of responsibilities and authorization of involved actors, authority, process, and regulatory aspects.

The intersection of three dimensions (e.g., conceptual x process x unification) makes available a set of relevant solution to develop interoperability according to the intersection's requirements. Thus, the integrated approach, despite it is constraining, is likely the easy way to set up interoperability since each organization adopts the same methods, models, or tools. The unified approach seems the most implemented approach since the concepts and tools are well identified, defined, and equipped, the model-driven engineering or else model-driven engineering and their practices are the most known approaches. Lastly, the federated, although it represents the most challenging approach and meets the simulation "spirit" expectations (no mapping, no standards but a dynamic and continuous adaptation), still remain poorly developed. Thus, the Enterprise Simulation roadmap published by the European Commission [START_REF]Enterprise interoperability research roadmap (version 5.0) final[END_REF], developing the federated approach for interoperability is considered to be one of the research challenges in the next years.

Vertical Decomposition: Toward 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 9.8 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 show 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 Fig. 9.8 MDISE architecture for enterprise interoperability 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 chapter 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 simulation projects (I-V-Lab (http://interop-vlab.eu/projects-i-vlab/)), including the DIH4CPS project [START_REF] Andres | An information management conceptual approach for the strategies alignment collaborative process[END_REF].

About human and organization, we believe that holacracy, which is decisionmaking 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 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, simulation plays the role of gluing them together.

Additionally, in Sect. 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 simulation management life cycle. The service approach will keep driving this development [START_REF] Coutinho | Service-based negotiation for advanced collaboration in enterprise networks[END_REF].

Horizontal Alignment: Toward Simulation for Better

Collaboration Between Service Network 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 simulation of practices in terms of business process models and decision models. In MDSEA, simulation is a key factor for enterprise collaboration. Enterprise models ensure not only simulation 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 with MDA or MDI or service-oriented modeling and architecture (SOMA), 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 with 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 simulation 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 modeling 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 toward cooperation and collaboration and an important level of integration, according to Reference [START_REF] Afsarmanesh | On the classification and management of virtual organisation breeding environments[END_REF].

In the frame of MDISE, the purpose is to extend the MDSEA and MDI principles to a federative approach to develop simulation. 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 a simulation model to insert between organizations. This model aims to identify and allow simulation 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 simulation model does not take any interest in the modeling 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 simulation 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 simulation model" approach to the "mutual adjustment", mentioned in Reference [START_REF] Vallespir | Enterprise modelling for interoperability[END_REF], thus fits the federated approach of the simulation 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 simulation situations. These atomic COTS belong to a set and can be combined to provide a complex COTS to establish simulation 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 simulation 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, a simulation 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 simulation 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 simulation 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 simulation 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 simulation model can be initiated with existing components and continued with emergent ones if requested.

Implementing Framework and Method in MSTB Evolved

Hezam Haidar, Nicolas Daclin, Gregory Zacharewicz, Guy Doumeingts.

As an historical perspective, to operationalize the models from BSM to TSM, [START_REF] Bazoun | SLMToolBox: an implementation of MDSEA for servitisation and enterprise interoperability BT-Enterprise interoperability VI[END_REF], Gregory [START_REF] Zacharewicz | Model-based approaches for interoperability of next generation enterprise information systems: state of the art and future challenges[END_REF] proposed the frame of the EU FP7 Research Project MSEE "Manufacturing Service Ecosystem" ID 284860 (http://www.msee-ip.eu/). The authors of References [START_REF] Bazoun | SLMToolBox: an implementation of MDSEA for servitisation and enterprise interoperability BT-Enterprise interoperability VI[END_REF] 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 chapter, 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 life cycle, such as considering the evolution of ICT from both IT and OT points of views. Models will identify and highlight the need for simulation. It will help users mitigate barriers to simulation using models and simulations to manage exceptions and ensure business continuity. The objective is to prevent an ICT simulation issues occurring during production or manage it with short business resilience duration. The new version of MSTB is called MSTB evolved.

Models and 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 subsection. 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.

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 simulation 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 Sect. 3.1.1, is 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 the previous issues encountered with other enterprise modeling languages regarding its capacity to represent interoperability [START_REF] Bazoun | SLMToolBox: an implementation of MDSEA for servitisation and enterprise interoperability BT-Enterprise interoperability VI[END_REF]. 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 [START_REF] Arsanjani | Service-oriented modeling and architecture[END_REF] 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 with 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, business people 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.

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 simulation solutions available to handle them; they will be used to stress the models and simulate interoperability management scenarios to evaluate their interest.

According to Sect. 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 simulation. 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 Sect. 3.1.1.

Each data used by stakeholders have specific structure that leads to semantic issues. The use of a short-lived ontology concept [START_REF] Zacharewicz | Short-lived ontology approach for agent/HLA federated enterprise interoperability[END_REF] can tackle this barrier. Short-lived ontology fits the federated Enterprise Simulation 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.

Interface Process Model at TIM Level

This subsection focuses on the modeling of data workflows at the TIM level of MDISE. This task will select accurate language to the TIM level of modeling. 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 Sect. 5.1.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 modeling language will allow for describing after the domain extractions of Sect. 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 Sect. 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 Sect. 3.1.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 simulation 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 metamodel developed by OMG, which facilitates the implementation of the language.

Simulation Model Orchestration at TIM Run Time

According to the previous works published in References [START_REF] Bazoun | SLMToolBox: an implementation of MDSEA for servitisation and enterprise interoperability BT-Enterprise interoperability VI[END_REF], MDSEA was already instantiated to use the simulation to support decision-making. In this chapter, the authors considered the supply chain context and looks for simulation of different simulations derived from domain specific models of Sect. 5.1.1. According to Fig. 9.9, 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 simulation objectives) supporting those decisions. This step can be performed using decisional modeling methods such as GRAI grid (see Sect. 3description). Then, several simulation solutions should be selected according to the required information treatment (see [START_REF] Kozlenkova | The role of marketing channels in supply chain management[END_REF] in Fig. 9.9). 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 Sect. 2, 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 [START_REF] Zacharewicz | G-DEVS/HLA environment for distributed simulations of workflows[END_REF] 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 simulation flaws and solutions described at the TIM level in the modeling 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 ( [START_REF]TF2 model driven interoperability, engineering and simulation[END_REF], p. 2).

After the simulation, it is usually required to aggregate the results according to the same criteria of decomposition or enterprise layers (see [START_REF] Harland | Supply chain management, purchasing and supply management, logistics, vertical integration, materials management and supply chain dynamics[END_REF] in Fig. 9.9). 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 modeling 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 Fig. 9.9, 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 life cycle in Fig. 9.9 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.

Physical Infrastructure Interoperability with Simulation 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 Sect. 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 [41], including sectoral regulation such as ISO 21434 automotive regulation [42] 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 simulation 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 simulation requirements. This level will also propose a GAP analysis and deployment plan based on models defined in the 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 exchanging data in a degraded mode operation, will be described.

The simulation evaluation and TSM principle is based on the comparison between the current situation (AS-IS top BSM model coming from Sect. 4.1), the projected situation (TO-BE bottom BSM model from Sect. 4.1) and interface process model at TIM level (Sect. 5.1.3). It is prepared from the previous level to identifying more quickly and efficiently the simulation 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.

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 modeling, workloads, and performances, as presented in Fig. 9.10 that details CPS concepts within the MDISE approach. To facilitate and validate this user modeling 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.

Discussion and Conclusion

Hezam Haidar, Nicolas Daclin, Gregory Zacharewicz, Guy Doumeingts.

We proposed a guideline for enterprise 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 depend 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.

The chapter presents a framework and a method to guide enterprises in simulation design when they are involved in SC-ICTS. The contribution started by recalling enterprise modeling, simulation concepts, and model-driven approaches. Then, based on MDSEA, it defines the model-driven framework MDISE and methods dedicated to simulation 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 modeling 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.

Fig. 9 . 1

 91 Fig. 9.1 Physical system and the control system

Fig. 9 . 2

 92 Fig. 9.2 Creation of the information system in the GRAI model

Fig. 9 . 3

 93 Fig. 9.3 IDEF0

Fig. 9 . 4

 94 Fig. 9.4 GRAI grid formalism

Fig. 9 . 6

 96 Fig. 9.6 Information system formalism

Fig. 9 . 7

 97 Fig. 9.7 Framework for enterprise interoperability

Figure 9 .

 9 Figure 9.8 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 simulation of practices in terms of business process models and decision models. In MDSEA, simulation is a key factor for enterprise collaboration. Enterprise models ensure not only simulation 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

Fig. 9 . 9

 99 Fig. 9.9 Simulation-based decision aid for enterprise interoperability at the TIM level

Fig. 9 .

 9 Fig. 9.10 Basic cyber-physical system (CPS) by GRAI model in MDISE