Joseph Rahme Youssef
email: joseph.youssef@ims-bordeaux.fr

Gregory Zacharewicz
email: gregory.zacharewicz@ims-bordeaux.fr

David Chen
email: david.chen@ims-bordeaux.fr

Zhiying Tu

Enterprise operating system framework: federated interoperability based on HLA

Keywords: operating system, OS, architecture, model, infrastructure, interoperability

Operating system (OS) is a well-known concept in computer science as an interface between human and computer hardware (MacOS, Windows, IOS, Android). In the perspective of developing future generation of enterprise systems based on IoT and cyber-physical system principles, this paper proposes to develop an enterprise operating system (EOS) that will act as an interface between enterprise business managers and enterprise resources performing enterprise operations. The paper presents at first a set of requirements and functionalities of EOS. Then a survey on existing relevant works is given and mapped to the requirements. After that the existing models related to the federated enterprise interoperability are presented. The architectures of envisioned EOS and the federated interoperability are outlined. The last part draws some conclusions and gives future perspectives.

Introduction

Today, to be competitive in the market, enterprise operations need to be efficiently controlled and coordinated in order to react quickly to constantly changing market demands. To reach this goal, enterprise operations must be in real-time monitored and its resources be integrated as one system.

In the past, considerable efforts have been made to develop enterprise integration, enterprise resource planning (ERP) and management solutions; however those approaches fail to provide satisfactory solutions, especially for SMEs. Enterprise integration is still seen as a complex, costly and time-consuming task.

In parallel to the R&D on enterprise integration, ERP solutions have been massively implemented in enterprises, especially in large and medium size companies. During the last couple of years, the image of ERP systems seems to have changed from a highly promising into a very demanding system [START_REF] Burnson | Enterprise Resource Planning Software -Buyer Report, Software Advice TM[END_REF]. Most of existing ERP solutions in the market is proprietary systems. The interoperability between an ERP system and other systems in a company reminds difficult. Moreover, introducing an ERP solution in a company is becoming increasingly in size, rigidity and complexity which make the implementation and the updates very time consuming, involving high costs and disrupting current processes and operations.

In line with the development of the future generation enterprise manufacturing systems based on IoT and cyber physical system principle, this paper tentatively presents the latest development of an enterprise operating system (EOS). It aims at setting a loose coupled connection between enterprise's software applications through the federated interoperability principle. EOS allows joining existing relevant approaches together for complementarities and synergies [START_REF] Burnson | Enterprise Resource Planning Software -Buyer Report, Software Advice TM[END_REF]. The cooperating parties can accommodate and adjust 'on-the-fly' to ensure quick interoperability establishment, easy-pass, and dynamic environment update. The envisioned EOS will behave as an OS of the computer to monitor enterprise resources and coordinate enterprise operations.

The approach presented in the paper is part of an ongoing research activity carried out at IMS laboratory of University of Bordeaux to develop enterprise interoperability in order to improve the performance and competitiveness of small and medium size manufacturing enterprises in collaborative environments by executing enterprise models. In the paper focus is given on the EOS concepts and principles, the requirements and conceptual architecture of EOS as well as the technical and implementation architectures based on a federated interoperability framework.

The proposed EOS will behave in the same way as an operating system (OS) of the computer, but under enterprise context. It will act as a system-wide interface between enterprise business managers and enterprise resources performing daily enterprise operations (see Figure 1). The EOS will manage and interpret the enterprise content and requests defined by business managers and activities owner, trigger various enterprise operations with dynamically allocated enterprise resources (human, machining, computing), control the processes execution, and monitor the status of enterprise resources through various sensing devices and front-ends [START_REF] Chen | Towards an enterprise operating systemrequirements for standardisation[END_REF][START_REF] Zhiying | Federated Approach for Enterprise Interoperability: A Reversible Model Driven and HLA Based Methodology[END_REF].

Figure 1 EOS, interoperability interface and the external peripherals (see online version for colours)

To make this flexible, dynamically configured and real-time controlled enterprise a reality, a sound EOS capable of (realtime) monitoring enterprise resources and operations in order to dynamically allocate resources to required activities is more than a necessity but a pre-condition. In this context, the proposed EOS will be implemented as a new virtual back-end platform that allows the dynamic allocation of the enterprise activities with its related resources for ensuring the flexibility and real-time controlling of enterprise operations. This EOS will connect and combine the heterogeneous sensors and systems from multi-vendors in order to work as 'one' configured system. One of our motivations to propose EOS is due to the fact that today, enterprise operational management is largely dominated by traditional holistic enterprise management solutions like ERP which is a top-down integrated approach that includes in its framework the main enterprise applications and operating functions [START_REF] Burnson | Enterprise Resource Planning Software -Buyer Report, Software Advice TM[END_REF]. Nevertheless, this solution may constraint the business users due to the top-down 'enclosing' paradigm. It is difficult for an enterprise to implement its tailored solutions according the specific needs of each particular enterprise.

An alternative approach would be to provide loosely coupled connections between enterprise's software applications (federated interoperability) with the support of only one 'core central orchestrator' (EOS).

Another reason of proposing the EOS is to develop a response to the foreseen enterprise evolution towards a new generation of modular structured agile 'smart factory'. The proposed EOS will support this Fourth Industrial Revolution (or Industry 4.0) with federated interoperability and IoT.

In other words, EOS is a bottom-up federated approach only providing EOS (functions) that allows various heterogeneous applications from different vendors to connect to EOS and to work together.

From this perspective, EOS's approach presents the better perspective for industry in the context of factory of future (FoF). It allows connectivity, flexibility and real-time control with a bottom-up approach. It also allows providing more options for those enterprises with tailored solution, especially for SMEs. With a lower cost comparing with ERP, an enterprise equipped with an EOS will only deploy and install its required heterogeneous applications. Once EOS adopted in industry with the federated interoperability approach, a foreseen ecosystem would be developed in consequence to provide varieties of enterprise applications compatible to EOS.

Existing works relevant to EOS

Since the beginning of 80's, several architectures, platforms and models have been developed which are relevant in developing EOS. Eight approaches were identified and are reviewed in this section.

Existing works

The common object request broker architecture 'CORBA' was designed for facilitating and enabling the communication of systems deploying on diverse platforms, written in different languages and implemented on different OSs and models. It offers benefits such as inheritance, information hiding, reusability and polymorphism. However, CORBA is seen more as an enterprise application integration (EAI) platform rather than an EOS [START_REF] Gray | Transaction Processing: Concepts and Techniques[END_REF].

ENV 13550 was developed in 1990's to support the computer integrated manufacturing 'CIM'. The main objective is to support system-wide business process monitoring and control [START_REF] Leadbeater | Systems Architecture, Enterprise Model Execution and Integration[END_REF]. ENV defines the requirements to express the capabilities of environments for developing, executing and integrating enterprise models on an open IT based platform. ENV focused on enterprise model execution; integration of divers' heterogeneous applications is not well supported as CORBA [START_REF] Shorter | Requirements for Model Execution and Integration Services[END_REF][START_REF] Zacharewicz | SLMToolBox: Enterprise Service Process Modelling and Simulation by Coupling DEVS and Services Workflow[END_REF]. Interoperability issues were not addressed in ENV 13550.

Another well-known work similar to CORBA is EAI that provides integration of systems and applications residing on different OSs and using different database solutions across an enterprise (SCM, ERP, CRM, payroll…) [START_REF] Amice | CIMOSA Open System Architecture for CIM, 2nd and Extended Revision[END_REF]. As CORBA, EAI was not dedicated to enterprise process and operation monitoring and control that are to be supported by EOS. It aims at integration approach rather than loosely coupled interoperability [START_REF] Linthicum | Enterprise Application Integration[END_REF].

Concerning this last point, we must mention the workflow management coalition 'WfMC' which focuses principally around process definition file interchange by using the standard 'XPDL' which presents a process design format for storing the visual diagram and process syntax of business process models [START_REF] Hollingsworth | The Workflow Reference Model, Workflow Management Coalition, Document Number[END_REF]. Like ENV 13550, 'WfMC' aims at process model execution that is one of the main functions in EOS. It is worth mentioning two other early works to support integration and interoperability of heterogeneous enterprise systems: OSF/DCE and ODP. OSF/DCE is used to allow different OSs to distribute processing and data across the enterprise. It supports the sharing of information and provides services to mask the complexity of multi-vendor network environments [START_REF] Turner | Advances in Home Care Technologies, Results of the MATCH Project[END_REF]. ODP describes and builds widely distributed systems and applications in a multi-vendor environment [START_REF] Zurawski | The Industrial Information Technology Handbook, Handbook[END_REF]. Both ODP and DCE are similar approaches aiming at supporting system-wide distributed communication and sharing of information that is also a core functionality to be provided by EOS.

Further to the above-mentioned works, service orientation has gained interest in the middle of 90's and has been used as a basic principle to develop enterprise integration and interoperability platforms. To this end, the most well-known are enterprise service bus (ESB) and service oriented architecture (SOA). The 'ESB' is developed in analogy to the bus concept found in computer hardware architecture combined with the high-performance computer OSs, and used for designing and implementing communication between mutually interacting computing hardware [START_REF] Flurry | Enterprise Service Bus, IBM -DeveloperWorks[END_REF]. While the 'SOA' is an architectural style that support service orientation including service-based development and outcomes services [START_REF] Salayandia | Towards a Workflow Management System for Services Oriented Modules[END_REF]. This technique involves the interaction between loosely coupled services that function independently and enables networked applications to cooperate and exchange information. It does not directly support functions required by an EOS but providing interesting principle to develop the EOS.

Both ESB and SOA cannot directly be used as an EOS but they provide interesting concepts and principle to develop and build the EOS (The Open Group, 2012).

Efficiency of existing techniques for EOS

Considering enterprise resource management (ERM), ENV 13550 and to a lesser extent the WfMC deal with the human and machine resources; the other existing approaches only focus on IT resource management specially monitoring and control. SOA allows to leverage existing resources and integrate them using service-oriented integration techniques. It delivers the flexibility and agility that business resources require in order to facilitate the combined use of the resources to deliver various required services; this is a useful approach for EOS [START_REF] Aiim | Enterprise Applications -Adoption of E-Business and Document Technologies[END_REF][START_REF] Bieberstein | Service-oriented Architecture Compass: Business Value, and Planning[END_REF][START_REF] Favre | The Workflow Management Coalition Specification, Workflow Management Coalition, Terminology & Glossary[END_REF][START_REF] Moon | Design and implementation of a resource management system using on-demand software streaming on distributed computing environment[END_REF][START_REF] Rademakers | Open-Source ESBs in Action[END_REF][START_REF] Zaraté | Tools for Collaborative Decision-Making[END_REF].

As for the enterprise process management (EPM), most of the existing approaches include this functionality; However, in an EOS, the 'business process' defined by business users and the 'process' that is orchestrated to ensure internal working of platforms, are both included but the focus is on the business process execution. In this sense, ENV 13550 and WfMC provide the most interesting concepts and principles to define EOS by controlling the process model run-time execution (sending command triggering the starting of processes, recording the ending status and sending required capability to resource management to find/allocate the available qualified resource) [START_REF] Chang | Business Process Management Systems, Strategy and Implementation[END_REF][START_REF] Fagg | Taskers and General Resource Managers[END_REF][START_REF] Gable | Information management journal[END_REF][START_REF] Henning | Response to 'The Rise and Fall of CORBA[END_REF][START_REF] Sethi | Integrated network management IV[END_REF][START_REF] Vollmer | The Forrester WaveTM: Enterprise Service Bus for Application Development & Delivery Professionals[END_REF].

Referring to enterprise information management (EIM), all existing approach support the intercommunication of information between the EOS internal and external components which is an essential function; However due to the heterogeneous data sources in an enterprise, interoperability is fundamental to support this function [START_REF] Rasta | Data Quality-Based Resource Management in Enterprise Service Bus[END_REF][START_REF] Wainer | CORBA Based Architecture for Large Scale Workflow[END_REF].

Concerning the presentation management (PM), this functionality is necessary to interact with all resources and business users connected to an EOS, ENV 13550 provides a set of interfaces and commands between internal and external worlds of the platform. It organises the information flow between the platform and the enterprise resources, and interacts with the human, machine and IT dialogue services [START_REF] Ceiton | Front-End and Back-End EAI[END_REF][START_REF] Jin | Research on the Model of Enterprise Application Integration with Web Services[END_REF][START_REF] Wyszkowski | ESB Application for Effective Synchronization of Large Volume Measurements Data[END_REF].

For interoperability management (IM), existing approaches did not develop this function to a mature and satisfactory level. They are focusing on the enterprise integration and none of them proposes the complete solution for all the interoperability issues especially to ensure the loosely coupled interoperability. A set of interoperability utility services needs to be developed to support the use of the EOS [START_REF] Konstantas | Interoperability of Enterprise Software and Applications[END_REF][START_REF] May | Parallel I/O for High Performance Computing[END_REF][START_REF] Omicini | Engineering societies[END_REF][START_REF] Saha | Networking Infrastructure for Pervasive Computing, Enabling Technologies[END_REF][START_REF] Xu | Enterprise Integration and Information Architecture, a Systems Perspective, Book Depository[END_REF].

In conclusion, the existing works are all relevant to designing and developing an EOS but they do not support and cover all the requirements and functionalities required by EOS. Each of them has its particular objectives with specific focuses. CORBA and EAI are seen more as an EAI platform rather than an EOS. ENV 13550 moved a step towards an EOS, but unfortunately the work of ENV 13550 is discontinued. The WfMC, ODP and OSF ensure the information management by executing the intercommunication data exchange, but they do not cover all the EOS functionalities. The ESB and SOA developed to ensure enterprise integration and interoperability platforms, cannot be directly used as an EOS but they provide interesting concepts and principle to develop and build the EOS. The following notations are used: '+ + +' means that there is a strong correlation and that the approach highly fulfils the EOS criteria, '+' denotes that there is weak correlation and '+ +' is in between, '-' means that the approach does not meet the criteria. Table 1 gives an evaluation on the degree of relevant of the existing approaches to EOS. The results of the comparison have been quantified and summarised in Figure 2.

Requirements and functionalities of EOS

This section presents a preliminary set of requirements and functionalities for developing an enterprise operating system. They are inspired from and based on the work specified in a pre-European standard known as prENV 13550 'Advanced manufacturing technologysystems architectureenterprise model execution and integration services' (CEN, 1999;[START_REF] Chen | Towards an enterprise operating systemrequirements for standardisation[END_REF]. This pre-European standard benefits from the result of European esprit project CIMOSA [START_REF] Tolk | The levels of conceptual interoperability model[END_REF].

Enterprise resource management

ERM is the efficient and effective deployment and allocation of an organisation's resources including: the sets of individuals who make up the workforce of an organisation and business sector 'human', the types of devices and tools containing one or more parts that use energy to perform an intended action 'machines', and the collections of physical elements that constitutes computer and communications systems as well as software applications 'IT resources'. ERM is essential for EOS, it provides a real-time and global view of the 'occupation' of the resources in a company by monitory the enterprise resources system-wide (available, occupied, out-of-order…) [START_REF] Gray | Transaction Processing: Concepts and Techniques[END_REF]. Main required functionalities of ERM are: checking the availability of the resources and pre-assigning it when available; signalling the process management that those critical resources are reserved; matching the required capabilities to the capabilities of existing available resources; managing time and performance management support of enterprise functions and operations; and ensuring that the right resources are allocated to the right place at the right time.

Noting that only the resources connected to EOS is to be monitored and managed by EOS, for example those ones involved supporting defined processes. IT and automated machine resources are to be connected directly to EOS. Human resources are connected to EOS via appropriate portable interfaces.

Enterprise process management

EPM is required for EOS to help orchestrating and carrying out organisational activities so that operational processes defined by the decision makers are executed, aligned and integrated. Resources required to execute processes are dynamically allocated/de-allocated by ERM. Main functionalities of EPM include: registering and managing process priorities using the run-time repository service; sending commands triggering the starting of processes, recording ending status of processes (done, not done, fail…); responding to rule interpretation notifications when a process is notified as terminated, requesting ERM to take appropriate house-keeping action and invoking events handling to terminate; checking authorisation to execute a process; managing event queues and traceability by time-stamping and recording the history of events; escalating exception-related processes for persistent and non-persistent errors and damage control [START_REF] Leadbeater | Systems Architecture, Enterprise Model Execution and Integration[END_REF].

Enterprise information management

EIM supports information and data exchange between all entities connected to the EOS such enterprise resources and business managers [START_REF] Leadbeater | Systems Architecture, Enterprise Model Execution and Integration[END_REF]. EIM is specialised in finding solutions for optimal use of information within the organisation, for instance to support decision-making processes or day-to-day operations that require the availability of data and knowledge. Main required functionalities of EIM are: maintaining consistency with the system-wide run-time name space; supporting transparent access to system and user data stored in several heterogeneous database systems; supporting transparent access to data with no concern for data location, data replication and storage mean type; and ensuring information, data confidentiality and security to protect from nonauthorised access.

Presentation management

PM is concerned with the interface between internal and external worlds of EOS. It produces a user interface which makes it easy (self-explanatory) and efficient to organise and coordinate the communication and information flow between enterprise resources and internal entities of EOS including the human, machine and applications dialogue services [START_REF] Gray | Transaction Processing: Concepts and Techniques[END_REF]. It is mainly required for: transposing the control and information inputs into the appropriate forms for the involved functional entities and assigned resources; applying object views to extract that part of the information needed by the involved resources.

Interoperability management

IM is a utility service of EOS presented as a precondition for a successful integration of the business entities of the enterprise involving business process communication, cooperation and coordination, enterprise-wide knowledge sharing as well as enterprise inter-networking, enabled by application and physical components. The federated approach aims at bridging the gap from interoperability concepts to the implementation of interoperable enterprise systems development by allowing quick interoperability establishment, easy-pass, and dynamic environment update in the heterogeneous and multi-partners environment.

Models relevant to federated enterprise interoperability

Several models mentioned in this section have achieved some success in developing systems interoperability based on the federated approach. However, none of them proposes the complete solution for all the interoperability issues in order to develop an interoperability interface for ensuring the inter federates communications and the data connection between the components of the EOS and the external peripherals.

Existing models

Levels of information systems interoperability (LISI) is mainly used to select pragmatic solutions and a transition path for achieving higher states of capability and interoperability by focusing on technical interoperability and the complexity of interoperations between systems. But LISI model does not address the environmental and organisational issues that contribute to the construction and maintenance of interoperable systems. Organisational interoperability maturity (OIM) can be seen as the evolved LISI model in the context of the layers developed in the command and control support (C2S) Study by extending LISI into the organisational layer [START_REF] Chen | Levels of information systems interoperability[END_REF]. The database interoperability and inverted-V model is an overall architecture to merge information comprised in heterogeneous data sources into one technically consistent and semantically coherent information space. However, it is only for data but not procedure or architecture [START_REF] Tolk | Bridging the data gaprecommendations for short, medium and long term solutions[END_REF].

The levels of conceptual interoperability model (LCIM) have been carried out successfully in simulation domain, but the basic premises apply to many complex sets of interoperating systems [START_REF] Tolk | The levels of conceptual interoperability model[END_REF]. The system of systems interoperability (SOSI) extends the existing models by adding a focus on programmatic, constructive and operational issues which must be managed across the life cycle [START_REF] Morris | System of Systems Interoperability[END_REF].

The model driven architecture (MDA) approach focuses on portability, interoperability and reusability starting with the well-known and long established idea of separating the specification of the operation of the system from the details of the way the system uses the capabilities of its software execution platform. It contributes on building an interoperable information and communications technology (ICT) model, from enterprise models to technology models. MDA also provides flexibility and adaptability to accommodate changes at a higher abstraction level. However, several studies doubted that MDA will follow the old way of integrated computer-aided software engineering to ruin, to spend 10% effort to generate incomplete and useless code (80% to 90%), but spend 90% effort on struggling in tracing down the rest part to achieve perfection. In addition, the information is losing during the model transformation, such as details of system behaviours [START_REF] Amber | Agile model-driven development is good enough[END_REF]. The soundness of the model driven interoperability (MDI) methodology has been demonstrated in the current researches, but no full industrial scale validation has been yet achieved. Only some projects have been especially carried to demonstrate these concepts in an industrial real world significant application [START_REF] Elvesaeter | Towards an Interoperability Framework for Model-Driven Development of Software Systems, Interoperability of Enterprise Software and Applications[END_REF]. ADM shows its strong power in obtaining information from the legacy systems. But, many people doubt on the validity of this information for achieving federated enterprise interoperability. Architecture driven model (ADM) met the same model transformation problems as MDA [START_REF] Omg | Architecture Driven Modernization (ADM): Knowledge Discovery Meta-Model[END_REF].

The remote method invocation (RMI) allows the programmers to write object-oriented programming in which objects on different computers can interact in a distributed network. The distributed interactive simulation (DIS) defines an infrastructure for linking simulations of various types at multiple locations to create realistic, complex, virtual worlds for the simulation of highly interactive activities. The aggregate level simulation protocol (ALSP) describes a collection of infrastructure software and protocols for passing the messages between the various participants of a distributed simulation [START_REF] Massei | HLA-Based Real Time Distributed Simulation of a Marine Port for Training Purposes[END_REF].

The RMI, DIS and ALSP simulation and application distribution frameworks can support distributed system interoperability, but in varying degrees. None of them can fully satisfy the requirement of the federated approach and especially as concerned with the component coupling, time management, ownership management, environment flexibility and data distribution services [START_REF] Bruzzone | Agent directed HLA simulation for complex supply chain modeling[END_REF][START_REF] Buss | Distributed simulation modeling: a comparison of HLA, CORBA And RMI[END_REF]IEEE, 1995;[START_REF] Weatherly | ALSP-Theory, Experience, and Future Directions[END_REF].

The ontology can fully support the conceptual enterprise interoperability. However, enterprises require more and more dynamic, complex, and advanced interoperability, this kind of architectures independently can hardly handle the updated requirements [START_REF] Zacharewicz | Short-Lived Ontology Approach for Agent/HLA Federated Enterprise Interoperability[END_REF].

Efficiency of models for federated interoperability concept

Due to the fact that enterprises require more and more dynamic, complex, and advanced interoperability, these methodologies, technologies, and architectures independently can hardly handle these requirements any more. A harmonised and reversible high level architecture (HLA) based methodology is being implemented as a novel idea that combines the existing methods and techniques to develop model driven federated enterprise interoperability. This methodology will creatively combine the excellences of some of these existing methodologies, technologies, and architectures, and propose an innovative way to tackle enterprise interoperability at service and data levels through a federated approach.

Architectures

This section outlines the EOS conceptual architecture, EOS technical architecture and the technical architecture of the harmonised/reversible development framework in order to meet the requirements and functionalities identified in Sections 2 and 3.

EOS conceptual architecture

Figure 4 gives the EOS conceptual architecture. This EOS is developed and implemented as a new virtual back-end platform that allows the decisions makers to connect to and communicate through the enterprise systems (hardware, software, network, machines…) in an efficient and effective way [START_REF] Chen | Towards an enterprise operating systemrequirements for standardisation[END_REF]. Human type resources are human operators to be monitored and controlled by EOS. The sets of individuals who make up the workforce of the enterprise. They are commercial and purchasing agents, product designers, production managers, shop floor operators etc... IT type resources are the physical elements that constitute computer and communications systems. They include computer and other data processing and storage devices, enterprise applications such as MRPII planning software, shop floor scheduling software, CAD, sale forecasting software, CRM software and inventory management software.

Machine type resources are machines, materials and tools containing one or more parts that use energy to perform an intended action. Machines are usually powered by mechanical, chemical, thermal, or electrical means such as automated/manual transfer lines, conventional and NC machines, robots etc. Business users are not monitored and controlled by EOS; they define what and how enterprise operations will be done and send commands to resources via EOS.

Interoperability interface is the interface that includes the enterprise processes and required information. It enables business interoperability between EOS executed systems and the external components related to the EOS.

As shown in Figure 4, EOS is an interface between business users defining what/how business is to be done, and the three types of enterprise resources performing defined operations.

ERM dynamically monitors the status of enterprise resources, search and allocate suitable resources to operations that must be done, and ensures that the right resources are allocated to the right place at the right time.

EPM executes business processes defined by business users, sends commands triggering the starting of processes, records ending status of processes (done, not done, fail…), and executes EOS internal processes/operations.

EIM manages, protects and supports information and data exchange of all kinds between the enterprise's resources connected to the EOS, and ensures information and data confidentiality and security to protect from nonauthorised access.

PM is a set of services with appropriate interfaces that allow business users and other enterprise resources to connect to EOS and receive/send information.

IM is a set of services that provide necessary mapping between heterogeneous resources to make them interoperable through EOS (Youssef et al., 2016b).

EOS technical architecture

As shown in Figure 5, the enterprise activities are executed and generated through the EOS internal components at beginning from the starting phase.

At first, each business manager accesses the generalpurpose and vertical software's interfaces in order to request the day-to-day activities and operations. The related software sends special commands to connect and communicate with the EOS front-end interface called presentation module in order to execute the requested job.

After that, the presentation module interprets the run-time entities and triggers the event which will be registered with their associated information through the event registration component using the run-time repository service, and produces the event handling component.

Next, the event handling manages the events' priorities, queues and traceability, provides the order identifier, and creates the process occurrence. The process occurrence manages the process structures and requests scheduling from the process scheduling component which interprets the process behavioural, information and resource requirements. This sub-service checks the authorisation to execute the process, retrieves process descriptions from the run-time repository, invokes the ERM to allocate the required resource capabilities, and forwards the details to the rule interpretation.

Later, the rule interpretation component provides functionality to retrieve the sequencing and conditional rules associated with the identified enterprise process, maintain a state record of all enterprise activities, and respond to detected events in order to initialise or terminate the activity.

Subsequently, the activity occurrence schedule created by the rule interpretation is forwarded to the interoperability component which is responsible of requesting from the ERM to assign resources allocated by the process scheduling component, invoking the EIM to acquire the object states and specify the information object required, requesting from the ERM to release the involved resources when terminating an activity, and signalling the termination of the current activity to the rule interpretation component.

The resource controlling checks the availability of the resources and pre-assigns it when available, responds to the interoperability controlling requests in order to assign agents, and responds to the process scheduling requests to allocate and de-allocate resources. The resource handling component ensures the resource optimisation and the resource mapping by selecting the appropriate resources after matching the capabilities required and by taking into consideration the time, performance and priority.

The PM services are controlled by the resource handling component for handling human, machine and IT dialogues.

The human dialogue provides functionality for presenting in graphical format the current status and the past history of events, allowing authorised personnel to intervene manually in order to modify the contextual parameters at run-time.

The machine dialogue supports the necessary features in order to provide access to the various functional capabilities of the machine. It provides the functionality required for receiving and interpreting responses from the machine.

The IT dialogue provides functionality for interrogating application program interfaces to determine its capabilities, providing support for the integration of the functional entities implemented by existing IT application programs.

Harmonised and reversible development frameworkinteroperability interface for EOS

A new framework is presented and will be used as an interoperability interface connected to the EOS in order to set up interoperability rapidly among existing enterprise information systems. This framework will use the existing models benefits for creating a novel way to support the development of federated approach of enterprise interoperability. Thus, the methodology presented will utilise MDA to clarify the system architecture and relationship among systems, and apply model reverse engineering to reuse and align different EOS components and federates to initiate a federate enterprise interoperability environment, and use the HLA and SOA functionalities as technical support.

This framework is mainly used in order to rapidly develop HLA based interface for achieving federated enterprise interoperability.

Primary concepts are separately presented as follow:

 Harmonised: HLA is successful in defining how to create a global software execution composed of distributed simulations and software applications. Meanwhile, MDA becomes the standard for promoting the use of models and their transformations to consider and implement different systems. However, they both still have drawbacks expected to be improved. HLA and MDA complement each other by using their achievements, and this harmonisation is conducive for federated enterprise interoperability. This framework is a synthetic framework, which consists of several techniques. As the framework in Figure 6 shows, a new five steps development life cycle is proposed which aligns MDA and HLA FEDEP. MDA is easy to use and understand, and tightly bounded with unified modelling language, meta-object facility (MOF). It appears to be an appropriate choice to overcome the interoperability barriers, which is mentioned in the MDI framework [START_REF] Elvesaeter | Towards an Interoperability Framework for Model-Driven Development of Software Systems, Interoperability of Enterprise Software and Applications[END_REF]. HLA FEDEP is the standard for development and execution of HLA federation. It is quite similar to the waterfall development but with lookback test phase. MDA and HLA FEDEP can be easily aligned, because they have several similar steps. In addition, this framework uses web services to improve the flexibility and compatibility of the HLA (Youssef et al., 2016b). The web services allow potential external systems to discover the existing HLA federation, and then connect to it.   Reversible: means that this framework uses model reverse engineering technique to discover part of the models from the legacy system. Model reverse engineering technique aims at avoiding rebuilding the complete legacy system for a new reuse. The objective is to accelerate the development and reduce the cost. As Figure 6 illustrates, there are two kinds of dotted arrows, which have opposite directions to the five steps development life cycle. These two kinds of arrows represent two different scenarios of model reversal in this framework. This methodology proposes a way of using UML models discovered from the existing systems to generate HLA FOM that represents system static information and HLA federate code block that represents system behaviour.

 HLA: means that this framework dedicates to the development of HLA based application. The RTI used in this approach is an open source RTI, poRTIco. The reason of choosing it is not only because of the software price, but also the objective of initiating a global open framework and receiving comments from contributors who can be interested in this idea. In addition, as mentioned earlier in harmonised part, web services will be used to improve the limitation of the traditional HLA.

This framework creatively combine the excellences of the existing methodologies, technologies, and architectures, and propose an innovative way to tackle enterprise interoperability at service and data levels through a federated approach.

The goal is to achieve the interoperability among those existing federates in a common project context. The steps of this approach are presented as follows:

Case study: bank's operation

A simulation system in the banking and finance environment called 'exchange rate' has been developed and implemented as a real-world system.

The exchange rate is defined as a rate at which a country's currency is exchanged in terms of another currency. The bank's exchange rates are constantly changing once every business day based on current market conditions. In our case, the currencies exchanged are EURO and USD.

Every participating application in this system is called 'federate' that interacts with other federates through the run time infrastructure (RTI).

In our case 'poRTIco' open source software was chosen as a RTI that can support heterogeneous environments. It is designed with modularity and flexibility and provides a set of software services for the dynamic information management and inheritance, in which federates coordinate their operations and exchange data during a runtime execution. This kind of federations is provided by IEEE in order to publish and subscribe events between federates.

Figure 11

The exchange rate form federate integrated with poRTIco (see online version for colours)

Figure 12 The ERM federate integrated with poRTIco (see online version for colours)

As shown in Figures 8 and9, the EOS internal components are connected together and to the external components in order to create a new activity (exchange rate update), analyse this activity, turn it as a process and execute it through special resources and information (Youssef et al., 2016a).

Each EOS component has an essential role during the execution through the RTI in order to ensure that the exchange rate new activity is generated based on the federated approach.

As shown in Figure 10, the 'exchange rate form' of the core banking system and 'PM' federates are fully developed and implemented using Vb.net programming language on the Visual Studio 2010 platform. The other federates, 'EOS interface', 'EPM', 'IM', 'information management', and the 'ERM' are fully developed and implemented using Java language on Eclipse version 6 platform.

1 The exchange rate form of the core banking system is connected to the related SQL storage database. It is used as a user interface that allows the bank's branch manager to modify the daily currencies rate between EURO and USD.

2 The EOS interface is mainly used in order to transmit the request job, restrict any operation on the previous rate from any teller and create the process.

3 The EPM is mainly used in order to ensure that the login username and password are compatible with the required privileges and retrieve the exchange rate attributes.

4 The IM has two roles:

a to preserve the correct rate value from the information management federate b to request from the resource management federate to assign the specified external resources (rate application, printer and teller) in order to execute the operation.

5 The information management is responsible of sending the new exchange rate value to the IM federate.

6 The ERM is mainly used in order to respond to the IM federate by checking the availability of the related resources and pre-assign it when available.

7 The PM is the federate that modify the exchange rate on the rate application, print out the operation receipt and notify the teller to use the new exchange rate.

The seven federates are connected together and they are communicating through poRTIco in order to publish and subscribe events between modules. Figures 11 and12 show a sample of code related to federates that are developed in different heterogeneous environments and integrated with poRTIco by calling the member functions of class RTI:RTIAmbassador which is contained in the LibRTI, and by extending and implementing the RTI:FederateAmbassador that uses pure virtual functions to send messages and requests to the RTI.

Each HLA federate ensures the execution of two parts:

1 The federate code block which is the source code of the federate developed, implemented and connected to the local RTI component using the .Vb and .Jar languages from the C# and the java libraries 'LibRTI' in order to form a complete federate.

2 The local RTI component code 'LRC' that provide the services for the federate through communication with the RTI executive component and the other federates.

As shown in Figure 13, the MoDisco software tool has been selected in our case study in order to generate a readable UML file in XML format. This tool is an open source plug-in of the Eclipse generative modelling technologies (GMT) component for model-driven reverse engineering used in order to allow practical extractions of models from legacy systems.

The UML file is generated through the 'KDM to UML converter' after the usage of two existing discoverers:

1 JavaDiscoverer which discovers KDM models from java sources 2 CSharpDiscoverer which discovers models from C# sources.

As shown in Figure 14, the converted UML models include packages, interfaces, classes, and also the properties and operations of classes and associations and dependencies among the classes.

In order to generate HLA FOM, a critical phase must be occurred by selecting the similar entities among the federates participating in this simulation after comparing their UML models. However, the .uml file would contain bulk information, which is not interesting for HLA FOM generation, such as external java package and common java data types. Thus, an 'analyse UML' sub-module is required to select the useful information, and arrange this information.

After the analysis of the UML model, the useful attributes are selected and the models are transferred into HLA FOM file by following different RTI FOM file format as shown in Figure 15. According to the poRTIco RTI FOM file format, UML:Class matches to Objects:Class, and UML:Attribute matches to Objects:Attribute.

Federates interact using services proposed by the RTI. They can notably 'publish' to inform about an intention to send information to the federation and 'subscribe' to reflect some information created and updated by other federates.

This experimental case study is fully implemented in several heterogeneous environments based on the interoperability and uniformity principles in order to provide a set of domain-independent APIs used to access capabilities and features, and to exchange data between federates using the XML format.

Conclusions

This paper has tentatively presented the requirements, the conceptual, technical and development architectures to build an EOS for the new generation enterprise systems such as for example envisioned in Industry 4.0. Moreover, it also outlined the technical architecture of the reversible model driven and HLA based framework and methodology for implementing a federated approach under the enterprise interoperability framework in order to ensure the inter federates communications and the data connection between the components of the EOS and the external peripherals. This framework has the main role to support establishing enterprise interoperability dynamically in a heterogeneous and multi-partners' environment, facilitate re-use of models and re-engineering sub-systems based on models, and allowing extracting from legacy systems and software applications relevant information/data for EI engineering or re-engineering.

A case study has been designed, developed and implemented in order to test the EOS in the service sector using the federated interoperability approach for quick interoperability establishment, easy-pass, and dynamic environment update.

The proposed EOS tends to reconciliate two different but complementary initiatives for enterprise management and control that exist in the market: IT platforms/infrastructure and ERP based application packages.

The reason for proposing to develop an EOS is first of all to contribute a part of the response to the foreseen enterprise evolution towards a new generation of modular structured agile 'smart factory' based on cyber physical system principles. Traditional factory automation, empowered with internet of things (IoT), will operate a challenging industrial migration towards the Fourth Industrial Revolution (or Industry 4.0). The massive use of connected sensors and mobile devices connected to or assisting humans will make possible to collect timely real-time information throughout the enterprise. Using the real-time data on enterprise operations, events and resources, an EOS will allow the dynamic scheduling of enterprise operations with on-the-fly resources allocation for ensuring the flexibility and real-time control of enterprise functions.

The requirements presented in the paper are based on and inspired from some existing relevant approaches, in particular ENV13550 with necessary generalisation and extension to focus on the core functions of an OS for enterprise. The proposal is challenging and its success mainly depends on two factors. One is the acceptance of EOS in industry as a standard to develop an ecosystem providing varieties of enterprise application compatible to EOS; the other is the 'interoperability' service that allows other heterogeneous non-EOS compatible applications to run on EOS.

Several continuous works and tasks are being executed in order to validate and implement our proposed EOS such as:  refining both requirements and architectures at the one hand   developing a prototype to test the EOS against another case study in the manufacturing sector  starting some preliminary discussion in relevant standardisation working groups such as CEN and ISO that deal with integration and interoperability.

Figure 2

 2 Figure 2 Summary of the existing techniques services and efficiencies based on the EOS requirements (see online version for colours)

Figure 3

 3 Figure 3 Summary of the models' services and efficiencies based on the federated interoperability concept (see online version for colours)

Figure 4

 4 Figure 4 Eos conceptual architecture (see online version for colours)

Figure 5

 5 Figure 5 EOS technical architecture (see online version for colours)

Figure 6 Figure 7 Figure 8 Figure 9 Figure 10

 678910 Figure 6 Harmonised and reversible development framework for HLA based application (see online version for colours)

Figure 13 Figure 15

 1315 Figure 13 MoDisco configuration and specifications (see online version for colours)

Table 1

 1 Comparison of existing approaches against EOS requirements

		Enterprise resource	Enterprise process	Enterprise information	Presentation	Interoperability
		management	management	management	management	management
	CORBA	+	+	+ + +	+ + +	+
	ENV 13550	+ + +	+ + +	+ + +	+ + +	-
	ESB	+ +	+	+ +	-	-
	WfM	+ +	+ +	+ + +	+ + +	+ +
	EAI	+ +	+ +	+ + +	+	+
	OSF/DCE	-	+	+ + +	+ + +	+ +
	ODP	+	-	+ + +	+ + +	+ +
	SOA	+	+ +	+ +	+ +	+


Greg Zacharewicz
email: gregory.zacharewicz@ims-bordeaux.fr

To appear in Sage Simulation

Keywords: Discrete Event Modeling and Simulation, G-DEVS, DEVS, Distributed Simulation, HLA. 

The Generalized Discrete Event System specification (G-DEVS) language was introduced by Norbert Giambiasi in the 1990s. This paper first examines the specification of G-DEVS and gives an historical view of N. Giambiasi's works that contributed to this concept. The paper particularly focuses on the extension of G-DEVS to distributed simulation. An example of a G-DEVS model of a ski chairlift system with chair and skier is proposed to show the accuracy gained by using G-DEVS instead of other classical discrete event modeling formalisms. Then, the paper presents how G-DEVS has been extended for interoperability with other components in the context of supply chain M&S coping, with the possibility to compose different model formats at simulation time. Next, the focus is on a G-DEVS editor tool and its extensions: LSIS_DME. The distributed simulation and the HLA standard were used to support the interoperability of various models and simulators.

INTRODUCTION

The Generalized Discrete Event System specification (G-DEVS) language was proposed by N. Giambiasi in the middle of the 1990s (Giambiasi 2000). He created G-DEVS to more accurately capture the signals and states of complex systems using polynomial approximations of real data. This formalism has been used in several works. It has been originally discussed in B. Escude's PhD thesis. Section 2 presents an overview the G-DEVS formalism from a theoretical point of view. This includes a recall of the formalism, compiled with different contributions. Section 3 presents an historical perspective situating various contributions to G-DEVS. In Section 4, these contributions are illustrated by developing a simple case study of a ski chairlift that exposes the interest of G-DEVS. This academic example shows the accuracy gains regarding the data handled by the model in a real system. Section 5 focuses on the use of G-DEVS and HLA in the context of interoperability demand with other tools. Section 6 presents the LSIS_DME modelling and simulation tool. This tool is compliant with the HLA standard. Finally, the paper presents the interoperability between G-DEVS modelling and simulation with other modelling languages and simulators in reference to model transformation and distributed simulation standards.

G-DEVS OVERVIEW

Formal description of G-DEVS

Traditional abstraction with discrete events approximates input-output signals as a piecewise-constant trajectory. Nevertheless, this abstraction seems limited when data relationships are not constantly linear and even more complex. In the middle of the 1990s, Norbert Giambiasi proposed extending DEVS to deal with more complex information using polynomial approximation. In detail, G-DEVS defines the abstraction of a signal with a piecewise-polynomial trajectory (Giambiasi, 2000). Fig. 1 illustrates a comparison between a piecewise-constant segment and a piecewise-polynomial segment. Giambiasi's idea was to transmit not the unique value of an event, but rather the coefficient values that describe the polynomial that approximates real information. Basically, in G-DEVS an input event is a list of coefficient values of the polynomial describing the continuous signal. The degree of the polynomial is the degree of the event. Therefore, when modeling a signal, DEVS can be considered as a particular case of G-DEVS, i.e., a 0-order G-DEVS. The representation of an original continuous signal is thus more accurate with G-DEVS, since many mathematical functions can be approximated with the Taylor function into polynomial functions. Then, to recreate as an output a continuous information, it can be used, with a sensible amount of data, mathematical methods such as Lagrange-Hermite interpolation approaches in order to recreate an appropriate polynomial level. However, this kind of methodology is beyond this paper's scope and are not developed here.

Fig. 1. Piecewise constant vs. polynomial Trajectories

We recall in this section the G-DEVS formalism. As introduced previously, it finds its main interest by the fact that, from a mathematical point of view, classical discrete event abstraction approximates observe input-output signals as a piecewise-constant trajectory. As presented earlier, G-DEVS defines abstractions of signals with piecewise-polynomial trajectories. Thus, G-DEVS defines an event as a list of values. These values represent the polynomial coefficients that approximate the input-output trajectory. Formally, G-DEVS represents a dynamic system as an n-order discrete event model with:

DES N = <XM, YM, S, δ int , δ ext , , D>
The following mappings are required:

XM = A n+1
, where A is a subset of integers or real numbers

YM = A n+1 S = Q x (A n+1 )
For a total state S defined by the following set of state variables (q, (a n , a n-1 ,......, a 0 ), 0) and a continuous polynomial input segment w : <t 1 , t 2 >  X, are defined:

The internal transition function:

int (q, (a n , a n-1 ,......, a 0 )) = (Straj q, x ((t1+D((q, (a n , a n-1 ,......, a 0 )), x))))

with x =a n t n +a n-1 t n-1 +…….+a 1 t+a 0 and Straj model state trajectory

q de Q et w : <t1, t2> X, Straj q,w : <t1, t2> Q
The external transition function:

ext (q, (a n , a n-1 ,......, a 0 ), e, (a n ', a n-1 ',......, a' 0 )) = (Straj q, x(t 1 +e), x') with: Coef (x) = (a n , a n-1 ,......, a 0 )

and Coef (x') = (a n ', a n-1 ',......, a' 0 )

Coef: function to associate n-coefficients of all continuous polynomial function segments over a time interval <ti, tj> to the constant (n+1) values (a n , a n-1 ,......, a 0 ), such as: w(t) = a n t n +a n-1 t n-1 +…….+a 1 t+a 0 InCoef:  (q, (a n , a n-1 ,......, a 0 )) = (q, x)

The output function:

 : S  A n+1
The function defining the life time of the states: D(q, (a n , a n-1 ,......, a 0 )) =

MIN(e/Coef (Otraj q, x(t 1 )) 

Coef (Otraj q, x(t 1 + e))

with Otraj model output trajectory: Otraj q,w:<t1, t2> Y

DEVS Coupled model

Zeigler (1976) introduced the concept of the coupled model. Each basic model of a coupled model interacts with the other models to produce global behavior. The basic models are either atomic models or coupled models stored in a library. G-DEVS model coupling is using same hierarchical approach as DEVS. In consequence, a G-DEVS coupled model is defined by the following structure (reused from DEVS):

MC = < X, Y, D, {M d /dD}, EIC, EOC, IC, Select>

X:

set of external events.

Y:

set of output events.

D:

set of components names.

Md:

DEVS models.

EIC:

External Input Coupling relations.

EOC:

External Output Coupling relations.

IC:

Internal Coupling relations.

Select: defines priorities between simultaneous events intended for different components.

DEVS and G-DEVS Simulator

Ziegler (2000) proposed the concept of a DEVS abstract simulator to define the simulation semantics of a formalism. The architecture of the simulator was based on the hierarchical model structure. G-DEVS respects and uses the concepts of the DEVS abstract simulator.

The processors involved in a hierarchical simulation are: Simulators, which ensure the simulation of the atomic models; Coordinators, which ensure the routing of messages between coupled models; and the Root Coordinator, which ensures the global management of the simulation (Fig. 2).

The simulation runs due to the exchange of specific messages between the different processors:

XMessage:

Represents an external event (e.g., coefficient-event vector in G-DEVS).

*message:

Represents an internal event.

Ymessage:

Represents an output event.

Imessage:

Initializes the model with all the default values chosen by the user.

Fig. 2. From model to simulation

3. CHAIRLIFT EXAMPLE This section presents the example of a detachable 1-seater chairlift system in which a skier is moved on a suspended chair along a cable sustained by pylons. This example is attempting to continue the series of academic examples to illustrate GDEVS, such as the bottling chain system, introduced by Giambiasi (2001), in which barrels were moved horizontally on a conveyor belt. Here, a chairlift loads and unloads skiers on a chair. Then chair moves skier from starting point to the top of a ski track, it is released by a commanded system. Fig. 3 schematically describes this system. For educational purpose, it is assumed that chairs are detachable and released one by one and we consider in this example that only one at a time can be on the route. We use a chair speed input value to command the speed of the chairlift. The chair can be stopped in case the skier falls down at departure or arrival step, slowed down if the skier is in a difficult situation or speeded up to reduce the lost time due to previous situations. The system precisely situates the skier trough the chair position computed as a continuous value. Localizing the skier can be useful for restarting the system after a breakdown, carefully handling skier arrival or in case of emergency.

The model here was realized using the G-DEVS formalism, with the goal of showing accuracy gains compared to other formalisms like classical DEVS.

A hybrid system is one in which the model specification includes both continuous descriptions in the form of differential equations and discrete events. [START_REF] Praehofer | Systems theoretic formalisms for combined discrete continuous system simulation[END_REF] developed a formalism to synthesize hybrid model specification utilizing continuous and discrete event sub-sets and illustrated the idea for a barrel generator system. Under G-DEVS, the hybrid system may be specified uniformly utilizing only discrete events and will yield similar quality results as in Praehofer's work.

The system is characterized through a continuous input (chair speed), a continuous output (chair position), and a discrete output (skier). Chair position also serves as a state variable. The chair speed causes the value of chair position to change and the first derivative of chair speed is equal to chair speed. A skier is considered reaching his destination when the chair position variable reaches the position value + 100 m; it is then outputted through the discrete output port, skier that can be used to count the number of skiers reaching the top of chairlift.

Next, chair position is reset to 0. Given that chair position represents the integration of chair speed over time, its behavior is piecewise linear and its individual segments may be expressed in G-DEVS in the form of discrete coefficientevents. Thus, the chairlift system may be modeled uniformly through discrete events in G-DEVS. In contrast, in [START_REF] Praehofer | Systems theoretic formalisms for combined discrete continuous system simulation[END_REF], the M&S approach mandate a traditional hybrid specification. in:= false endif   (((ac, bc), sigma, in))

if in = false then send out the skier variable to output skier and send out (ac, 0) to port-chair position else send out (ac, bc) to port-chair position endif This example reflects the use of Mealy representation in the modeling, where the generation of an output event is triggered by an input event. An output event is assumed to result at the same time the causal input event is intercepted by the model. Thus, while synthesizing a coupled model, if loops characterized by zero delays are encountered, the simulation process will fail, since an infinite number of events may be generated at the exact same time. Clearly, this is an artifact of the zero delay assumption, stemming from approximating delay values to zero. To address the problem effectively, a small but finite delay, t, may be introduced between the input and output events. The hybrid system serves as a good vehicle to intuitively understand the power of generalization inherent in the G-DEVS approach. Consider that the chair position variable is an N th order function of the input inflow. To represent the state of the model would require N+1 coefficients and a G-DEVS specification may be developed along the same lines as described earlier. An input event associated with inflow will cause a state change in at least one of the N+1 coefficients, thereby triggering execution of the model.

If we focus on the chair position value state variable of the studied system, we can see that using G-DEVS can give a more precise value of the chair (and skier) position. Fig. 5, gives the variation of this state variable during simulation. Depending on some incidents (e.g., delay, slow down) that can occur while moving; we can observe that the skier and chair position is not the same, due to the slope of the polynomial functions that describe it. In detail, in the first case the chair position is purely linear. In the second case, a stop occurs while lifting; it follows a short delay of 3 time units. And in the last case, the chair starts more slowly and then needs to be accelerated to reach the deadline to make the skier arriving at destination on time. The result is that at any time during the simulation the skier (chair) position can be questioned to give its current value more precisely than can piecewise-constant values according to ac, bc and e. In comparison, the position is much more precise than only considering discrete steps reached such as considering, for instance, the numbers of pylons reached. Bruno Escude started his PhD work with the statement that systems whose input/output are dynamic functions of time are nevertheless modelled by classical discrete event specification (e.g. DEVS) that approximates the input, output, and state trajectories through piecewise constant segments, where these segments correspond to discrete time intervals that are not necessarily equal in length. For systems that defy accurate modelling through piecewise-constant segments, B. Escude, mentored by S. Ghosh and N. Giambiasi (2000Giambiasi ( , 2001)), presented G-DEVS for the first time in a journal paper as "a generalized discrete event specification", wherein the trajectories are organized through piecewise-polynomial segments. They argued that the use of polynomial functions for segments promises higher accuracy in modelling continuous processes rather than discrete event abstractions. They also compared and observed that discrete event systems, including DEVS and G-DEVS, executed faster on computers because executions denoted significant abstractions in the system, unlike in continuous simulations where execution is continuous and exhaustive. Moreover, they observed in practice that G-DEVS' superiority over DEVS lies in its ability to discretize a system characteristic. A key contribution of G-DEVS is that it permits the development of a uniform simulation environment for hybrid, i.e., both continuous and discrete, systems. They concluded by illustrating G-DEVS on both a first-order system and a hybrid system, with piecewise linear segments. These two representative systems were modelled under G-DEVS and executed on a simulator developed for G-DEVS execution.

At the same time, Armand Damiba, a PhD student, under the supervision of N. Giambiasi, and Aziz Naamane (2001), proposed an approach combining a bond-graph with G-DEVS' formalism for the modelling and simulation of complex systems using discrete event methods. They showed how to build discrete-event simulation models for bond-graph elements, using either piecewise linear input-output trajectories or any kind of polynomial trajectories. One of the main advantages of their method is the reduction in the number of simulation steps, and therefore the possibility of studying dynamic-hybrid systems using only the discrete event paradigm.

Then, Jean Claude Carmona, N. Giambiasi, and A. [START_REF] Carmona | Generalized Discrete Event Abstraction of Continuous Systems: Application to an Integrator[END_REF] described the fundamental integrator operator, the time delay operator, and the concept of output feedback. Thus, they proposed an integrator under piecewise-linear input trajectories, thus, under trajectories described by a sequence of general order polynomials (G-DEVS), ensuring a user-given accuracy. Also, they obtained smart behavior in the case of input discontinuities contrasting with the unsatisfactory examples of classical numerical solvers. Furthermore, a detailed comparison with discrete-time simulation techniques, such as Euler, allowed the assessment of an important computational gain using the proposed techniques. Finally, the complete treatment of a hybrid system not only illustrated the relevance of this approach, but underlined the interest of its application in the more general contexts of mixed-mode simulation and distributed simulation.

Later, [START_REF] Giambiasi | Generalized discrete event abstraction of continuous systems: GDEVS formalism[END_REF] proposed to model basic continuous components of dynamic systems in a way that facilitated the transposition to a G-DEVS model, which thus offered the ability to develop a uniform approach to model hybrid systems (abstraction closer to real systems), i.e., systems composed of both continuous and discrete components. The approach was obviously a discrete-event approach, in which the choice of the time interval between two steps of calculation was based on the behavior changes of the process and no longer constant and/or a priori given. The underlying objective was to strictly satisfy a given accuracy with a low computational cost. More precisely, they presented a G-DEVS model of an integrator using polynomial descriptions of input-output trajectories. They showed its great capability of easily handling the delicate problem of input discontinuities, and made a detailed comparison with classical discrete time simulation methods, thus demonstrating its relevant properties. Several examples, including a complete hybrid system, illustrated their results.

Gabriel Wainer and N. Giambiasi (2004a) and ( 2005) introduced the Cell-Discrete Event System Specification (Cell-DEVS) formalism that allows defining asynchronous cell spaces with explicit timing delays (based on the specifications of the DEVS formalism). They used Cell-DEVS to solve different applications and go one step further in the definition of complex continuous systems by combining Cell-DEVS and Generalized DEVS (G-DEVS). In particular, they proposed a model describing the electrical behavior of the heart tissue, as previous research in this field has thoroughly studied this problem using differential equations and cellular automata. They showed that they can provide adequate levels of precision at a fraction of the computing cost of differential equations. They demonstrated that the use of the G-DEVS formalism is perfectly suited to deal with this category of problems, thus improving complex systems analysis. As a conclusion, Wainer and Giambiasi showed that their approach permits extending easily models to provide different actions in different cells, while not affecting performance (2004b).

Gregory Zacharewicz (2008a), as a PhD student under the supervision of Claudia Frydman and N. Giambiasi, presented a Workflow environment allowing distributed simulation based on DEVS/G-DEVS formalisms. A description language for Workflow processes and an automatic transformation of a Workflow into a G-DEVS model were defined. They introduced a new distributed Workflow Reference Model with HLA-compliant Workflow components, detailed the HLA objects shared between Workflow federates, and presented the publishing/subscribing status of each of these federates. Finally, they illustrated the use of this distributed environment with an example from Microelectronic production Workflow.

Recently, Amine Hamri, A. Naamane, and N. [START_REF] Hamri | Generalized discrete events for accurate modeling and simulation of logic gates[END_REF] have presented and demonstrated using G-DEVS to build precise discrete-event models of logic gate design and analysis in order to get more accurate and faster simulations. In this work, states were represented with linear piecewise trajectories (G-DEVS of order 1), contrary to the classical Boolean logic models where states have constant piecewise trajectories (0 and 1). With G-DEVS models, the transition from a low level to a high one and vice versa is a linear trajectory, which is more realistic than the instantaneous transitions of classical logic gate models. They also demonstrated that this accurate representation does not require any more computations than does the DEVS model.

Several works in different application domains have been developed by using and citing G-DEVS such as [START_REF] Barhen | Asynchronous Discrete Event Systems and Emergence of Computational Chaos[END_REF]. They cannot be all developed here. We can cite [START_REF] Wainer | Accurate Modeling and Simulation of Heart Tissue with GDEVS/Cell-DEVS[END_REF] that accurately modeled and simulated Heart Tissue and Zacharewicz and T. [START_REF] Alix | Product-service systems scenarios simulation based on G-DEVS/HLA: Generalized discrete event specification/high level architecture[END_REF] that modeled and simulate joint product and service design. In Le Goc (2003), the knowledge about the behavior of a continuous process has been formalized in terms of relation between discrete events so that a recursive recognition process of signatures was used to design monitoring cognitive agents. At the end, B. Zeigler has listed G-DEVS [START_REF] Zeigler | DEVS today: recent advances in discrete event-based information technology[END_REF] as one of the significant contribution in the recent advances of DEVS.

G-DEVS' DISTRIBUTED SIMULATION AND INTEROPERABLITY

For interoperability purposes, G-DEVS has been proposed to extend the specification by giving the possibility to couple not only distributed G-DEVS models, but also G-DEVS and non-G-DEVS simulation components. Inspired by [START_REF] Zeigler | Theory of quantized systems: formal basis for DEVS/HLA distributed simulation environment[END_REF], Zacharewicz (2008a), during his PhD thesis under the supervision of Giambiasi and Frydman, proposed to open G-DEVS to distributed simulation. At that time, the standard for High Level Architecture (HLA) (IEEEa 2000) was rising; it was reviewed and adopted as a concrete potential frame to develop G-DEVS distributed models. The objectives of these works were to optimize resource use, work on remote resources, and/or reuse existing simulations, and more generally systems, by interconnecting them. A distributed processing must ensure interoperability, confidentiality, integrity, and causality using temporal synchronization algorithms.

Distributed Simulation

Different implementation of the RTI (Run Time Infrastructure) of HLA was realized and choice was made between open source, freeware, and commercial RTI solution implementation. Data need to be synchronized and interoperable between the different applications that exchange them. The RTI selected for these purposes in data exchange was poRTIco RTI (poRTIco, 2010). The main reason for this choice comes from the Java open source development of this 1.3-certified and 1516-compliant tool. Portico was set and parameterized under Eclipse. The FOM file includes variable objects to be shared. These objects are mainly product attributes, along with their geolocation and crossings points.

The different federates involved in the platform are either G-DEVS Models or other heterogeneous software applications. The platform has been tested and used in supply chain modelling and simulation [START_REF] Zacharewicz | Distributed simulation platform to design advanced RFID based freight transportation systems[END_REF].

The distributed simulation was chosen to ensure the exchange of information between IS, because it can handle data from heterogeneous distributed systems without interpreting them; moreover, it has mechanisms for exchanging synchronized messages. This is a means to convey and orchestrate the exchange of data between IS, as an alternative to SOA. It is robust (running at low levels with local behavior commonly expressed by discrete event models, such DEVS [START_REF] Zeigler | Theory of Modelling and Simulation[END_REF]Zacharewicz, 2008a)) and, finally, it is completely explicit (using synchronization algorithms (Fujimoto, 2000)).

The performance aspect of the messages exchanged, i.e., the interpretation of messages for the simulation, was left to the IS and was not addressed directly by the distributed simulation.

High Level Architecture Overview

The Architecture of High Level, High Level Architecture (HLA) (IEEEb, 2000), is a specification of software architecture that defines a normative framework to create global execution software consisting of distributed simulations and applications. This standard was introduced by the Office of Defense Modeling and Simulation (DMSO) (1998) of the Department of Defense (DoD). The original goal was the reuse and interoperability of military applications, simulations, and sensors. In HLA, each participating application is called federated. An HLA federate interacts within an HLA federation (Federated Group). HLA definitions have been formalized in Standard HLA 1.3 in 1996and HLA 1516(IEEEa, 2000) in 2000.

The report on interoperability solutions implementations (Zacharewicz, 2008a) attests that significant enterprise interoperability solutions use HLA standards to support the distributed implementation of enterprise interoperability between components at a "run time" level.

LSIS_DME AND ITS EXTENSIONS

LSIS-DME: DEVS (and G-DEVS) Modeling Editor

Creating G-DEVS models in an editor was a challenge in the late 1990s. In 2000, the first G-DEVS editor was proposed and released under the name of DIAM-SIM (Giambiasi, 2000). Then, in 2005, using a more recent programming language, a new editor was proposed called LSIS_DME (Zacharewicz, 2008a). This last one was chosen to recode the models recalled in the previous section and to perform simulations of these G-DEVS models. The main reason for this reimplementation came was the deprecation of the code developed in the 1990s.

The elected language was Java and the eclipse platform for portability aptitudes, ability to develop lightweight web applications, and to exchange information in XML format. This new Java-based development environment has allowed the tool and G-DEVS Model created inside to be more open and interoperable with other tools and has also supported a better user-friendly graphical editor.

Also, the runtime target was improved and tailored for G-DEVS simulation formalism (Giambiasi, 2000).

As an illustration, many examples, such as the models proposed by [START_REF] Carmona | Generalized Discrete Event Abstraction of Continuous Systems: Application to an Integrator[END_REF], workflow models, and the conveyor example in section 3, have been graphically modelled with LSIS_DME. Fig. 6 depicts a G-DEVS atomic model screenshot captured in the software. The software create, save, and edit G-DEVS or DEVS atomic and coupled models with only a couple of clicks and almost no lines of code required from the model maker. This permits non-specialists, including industry practitioners and students, to get into the G-DEVS modeling phase within a very short time.

Fig. 6. G-DEVS Model in LSIS_DME

In addition, LSIS_DME has been extended to run distributed simulations. It was completed to become HLA compliant, according to the methodology provided in Zacharewicz's PhD thesis (2008a). These models are therefore potentially able to be simulated in a distributed environment according to the HLA standard.

This implements the class FederateAmbassador and callback functions from RTIAmbassador to communicate with the Run Time Infrastructure. LSIS_DME has been initially configured to connect a commercial RTI in the frame of a European project. Then, it was migrated to an open source framework (details in section 6). LSIS_DME has permitted performing distributed simulations connected with other components (client orders event generator, data bases, guidance emulator of crossing, etc.). The LSIS_DME extensions solutions for the platform was coded using the software development environment Eclipse.

LSIS_WME: Workflow Component editor

LSIS_DME's original features mostly apply to users in the field of M&S. To tackle a production chains' design, the use of G-DEVS and associated tools was not easy entry point. To overcome this problem, Zacharewicz et al. (2008b) introduced a more conceptual language associated with a graphical tool with a reduced number of concepts appropriate for nonspecialists. In detail, the production data exchange defines the flow of information (like sequence planning or tracing/tracking data) between tasks to be performed by resources. In more detail, this data flow between the chain steps and the logistic partners, the products, and the client pass through products that can be equipped, for example, with RFID tags, RFID readers, and any mobile station. This flow must be orchestrated by a technical component able to manage routing, sequencing, and aggregating information. This component is in fact composed of a workflow engine that describes the organization of the proper sequence of information to exchange regarding causality and, in addition, a HLA RTI that sustains the time synchronization specified in this tool.

The WfMC proposed an XML representation of Workflow currently accepted as a standard in the Workflow community (WfMC, 1999;2005). The XML Workflow process model structure correctness can be certified by referring to a Workflow Document Type Definition (DTD). This XML representation is not fully convenient for the XML specification of production or logistic Workflow. On the one hand, the specificities of data transiting in a flow of production need to be identified to be handled by production software and exploited at the end of flow. On the other hand, some definitions of this DTD are relative to administrative Workflow and are not required for the kind of Workflow under our scope, which can overcast the description for non-Workflow expert users.

Thus, Zacharewicz (2008a) proposed a simple graphical language to represent the components involved in Workflow dedicated to the representation of production systems. A XML Workflow process model is composed of tasks components (Fig. 4 square items) that treat items and controllers' components (Fig. 4 round items) that route items between tasks. Items (information, e.g., product, routing data, etc.) pass over a sequence of these components. The items are performed by resources (e.g., Valve, Conveyor, etc.). model by coupling G-DEVS atomic models (Fig. 5). The coupled model coupling relation was generated and a library of logistic models was proposed. This G-DEVS model takes advantage of formal properties. In conclusion, the workflow contains both G-DEVS models and other software components. HLA interoperability permits performing distributed simulation to validate the coherence of information flow to be exchanged between the partners before real execution.

Hybrid Simulation Platform

The LSIS_DME and WME editors have been involved with previous work using HLA to ensure interoperability, as mentioned in Zacharewicz (2008b[START_REF] Zacharewicz | A Generalized Discrete Event System (G-DEVS) Flattened Simulation Structure: Application to High-Level Architecture (HLA) Compliant Simulation of Workflow[END_REF]. They have been reused for building an application platform dedicated to a simulation case study of supply chain model partners. The accomplishment of mixing several simulation tools and other software demonstrated that formal execution can be composed with other data handling tools such as data bases systems, ERP, etc.

Fig. 8 presents the distributed components of the platform that used HLA to communicate in a System of System approach of the announced logistic project [START_REF] Zacharewicz | Distributed simulation platform to design advanced RFID based freight transportation systems[END_REF].

Here, the G-DEVS models were coupled with RFID databases, GIS maps, and constraint solver software. Because workflow modelling is now mostly represented according to the BPMN standard, the authors defined a transformation approach of BPMN 2.0 models into DEVS and G-DEVS simulation models based on the metamodel approach, particularly with the need for data. They described the methodology for enrichment of obtained DEVS or G-DEVS models through performance indicator settings (time and costs).

Other approaches are still under development for using G-DEVS as the convergence formalism for many paradigms, both conceptual or not. G-DEVS is an unambiguous formalism ready for simulation. These works often deal with multi modeling and model transformation. Thus, this demonstrates the continuing interest in G-DEVS.

CONCLUSIONS

This paper proposed a state-of-the-art G-DEVS formalism. It also outlined a history of different contributions. Then, it provided the example of a chairlift system. In addition, it introduced the use of G-DEVS models in distributed simulation with the objective of interoperability with other systems. The HLA standard can be used not only for interoperability between distributed G-DEVS models, but also potentially with other simulation formalisms. Recent research has consisted in bringing missing features to G-DEVS regarding its interoperability with other software. We keep in mind that polynomial abstractions are still controlled by experts to define appropriate thresholds, for instance. One open issue is that some domain-dedicated software agents can use the semantics of the domain to determine the shape of the polynomial function to be used in the model and simulation.

ACKNOWLEDGEMENT

This paper is dedicated in the memory of Norbert Giambiasi, who was the initiator, director, and mentor of these works. I have special thoughts for Claudia Frydman, his wife, who has contributed to this research work by bringing the vision of a computer scientist, including the consideration of performance computing that has always been perfect complement to Norbert's vision focused on digitalization and system specification. For myself, I was mentored by both of them, particularly during my PhD study and the works presented in section 2.4 and the specific study case developed in section 2.5 at the LSIS Lab and Aix-Marseille University.

Fig. 3 .

 3 Fig. 3. Chairlift, chair (and skier) position

Fig. 4

 4 Fig.4describes graphically the evolution of the input, chair speed, output skier, and the coefficientsac and bcas the simulation progresses and time advances. The continuous variable chair position is determined from the discrete coefficient value utilizing the "Coef -1 " function, as presented in Fig.5.

Fig. 4 .

 4 Fig. 4. Evolution of Chair Speed, Skier, and the coefficientsac and bcas a function of time for Chair Position.

Fig. 5 .

 5 Fig. 5. Continuous representation of the "Chair Position" variable

  Fig.7details the Workflow model of a bottling and packing chain process with the graphical Workflow Model Editor tool (LSIS_WME) developed at LSIS University Aix-Marseille(Zacharewicz, 2008a). It represents the high-level Workflow model of the information exchange (data flow) between different components. This model consists of an initialization task (Play symbol), an end task (Stop symbol) (in the figure, they are initiated and finished by server component), and several tasks for data treatment (the tasks are allocated to the components; the swim lines distinguish the responsibilities). In addition, the model contains controllers (OR-join, OR-split, etc.) to route the data between the tasks.

Fig. 7 .

 7 Fig. 7. Supply Chain project Workflow

Fig. 8 .

 8 Fig. 8. G-DEVS HLA platform