Lanshun Nie

Xiaofei Xu

David Chen

Gregory Zacharewicz

Dechen Zhan

To appear in

Keywords: MDI, MDA, ESA, Interoperability, Architecture, Model transformation

This paper presents GRAI-ICE Model Driven Interoperability Architecture (MDI) which is developed based on MDA (Model Driven Architecture) of OMG and some initial works performed in INTEROP NoE. This MDI architecture aims at supporting the development of changeable on-demand and interoperable ESA (Enterprise Software Application). The architecture defined five modelling levels, i.e., Top CIM, Bottom CIM, Object oriented PIM, Pattern oriented PSM, and Component and configuration oriented CODE. This paper presents in detail core concepts and rational of each modeling level. An application example in nuclear equipment industry is outlined.

Introduction

Today, with the increasing pressure from competitive market, enterprises particularly SMEs are obliged to work in network in order to meet the changeable and customized demand. ESA (Enterprise Software Application) supporting the business should be adaptable and flexible to the business change. In such networking approach and with the development of the globalization of the economy, enterprises have to cooperate with partners such as material suppliers, service suppliers, distributor, retailer and public administration to provide highquality products and services to customers. In order to cooperate, it is required for enterprises to have capabilities of interoperability in the level of both business and IT/software systems, i.e. ESA. Changeable on-demand and interoperable ESA brings great challenge to software architecture, implementation, deployment, in a word, software development [START_REF] Pautasso | Autonomic resource provisioning for software business processes[END_REF][START_REF] Bourey | Report on Model Driven Interoperability[END_REF]. This paper demontrates how MDI (Model Driven Interoperability) contribute to these developments.

Problems and Research Objectives

Code is the core artefact in traditional software development process. This process is usually very long, and the cost is usually very high. It is not rapid and adaptative enough to develop changeable on-demand interoperable ESA. Since years there is a shift from code-based software development to model-based software development. The most known approach is MDA (Model Driven Architecture) [START_REF] Omg | MDA guide version 1.0.1[END_REF]. In the objective of tackling interoperability at each level of life cycle development, MDI (Model Driven Interoperability) architecture has been introduced by generalysing the steps of MDA. It deals with interoperabilty between ESAs during their respective developments. In this new methodology, conceptual models of enterprise interoperabilty are elaborated to facilitate the interoperablity at the coding level. Software development starts from business level where a Computing Independent Model (CIM) is elaborated and then transformed into executable ESA system by automatic/semi-automatic transformation and code generation tools.

There are still some research questions due to the fact that MDA, and by heritage, MDI only defines the framework and some guiding rules, but not detailed method to follow, nor modelling languages. For example enterprise modelling techniques are not well considered at the CIM level. Should the CIM level be further divided in order to model both business and software requirements? The interoperability among adjacent levels is also not sufficiently studied.

The research objective is to address the problems mentioned above through the elaboration of a Model Driven Interoperability Architecture (entitled GRAI-ICE MDI) taking into account the MDA and some initial works performed in INTEROP NoE. This MDI architecture aims at defining both the modelling levels of the architecture and model transformation method between adjacent levels. The proposed GRAI-ICE MDI will support the development of interoperable, configurable and executable next generation ESA.

Background and Related Works

Model Driven Interoperability (MDI) architecture [START_REF] Bourey | Report on Model Driven Interoperability[END_REF][START_REF] Omg | MDA guide version 1.0.1[END_REF] aims at decreasing the complexity and difficulty of interoperable software system development by decomposing complex, abstract system into multiple levels. The basic ideas are:

(1) decoupling the requirement specification and function specification from implementation specification in specific platform; (2) establishing computation independent model (CIM) which describes business requirement, platform independent model (PIM) which describes design of software, and platform specific model (PSM) which describes implementation mechanism of system; (3) transformation and mapping from upper level model to lower level model, refining the model and automatically generating software from models [START_REF] Bezivin | Towards a precise definition of the OMG/MDA Framework[END_REF][START_REF] Meservy | Transforming software development: An MDA road map[END_REF].

It has been recommended for modelling using languages and technologies such as UML, MOF and CWM, and transforming models using technologies such as meta-model and pattern [START_REF] Bezivin | From object composition to model transformation with the MDA[END_REF][START_REF] Lemesle | Transformation rules base on meta-modeling[END_REF]. However, MDI only defined some guiding rules, but not the details such as concrete modeling elements, modeling methodology and model transformation method [START_REF] Tan | Application MDA in a conception design environment[END_REF]. Consequently, it is necessary to select or refine modeling method(s) and organize them consistently.

Researchers have studied some most known existing modeling methodology, language and tools such as CIMOSA [START_REF] Kosanke | CIMOSA--overview and status[END_REF], GRAI [START_REF] Chen | GRAI integrated methodology and its mapping onto generic enterprise reference architecture and methodology[END_REF] and IDEF [START_REF] Chen | Architectures for Enterprise Integration and Interoperability: Past, Present and Future[END_REF]. UML (Unified Modeling Language) is the most widely used modeling language for software specification [START_REF] Chen | Architectures for Enterprise Integration and Interoperability: Past, Present and Future[END_REF]. The former is suitable for business level, i.e. CIM level. The latter is suitable for software oriented modelling, i.e. PIM and PSM levels. However, there still exists a big semantic gap between them and no existing approach shows how to integrate them to a consistent architecture. Therefore, the question is still open on how to select, from the existing business modeling methods and software modeling methods, adequate formalisms, to refine, combine and integrate them into MDI architecture.

Motivated by the requirement of developing changeable on-demand and interoperable ESA, and based on some existing modeling languages, a Model Driven Interoperability architecture, entitled GRAI-ICE MDI architecture, is proposed. GRAI refers to GRAI methodology and is used at CIM level to describe business user oriented requirements. ICE means Interoperable Configurable and Executable. This approach is based on some initial works performed in INTEROP-NoE and further developed within the frame of INTEROP VLab through a research collaboration between University Bordeaux 1 (IMS/LAPS) and Harbin Institute of Technology (HIT) and also the company GFI.. It aims at defining concrete modelling elements (concepts) and relations among them at all levels of MDI architecture so that the model of ESA can be described precisely and consistently by these elements. This architecture supports model transformation top-down (CIM→PIM→PSM→CODE), and from code to system deployment.

Also performed in INTEROP NoE, R. Grangel etc. proposed a similar MDI framework. They broke down CIM level into two sublevels, i.e. top-level CIM and bottom-level CIM. Besides this, their research work focus on transformation from top-level CIM model to bottom-level CIM model, with an example of transforming GRAI extended actigrams into UML activity diagrams [START_REF] Grangel | Transforming GRAI extended actigrams into UML activity diagrams: a first step to Model Driven Interoperability[END_REF][START_REF] Grangel | A proposal for goal modelling using a UML profile[END_REF].

Purpose and Structure of the Paper

The purpose of the paper is to present the preliminary research results on Model Driven Interoperability architecture for developing Interoperable ESA. In this paper focus is on the set of modelling methods and languages defined in MDI. The related transformation methods will be presented in a forthecoming paper.

After the introduction given in section 1, the global GRAI-ICE MDI architecture is presented and explained in section 2. Then, section 3 to section 5 will explain the problems, target of modelling, core concepts and relations, as well as modelling methods used at the three main levels (CIM, PIM, and PSM). Section 6 presents the last level of the architecture (ESA component and system level) and outlines the principle of model transformation and supporting tools. An application case is discussed in section 7. Finally section 8 and 9 respectively conclude the paper and discuss on future perspectives.

Overview of GRAI-ICE MDI Architecture

GRAI-ICE MDI follows the basic structure of MDA proposed by OMG. It includes four modelling levels and one system level. It also includes transformation methods between these levels. The global view of GRAI-ICE MDI architecture is shown Fig. 1. Note that CIM level is divided into two sub-levels: Top CIM (business oriented CIM) and Bottom CIM (ESA oriented CIM). ESA system is assembled by business components. It provides service to users by parsing the executable workflow model and scheduling function of business components supported by workflow engine.

TOP CIM and Bottom CIM

There are two main modelling objectives at CIM level. On the one hand, CIM supports business process modeling, analysis, and optimization, with business people as the stakeholder. On the other hand, CIM also supports the modeling of ESA requirements, with business people and software developer as the stakeholders. Consequently the CIM level of GRAI-ICE MDI is further divided in two sub-levels: Top CIM (business oriented) and Bottom CIM (ESA oriented).

Business oriented CIM aims at modeling three kinds of process (or flow). The first is physical process and physical product flow, which supports the analysis and optimization of the time, cost, quality and needed services. The second is business process and document flow, which supports managing, controlling and recording physical process. The third is decision process and order/plan flow which aims at controlling and coordinating physical process and resources. Besides, it is also necessary to describe enterprise organization and decision-making structure.

The core modeling concepts/elements of business oriented CIM are: All elements can be further classified into sub-elements. For example, the element "Function/Action" is classified into "function", "business action", "decision action" and "physical action". The element "Information" is classified into "document", "order", "event" and "report". The view of CIM model can be exactly described by the combination of these elements and sub-class of them. GRAI-ICE CIM model is composed of three kinds of process diagram and some UML class diagram for information, organization, resource, etc.

Physical process model describes the transformation and state transition of physical product in manufacturing. It includes six kinds of basic elements, i.e. product, action, order, resource, organization and QQV. Business process controlling/recording physical process describes the transformation and state transition of documents, such as receipts, orders, reports. It includes four kinds of basic elements, i.e. information/documents, order, action, and organization. Decision process model is based on GRID model of GRAI methodology. It has two dimensions. One is the decision level, for example strategic, tactics, operational levels. The other is the functions. The decision process model describes both the decision making process and the results which coordinate various functions and control other decision making processes.

Information entities and the relations can be identified by analyzing the information flow embedded in business process to build information model. Also, organization model is also needed to construct at this level. Relation inside each kind of elements, such as information, organization, function, product, and resource, is described using UML class diagram.

Analysis and simulation can be performed on business oriented CIM (AS-IS) of existing system. Then, by optimization and re-engineering, the TO-BE CIM can be obtained Business requirement for ESA is analyzed on the basis of TO-BE CIM. The result is ESA oriented CIM which focus on software requirement definition. For example, the physical process is not concerned since ESA does not control this process directly. We refine models extracted from TO-BE CIM and distinguish those activities (processes and information) which will be processed by machine or human with human-machine interaction. Due to the limited space, the specification of ESA oriented CIM is not described in detail in this paper.

ICE-PIM

ICE-PIM is based on object-oriented approach, UML and workflow technology. The core concept BO is proposed for integrating both the process oriented model and object oriented software implementation. ICE-PIM is the bridge connecting business model and software implementation.

At this level, information entities in the business process of CIM are abstracted and formalized as Business Objects (BO) describing the data structure, data dependency and relations. From the perspective of users, BO is an information entity with its state transitions and operations. From the perspective of software implementation, BO is an integrated object with unique identity, a lifecycle, several data sets and several operation sets. For example, the abstraction of a purchasing order is a BO. It provides a good basis for component-based software development. As mentioned above, CIM is more process oriented, in addition to BO, it is necessary to transform business process of CIM into workflow model. In other words, PIM mainly consists of business objects model and workflow model.

The meta-model of ICE-PIM is shown in Fig. 3. Role model defines the access to data and operation. ICE-PIM provides all essential design facets of ESA.

ICE-PSM

On one hand, ICE-PSM follows and inherents the design information from ICE-PIM level models and transforms them into platform specific implementation model. On the other hand, it is the basis for code generation. Software pattern and platform specification are two cornerstones for ICE-PSM.

Business Component (BC) is a largest grained unit of software development, and is a realization body of Business Object (BO) which is the finest grained operation unit of business system. BC is an implementation and running pattern for business components and is the core modeling elements in ICE-PSM. It is based on software pattern and XML, and can be transformed to code by code generator. It is a link between business object model and ESA system. Because of limited space, metamodel of BC is omitted.

The executable workflow model consists of workflow model of PIM level and implementation details based on schedule pattern. It is described by the language supported by workflow engine (e.g. business process modelling engine, state transition event driven engine…). The static configurable model (SCM) is extracted from the relation between business object and role model.

Pattern based ICE-PSM formulizes the software implementation model, simplifies the development of complex ESA and supports industrialized component development. The use of XML provides standard data source for code generation, automatic system configuration and deployment, and interoperability.

Generation of Code: ESA Components and System

In this level, PSM will be transformed into business components and ESA system. There are three phases for business component. The first is stem business component in software development phase. The properties related with roles and individuals are still in parameter. The second is reused business component in deployment phase. Variable properties of BC are finalized for special role/user. So, the BC in this state is role-related component. The third is individualized business component in running phase. The components show different interfaces and behaviors according to the configuration and requirement of users. By doing so, the requirement of flexibility is distributed in several phases and the difficulty of development is decreased.

The ESA development is based on business components. Firstly, the business component models are transformed into stem business components by code generator. Then, they are assembled by workflow, association mechanism and extend mechanism into complete business process. The workflow engine will manage the execution by invoking the different implement BO in the right order. Verification of correctness can be done by running simulation using the workflow engine before execution. After that, they are configured and deployed based on the information of PSM.

An Application: Purchase Management

The proposed architecture, methods, and associated tools and framework have been applied in ESA (Enterprise Resource Planning system) development in several Chinese enterprises. The time of development and deployment is shortened in more than 40%. The application in one of them, i.e. SHANDONG Nuclear Equipment Co. LTD, China is outlined below.

Based on the GRAI-ICE MDI architecture, a set of tools have been developed. Firstly, a MOF, XML and Eclipse based extendable modeling tool supports defining modeling elements on demand and is used in modelling. A running framework has also been developed with a workflow engine inside for ESA. Some patterns in ESA have been extracted and formulized for business objects. XML and pattern based PSM model for BO is built. Based on pattern based PSM, we developed a PSM modeling tool and code generation tool, which support software developer for modeling PSM quickly, generate BC code, configure them and deploy them into the running framework.

Conclusions

Changeability on-demand and interoperability are critical characteristics for ESA in today dynamical economical environment. A concrete and operable model driven interoperability architecture entitled GRAI-ICE MDI is proposed for developing ESA. It integrates both business modeling methods and software modeling methods, defines proper levels and transformation between models elaborated at these levels. The vertical transformation is developed straightforward along the thread "information entity→business object→business component model→stem business component→reused business component". Dynamic component/service assembly based on workflow technology and variable business component gives good support to ESA assembly, configuration and deployment.

The originality of the proposed approach is as following: (1) A nearly complete implementation of MDA/MDI is given in GRAI-ICE MDI, which appropriately integrates enterprise modelling, software modelling and software architecture. [START_REF] Bourey | Report on Model Driven Interoperability[END_REF] The proposed architecture is interoperable, configurable and executable. (3) CIM is divided into business oriented CIM and ESA oriented CIM to capture both business and software requirements. (4) The proposed architecture and associated tools have been successfully applied in changeable on-demand and interoperable ESA development. Last but not least, the time of development and deploy has been greatly shortened.

Perspectives

Considering the technical trend such as service computing and SaaS (Software as a Service), the GRAI-ICE MDI architecture should be adapted to service-oriented model-driven interoperable architecture. Business components will evolve to service components and ESA will evolve to service components composition.

More and more components and services are available on Internet. In order to incorporate, manage and reuse them in GRAI-ICE MDI architecture, it should not only be top-down, i.e. transformation and generation from business to IT, but also bottom-up, i.e. discovery, assembly and composition from existing IT elements to meet new business interoperability requirement [START_REF] Zacharewicz | Short-Lived Ontology Approach for Agent/HLA Federated Enterprise Interoperability, I-ESA China[END_REF]. Also, validation of the models by simulation can be envisaged.

For now, GRAI-ICE MDI architecture focuses more on function requirement of ESA. However, non-function requirements such as confidentiality, security, timing, are crucial for run-time system. So, how to extend the proposed architecture to modeling non-function requirement and transform them into ESA is another important issue to consider in the future.

Fig. 1 .

 1 Fig. 1. GRAI-ICE MDI architecture Top CIM, which is business oriented and based on GRAI methodology, is a set of models focusing on the description of decision making process, business process and physical product flow process. Bottom CIM, which is ESA oriented, extracts from Top CIM and describes more in detail business requirements which must be supported by ESA, i.e. function/process, information, organization and decision making structure. ICE-PIM is concerned with the object-oriented design of ESA. It focuses on identifying and describing business objects (BO). It includes BO model, BO-Based workflow model, role model, and data model.

( 1 )

 1 Physical Product, (2) Information, (3) Function/Action, (4) Resource/Facility, (5) Organization, (6) QQV (Quality-Quantity-Value points): the point or the location where input, output or support should be measured, verified, recorded, controlled, processed, or reported, (7) Connection Sign. The models at business oriented CIM level are composed by these elements and their relations. The meta-model of business oriented CIM is shown Fig.2

Fig. 2 .

 2 Fig. 2. Metamodel of business oriented CIM

Fig. 3 .

 3 Fig. 3. Metamodel of GRAI-ICE PIM model Based on the meta-model, the composition of PIM model is as following. Business object model describes BOs and relationship of BOs. BO integrated diagram describes the detail of BO in four dimensions. (1) BO Data diagram describes the relations among data sets in IDEF1x. (2) BO class diagram describes the DPR (controlling relation between operation and data set), the relations among OP (operation of BO) and activity AT (activity set of BO). (3) BO state diagram describes the state SS, transition ST, and the properties associated with lifecycle. (4) BO use case diagram describes the relation among roles and operations. Relations among several BOs are described by BO-R model in two levels. The first level, i.e. BO level, describes the data dependency relations among BOs, such as association and integration. The second level, i.e. entity-relation level, considers the data set inside BO as entity and then describes the relations among them. Workflow model describes the sequence of activities of one BO of multiple BOs. The business object model is the core of PIM level. Workflow model assembles BOs into process supporting business function. Data, operation and state of BO provide input, output and trigger event for workflow exectuion. Data model describes the data schema of all BOs and provides global business view for users.

Fig. 4 (

 4 a) gives a segment of business process model at Top CIM level in purchase management domain. Fig. 4 (b) shows the BO-relation model at PIM level in the same domain.

Fig. 4 .

 4 Fig. 4. Example of CIM model and PIM model in purchase management domain Fig. 5 (a) shows a segment of XML file, which is the PSM of purchase order BO. Fig. 5 (b) shows the running component of purchase order, which is generated from PSM model.

Fig. 5 .

 5 Fig. 5. Example of PSM model and component of purchase order BO


Z Tu

G Zacharewicz

D Chen

Unified Reversible Life Cycle for Future Interoperable Enterprise Distributed Information Systems

Keywords: Interoperabilitty, HLA, MDA, FEDEP, Information System

This paper aims at improving the re-implementation of existing information systems when they are called to be involved in a system of systems, i.e. a federation of enterprise information systems that interoperate. The idea is reusing the local experiences coming from the development of the original information system with the process of Model Discovery and Ontological approach. We give first, a review of ongoing researches on Enterprise Interoperability. The MDA can help to transform concepts and models from the conceptual level to the implementation. The HLA standard, initially designed for military M&S purpose, can be transposed for enterprise interoperability at the implementation level, reusing the years of experiences in distributed systems. From these postulates, we propose a MDA/HLA lifecycle to implement distributed enterprise models from the conceptual level of federated enterprise interoperability approach. In addition to this classical development, we propose a model reversal methodology to help re-implement the legacy information system, in order to achieve the interoperability with other systems.

Introduction

In the globalised economic context, the competitiveness of an enterprise depends not only on its internal productivity and performance, but also on its ability to collaborate with others. This necessity led to the development of a new concept called interoperability that allows improving collaborations between enterprises. No doubt, in such context where more and more networked enterprises are developed; enterprise interoperability is seen as a more suitable solution to total enterprise integration.

Since the beginning of 2000, several European research projects have been launched to develop enterprise interoperability (IDEAS, ATHENA, INTEROP). Three main research themes or domains that address interoperability issues were identified, namely: (1) Enterprise modeling (EM) dealing with the representation of the inter-networked organization to establish interoperability requirements; [START_REF]IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) -Federate Interface Specification[END_REF] Architecture & Platform (A&P) defining the implementation solution to achieve interoperability; (3) Ontologies (ON) addressing the semantics necessary to assure interoperability.

This paper intends to propose an improvement of the re-implementation of existing information systems when they are called to be involved in a system of systems. Compare to the traditional IS and Simulation development process, we involve the bottom-up process of Model Discovery and Ontological approach into our framework. In the framework, first, we align MDA and HLA to propose a lifecycle to implement distributed enterprise models from the conceptual level of federated enterprise interoperability approach. Besides that, a model reversal methodology is integrated with the MDA/HLA development lifecycle to assist reengineer the legacy information system, in order to achieve interoperability with other systems. Compared to other techniques relevant to interoperability problems, such as SOA, our methodology focuses on providing a standard service API for all the participants. They can use this API to develop communication agent which adapts to the existing IT system without changing it.

The paper is structured as follows. We start out with a survey of related work in the area of HLA, MDA and their harmonization, as well as in the area of reengineering to model-driven architectures (section 2). Then, we describe our motivation of this work (section 3). After that, we explain two main parts of our methodology, alignment of MDA and HLA FEDEP (section 4) and Model Reversal (section 5).

IS and Simulation Development Life Cycle: State-of-the-Art

HLA

The High Level Architecture (HLA) is a software architecture specification that defines how to create a global software execution composed of distributed simulations and software applications. This standard was originally introduced by the Defense Modeling and Simulation Office (DMSO) of the US Department Of Defense (DOD). The original goal was reuse and interoperability of military applications, simulations and sensors.

In HLA, every participating application is called federate. A federate interacts with other federates within a HLA federation, which is in fact a group of federates. The HLA set of definitions brought about the creation of the standard 1.3 in 1996, which evolved to HLA 1516 in 2000 [1].

The interface specification of HLA describes how to communicate within the federation through the implementation of HLA specification: the Run Time Infrastructure (RTI).

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. The information exchanged in HLA is represented in the form of classical object class oriented programming. The two kinds of object exchanged in HLA are Object Class and Interaction Class. Object class contains object-oriented data shared in the federation that persists during the run time; Interaction class data are just sent and received information between federates. These objects are implemented within XML format. More details on RTI services and information distributed in HLA are presented in [1].

The FEDEP (Federation Development and Execution Process) describes a highlevel framework for the development and execution of HLA federation. FEDEP uses the seven-step process to guide the spiral development of the simulation system through phases of requirements, conceptual modelling, design, software development, integration, and execution [START_REF]IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) -Federate Interface Specification[END_REF].

MDA

The first methodology studied is Model Driven Architecture (MDA). This methodology defined and adopted by the Object Management Group (OMG) in 2001, (updated in [3]) is designed to promote the use of models and their transformations to consider and implement different systems. It is based on an architecture defining four levels, which goes from general considerations to specific ones.

 CIM Level (Computation Independent Model): focusing on the whole system and its environment. It is also named « domain model », it describes all work field models (functional, organisational, decisional, process…) of the system with an independent vision from implementation.  PIM Level (Platform Independent Model): modelling the sub-set of the system that will be implemented.  PSM Level (Platform Specific Model): that takes into account the specificities related to the development platform.  Coding Level: The last level consists in coding enterprises applications (ESA: Enterprise Software Application).

To complete this description, a Platform Description Model used for the transformation between PIM level and PSM level is added to these four kinds of models corresponding to four abstraction levels.

MDA/HLA harmonization

In [START_REF] Andreas | Avoiding another Green Elephant-A Proposal for the Next Generation HLA based on the Model Driven Architecture[END_REF], Andreas Tolk mentions that while the HLA can help the MDA to improve in its principles concerning distributed simulation systems, the MDA can help the HLA implementers to improve their products based on the experiences of the OMG partners and the related software industry. Meanwhile, [START_REF] Andreas | Avoiding another Green Elephant-A Proposal for the Next Generation HLA based on the Model Driven Architecture[END_REF] proposes to consider five aspects for merge HLA and MDA together: Domain Facilities, Pervasive Services, RTI as Middleware, Federation Development Tools, and Data Engineering.

A solution of applying MDA to HLA is proposed in [START_REF] Shawn | The Next Step Applying the Model Driven Architecture to HLA[END_REF]. In this methodology, the Component-based development (CBD) is underlined. The design goals and philosophy of CBD also share many similarities with the goals of HLA federate development, including the promotion of reuse and interoperability. However, HLA currently has no standardized development approach to CBD, known as a component model, analogous to the CORBA Component Model (CCM) or the Enterprise Java Bean (EJB) container. As a result, there is no commonality in design and implementation between federates, nor any formal way of separating and reusing the behavioural aspects of an HLA component. This results in an increase in development and maintenance costs, as well as impacting on the potential for reuse outside of the FOM for which the federate was built. As the result, they introduce SCM (simulation component model) into HLA (fig. 2.1.). SCM is one potential candidate for the definition of a standardized model for component-based simulation development. This architecture employs a component model based on the OMG's CCM, and describes how the separation of integration logic and simulation behaviour can be achieved for an HLA federate. This SCM development model also provides a commonality of design between federates, allowing them to access both HLA and extended CBD services (such as data transformation services between federates and the FOM) in a consistent manner.

MDA-Based Reverse Engineering

A framework to reverse engineering MDA models from object oriented code is presented in [START_REF] Favre | MDA-Based Reverse Engineering of Object Oriented Code[END_REF]. This framework is based on the integration of compiler techniques, metamodeling and formal specification and it also distinguishes three different abstraction levels linked to models, metamodels and formal specifications, as fig. 2.4 shows.

In this framework, the model transformations are based on classical compiler construction techniques at model level. At the metamodel level, MOF metamodels are used to describe the transformations from model level. MOF metamodels describe families of ISMs, PSMs and PIMs. Every ISM, PSM and PIM conforms to a MOF metamodel. Metamodel transformations are specified as OCL contracts between a source metamodel and a target metamodel. MOF metamodels "control" the consistency of these transformations. The level of formal specification includes specifications of MOF metamodels and metamodel transformations in the metamodeling language NEREUS that can be used to connect them with different formal and programming languages. The transformations are based on static and dynamic analysis at model level [START_REF] Favre | MDA-Based Reverse Engineering of Object Oriented Code[END_REF].

 Static analysis extracts static information that describes the software structure reflected in the software documentation (e.g., the text of the source code). Static information can be extracted by using techniques and tools based on compiler techniques such as parsing and data flow algorithms.  Dynamic analysis extracts dynamic analysis information, which describes the structure of the run-behavioral, by using debuggers, event recorders and general tracer tools. Dynamic analysis is based on an execution model including the following components: a set of objects, a set of attributes for each object, a location and value of an object type for each object, and a set of messages. Additionally, types such as Integer, String, Real and Boolean are available for describing types of attributes and parameters of methods or constructors.

Fig. 2.4. MDA-based reverse engineering framework 3 Studied Context

A multiple agent/HLA enterprise interoperability methodology is proposed in [START_REF] Zacharewicz | HLA Supported, Federation Oriented Enterprise Interoperability, Application to Aerospace Enterprises[END_REF]. It mentions several enterprises who all participate in a cooperative project, and they need to exchange various information any time, so the framework (fig. 3.1) defined in the methodology provides a platform based on HLA, where each enterprise plays as a federate and connect to each other. This methodology will involve MDA&HLA FEDEP alignment in order to use both of their advantages to realize proper component reuse and rapid development.

Besides that, in order to achieve a rapid federate development according to the legacy IT system, the model reverse engineering is integrated with this alignment. . This new methodology aims to adopt the strong points from both HLA FEDEP and MDA while overcoming their weak points, then, to achieve proper component reuse and rapid development.

Phase 1: Domain requirment definition

The main task of this phase is to collect clear and enough requirements from customer in order to define the objective of the system, to describe the environment of the system, the senario of the system. At the same time, all these definition and description need to be reasonable, understandable for all the stakeholder. CIM of MDA has more similar task with Define Federation Objectives, Develop Federation scenario together in HLA FEDEP. As the result, we align them in this phase, to convert the user requirement, which is more textual based, into more visual model, such as UML use case to derive the federation requirement, etc.

Phase 2: Domain scenario systematization

The main task of this phase is to refine the domain scenario and business process defined in the first phase, to identify and describe the entities involved in the scenario and business process. And then, to define the relationships among entities and behaviors, events for each entity, etc. This phase integrates PIM in MDA, which describes the operation of system but doesn't address the detail platform information yet, as well as steps of Perform Conceptual Analysis, Develop Federation Requirements and Select Federates in HLA FEDEP, which also define and select general participators of the federation, then describe their relationship, behaviours and event in general.

Fig. 3.2. IS and Simulation Devellopment Life Cycle

Phase 3: System model specialization

In this phase, according to the technique chosen and platform selected, the system needs to be refined, for instance, to refine federation and federate structure, to allocate functions and attributes, etc. Detailed design will carry out at this time. This phase integrates the following parts in MDA and FEDEP. PSM in MDA, which is in the form of software and hardware manuals or even in an architect's head, will be based on detailed platform models, for example, models expressed in UML and OCL, or UML, and stored in a MOF compliant repository. The Prepare federation design, Prepare plan, Develop FOM, and Establish federation agreement in FEDEP will produce federate responsibilities, federation architecture, supporting tools, integration plan, VV&A plan, FOM, FED/FDD and time management, date management, distribution agreements, etc.

Phase 4: System Implementation

This phase's task is to transfer the specific system model into code, to create the executable federation and runable federate. At this level, MDA has various transformation techniques from model to code. In the FEDEP, Implement Federate designs will provide modified and/or new federates and supporting database. Implement Federation Infrastructure will provide implemented federation infrastructure and modified RTI initialization data. Plan Execution and Integrate Federation will provide execution environment description and integrated federation.

Phase 5: Test

Throughout the previous steps of the MDA and HLA FEDEP alignment process, testing is essential to ensure fidelity of the models. Testing phase includes the Test Federation, Execute Federation and Prepare Outputs, and Analyze Data and Evaluate Results in HLA FEDEP. Meanwhile, it will also refer to the outputs from the previos steps, such as the original user requirment in the first step, and federation test criteria from second phase.

Model Reversal

This section describes a brand-new process of model reverse engineering with different senarios constraints (see fig. 3.2). The reverse process will re-characterize the legacy system in order to capitalize on the information and functions of the existing system, and make it easy for reusing in a new HLA compliant system. This methodology will assite to HLA FEDEP / MDA alignment mentioned in previous section, to fully achieve rapid development of federation and/or federate based on the legacy IT systems. We distiguish two kinds of reversal scenarios as following.

1. First, when an enterprise intents to start exchanging information in a new cooperative project with other enterprises. In that case, the HLA federation has not been created yet, so we propose to reverse the code of the legacy information systems to the first definition phase (domain requirment definition). Then from top to down, we generate the model for each phase, finally we produce a federation and federate rapid development template. 2. Second, if an enterprise intents to paticipate in a existing cooperative project and exchange data with other heterogeneous IS. Thus, we assume an HLA federation has already been created. Here, according to the HLA FEDEP, federate starts to be considered from the second step (Perform Conceptual Analysis) as the reversal scenario 2 shows in fig. 3.2. Therefore it is not necessary to reverse to the first phase, the reversal can stop at the second phase (Domain scenario systematization). One will only reuse the model of the existing federation to create the model for the federate related to the legacy system of the new participator. Finally, the model of the existing federation and the new federate model are used to generate the code template for the new federate for rapid development.

Conclusion and Future Works

Based on the state-of-the-art, we have proposed a new systematic methodology, which is a valuable outcome of the combination of HLA FEDEP & MDA alignment and Model reverse engineering. This methodology provides a new five steps process to develop models of simulation starting from conceptual enterprise models. In addition, it also bridges the gap from concepts to implementation in the field of enterprise modelling by offering a new standardised and reversible approach. This methodology seems promising regarding to real enterprise information system requirement of distribution, federated interoperability and agility of adapt to dynamic context. Compared with other techniques, which can solve the interoperability problem, such as SOA, our methodology is trying to provide a standard service API for all the participants, who can use this API to develop communication agent which adapts to the existing IT system without changing it.

Up to now, this work is still in a research process. The methodology presented (each phase of HLA/MDA alignment and the model reversal process) still needs to be refined and detailed. A case study will allow testing the proposed approach in an industrial context.

Fig. 2 .

 2 Fig. 2.1. simulation component model

Fig. 2 . 2 .

 22 Fig. 2.2. FEDEP MDA alignment

Fig. 3 .

 3 Fig. 3.1. Interoperable System of Information-Systems


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

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

Bruno Vallespir
email: bruno.vallespir@laps.ims-bordeaux.fr

HLA Supported, Federation Oriented Enterprise Interoperability, Application to Aerospace Enterprises

Keywords: Federation, Enterprise Interoperability, HLA, Collaborative Framework Simulation, Implementation

 for enterprise interoperability to represent the ability of interactions between enterprise systems. In this approach, the interoperability is considered as significant if the interactions can take place at least at the three different levels of conceptual abstraction and if interoperability barriers can be bridged. Then, an interoperability approach can be proposed considering the degree of integration between the different enterprises. After that, we give a review of ongoing researches using HLA to support enterprise interoperability execution. Indeed, the HLA standard, initially designed for military M&S purpose, can be transposed for enterprise interoperability at the implementation level, reusing the years of experiences in distributed systems. Then, we conclude the state of the art part by presenting MDA (Model Driven Architecture) methodology that assists the transformation of enterprise models from conceptual level to models for execution or simulation and the emerging MDI (Model Driven Interoperability) methodology for considering the interoperability transformation. We have recalled complementary levels of abstraction to describe enterprise models and a methodology to transform them, but there is no completed methodology for distributed Enterprise modeling, addressing interoperability consideration at each level. From that postulate, we propose to rationalize the development lifecycle of distributed enterprise models by merging the HLA FEDEP and the MDA / MDI methodology to a new unified lifecycle that will guide the development of distributed enterprises models from the conceptual level to the implementation of a solution. We finish by illustrating interoperability problem on the complex problem of aerospace international cooperation.

Introduction

Section Titles should be set in Times New Roman 12point bold, numbered as shown. Upper case should be used for the first letter of every major word.

In the globalised economic context, the competitiveness of an enterprise depends not only on its internal productivity and performance, but also on its ability to collaborate with others. This necessity led to the devel-opment of a new concept called interoperability that allows improving collaborations between enterprises. No doubt, in such context where more and more networked enterprises are developed; enterprise interoperability is seen as a more suitable solution to total enterprise integration. Since early 2000, several European research projects have been launched to develop enterprise interoperability (IDEAS, ATHENA, INTEROP). Three main research themes or domains that address interoperability issues were identified, namely: (1) Enterprise model-ling (EM) dealing with the representation of the internetworked organisation to establish interoperability requirements; [START_REF] Daclin | Enterprise interoperability measurement -Basic concepts[END_REF] Architecture & Platform (A&P) defining the implementation solution to achieve interoperability; (3) Ontologies (ON) addressing the semantics necessary to assure interoperability [START_REF]Thematic Network, IDEAS : Interoperability Development for Enterprise Application and Software -Roadmaps, Annex 1 -Description of work[END_REF]. This paper aims at investigating the contribution of Information Technology (IT) architecture and platform to develop enterprise interoperability, and in particular the interoperability of enterprise models which take place at higher level of abstraction. In the first part, we present the various approaches of interoperability and the current consideration of interoperability stated as conclusion of the Interop Network of Excellence (FP6, 508011) [START_REF] Chen | Enterprise Interoperability Framework and Knowledge Corpus -Final report Annex: Knowledge Pieces[END_REF]. Then, we recall the High Level Architecture (HLA) [4] that is a standard for distributed simulation. After that, we present a state of the art of the frameworks that already uses HLA in Enterprise interoperability. It gives a review of ongoing researches in using HLA to support enterprise interoperability development. We define then three ways of investigation. The first concerns the time management in enterprise interoperability, the dynamic aspects have to be tackled with sound techniques, the synchronisation can be considered as it was recently employed in Workflow management [START_REF] Zacharewicz | G-DEVS / HLA Environment for Distributed Simulations of Workflows[END_REF]. The second aspect concerns the definition of Enterprise ontology. Federation approach in interoperability requires highlevel representation of data to be exchanged. Computer science ontology, Object, and Interaction in HLA can give key to this problem. The last way concerns the confidentiality of data. Indeed, enterprise must manage the confidentiality of the data they share with other entities. Sub part of enterprise data must be defined. The knowledge coming from information systems, databases and military experiences can be studied to find a way of keeping data safe. We finish by proposing to specialise the HLA Federation Development and Execution Process (FEDEP) [6] development cycle to the concern of enterprise modelling.

Basic Concept of Interoperability

Enterprise Interoperability refers to the ability of interactions between enterprise systems. The interoperability is considered as significant if the interactions can take place at least at the three different levels: data, services and process, with a semantics defined in a given business context [START_REF]Thematic Network, IDEAS : Interoperability Development for Enterprise Application and Software -Roadmaps, Annex 1 -Description of work[END_REF]. A unifying three dimensional framework has been proposed in [START_REF] Daclin | Enterprise interoperability measurement -Basic concepts[END_REF] for enterprise interoperability to represent the ability of interactions between enterprise systems.

Interoperability extends beyond the boundaries of any single system, and involves at least two entities. Consequently establishing interoperability means to relate two systems together and remove incompatibilities. Incompatibility is the fundamental concept of interoperability. It is the obstacle to establish seamless interoperation. The concept 'incompatibility' has a broad sense and is not only limited to 'technical' aspect as usually considered in software engineering, but also 'information' and 'organisation', and concerns all levels of the enterprise [START_REF] Chen | Enterprise Interoperability Framework and Knowledge Corpus -Final report Annex: Knowledge Pieces[END_REF].

Our goal is to tackle interoperability problems through the identification of barriers (incompatibilities) which prevent interoperability to happen. Basic concepts relating to enterprise interoperability are categorised into three main dimensions as described below.

Dimension of interoperability barriers

This dimension takes into account three categories of interoperability problems.

-Conceptual barriers are related to the problems of syntactic and semantic of information to be exchanged. This category of barriers concerns the modelling at high levels of abstraction as well as the level of coding.

-Organisational barriers are related to the definition of responsibilities and authority so that interoperability can take place under good conditions.

-Technological barriers are related to the problem of use of information technologies. This category of barriers concerns the standards that are used to present, store, exchange, process, and communicate data through the use of computers.

Dimension of interoperability concerns

This dimension identifies various levels of enterprise where interoperability takes place. These levels are based on ATHENA Architecture.

-The business level refers to working in a harmonise way at the levels of organization and company in spite of for example, the different modes of decisionmaking, methods of work, legislations, culture of the company and commercial approaches etc. so that business can be developed and shared between companies.

-The process level aims at making various processes working together. A process defines a sequence of services according to a specific need of a considered company. Commonly, in a company, several processes run in interactions (serial or parallel). In the case of a networked enterprise, internal processes of two companies must be connected to create a common process.

-The service level is concerned with identifying, composing, and making function together with various applications (designed and implemented independ-ently) by solving the syntactic and semantic differences, as well as finding connections to various heterogeneous databases. The term `service' is not limited to computer-based applications but manual ones as well.

-The data level refers to making different data models (hierarchical, relational, etc.) and different query languages working together. The interoperability of data is related to find and share information coming from heterogeneous bases, which can moreover reside on different machines with different operating systems and databases management systems.

Dimension of interoperability approaches

This dimension takes into consideration the three admitted approaches to develop interoperability [START_REF] Iso | 14258 -Industrial Automation Systems -Concepts and Rules for Enterprise Models[END_REF].

-Integrated approach: there exists a common format for all models. This format must be as detail as models. The common format is not necessarily a standard but must be agreed by all parties to elaborate models and build systems.

-Unified approach: there exists a common format but only at a meta-level. This meta-model is not an executable entity as it is in the integrated approach but provides a mean for semantic equivalence to allow mapping between models. -Federated approach: there is no common format. To establish interoperability, parties must accommodate on the fly. Using federated approach implies that no partner imposes their models, languages and methods of work. Today, most of the approaches developed are unified ones such as for example in the domain of enterprise modeling, we can mention UEML (Unified Enterprise Modelling Language) and PSL (Process Specification Language) which aim at supporting the interoperability between enterprise models and tools.

Business

Using the federated approach to develop enterprise interoperability is most challenging and few activities have been performed in this direction. The federated approach aims to develop full interoperability and is particularly suitable for an inter-organizational environment (such as networked enterprises, virtual enterprises, etc.). In the enterprise interoperability roadmap published by the European Commission [START_REF]Enterprise Interoperability Research Roadmap, Final Version[END_REF], developing federated approach for interoperability is considered as one of the research challenges for the years to come.

Measuring Interoperability of Information Systems

In the more specific field of information systems, two methods have been proposed to evaluate the interoperability.

The LISI model (Levels of Information Systems Interoperability) [START_REF]Architecture Working Group[END_REF] is the first approach having been exactly developed to measure the interoperability of information systems. The model LISI is defined according to five levels of maturity which have to allow the evaluation of the potential degree of interoperability between two systems. Every level consists of characteristics connected to the interoperability.

The model LCIM (Levels of Conceptual interoperability Model) [START_REF] Tolk | The Levels of Conceptual Interoperability Model[END_REF] proposes a more abstract approach. It focuses on the quality of documentation of the data which are going to be exchanged, and on the quality of the interfaces between the interoperating systems.

HLA Recalls

The High Level Architecture (HLA) [4] [6] is a software architecture specification that defines how to create a global software execution composed of distributed simulations and software applications.

This standard was originally introduced by the Defense Modelling and Simulation Office (DMSO) of the US Department Of Defence (DOD). The original goal was Reuse and interoperability of military applications, simulations and sensors.

HLA concepts

In HLA, every participating application is called federate. A federate interacts with other federates within a HLA federation, which is in fact a group of federates. The HLA set of definitions brought about the creation of the standard 1.3 in 1996, which then evolved to HLA 1516 in 2000 [4].

The interface specification of HLA describes how to communicate within the federation through the implementation of HLA specification: the Run Time Infrastructure (RTI).

Federates interact using the proposed services 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. The information exchanged in HLA is represented in the form of classical objectoriented programming. The two kinds of object exchanged in HLA are Object Class and Interaction Class. The first kind is persistent during run time, the other one is just transmitted between two federates. These objects are implemented with XML format. More details on RTI services and information distributed in HLA are presented in [4].

In order to respect the temporal causality relations in the execution of distributed computerized applications; HLA proposes to use classical conservative or optimistic synchronization mechanisms [START_REF] Fujimoto | Parallel and Distributed Simulation System[END_REF].

HLA Implementation Components

An HLA federation is composed of federates and a Run time Infrastructure (RTI) [4].

A federate is a HLA-compliant program, the code of that federate keeps its original features but must be extended by other functions to communicate with other members of the federation. These functions, contained in the HLA-specified class code of FederateAmbassador, make interpretable by a local process the information received resulting from the federation. Therefore, the federate program code must inherit of Feder-ateAmbassador to complete abstract methods defined in this class used to receive information from the RTI.

The RTI supplies services required by distributed executions, it routes messages exchanged between federates. It is composed of two parts.

The "Local RTI Components code" (LRC, e.g. in Figure 2) supplies external features to the federate for using RTI call back services such as the handle of objects and the time management. The implementation is the class RTIAmbassador, this class transforms the data coming from the federate in an intelligible format for the federation. The federate program calls the functions of RTIAmbassador to send data to the federation or to ask information to the RTI. Each LRC contains two queues, a FIFO queue and a time stamp queue to store data before delivering to the federate.

Finally, the "Central RTI Component" (CRC, e.g. in Figure 2) manages the federation notably by using the information supplied by the FOM [4] to define Objects and Interactions classes participating in the federation. Object class contains object-oriented data shared in the federation that persists during the run time, Interaction class data are just sent and received.

Figure 2. HLA implementation components

A federate can, through the services proposed by the RTI, "Publish" and "Subscribe" to a class of shared data. "Publish" allows diffusing the creation of object instances and the update of the attributes of these instances. "Subscribe" is the intention of a federate to reflect attributes of certain classes published by other federates.

Existing Interoperability Approach Implemented in HLA Federations

We propose in this section a state of the art of the previous approaches using HLA to support the implementation of interoperability solution at the level of company components.

Multidisciplinary Collaborative Design of Virtual Prototyping

The development of complex products requires a multi-field knowledge and requires the computer designers assisted cooperation. The multi-field collaboration M&S technologies are effective approaches for specification and development of complex product.

Authors in [START_REF] Zhang | A Multidisciplinary Collaborative Design System in a Distributed Environment, 11th[END_REF] and [START_REF] Zhang | An approach of Multidisciplinary Collaborative Design for Virtual Prototyping in Distributed Network Environment[END_REF] suggest applying M&S multifield techniques at the level of the complex products development.

The key issue of this approach consists in integrating various, autonomous software tools into a distributed environment. In this work, the authors propose a structure based on HLA and Web services for developing interoperability solution in a multi-field collaboration and distributed environment context. The process of project management in multi-field collaboration is, in particular, deeply analyzed. An M&S platform centered on conception making in multi-field collaboration is presented. The question of interoperability of this research is also discussed.

Common Enterprise Modeling Framework's

for Distributed Organizations (CEMF-DO) CEMF-DO mission is to supply, in distributed organizations, a common structure into which the modeling, the simulation, the analysis and the management of the models for development of interoperability solutions are investigated and integrated. The implementation is done by integrating each distributed subpart of a considered process as a HLA federate (e.g. Figure 3).

The authors [START_REF] Berio | Common Enterprise Modelling Framework for Distributed Organisations[END_REF] activities are related to the Unified Enterprise Modeling Language (UEML) and to the management and synchronization of Enterprise Models, this research was executed as a working package in the INTEROP Network of Excellence (508011) [START_REF] Chen | Enterprise Interoperability Framework and Knowledge Corpus -Final report Annex: Knowledge Pieces[END_REF].

Modeling and Simulation Environments for Design, Planning and Operation of Globally Distributed Enterprise (MISSION)

The works of [START_REF] Jaekel | Distributed Federated Simulation of Supply Chains, in Deliverable D6.1 of Network of Excellence -Contract[END_REF] present a HLA federation approach of Supply Chains Distributed Simulation. Multinational companies have to face the new ways of distributed work. In this vast domain, the approach proposed by the authors concentrates on the distributed, decentralized simulation and, in particular, on the process of supply chain. The global concept is based on the results of the European Module of MISSION [START_REF] Rabe | The MISSION Project[END_REF] and on an extension of the IEM (Integrated Enterprise Modeling). The approach includes the modeling aspects that describe how a user can collect the necessary data for the distributed simulation. Besides, it describes how different models of simulation can be connected starting from a library of models, via a model of company until the automatic generation of the required files of interface. The approach extends HLA to support an industrial use of the distributed simulation. We can consider this approach as a specific enrichment to the application of the HLA standard.

In this approach (i.e. Figure 4), a simulation tool manages the definition and the interoperability of simulation models by exchanging objects. It proposes an intuitive graphical tool to define simulation scenarios of process chains. The simulation manager tool guarantees the coherence between the federation configuration files for distributed simulation scenario and generates all files necessary for the RTI.

LSIS -Workflow Model Editor (LSIS-WME)

In [START_REF] Zacharewicz | G-DEVS / HLA Environment for Distributed Simulations of Workflows[END_REF], an "open" M&S platform is proposed to create and execute models of production flow in the field of Micro Electronic industry manufacture. HLA allows in this platform insuring interoperability of the M&S environment with other heterogeneous software components of the company, notably specific professional applications previously standing alone.

On the one hand, the distributed simulation is used to simulate new road of production to anticipate wrong changes that can concurs to dysfunctions or wrong performance in the production. The workflow models of production route are graphically represented referring to key concepts enounced in [START_REF]Terminology & Glossary[END_REF] [START_REF]Workflow Process Definition Interface --XML Process Definition Language (XPDL)[END_REF]. A Workflow process model is composed of tasks components that treat items (by calling resources), and controllers components that route items between tasks. Items pass over a sequence of these components. These components are linked by directed arrows in order to define a graphical component based model specification. On the other hand, the environment is employed during real time to manage the flow of data associated to the flow of products, to trigger autonomously and right in time specific applications (previously manually called).

The figure 5 illustrates interoperability, orchestrated by a HLA RTI, between LSIS-WME environment and enterprise software components. The applications communicate by publishing and subscribing to information maintained by the RTI, the access to data is restricted regarding to rights defined in publish/subscribe to information regions. This representation illustrates also the capacity of the environment to be plugged to other heterogeneous HLA compliant software components. Other enterprise models can communicate by becoming HLA compliant in order to insure interoperability also at a higher level.

Perspectives to Remove Conceptual Barriers

From the state of the art of the Interoperability in federation domain and implementations experiences presented in the preceding points, we can define several directions of almost natural matching with HLA concepts in the following domains.

The first direction concerns the definition of commonly recognized paradigms and data structure because order and clarification is required to propose a sound paradigm. The second requirement not addressed at the enterprise modeling level is the synchronization of data. The order of data exchanged is important, ignoring this can lead to misunderstanding and wrong functioning of the model. Finally the enterprise modeling must consider the confidentiality management of data. The interoperability can be considered between concurrent enterprises in that context, a strategy of data sharing/not sharing between these must be defined. We present in the next points propositions to address these requirements.

Defining Ontology in XML

The development of a federation interoperability solution requires the creation of ontology at a meta-level, to be collectively admitted by the various federates components. At the implementation step, the choice of XML allows the definition of DTD (Data Type Definition), this data structure is a grammar verifying the consistency of a XML document. An inventory of XML enterprise ontology is done in [START_REF] Chen | European Initiatives to develop interoperability of enterprise applications -basic concepts, framework and roadmap[END_REF].

The WfMC (Workflow Management Coalition) chose XML as the representation of Workflow standard [START_REF]Workflow Process Definition Interface --XML Process Definition Language (XPDL)[END_REF], this standard defines the keys concepts required in the definition of a workflow model of document, physical product or data. In [START_REF] Zacharewicz | G-DEVS / HLA Environment for Distributed Simulations of Workflows[END_REF], a subset of this whole standard was used to define models of products flow. These models were able to be automatically transformed by an algorithm into a model able to be simulated (i.e. not ambiguous and with explicit notion of time). For these requirements, DEVS formalism [START_REF] Chen | European Initiatives to develop interoperability of enterprise applications -basic concepts, framework and roadmap[END_REF] was selected since its strong expression power to specify systems. Thanks to HLA standard compliance, this flow application is able to communicate with different levels of abstraction applications if we consider a mechanism of data aggregation.

On the one hand, main corpuses of ontology are implemented in XML. On the other hand, this format is also used by HLA that defines objects and interaction in this common format. These data defined according to a classic structure of object programming allow facilitating the reuse and the constitution of libraries of data to be shared. Moreover, the possibility of transforming XML data structure by the use of a XSL processor (eXtensible StyleSheet Language) gives consistency and robustness to data. The data can be transformed according to the level of abstraction required from the enterprise level to the implementation level by defining automatic mechanism of transformation as presented in LSIS-WME project [START_REF] Zacharewicz | G-DEVS / HLA Environment for Distributed Simulations of Workflows[END_REF].

Temporal Enterprise Interoperability Management

The current researches expressed in [START_REF] Chen | Enterprise Interoperability Framework and Knowledge Corpus -Final report Annex: Knowledge Pieces[END_REF], [START_REF] Chen | European Initiatives to develop interoperability of enterprise applications -basic concepts, framework and roadmap[END_REF] and [START_REF] Doumeingts | Enterprise Modelling techniques to improve efficiency of enterprises[END_REF] identify the necessity of a space management but also of time to remove at best the conceptual barriers. The domain of the Modeling and Distributed Simulation may propose today mature solutions in these domains.

In particular, the respect of temporal causality of exchanged information is addressed since the end of the 70s with the introduction of synchronization algorithms [START_REF] Fujimoto | Parallel and Distributed Simulation System[END_REF]. Later, standards e.g. [4], implying these algorithms have been introduced, to support and to facilitate the development of application platforms of distributed M&S. In [START_REF] Zacharewicz | Lookahead Computation in G-DEVS/HLA Environment[END_REF], the interaction between distributed DEVS models [START_REF] Chen | European Initiatives to develop interoperability of enterprise applications -basic concepts, framework and roadmap[END_REF] is detailed. These solutions can be transposed into an upper level of abstraction, in particular at the enterprise interoperability level. Therefore, the synchronization of enterprise models can be considered within the experience of lower level constraints (e.g. M&S level). For instance M&S enounces time related rules (i.e. causality) to be considered for more real-world accuracy of the upper level model. At the end, it is also interesting to envisage trans-level interactions between enterprise models, models for simulation, and data resulting from real world sensors to define a multi level, real time execution, application for enterprise interoperability.

Data Sharing Management (Confidentiality)

Another main issue of interoperability is the data confidentiality management. The standard [START_REF] Iso | 14258 -Industrial Automation Systems -Concepts and Rules for Enterprise Models[END_REF] states on the requirement for an enterprise to share some selected sets of data in the situation of interoperability but to keep confidentiality of others. Directed by military goals, the HLA address this problem. HLA based its approach on set theory, it sub sets of data to share by interoperability and some other data not to be revealed to others components. In more details, data of enterprise need to be partitioned into classified sets with levels of confidentiality. This field is well developed in military interoperable war games [4] and could be transposed to enterprise purpose.

In detail, HLA employs mathematical set theory to define subsets of data to be exchanged and confidential data regarding to federates right status to share, update, handle and to receive data. These definitions can be generalised at an upper level. Finally, at the lower level, these concepts will be implemented from entity relation and data object model specified from data sets.

"From Enterprise Model to Execution" Methodology

The preceding points give evidence of no existing unified methodology to go from enterprise model to the implementation of a solution or to the model simulation (to obtain validations). We propose to explore existing methodology of model transformation.

MDA (Model Driven Architecture)

The first methodology studied is MDA (Model Driven Architecture®). This methodology defined and adopted by the OMG (Object Management Group) in 2001, (updated in 2003 [START_REF]OMG: MDA Guide Version 1.0.1. Object Management Group[END_REF]) is designed to promote the use of models and their transformations to consider and implement different systems. It is based on architecture defining four levels (i.e. Figure 6), which goes from general to specific:

Level CIM (Computation Independent Model): focusing on the whole system and its environment.

It is also named « domain model », it describes all metiers models (functional, organisational, decisional, process…) of the system with an independent vision from implementation.

Level PIM (Platform Independent Model): model the sub-set of the system that will be implemented.

Level PSM (Platform Specific Model): that takes into account the specificities related to the development platform.

Coding Level: The last level consists in coding or more generally enterprises applications (ESA: Enterprise Software Application).

Figure 6. MDA method reference framework

To complete this description, a Platform Description Model used for the transformation between PIM level and PSM level is added to these four kinds of models corresponding to four abstraction levels.

MDI (Model Driven Interoperability)

The approach "Model Driven Interoperability" (MDI) consists in considering interoperability problems from enterprise models level instead of only at the coding step.

These works realised in the Task Group 2 (TG2) of INTEROP-NoE state at defining an approach inspired from OMG MDA® [START_REF] Bourey | Report on Model Driven Interoperability[END_REF]. The goal is to tackle the in-teroperability problem at each abstraction level defined in MDA and to use models transformations techniques to link vertically the different levels of abstraction or horizontally to ensure each models of the level interoperability. The general framework of the approach proposed in TG2 is presented in Figure 7. The main goal of this methodology, based on model transformation, is to allow a complete follow from expressing requirements to coding of a solution and also a greater flexibility thanks to the automation of these transformations. In the context of TG2, experimentations have been realized and in particular the feasibility study to transform GRAI Methodology [START_REF] Chen | GRAI integrated methodology and its mapping onto generic enterprise reference architecture and methodology[END_REF] [25] Models to UML between CIM and PIM levels [START_REF] Bourey | Report on Model Driven Interoperability[END_REF]. These works are additional works realised in the context of ATHENA to define UML profiles to take into account Service Oriented Architectures at PIM level [START_REF] Gorka | A Platform Independent Model for Service Oriented Architectures" Tor Neple, Anthony Beardsmoreand Michael Friess[END_REF]. These results have consolidated by results presented by J. TOUZI [START_REF] Touzi | Aide à la conception de Système d'Information Collaboratif support de l'interopérabilité des entreprises[END_REF] that have proposed an interoperability transformations method from BPMN to UML in the context of services oriented architecture.

Nevertheless, if the soundness of the methodology has been demonstrated, no full industrial scale validation have been yet realised. A project ISTA3 [START_REF] Grand | Projet ISTA3 Interopérabilité de 3ème génération, pour les Sous-Traitants de l'Aéronautique[END_REF] has especially for goal to demonstrate these concepts in an industrial real world significant application. The different methodological propositions will be tested and refined by focusing on model interoperability and their interoperability. It will consist in particular to improve the flexibility of the MDI transformation process in the way of obtaining dynamic interoperability in the context of federated approach.

HLA FEDEP

HLA proposes a development life cycle of federate and federations based on the waterfall software engineering cycle. This life cycle is named FEDEP [6].

From the very beginning of the elaboration of the HLA standard, a need was identified in the HLA federations development. This need is characterized by a high degree of flexibility in the process of composition and execution of HLA applications that realize objectives of a "compound" application. The purpose of FEDEP is to avoid the reiteration (every new federation construction) of already treated questions dealing on the way the HLA applications were built and how they run. Indeed, it was recognized that the process of development and execution of HLA federations can vary significantly between applications create by various designers.

Figure 8. Federation development and execution process (FEDEP).

For the reasons enounced previously, the DMSO has identified, a cycle of seven steps that all HLA federation designer should follow to develop and execute their federations. Figure 8 illustrates each of these steps and the following summary is detailed in the next point. We specialise then the methodology for enterprise modelling.

Step 1: Federation Objective Definition: the user of the federation and the development team of the federation define and agree a set of objectives and inform what must be carried out to realize these objectives.

Step 2: Conceptual Analysis Realization: based on the space characteristics of a problem, an appropriate representation of the domain of the real world is created.

Step 3: Federation Design: federates, reusable in the considered federation, are identified. The activities for the modification of the federates and\or the creation of new federates are executed. The features required by the federation are assigned to the federates and a plan is defined for the development of the federation and its stake in work.

Step 4: Development of federation: the Federation Object Model (FOM) is developed. Agreements between the federates are established on the basis of data to be shared and the algorithms which will run it. Finally, new federates and\or the modifications of existing federates are implemented.

Step 5: Planning, Integration And Test Of The Federation: all the activities of integration necessary for the federation are executed and tests are realized to insure these conditions of inter-functioning.

Step 6: Federation Execution And Outputs Preparing: the federation is executed and the data produced by the execution of the federation are pre-treated. This step is an addition with regard to the former standard; it marks the necessity of a phase of calibration of the classification of the results.

Step 7: Data Analysis And Results Appraisal: the data produced by the execution of the federation are analyzed and estimated and the results are presented in a report to the user.

Conclusion on Existing Model Transformation

Methodologies Similarity appears by comparing the steps of the various methods. Nevertheless from our consideration a lack of distribution consideration in MDA/MDI and not enough specificity to enterprise interoperability in HLA have been also identified. From these statements, we propose to define an enterprise model specific development methodology based on the HLA Federation Development and Execution Process (FEDEP) [6]. It will clarify and systematise the development process of enterprise models. We precise that we have restricted our methodology to address transformation of enterprise models of distributed enterprises interoperating in unified or federated manner and when the coding will be done respecting the HLA standard.

The proposed unified methodology for development of interoperating enterprise model follows the HLA FEDEP that proposes seven steps in the federation creation. This formalization will help also the reuse of the development knowledge. It will also give a common metric to compare solution developments and refer to HLA standard to ensure heterogeneous components interoperability.

Enterprise Model Unified Transformation Methodology

We presented in §4 various enterprise models implementation using HLA, each has followed its own development cycle. In order to be able to compare these methods and models, besides to clarify and rationalise the implementation; we propose a common method by the convergence of HLA FEDEP MDA, MDI steps. This life cycle propose to standardise the steps to reach simulation or implementation from a conceptual enter-prise model, it is depicted in Figure 9. Phase 2: As described in the FEDEP second step, a conceptual model is required. In our case, this model contains enterprise models represented as entities and actions that represent external information exchanged between enterprises. This representation can naturally use the typical enterprise relation model elaborated in the enterprise model interoperability field (e.g. UEML models [START_REF] Ueml | Public Web for UEML[END_REF]). We address in that step what are the information to exchange, in others terms, what is the structure of the distributed ontology. This level is considering the MDA PIM level.

Phase 3: As FEDEP third step, the mapping of enterprise models into HLA federates is realised, in detail the way models handle received information and how they send information to the federation is addressed, these mechanisms can conform to synchronisation algorithm proposed in [START_REF] Zacharewicz | Lookahead Computation in G-DEVS/HLA Environment[END_REF]. We pay here attention to reuse already existing enterprise models. Not existing enterprise models federates are created. Phase 4: In the FEDEP fourth step, the methodology maps enterprise interoperating connections between models into HLA interactions and objects. Then, these data are structured to generate the associated FOM. The strategy concerning the confidentiality of data problem is also explicitly addressed in that step. In details, on the one hand, an enterprise model that owns an incoming relation with an influencer enterprise "publishes" on an Interaction Class defining the coupling relation by publishInteractionClass(). On the other hand, an enterprise model possessing an interoperability outgoing relation "subscribes" to the Interaction Class published by the enterprise which influence it by using subscribeInteractionClass(). The methodology may also propose to generate, in the FOM, objects that define various shared elements of local enterprises; for instance, enterprise performance measurement tracking. Tracked enterprise federate publishes using RTIAmbassador publishObjectClassAttributes() and tracker enterprise federate subscribes using sub-scribeObjectClassAttributes(). To respect the time causality, the interactions among enterprise federates are defined "Time Stamped Order". They are emitted with a timestamp related to the local logical time of supplier enterprise federate in order to the RTI handles them respecting the causality (we address here the time management of the data).

At the end, the enterprise model federates generated by this methodology can be reused and interfaced with heterogeneous HLA-compliant models. For instance, "client models" federates can be upstream connected to enterprise federates and "enterprise subcontractors" federates can be downstream connected. The results obtained by simulation are used for validation of the models by test and analyse; in case it does not fulfilled the specification the methodology must allows doing feedback correction as described in the FEDEP last step.

Complex Problem of Aerospace International

Cooperation Interoperability The design of a new launch vehicle is a strongly complex task. The creation of a huge number of unique new parts, the involvement of a legion of engineers from several domains, countries, the need for frequent and intensive collaboration among them, the length of the development cycle, and the consequent expenses, are all on a scale that few other industries approach [START_REF] Klapproth | Sky CAD: design interoperability streamlines aerospace R&D[END_REF].

In military and aerospace community, the interoperability has been historically tackled at the technological level to facilitate reusing. Efforts in the way of standardisation have been instigated.

In particular, on the US side, the National Institute of Standards and Technology (NIST) leads programs for Systems Integration and Interoperability. NIST offers a variety of technological assistance to U.S. aerospace firms to enhance their competitiveness in the global marketplace [31]. In detail of the technical aspects, computer-controlled manufacturing processes need to speak the same language. Computer-aided design systems need to be able to receive and hand-off product data accurately within and between shops. NIST research means aerospace manufacturers spend less time solving systems integration and interoperability problems and more time building planes [31].

The NIST Manufacturing Interoperability equips U.S. manufacturers with the technical guidance and testing support needed to interoperate in today's global, heterogeneous manufacturing world. Systems Integration for Manufacturing Applications coordinates NIST research efforts to improve interoperability and data integration in the areas of manufacturing e-commerce, product data, and scientific data.

The NIST Manufacturing Engineering Laboratory (MEL) [START_REF]The NIST MEL: assisting aerospace manufacturing through measurements and standards Stieren[END_REF] has for goal assisting aerospace manufacturing through measurements and standards; it is a good example of what can be done in aerospace manufacturing technical interoperability. MEL is one of the seven NIST measurement and standards laboratories. MEL works with the American manufacturing sector to develop and apply technology, measurements, and standards. MEL provides industry-needed engineering tools, interface standards, systems architectures, and traceability.

This study stresses the fact that efforts to make specific aerospace sector converge with the industrial sector on unified standardization points are strongly considered. However, most of the standards are dedicated to technical interoperability, and we believe that aerospace need to explicitly consider other abstraction level of interoperability: business and also organizational (i.e. Figure 1). In particular, for European multi-countries projects, the following aspects are relevant but complex to handle and not clearly integrated in projects: human organizational working, cultural aspects, communication, working laws, costs, etc. We are at the beginning of new challenging considerations on the conceptual level of aero-spatial programs that still need to be addressed. We state that this field can learn experience from interoperability seen from the Enterprise-Modeling research field point of view; e.g. the new life cycle we propose in § 6.5 tackles interoperability at the different abstraction levels of enterprise model conception. In addition, interoperability association, Interop V-Lab [33], supplies deliverable on multi countries projects led in the field of Enterprise Interoperability that can turn out helpful experiences and resources.

Conclusion

This article has given a state of the art of model transformation methodologies and illustrated the use of HLA standard for the implementation of enterprise applications federations.

Three main concerns of interoperability barriers have been identified at the conceptual level and ways of solutions relative to the use of the HLA standard have been envisaged at the coding level. More detailed solutions that answer to specific enterprise modelling are under our scope of research and will guide our future works. In the way back the exploitation of the modelling and simulation level knowledge gives some keys from the data exchange point of view concerning time, confidentiality and organisation.

After this statement, we propose the first release of a clear and systematic methodology, specialised from the HLA FEDEP, MDA/MDI methodologies, to develop models of simulation from conceptual enterprise models. This methodology of model transformation and implementation seems to be really promising regarding to actual requirement of distribution, federated interoperability and information systems dynamic behaviour of enterprises. At the end, it tries to bridge a gap from concepts to implementation in the field of enterprise modelling by offering a new standardised and systematic way.

Figure 1 .Figure 1

 11 Figure 1. Framework for enterprise interoperability Figure 1 shows the graphic representation of the interoperability framework.

Figure 3 .

 3 Figure 3. Distributed supply chain

Figure 4 .

 4 Figure 4. Interoperability model approach

Figure 5 .

 5 Figure 5. Components interoperability in microelectronic components manufacture

Figure 7 .

 7 Figure 7. Cadre de référence pour la méthode MDI

Figure 9 .

 9 Figure 9. New convergent Methodology Phase 1: In a first step, the objectives of the federation of enterprises have to be defined. Basically, the common goal of all federation created by this methodology consists in defining federation of interoperating enterprise models. This step is also considering the domain model of MDA CIM level.

Author Biographies

GREGORY ZACHAREWICZ is Associate Professor in Bordeaux 1 University (IUT MP). His research interests include DEVS, Distributed Simulation, HLA, and Workflow. He recently focused on Enterprise Modeling and Interoperability. www.laps.u-bordeaux1.fr/ DAVID CHEN is professor at University Bordeaux 1, researcher at IMS. His research interests include enterprise modeling, integration and interoperability. He has been actively working in European research program in the related areas (FP1-FP6), participating in several cooperation programs between the European Union and China in enterprise integration. David CHEN is also involved in relevant standardization activities. He is member of CEN TC 310/WG1 (System Architecture), expert of IEC/ISO JWG15 (Enterprise-Control System Integration) and ISO TC184/SC5/WG1 (Modeling and Architecture). He is also member of the IFIP WG5.12 (Architecture for enterprise integration) and IFAC WG5.3 (Enterprise Integration and Networking). He has published more than 80 papers in international journals and conferences. www.laps.u-bordeaux1.fr/ BRUNO VALLESPIR is full Professor at University Bordeaux I and member of IMS. Within this framework, he is today responsible of the research group about production systems. Bruno Vallespir's research topics are production management, performance evaluation and enterprise modeling including modeling tools and design methodologies. On these topics, he published more than 60 papers in conferences, journals and books, was involved in around 20 international, European (from FP1 to FP6, mainly ESPRIT) or French projects and working groups. Recently, he was involved in INTEROP NOE. He is member of several working groups and steering committees of IFIP and IFAC. www.laps.u-bordeaux1.fr/