Frederick Benaben
email: frederick.benaben@mines-albi.fr

Tiexin Wang
email: tiexin.wang@mines-albi.fr

Sebastien Truptil
email: sebastien.truptil@mines-albi.fr

A General Model Transformation Methodology to Serve Enterprise Interoperability Data Sharing Problem

Keywords: interoperability, model-driven engineering, model transformation, semantic check, syntactic check

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Nowadays, the world is becoming smaller and smaller. With the advancements of science and technology, more and more collaborations among countries, companies and persons are appeared. Such collaborations appear and disappear within specific periods, with achieving or failing of their goals. Based on this fact, the ability of cooperating with different partners becomes crucial to modern systems and organizations. Furthermore, "interoperability" is proposed specially to describe such ability. There are several definitions for interoperability; one of the initial definitions of interoperability could be referred in [START_REF] Amice | CIMOSA: CIM Open System Architecture[END_REF]. Another two definitions are listed here: as defined in [START_REF] Konstantas | Interoperability of Enterprise Software and Applications[END_REF], "interoperability is the ability of a system or a product to work with other systems or products without special effort from the user"; a similar definition of interoperability is stated in [START_REF] Nancy | What does interoperability mean, anyway? Toward an Operational Definition of Interoperability[END_REF], interoperability is "a measure of the degree to which diverse systems, organizations, and/or individuals are able to work together to achieve a common goal. For computer systems, interoperability is typically defined in terms of syntactic interoperability and semantic interoperability". Two key issues that stated in the two definitions are: "cooperate without special users' effort" and "semantic and syntactic" aspects. Although in different domains and from different views of one domain, the definitions of interoperability might be slightly different, the essence reflected by these definitions is similar. Fig. 1 shows the interoperability issue and the data sharing problem of it.

Fig. 1. An illustration of interoperability issue

Fig. 1 shows a collaboration situation between two companies. Modern companies use information systems to manage their business; in some aspects, the cooperation among companies depends on the merge of their information systems. Furthermore, merging information systems relies on the interactions of their applications. So, sharing data among these applications (both within one system and from different systems) is important for enterprise cooperation. However, generally the structures of data are designed for specific applications used by particular enterprises; it is difficult to share data among different applications. Model transformation provides a possible solution to data sharing issue.

"Enterprise Interoperability Framework (EIF)" [START_REF] Chen | Enterprise Interoperability Framework and Knowledge Corpus -Final report Annex: Knowledge Pieces[END_REF] shows a possible way of combining formally enterprise interoperability and model-driven engineering (especially the model transformation part). However, traditional model transformation practices have their own weakness: low reusability, repetitive tasks, huge manual effort, etc. In order to apply model transformation to solve interoperability problems, a general model transformation methodology (shield these weaknesses) is required. This paper presents such a general model transformation methodology.

This paper is divided into five sections. In the second section, the basic principles of model-driven engineering (MDE) and model transformation are presented. The third section describes the overview of the general methodology. The detail of syntactic and semantic checking measurements is illustrated in the fourth section. Finally, the conclusion is proposed in the fifth section.

Basic Background Theories

In this section, the basic background theories of this general model transformation methodology (GMTM) are presented. These theories are divided into two group: theories owned by MDE domain and theories belonging specially to model transformation domain.

Model-driven Engineering

Model-driven engineering (MDE) [START_REF] Schmidt | Model-Driven Engineering[END_REF], which initially referred as model-driven software development, is an important direction in the development of software process. It takes modeling and model transformation as the main means of software development methods. Comparing with other software development methods, the main features of model-driven development approach are paying more attention to construct the abstract description of different areas of knowledge: the domain models; then based on these models to characterize the software system. Through layers of automatic (semi-automatic) conversion of the models, the development from design to achieve the transition to the final completion of the entire system will complete. At this moment, the principles of "model driven engineering" are applied on many different domains (knowledge engineering, enterprise engineering, etc.); it is not restricted to software development any more.

As an example to broader MDE's vision, "model-driven architecture (MDA)" [START_REF] Soley | the OMG staff: Model-Driven Architecture, OMG Document[END_REF] was launched in 2001 by the Object Management Group (OMG). Fig. 2 shows the basic principles of MDA.

Fig. 2. Simple illustration of MDA

In MDA, models could be divided into three groups: "CIM", "PIM" and "PSM". In each of the three groups, large number of models could be built to reflect the characteristics, which based on different point of views, of one system. Models in PIM layer should be generated by transforming the models from CIM layer; the mechanism of building PSM layer's models follows the same principle (generated by transforming models from PIM layer).

In MDE context, everything could be regarded as a model or could be modeled. In simple words, MDE uses models to describe the reality (concerns the modeling techniques) and uses model transformations to solve conversion problems. Modeling, as one key role of MDE, means the activities of building models; model transformation, as another key role of MDE, means the process of taking the source model to generate the target model.

Model and Meta-model

Model and meta-model are two basic concepts in MDE; Fig. 3 shows the relation between them.

Fig. 3. Relation between model and meta-model

As defined in [START_REF] Bezivin | Model driven engineering: An emerging technical space[END_REF], model is "a simplification of the subject and its purpose is to answer some particular questions aimed towards the subject". Models are built to represent the characteristics of real systems based on specific point views. Metamodels are a specific kind of model; they make statements about what can be expressed in valid models. Meta-models could have several layers; meta-model defines building rules for models that conform to it.

Model Transformation

Model transformation plays a key role in MDE; it is the nexus among heterogeneous models. With the extensive usage of MDE theory, more and more theories, techniques and tools of model transformation have been created. Large amount of model transformation practices have been developed to serve some specific domain problems using these theories, techniques and tools; two examples are stated in [START_REF] Castro | Applying CIM-to-PIM model transformations for the service-oriented development of information systems[END_REF] and [START_REF] Grangel | Transformation of decisional models into UML: application to GRAI grids[END_REF]. In general, according to [START_REF] Czarnecki | Classification of Model Transformation Approaches[END_REF], there are two main kinds of model transformation approaches. They are: model-to-code approaches and model-to-model approaches. For model-to-code approaches (PIM to PSM), there are two categories: "Visitor-based approaches" and "Template-based approaches". For the model-to-model approaches, there are five categories:  Direct-dManipulation Approaches: offering an internal model representation plus some API to manipulate this model  Relational Approaches: grouping declarative approaches where the main concept is mathematical relations  Graph-Transformation-Based Approaches: e.g., VIATRA, ATOM and GreAT  Structure-Driven Approaches: an example is "OptimalJ" model transformation  Hybrid Approaches: combining different techniques from the previous categories The detail of these approaches (their applicable situations, working mechanism, etc.) could be consulted in [START_REF] Czarnecki | Classification of Model Transformation Approaches[END_REF].

However, as mentioned above, traditional model transformation practices have internal weaknesses; these weaknesses limit the scope of model transformation usage. As the inner characteristics and requirement of modern enterprise interoperability (e.g. agility, transient, heterogeneity, complexity), traditional model transformation practices are not a good choice to serve it. So, a general model transformation methodology is required.

Overview of the General Methodology

This section presents the detail of GMTM. The main objective of GMTM is "overcoming the shortcomings of traditional model transformation practices and serving to enterprise interoperability". "General" means the use of this methodology is widely, not limited to a specific domain. In order to be general, the process of defining model transformation mappings should be automatic. To achieve this goal, semantic and syntactic checking (S&S) measurements are combined into the traditional model transformation process.

Theoretical Main Framework of the General Methodology

GMTM is created on the basis of a theoretical main framework, which is based on [START_REF] Bénaben | Information Systems design for emerging ecosystems[END_REF], and shown in Fig. 4. The necessary condition of doing model transformation between two models is: the source model and target model should have some potential common items (to be detected and found). For the reason "models are built based on the rules defined in their meta-models", the potential common items could be traced on meta-model layer.

The source MM shares part of its concepts with the target MM. As a consequence, the source model embeds a shared part and a specific part. The shared part provides the extracted knowledge, which may be used for the model transformation, while the specific part should be saved as capitalized knowledge in order not to be lost. Then, mapping rules (built based on the overlapping conceptual area between MMs) can be applied on the extracted knowledge. The transformed knowledge and an additional knowledge (to fill the lack of knowledge concerning the non-shared part of concepts into the target MM) may be finally used to create the shared part and the specific part of the target model.

The Meta-meta-model within Main Framework

According to [START_REF] Del Fabro | AMW: A Generic Model Weaver. 1ère Journées sur l'Ingénierie Dirigée par les Modèles[END_REF], in order to apply semantic checking measurements in the process of defining model transformation mapping rules, some principles should be obeyed. In this GMTM, the mechanism of applying S&S in model transformation process is defined in a meta-meta-model (MMM), which is shown at the top of Fig. 4.

There are several meta-modelling architectures, for example "MOF: Meta-Object Facility" [START_REF]MOF 2.0 Query / Views / Transformations RFP[END_REF]. These architectures define their own semantic and syntax. For GMTM these existing meta-modelling architectures are complex to use. So, based on the context of model transformation, we adapt the idea stated in MOF and generate this MMM. Fig. 5 shows the content of this MMM.

Fig. 5. The class diagram of the meta-meta-model

For GMTM, this MMM works on the top abstract level of all the other models. As this MMM is defined as a common criterion, the meta-models (for both source models and target models) could be built or transformed to the versions that conform to it.

As shown in Fig. 5, there are ten core elements in this meta-meta-model. As models may come from various domains or systems, a class named "Environment" is defined to stand for these domains. All the model instances are standed by the class "Model", every model belongs to a specific "Environment". "Model" is made of "Element", which has two inheritances: "Node" and "Edge". "Node" are linked by "Edge" based on their "roles". "Element" has a group of "Property", the "Property" could identify and explain the "Element". "Property" has a data type: "Primitive Type" or "Enumeration"; to a certain extend, data type could differentiate "Property".

All these items (with the relationships among them), illustrated above, present the standard requirement on specific meta-models. Another two key items shown in Fig. 5 are: "Semantic Relation" and "Syntactic Relation". They exist on different kinds of items (e.g. between a pair of elements). Model transformation rules are generated based on these two relations.

Generally, model transformation mappings are defined on the element level (node and edge); the mapping rules are usually generated by domain experts. However, applying model transformation practices to serve enterprise interoperability requires model transformation practices to be more flexible and easier (faster) to integration. So, semantic checking and syntactic checking that focused on element and property levels, are introduced to automatically define the mappings (replacing manual efforts). Also, in the MMM, the property and its dada type are highlighted; both of them are used to deduce semantic relation on element level. Furthermore, the inner attribute of element and property: their names, have also been used to define semantic and syntactic relations.

Matching Mechanism

In GMTM, model transformation is regarded as an iterative process: a target model (generated by one transformation iteration) could be the source model for the next iteration. In each iteration phase, transformation process is divided into three steps: matching on element level (coarse-grained matching), hybrid matching (fine-grained matching) and auxiliary matching (specific parts matching). All these three steps are supported by software tool; experts may only be involved in the validating process.

Iterative Matching Mechanism

According to the theoretical main framework, model transformation mappings are built on the potential shared parts between source model and target model. During the transformation process: the specific part of source model is saved as capitalized knowledge and the specific part of target model should be enriched with additional knowledge. So, a question may be put forward: how to deal with the capitalized knowledge and where the additional knowledge comes from? The "iterative matching mechanism" gives a possible answer to this question. Fig. 6 shows the general idea of this iterative matching mechanism.

Fig. 6. Overview of iterative matching mechanism

One complete model transformation process may involve several iterations; each of iterations is an independent model transformation instance. An intermediate model is both the target model of the former iteration and source model of the latter iteration. All the specific parts (unmatched items: properties and elements) from source models are saved into ontology as capitalized knowledge, and the specific parts of target models are enriched with additional knowledge (capitalized knowledge from former iterations) that extracted from the same ontology.

Matching on Element Level Generally, model transformation mappings are defined on element level (nodes and edges); if two elements (come from source model and target model, respectively) stand for the same concept (shared concept between two models), a mapping should be built. As stated above, semantic and syntactic checking measurements are applied on a pair of elements to detect the relation between them.

The mechanism of defining matches on element level is illustrated by an example shown in Fig. 7.

Fig. 7. Example of making matching on element level

The two specific meta-models (marked as A and B) are supposed to be conformed to the MMM. Model A has "m" elements and model B has "n" elements; the mappings should be built within the "m*n" element's pairs. Table 1 shows this comparison matrix. This matrix is built automatically by software tool; based on different inputs (model instances), similar matrix would be generated automatically. Within each element's pair, there exists an "Ele_SSV" value. "Ele_SSV" stands for "element's semantic and syntactic value"; it is calculated based on the elements' names and their properties. Formula (1) is defined to calculate "Ele_SSV" value.

Ele_SSV = name_weight*S_SSV + property_weight*(∑ Max(P_SSVi) 𝑥 𝑖=1 )/x (1)
In ( 1), "name_weight" and "property_weight" are two impact factors for the parameters elements' names and elements' properties, respectively. Both the values of "name_weight" and "property_weight" are between 0 and 1; the sum of them is 1. "S_SSV" stands for "string semantic and syntactic value; it is calculated based on the words (element's name is a word). "P_SSV" stands for "semantic and syntactic value between a pair of properties"; another example which shown below, is used to calculate "P_SSV". "x" stands for the number of properties of a specific element from source meta-model (e.g. element E1).

The example shown below is used to generate the "Ele_SSV" value within the element's pair of E1 and e1 (focuses on their properties' group); table 2 is created for this example. This kind of tables is also built automatically (for different comparing elements' pairs) by software tool. E1 has "x" properties and e1 has "y" properties; within each of the "x*y" pairs of properties, there exists a "P_SSV". Formula (2) shows the calculating rule of "P_SSV".

P_SSV = pn_weight*S_SSV + pt_weight*id_type (2)
In (2), "pn_weight" and "pt_weight" are two impact factors for the parameters properties' names and properties' types, respectively. The sum of "pn_weight" and "pt_weight" is 1. "S_SSV" is the same as stated in [START_REF] Amice | CIMOSA: CIM Open System Architecture[END_REF]; this time, it stands for the semantic and syntactic value between two properties' names. "id_type" stands for "identify properties type". If two properties have the same type, this value is 1; otherwise, this value is 0.

With the help of table 2 (also needs the "S_SSV" between E1's name and e1's name), the "Ele_SSV" between element "E1" and "e1" could be calculated. In this way, table 1 could be fulfilled with calculated values. For each element (E1, E2…) of the source model A, it has a maximum "Ele_SSV" value with a specific target model element (e1, e2…); if this value exceeds a predefined threshold value (e.g. 0.5), a match is built between the two elements. Moreover, making matching between two elements requires building mappings among their properties; table 2 provides necessary and sufficient information to build mappings on property level. The rule of choosing property matching pairs is same of choosing element matching pairs (set another threshold value). In this way, both on element and property levels, the matches are: "one to one" and "many to one". At this moment, the impact factors and selecting threshold values are assigned directly by experience.

Hybrid Matching

After first matching step, some of the elements (both belonging to source and target meta-models) are still unmatched; even the matched elements, some of their properties are still unmatched. The hybrid matching step focuses on these unmatched items. This matching step works on property level, all the matching pairs would be built among properties (come from both the unmatched and matched elements).

All the unmatched properties from source model will be compared with all the properties from target model. A comparison matrix (similar to table 2) is created to help complete this step. The mechanism of building such matching pairs is also depending on semantic and syntactic checking measurements (based on properties' names and types).

In hybrid matching step, all the matching pairs are built on property's level. This step breaks the constraint: property matching pairs only exists within matched element's pairs; this constraint is the main granularity issue involved in model transformation process. However, it is also necessary to consider about the influence from element's level when building mappings in hybrid matching step. The matching mechanism of this step shows in [START_REF] Nancy | What does interoperability mean, anyway? Toward an Operational Definition of Interoperability[END_REF].

HM_P_SSV = el_weight*S_SSV + pl_weight*P_SSV (3)
In (3), "HM_P_SSV" stands for "hybrid matching property semantic and syntactic value". "el_weight" and "pl_weight" are two impact factors for the parameters "element level" and "property level", respectively. The sum of "el_weight" and "pl_weight" is 1. "S_SSV" is calculated between two elements' names (for source property and target property, respectively). "P_SSV", as stated in (2), calculates the syntactic and semantic relation between two properties based on their names and types.

This step achieves "one to many" matching mechanism on element's level, and on property level matching breaks the matched elements' constraint: properties from one source element could be matched to properties that from several target elements.

Auxiliary Matching After the first and second matching steps, all the shared parts (presented in the theoretical main framework) between source model and target model are regarded to be found. However, according to the iterative model transformation process mentioned at the beginning of this subsection, there are still some specific parts that should be stored as capitalized knowledge or enriched as additional knowledge. Auxiliary matching step focuses on the mechanism of storing and reusing these specific parts from both source and target models.

All the unmatched items from source model, which regarded as specific parts, are stored in ontology (which is called "AMTM_O" within this project). AMTM_O designed with the same structure as MMM that shown as Fig. 5.

The syntactic and semantic checking measurements that involved in these three matching steps will be explained in detail respectively in the following section.

Syntactic and Semantic Checking Measurements

GMTM requires defining automatically the model transformation mapping rules. So, semantic and syntactic checking measurements (executed by software tool) are involved. As shown in (4), the "S_SSV" stands for the semantic and syntactic value between two strings. S_SSV = sem_weight*S_SeV + syn_weight*S_SyV (

"Sem_weight" and "syn_weight" are two impact factors for the parameters semantic value and syntactic value; the sum of them is 1. The two following subsections illustrate the way to calculate "S_SeV" and "S_SyV", respectively.

Syntactic Checking Measurement

Syntactic checking measurement is used to calculate the syntactic similarity between two words (elements' and properties' names in our case). There exists several syntactic checking methods; majority of them use classic similarity metrics to calculate the syntactic relations. Some of examples could be referred in [START_REF] William | A Comparison of String Metrics for Matching Names and Records[END_REF].

The syntactic checking measurement in GMTM could be divided into two phases:

1. Pretreatment: focuses on finding if two words that in different forms (e.g. tense, morphology, gender) stand for the same word. 2. "Levenshtein Distances" algorithm [START_REF] Wilbert | Measuring Dialect Pronunciation Differences using Levenshtein Distance[END_REF]: calculates the syntactic similarity between two words. "Levenshtein distances" is equal to the number of operations needed to transform one string to another. There are three kinds of operations: insertions, deletions and substitutions. Formula (5) shows the calculation of syntactic relation between two words: word1 and word2 based on "Levenshtein distances". S_SyV = 1 -LD / Max (word1.length, word2.length)

In [START_REF] Schmidt | Model-Driven Engineering[END_REF], "S_SyV" stands for the syntactic similarity value between "word1" and "word2"; "LD" stands for the "Levenshtein distances" between them. The value of "S_SyV" is between 0 and 1; the higher of this value means the higher syntactic similarity.

Semantic Checking Measurement

Contrast to syntactic checking measurement (rely just on comparing the two words); semantic checking measurement should rely upon a huge semantic thesaurus which contains large amount of words, their semantic meanings and semantic relations among them. A specific semantic thesaurus has been created for GMTM, and it is based on the basis of "WordNet" [START_REF] Huang | An OWL-based WordNet lexical ontology[END_REF]. Fig. 8 shows the structure of this semantic thesaurus.  Word base: normal English words (nouns, verbs and adjectives) are stored here.  Sense base: contains all the word senses; a word could have "one or several" senses. E.g., word "star": it has six senses (four as a noun and two as a verb).  "Synset" base: synonym groups; the word senses are divided into different synonyms groups. Semantic relations are built among different synsets.

Table 3 shows the content stored in this semantic thesaurus and the numbers of each kind of items. There are five kinds of semantic relations defined among synsets: "synonym", "hypernym", "iterative hypernym", "similar-to" and "antonym". For each of the semantic relations, a specific value (between 0 and 1) is assigned to it. Table 4 shows these "value and semantic relation" pairs. 2), ( 3) and ( 4) can work for GMTM.

Conclusion

In this paper, a general model transformation methodology (GMTM) is presented. This methodology aims at dealing with the data sharing problem of enterprise interoperability. As the inner requirement of interoperability: flexibility, faster exchange information, this general methodology should surmount the traditional model transformation practices' weaknesses (limited to specific domains). Some points, which need to be improved in the future, are listed below:

 The impact factors such as: "sem_weight" and "pn_weight" and threshold values: the better way of assigning them is by using some mathematic strategy ("choquet" integral?).  Semantic checking measurement: only formal English words are stored in the semantic thesaurus with semantic meanings; not for words (in specific cases).  The S_SeV values that defined in table 4: more test cases are needed to modify these values into reasonable scope.

The usage of GMTM is not limited to the interoperability domain; GMTM allows MDE theories to serve other engineering domains too. 9 shows the general contribution of GMTM: converting rough data to information. With rules that defined in specific domains, such information could be transformed to knowledge which serves to domain specific problems.

Fig. 4 .

 4 Fig. 4. Theoretical main framework Fig. 4 illustrates the theoretical basis of GMTM. The significance of doing model transformation could be "sharing knowledge", "exchanging information", etc. The purpose of model transformation practice is: generate the target model based on the source model.

Fig. 8 .

 8 Fig. 8. Structure of the semantic thesaurus Fig. 8 shows three kinds of elements stored in the semantic thesaurus.

Fig. 9 .

 9 Fig. 9. Position of GMTM usage

Table 1 .

 1 Element level selected matrix

	A	B	e1	e2	……	en
	E1		Ele_SSV	Ele_SSV	……	Ele_SSV
	E2		Ele_SSV	Ele_SSV	……	Ele_SSV
	……		Ele_SSV	Ele_SSV	……	Ele_SSV
	Em		Ele_SSV	Ele_SSV	……	Ele_SSV

Table 2 .

 2 Property level selected matrix

	E1	e1	p1	p2	……	py
	P1		P_SSV	P_SSV	……	P_SSV
	P2		P_SSV	P_SSV	……	P_SSV
	……		P_SSV	P_SSV	……	P_SSV
	Px		P_SSV	P_SSV	……	P_SSV

Table 3 .

 3 Content in semantic thesaurus

	Items	Number
	words	147306
	word senses	206941
	synsets	114038

Table 4 .

 4 Relations and values pairsIn table 4, all the "S_SeV" values are assigned directly (by experience); these values should be assigned with more reasonable methods.With the huge content stored in the semantic thesaurus (shown in table 3 and table 4), formula (1), (

	Semantic relation	S_SeV	Remark
	synonym	0.9	words from the same synset
	hypernym	0.8	two synsets have this relation
	similar-to	0.85	only between two adjectives
	antonym	0.2	words have opposite meanings
	iterative hypernym	0.8	n	inheritance hypernym relation

By combining semantic and syntactic checking measurements into model transformation process, an efficient general model transformation methodology is created. With the improvement on some of the details that involved in this GMTM, this methodology may serve to a large number of domains.


Stéphane Billaud

Nicolas Daclin

Vincent Chapurlat

Interoperability as a key concept for the control and evolution of the System of Systems (SoS)

Keywords: Interoperability, System of Systems (SoS), System of Systems Engineering (SoSE), Performance, Stability, Integrity, Adaptability

A coalition of enterprises wanting to collaborate, and more generally a Collaborative Network of Organizations (CNO), can conceptually be assimilated as a System of Systems (SoS) presenting a number of characteristics to respect all over its life cycle. Interoperability is one of these characteristics (both functional and non-functional), which is from our point of view, essential in order to guarantee the control of the SoS, its behavior and the fulfillment of its mission(s). Moreover, it ensures the reaction of the SoS to deal with some risky situations and with potential local or global deficits during its functioning. In this paper, we propose to determine the relation between the current level of interoperability of the SoS and its functioning whatever may be its situation. A matrix shows how this relation evolves taking into account several characteristics of the SoS, particularly its capacity to respect interoperability requirements (Compatibility, Interoperation, Autonomy and Reversibility) and the so-called analysis perspectives of the SoS: Performance, Integrity and Stability. This relation is requested in order to permit and to guide SoS behavioral simulation currently in development. Thus, a set of indicators is derived and formalized.

Introduction

The following definition seems to adequately encapsulate the multiple definitions that have been given to the concept of System of Systems and will be useful for the remainder of this paper. A System of Systems (SoS) is a set of heterogeneous and existing subsystems assembled together to achieve a global mission that a system alone cannot fulfil, while maintaining the operational and managerial independency (autonomy) of each of the subsystems. These subsystems have then to be able to communicate and to work harmoniously together or to adapt their behavior and functioning locally when facing any evolution of the environment of the SoS [START_REF] Boardman | System of Systems -the meaning of of[END_REF], [START_REF] Jamshidi | System of systems engineering: innovations for the twenty-first century[END_REF], [START_REF] Maier | Architecting principles for systems-of-systems[END_REF], [START_REF] Ackoff | Towards a System of Systems Concepts[END_REF], [START_REF] Carney | Topics in Interoperability : System-of-Systems Evolution[END_REF]. It is admitted that the SoS Engineering (SoSE) activities carefully focus on choosing and assembling these subsystems as well as designing appropriate interfaces to facilitate this assembling [START_REF] Bilal | Collaborative Networked Organizations as System of Systems: a model-based engineering approach[END_REF]. Subsystems are selected and involved according to their potential roles, available resources, competences and know-how that can be shared in order to fulfil the SoS mission. Particular attention is given to some constraints that have to be also considered especially the capacity of subsystems of being interoperable. Indeed, for instance DoDAF [START_REF]Departement of Defense: DoD Architecture Framework Volume I : Definitions and Guidelines[END_REF] and System Engineering [START_REF] Adcock | The Guide to the Systems Engineering Body of Knowledge (SEBoK)[END_REF], [START_REF]International Council on Systems Engineering (INCOSE[END_REF] claim that interoperability is required to coordinate and make efficient such large multi-disciplinary and heterogeneous coalition of subsystems. Therefore, interoperability has to be fully considered when the chosen subsystems are assembled for a more or less short period during which they will have to work together, share flows, data and resources in order to build their SoS.

Moreover, a strong linkage exists between the interoperability and the so-called analysis perspectives namely Stability, Integrity and Performance [START_REF] Bilal | Collaborative Networked Organizations as System of Systems: a model-based engineering approach[END_REF]. Therefore, and to address this challenge, the original aim of this paper is to investigate the impact of the interoperability on the so-called analysis perspectives by proposing an impact matrix and by defining a set of indicators that characterizes and helps to understand this impact. With respect to the state-of-the-art and to the best of our knowledge, the requested interoperability of heterogeneous subsystems has not been yet handled before and this paper characterizes the novelty of the approach. It is evidently a new challenging area and there are research directions towards discovering it [START_REF] Camarinha-Matos | Collaborative networks: A mechanism for enterprise agility and resilience[END_REF].

This paper focuses first on the reasons behind considering the interoperability as a crucial characteristic of the SoS in order to control it and to help it achieving its mission throughout its evolution and in various situations that might take risky aspects. Afterwards, we define a set of requirements that allow us characterizing the requested subsystems' interoperability. Moreover, relationship between subsystems' interoperability and SoS' analysis perspectives is presented. The first result is a matrix aiming to assist the engineers, designers and managers involved in SoSE process in choosing their subsystems prior the assembling and understanding the impact of the interoperability over the SoS analysis perspectives all over its life cycle. This will be done by evaluating this impact through a simulation technique not described here. Therefore, a set of indicators is defined in order to concretize the existing relationship between the interoperability and the SoS analysis perspectives. These indicators are not exhaustive but in our point of view, the selected ones are complete and enough to allow the evaluation of the impact of interoperability on the SoS analysis perspectives.

Interoperability

Interoperability vs. SoS characteristics

Interoperability is defined recurrently in the literature in a way to provide a better understanding of its various aspects and levels [START_REF] Ford | A Survey on Interoperability Measurement[END_REF]. Thus, our attention is directed to define interoperability as the ability of connected, autonomous, "loosely coupled" and possibly heterogeneous systems to coexist, to interoperate and to exchange flows (data and services, material or energy) to/from other systems while continuing their own logic of operation preserving their autonomy.

In essence, this definition reveals various characteristics, which are consistent with the SoS expected characteristics. The autonomy of a subsystem i.e. the possibility to continue to act and make decisions, in order to ensure its own mission independently of other subsystems, is consistent with the expected managerial independency of the subsystems. The reversibility of a relation between two subsystems that allows a subsystem to achieve its mission, after breaking an alliance with other subsystems composing the same SoS, is coherent with the requested operational independency of the subsystems. The subsystems are seen as "loosely coupled". On the one hand, this kind of coupling enhances the connectivity which characterizes a SoS, where subsystems are capable of building links among their interfaces and destroying them dynamically [START_REF]Report On System Of Systems Engineering[END_REF] and on the other hand, it enhances the evolutionary development of the SoS [START_REF] Maier | Architecting principles for systems-of-systems[END_REF] when it becomes possible to easily remove, modify or add subsystems from the SoS. The heterogeneity of the subsystems is essential for the SoS since it can only achieve its global mission by leveraging the diversity of its subsystems [START_REF]Report On System Of Systems Engineering[END_REF].

Thus, maintaining a sufficient level of interoperability of each subsystem helps the preservation of these SoS characteristics (constituent subsystems autonomy, enriched connectivity and commitment to diversity of subsystems) and the SoS behavior.

Last, SoS passes through various stages in its life cycle (See Figure 1) during which these characteristics may evolve but have to be maintained in an acceptable range.

Interoperability vs. SoS analysis perspectives

Beyond the classical System Engineering approach, System of Systems Engineering (SoSE) puts emphasis on the selection of relevant subsystems taking into consideration the necessity of staying interoperable in order to participate efficiently in the global mission of the SoS.

In this way, it is required to formalize the design of a SoS by taking into consideration the relationships between subsystems' interoperability and some functional characteristics as non-functional of a SoS. We focus here on the impact of subsystems interoperability on non-functional characteristics namely analysis perspectives (Stability, Integrity and Performance) as demonstrated hereafter.

Stability reflects the ability of a SoS to maintain its viability and to adapt (e.g. its structure or its behavior i.e. this requests generally adaptation of concerned subsystems) to any change in its environment [START_REF] Bilal | Collaborative Networked Organizations as System of Systems: a model-based engineering approach[END_REF], [START_REF] Pénalva | SAGACE: La modélisation des systèmes dont la maîtrise est complexe[END_REF]. It characterizes the cohesive relationship that should exist between the system structure and its activities or programs which define what the system should do. The stability level of the SoS must evolve when subsystems have to deal with some risky and/or unexpected situations whether they are due to internal or external events. Stability has six basic concepts which are generic for any SoS: Constancy, Resilience, Persistence, Resistance, Elasticity, and Domain of attraction [START_REF] Grimm | Babel, or the ecological stability discussions: an inventory and analysis of terminology and a guide for avoiding confusion[END_REF]. Currently, none of the existing approaches (known as architectural styles of self-adaptation) enables a SoS to reason about itself and adapt to achieve particular stability, performance or quality objectives in the face of uncertainties and changes. The only existing architectural style of self-adaptation handles the stability from a local point of view of the subsystems without taking into consideration the subsystems interoperability that can impact positively or negatively the stability [START_REF] Weyns | On the challenges of self-adaptation in systems of systems[END_REF].

Integrity reflects the ability of a SoS to return to a known functioning and operating mode in case of any local change in its existing configuration (e.g. loss of one or more resources, or non-expected or even emergent situation due to subsystems interactions). When one or more subsystems of the SoS leaves the SoS, these subsystems have to continue to maintain their own operations and the remaining group of subsystems should continue to operate in the new context of the SoS.

Performance reflects the SoS ability to achieve its mission by reaching its objectives in terms e.g. of costs, duration, quality of service etc. It characterizes the relationship between the functions that have to be executed by the system and the compliance of the services provided by the resources for example, through indicators of time, quality and costs that reflect the efficiency, effectiveness and the relevance of the involved set of resources [START_REF] Bonnefous | Indicateurs de performance[END_REF]. The goal is not to guarantee a maximum level of performance, but to be able to return to a predefined level of performance after an external or internal change (addition, deletion, modification of a subsystem or an interaction etc.).

Evaluating the impact of interoperability on the analysis perspectives requests first to identify interoperability requirements and constraints allowing us to overcome the three classical barriers of interoperability detailed in [START_REF]Interop: Enterprise Interoperability-Framework and knowledge corpus -Final report[END_REF]: Conceptual, Technological and Organizational.

Improving both conceptual and technical interoperability is important to support organizational interoperability. These barriers take place in four areas of concerns of the SoS: flows (carrying out data, material or energy), services, processes and business. It is important to consider the three barriers to draw the interoperability requirements in order to allow proactive anomaly detection at the three levels (conceptual, technical and organizational).

The first basic interoperability requirement concerns the subsystems compatibility. The compatibility refers here to the interfaces imposed by the interactions between the subsystems. Interfaces can be technical, organizational, HMI or logical at high level of abstraction. Imposing standards interfaces or well-defined interfaces and common integration mechanisms are not always the solution in dynamic environment that can be considered as a SoS [START_REF] Kasunic | Measuring Systems Interoperability: Challenges and opportunities[END_REF], [START_REF] Panetto | Meta-modèles et modèles pour l'intégration et l'interopérabilité des applications d'entreprises de production[END_REF].

The second basic interoperability requirement concerns the subsystems' autonomy. A subsystem must effectively respects the expected objectives, stakeholders' requirements and constraints defined for the SoS (e.g. cost, delay, quality) but meanwhile, it should respect its own requirements.

During the operational phase of the SoS, subsystems' interoperation appears as another interoperability requirement. It concerns, the ability of a collection of subsystems to share or exchange specified information/energy/material in order to achieve a specified purpose/mission in a given context.

In the dissolution phase of the SoS, the inter subsystems' relations (reversibility) is an important interoperability requirement. For instance, once a set of subsystems break the alliance with each other, each subsystem must be able to return to a state in which it reaches at least its original level of performance while executing its usual operations and consequently it respects its own requirements.

Last, interoperability requirements vary from one SoS type to another. For instance Directed SoS is considered here whereas the SoS requires to have an authority and a management role over its group of subsystems while preserving their ability to operate independently.

Interoperability measurement

Interoperability has been studied in multiple fields [START_REF] Truptil | Collaborative process design for Mediation Information System Engineering[END_REF], [START_REF] Ruggaber | Athena-Advanced technologies for Interoperability of heterogeneous enterprise networks and their applications[END_REF] and various approaches have been proposed to measure and evaluate the interoperability level of a system whatever may be its nature and sometimes its complexity. These approaches are mainly based on maturity measurement. A recent survey presented fourteen interoperability models used to measure the interoperability [START_REF] Ford | A Survey on Interoperability Measurement[END_REF]: Spectrum of Interoperability Model (SoIM) [START_REF] Lavean | Interoperability in Defense Communications[END_REF], Quantification of Interoperability Methodology (QoIM) [START_REF] Mensh | A Methodology for Quantifying Interoperability[END_REF], Military Communications and Information Systems Interoperability (MCISI) [START_REF] Amanowicz | Military communications and information systems interoperability[END_REF], Levels of Information System Interoperability Model (LISI) [START_REF] Defense | of: C4ISR Architecture Working Group Final Report -Levels of Information System Interoperability (LISI). Washingt. DC OSD(ASD(C3I)) C[END_REF] (this model is similar to SoIM, it is suited and adapted for measuring information systems interoperability), Interoperability Assessment Methodology (IAM) [START_REF] Leite | Interoperability assessment[END_REF] (this model is similar to QoIM), Organizational Interoperability Maturity Model for C2 (OIM) [START_REF] Clark | Organisational interoperability maturity model for C2[END_REF](This model is an extension of the LISI model), Stoplight [START_REF] Hamilton | An Interoperability Road Map for C4ISR Legacy Systems[END_REF], Levels of Conceptual Interoperability Model (LCIM) [START_REF] Andreas | The levels of conceptual interoperability model[END_REF](this model is similar to LISI and OIM, however it is used in the conceptual design to prove if meaningful interoperability between the systems is possible), Layers of Coalition Interoperability (LCI) [START_REF] Tolk | Beyond technical interoperability-introducing a reference model for measures of merit for coalition interoperability[END_REF], NATO C3 Technical Architecture Reference Model for Interoperability (NMI) [START_REF] Nato | NATO C3 Technical Architecture[END_REF], System-of-Systems Interoperability Model (SoSI) [START_REF] Morris | System of Systems Interoperability (SOSI): final report[END_REF] (SoSI was proposed to support the Software Engineeringùùù* Institutes SoS interoperability research. However, it does not contain specific metrics to quantify interoperability within a SoS), Non-Technical Interoperability Framework (NTI) [START_REF] Stewart | Non-technical interoperability in multinational forces[END_REF] (this model is based on the OIM organizational model), Organizational Interoperability Agility Model (OIAM) [START_REF] Kingston | An organisational interoperability agility model[END_REF] (it builds upon the OIM organizational model), The Layered Interoperability Score (i-Score) [START_REF] Ford | The Interoperability Score[END_REF] (This model is a mathematical method made in order to measure the interoperability of all types of systems for a very specific operational scenario/thread).

After presenting the approaches mentioned previously, we realize that all of them focus on a specific application domain (the interoperability of information systems) and only few approaches integrate the organizational aspects of interoperability. Moreover, none of these interoperability measurement approaches has been presented or tested in large systems or organizations like the SoS and [START_REF] Ford | A Survey on Interoperability Measurement[END_REF] did not present any evidence of that. Therefore, the approach presented in the next section, offers an evaluation matrix that allows measuring the interoperability impacts, in a large and complex context (SoS), on the SoS analysis perspectives.

Interoperability impact matrix

The impact matrix aims to present a new approach of the interoperability-impact analysis which combines the interoperability sub requirements and their impact on the SoS analysis perspectives. Therefore, it is divided into two main axes: (I) the interoperability (Compatibility, Interoperation, Autonomy and Reversibility) and (II) the SoS analysis perspectives (Performance and Adaptability). The integrity and stability of the SoS are combined into one characteristic that we call: the SoS' adaptability. It is the ability of a SoS to adapt to any new situation or change and to return to a known operating or functioning mode whatever the changes result from internal (integrity) or external (stability) causes. It will be evaluated based on its six concepts: Constancy, Resilience, Persistence, Resistance, Elasticity, and Domain of attraction mentioned in Section 2.2.

Mainly, two subsystems inside a SoS are at a high level of interoperability if and only if they are at a high level of Compatibility, Interoperation, Autonomy and Reversibility.

Compatibility, Compatibility means to harmonize subsystems in order to be ready to collaborate. Compatibility focuses on a static point of view of the collaboration and remains insufficient to determine if the subsystems are interoperable during the SoS life cycle. It is necessary to consider the evolution of the context and of the situation of each subsystem. A set of indicators is required to analyze the impact of the compatibility between the subsystems on the performance of the SoS. They are divided into subgroups according to the kind of compatibility.

1. Organizational and conceptual compatibility indicators: syntax (the information to be exchanged is expressed with the same syntax?), preparedness (the data are well defined and documented?), Understanding (communication and shared information rate), Command style (are authorities/responsibilities are clearly defined?) and trust. In this case, compatibility impacts each perspective as follows: Compatibility  Performance: The compatibility between subsystems impacts the SoS performance. In the absence of compatibility of interfaces for example, it becomes impossible for interactions to take place, therefore the system will be unable to fulfill its mission(s) and by consequence unable to reach its performance's objectives. Furthermore, a low level of compatibility implies a limited interaction which will induce a lower performance.

On the one hand, an increase in the compatibility between the subsystems imposes sometimes constraints to respect. These constraints imply a decrease in the performance of the SoS. On the other hand, an increase in the compatibility might be useless if the subsystems reached already a sufficient level of compatibility to guarantee the predefined level of performance for the SoS. In this case, the performance will not vary with the increase of the compatibility.

A decrease in the compatibility between the subsystems prevents or limits the exchange of data/material/energy etc., this induces a decrease in the performance of the SoS. However, if the subsystems need a level of compatibility less than the actual one in order to perform perfectly, then a decrease of the compatibility will have no impact on the level of the predefined performance since their level of compatibility was higher than requested and they can absorb a decrease in the compatibility on condition that it remains sufficient to keep the necessary level to perform adequately.

Compatibility  Adaptability: An increase or decrease in the compatibility following an add, remove or modification of a subsystem or an interaction between the subsystems might induce a decrease in the performance of the SoS since the subsystems take a certain time to reach again an accepted level of compatibility necessary to get to the predefined level of performance. The level of performance might stay stable if the subsystems are able to adapt rapidly.

Interoperation, is the ability of a collection of communicating systems to share or exchange specified information/energy/material in order to achieve a specified purpose/mission in a given context. It is measured through a set of indicators which seem to be only adequate to a specific types of telecommunication SoS. However, these indicators can be applied to any kind of SoS since the flow between subsystems can be data, information, material or energy. Therefore, these indicators are not limited to the domain of telecommunication:

1. Time of interoperation: The time of interoperation corresponds to the duration between the date when information is requested and the date when the requested information is used 2. Quality of interoperation: The quality of interoperation takes in consideration three kinds of quality: (1) the quality of exchange (The quality of exchange draws up if the exchange is correctly performed), (2) the quality of use (The quality of use represents the number of information received by a partner in comparison with the number of information requested.) and, (3) the quality of conformity (The quality of conformity corresponds to the exploitation of the information)

3. Capacity: is the rate at which data may be passed over time 4. System overload: when more data must be exchanged than the system is able to transmit 5. Underutilization: when the system data rate/message load is less than its full capacity but messages are waiting in queues to be transmitted 6. Under capacity: when messages remain in queues and the system data rate is at the maximum 7. Data latency: is the elapsed time from the transmission to the reception Then, interoperation impacts each perspective as follows: Interoperation  Performance: The interoperation between the subsystems impacts the SoS performance. In the absence of the interoperation, the subsystems are no longer able to exchange data/material/energy etc. therefore the SoS cannot achieve its mission(s) neither its performance's objectives. Moreover, a subsystem with a very low capacity limits the interoperation with another subsystem with higher capacity; therefore the performance of the overall system (SoS) will be impacted.

An increase or decrease in the interoperation between the subsystems might have three different impacts on the performance of the SoS. It decreases the SoS performance if we exceed the capacity of the subsystems to absorb the high rates of interoperation. However, it increases the SoS performance if the subsystems are able to interoperate with the new imposed rates with higher performance.

Interoperation  Adaptability: An increase in the interoperation might induce an increase in the adaptability if and only if the subsystems are capable to operate with the new imposed rates, otherwise it implies a decrease in that adaptability and the SoS is not able to return to its predefined level of performance since the new interoperation indicators are not adequate to the new local or external changes. A decrease in the interoperation induces an increase in the SoS adaptability since the restrictions on the subsystems in terms of interoperation indicators are less significant.

The autonomy of the subsystems is the fact to be free to pursue its purpose. That freedom is limited by some constraints. However, those constraints cannot be allowed to overwhelm or violate its capacity or nature to perform. The autonomy is measured based on the classical performance indicators of each subsystem. Autonomy impacts the SoS analysis perspectives as follows:

Autonomy  Performance: Each subsystem of the SoS has its own mission(s) to fulfill independently from the overall mission of the SoS. However, if the autonomy of the subsystems increases, its participation in the SoS can be lower which implies a decrease in the SoS performance. Conversely, a decrease in the autonomy of a subsystem makes its participation in the SoS global mission less restrictive.

Autonomy  Adaptability: An increase in the subsystems' autonomy imposes more restrictions that prevent the new changes to be absorbed. Therefore, a decrease in the adaptability takes place. However, a decrease in the subsystems' autonomy implies more freedom to react to any changes and to return rapidly to the predefined level of performance, therefore an increase in the adaptability takes place.

Last, the reversibility means that a subsystem may maintain or retrieve easily its autonomy and performance (including positive and/or negative variations that are accepted) at the end of any collaboration. Reversibility has no impact on the analysis perspectives of the SoS, once a subsystem leaves the SoS, it continues its life cycle independently from the System of Systems. However, the requirements related to each subsystem have to be verified.

Table 1 shows how the variation in the interoperability requirements level (inducing then measurement of the respect of the requirement by suing one or several of the methods presented before) impacts the analysis perspectives of the SoS.

Table 1 Matrix of the subsystems interoperability's impact on the SoS analysis perspectives (S: Stable, I: Increase, D: Decrease).

Interoperability Analysis perspectives

Conclusions and perspectives

This paper illustrated the importance of the interoperability of the subsystems in the control and evolution of the System of Systems. After careful analysis, we realized that there exists a strong linkage between the interoperability and the SoS characteristics and between the interoperability and some other non-functional characteristics of the SoS (analysis perspectives). The significance of this paper lies in its ability awareness about the need to consider the interoperability prior the assembling of the subsystems. An impact matrix of the interoperability on the analysis perspectives has been proposed, it is a first crucial step towards an effective System of Systems Engineering. It permits the correct control and evolution of the SoS inside uncertain and unknowable environment in which it must operate.

The proposed matrix will serve to allow the evaluation of the impact of the interoperability on the analysis perspectives. This evaluation will be achieved through the simulation which is currently under development.

Figure 1

 1 Figure 1Life cycle of a SoS[START_REF] Bilal | Collaborative Networked Organizations as System of Systems: a model-based engineering approach[END_REF]


Matthieu Lauras
email: lauras@mines-albi.fr

Jacques Lamothe
email: lamothe@mines-albi.fr

Frederick Benaben
email: benaben@mines-albi.fr

Beatriz Andres
email: bandres@cigip.upv.es

Raul Poler
email: rpoler@cigip.upv.es

Towards an Agile and Collaborative Platform for Managing Supply Chain Uncertainties

Keywords: Supply Chain, Uncertainty, Collaborative Platform, Agility, Research Framework

Nowadays, one of the main challenges for Supply Chains is the management of disruptions and uncertainties. Turbulence and instability have now to be considered as the 'normal' situation. Future Supply Chains should be able to cope with this new context to stay competitive. To solve this issue, new approaches and technologies have to be designed in order to improve the agility capability of supply networks. To contribute to this new problem statement, as a part of the H2020 C2NET research project, this paper proposes a concrete research framework. The research aim consists in defining precise research orientations in one hand, and structuring a set of technical tasks able to result in an agile and collaborative platform on the other hand. Basically, the main components of the research framework are presented and the expected impacts are discussed.

Introduction

Modern Supply Chains are continuously challenged by unexpected disruptive events that are increasing in their frequency and effects: supply failures, demand changes, internal disruptions, etc. In this context, turbulence and instability can be no longer considered as an episodic crisis, rather the "norm" or the default status. The question is then to know how the Supply Chains can strive and gain in such disruptive environments and which supportive roles can the technology play. Current IT and decision-making systems are designed to run in more or less 'stable" environment. Disturbances are captured by exception handling mechanisms. Thus, calling for a new perspective in Supply Chains design and engineering. While current Supply Chains are tempting to be robust, tomorrow's Supply Chains need to become agile.

The current research work proposes to develop some innovative solutions to bridge this gap. This research project is a sub-part of the C2NET H2020 project (2015 -2018) that covets leveraging the potential of Cloud technologies providing a manufacturing infrastructure for a real-time knowledge of different supply chain components such as manufacturing assets status, inventory levels or current demand at consumption points. By providing specific tools for optimization and collaboration in the cloud, companies involved in a Supply Chain will be able to increase their agility to respond quickly, flexibly and efficiently to changes in demand and unexpected events that have place during products supply. C2NET is providing a technological infrastructure that will enable a continuous data collection in real time from manufacturing processes that take place within a plant including logistics operations intra-plants, as well as from products, which are being processing along the whole supply chain. C2NET will facilitate its adaptation to actual manufacturing chains allowing data collection from a wide range of different information sources such as legacy systems (Enterprise Resources Planning, Manufacturing Execution Systems, Business Intelligence...), industrial control systems or directly from devices with different levels of intelligence built into machines and products such as smart sensors, embedded systems or Radio Frequency Identification. Collaboration throughout the Supply Chain using cloud-based tools and solutions is the main concept on which C2NET platform is based. This cloud platform is articulated around three main components as described in Figure 1: -The C2NET Data Collection Framework (DCF) that collects in real-time information from processes and products within the supply chain; -The C2NET Optimizer (OPT) that allows providing production plans and decisions to all concerned supply chain partners; -The C2NET Collaboration Tools (COT) that proposes a set of services able to facilitate the achievement of agreements and drastically reduce response time and cost of decision-making processes.

In this paper we focus only on the collaboration tools (C2NET-COT). The problem statement of this set of tools is to develop a new approach for facilitating collaborative demand, production and delivery plans along the supply network. Basically, the technical ambition is to design a modular architecture for interoperability of intra plant and extra plant processes in conjunction with mobile, collaborative tools for data sharing, data analytics and knowledge-based systems, at factory and at supply network level.

The paper is split up into three main sections. First a literature selection will propose to underline the concepts of "Agile Supply Chains" and "Collaborative networks". On this basis, we will propose in a second part a research framework able to structure the future developments on this subject. Then, a third part will discuss the main impacts that should be obtained at the end of this research project.

Literature Selection

Many companies have not fully recognized the nature of systemic supply chain risk and have continued to focus on seeking efficiency improvements [START_REF] Christopher | Building the Resilient Supply Chain[END_REF]). These authors argue that a new priority consist in searching for supply chain strategies that embody a significantly higher degree of resilience. Resilience implies flexibility and agility. Its implications extend beyond process redesign to fundamental decisions on sourcing and the establishment of more collaborative supply chain relationships based on far greater transparency of information (Christopher and Peck, 2004).

Agile Supply Chains

According to [START_REF] Lee | The triple-A supply chain[END_REF], an agile supply chain is a set of partners responding quickly to short-term changes in demand (or supply) and handling external disruptions smoothly. Sometimes agility can be mistaken for other similar but different concepts such as adaptability, resilience and virtuality. Researchers also had interest on the capabilities that are required to access agility. -Delayed choice: the process is partially defined during the design time and finalized at the execution. In this approach, the implementation of some subprocesses is chosen within a predefined list at the moment of the process execution. This approach is implemented in the YAWL system [START_REF] Adams | Proceedings of the 17th Conference on Advanced Information Systems Engineering Forum (CAiSE05 Forum)[END_REF]). -Delayed design: the process is partially defined, but some sub-processes are not identified during the design. This approach suggests to come back to a specific design time when required during the execution. -Risks management: various alternative paths are identified during the design time in order to adapt to risks, threats or opportunities. One path is finally chosen during each execution of the process. With this approach the number of paths to be identified can be too important in practice.

-AdHoc design: this approach extends the concept of delayed design. The sequence of activities can be changed, some tasks can be added or cancelled or repeated. It is the more common approach [START_REF] Adams | Proceedings of the 17th Conference on Advanced Information Systems Engineering Forum (CAiSE05 Forum)[END_REF].

The C2NET Collaborative Platform will propose a concrete support able to manage the agility of the collaborative situation, especially in manufacturing network environment. The main contribution of the C2NET Project regarding extent literature on this point consists in making agile Supply Chains concrete. Specific objectives will include the design and the implementation of an integrated system able to supervise, detect, adapt and assess the collaborative situation.

Collaborative Networks

The way how manufacturing and service industries manage their businesses is changing due to the emerging new competitive environments. According to (Camarinha-Matos and Afsarmanesh, 2005) the enterprises' success in the new dynamic environments is associated to the improved competencies in terms of new business models, strategies, governance principles, processes and technological capabilities of manufacturing enterprises of 2020. Moreover, especially for SMEs, the participation in collaborative networks is also a key issue for any enterprise that is willing to achieve differentiated and competitive strengths. Consequently, establishing collaborative relationships becomes an important issue to deal with customer needs, through sharing competencies and resources. Collaborative Networks consist of a variety of heterogeneous autonomous entities, geographically distributed, in which participants collaborate to achieve a common goal and base their interactions through computer networks. SMEs are characterized by limited capabilities and resources; therefore, in order to overcome possible barriers that can appear when establishing collaboration, joint efforts must be performed to achieve the desired collaborative scenarios. When establishing collaboration, networked partners share information, resources and responsibilities to jointly plan, implement, and evaluate a program of activities to reach a common goal and therefore jointly generate value. Thus, establish collaborative relationships imply sharing risks, resources, responsibilities, losses, rewards and trust. Collaborative networks manifest in a large variety of forms, such as virtual organizations, virtual enterprises, dynamic supply chains, professional virtual communities, collaborative virtual laboratories (Camarinha-Matos and Afsarmanesh, 2005) and collaborative non-hierarchical networks [START_REF] Poler | Intelligent Non-hierarchical Manufacturing Networks[END_REF]. The main challenges for creating collaborative networks are presented in VOmap and are divided into five focus areas (i) socio economic, (ii) VO management, (iii) ITC support services, (iv) ICT Infrastructures and (v) formal models and theories.

Based on this background, the C2NET project will focus on the research and technical development to overcome possible barriers encountered when enterprises participate in collaborative networks characterized by distributed partners with decentralized information. The C2NET project will allow exploiting enterprises' capabilities and resources to efficiently succeed on the participation in collaborative networks. Specific objectives will include the design of cloud computing ICT, due to the advantages encountered for manufacturing and service industry networks, and the development of an integrated framework, consisting of models, methodologies and tools, to support enterprises in dealing with decentralized decision making within collaborative networks.

Research Framework

Our research project aims at providing a Collaborative Manufacturing Network Platform with a set of tools in charge of managing the agility of the collaborative situation. These tools are specifically in charge of exploiting the gathered data in order to formalize a clear vision of the collaborative situation and to propose dynamic adjustments. The following specific objectives are targeted in this research framework:

-Supervision: Define and implement the exploitation mechanisms to use collected data (from IoT, from monitoring or any other means) in order to maintain models of the collaborative situation. -Detection: Define and implement the exploitation mechanisms of the situation models in order to diagnose any source of divergence of the collaboration with regard to the expected situation. -Adaptation: Define and implement the reaction mechanisms to deduce from the analysis of the situation models, the appropriate adjustments to propose to the running collaborative situation. -Assessment: Define, deploy, measure and exploit Key Performance Indicators (KPI) to ensure the relevant evaluation of the consequences of the adaptation actions

This part of the research work will improve the C2NET platform by providing it with five components dedicated to meet the four objectives previously described. These five components will be: (i) a knowledge base dedicated to store the collected data as exploitable models, (ii) a first service in charge of interpreting the collected data or reference KPI to feed the knowledge base, (iii) a second service in charge of watching the knowledge base in order to detect any divergence requiring adaptation measures, (iv) a third service in charge of exploiting the knowledge base and the detection reports to deduce and define the relevant adaptation actions, and (v) a fourth service in charge of continuous assessment of the agility actions in order to evaluate the taken measures and to provide a second order of agility by allowing thus the potential improvement of the three other services. Consequently, our research framework is structured according to these five elements (a knowledge base and four services). The Figure 2 describes this research framework.

Fig. 2. Research framework proposal.

Hereafter, we give some requirements regarding tasks that have to be done to develop the previously discussed elements.

The Knowledge Base

Based on both a state-of-the-art on collaborative knowledge bases (domain ontologies vs. collaborative situation ontologies) and the reference models, this first design aims at defining and implementing an exploitable knowledge base about collaborative situations. This knowledge base should be compliant with any collaborative situation concerned by the C2NET project in terms of concerned business domain and concerned collaborative structure. The obtain knowledge base should be open and usable by the four agility services.

The Modeling Service

This second design aims at defining and implementing the first agility service. This task should define the translation mechanisms that could allow to update the knowledge base according to the continuously gathered data. This task includes a strong work on data format interpretation (syntactic view) and also on data content interpretation (semantic view).

The Detection Service

This third design aims at defining and implementing the second agility service. This service is responsible for the detection of irregular situations based on the captured data. Actually, once the knowledge base implemented is populated with relevant data gathered thanks to the data acquisition framework, the detection mechanism can be triggered. Furthermore, the detection mechanism can take benefit from semantically described assets and processes in order to reveal something is going wrong with the occurring process.

Considering an enacted business process, the ability of surveying the different participants collaborating to achieve it becomes complex as these are probably belonging to different entities and abide by different rules. The adoption of the ESB technology as an interoperable framework for data collection augments the ability of applying a monitoring and detection mechanisms that will ensure such a functionality. More precisely, we will implement an event-based architecture that will subscribe to the exchanges data and that will trigger events expressing the nature of the exchange (time, sender, receiver, etc.). Once compared with the required pattern we will be able to detect if the data is relevant with regard to the required one. When the detection mechanism is not triggered by a produced event, it parses the gathered data recent and historical that is stored in the knowledge base looking for possible mismatching to start corrective procedures. Event expressing errors and specific issues are forwarded to the adaptation and assessment services.

The Adaptation Service

This fourth design aims at defining and implementing the third agility service. This service should use the analysis of the detection service, as well as the full knowledge base to deduce and suggest adaptation measures that could fit with the current situation and prevent its actual divergence.

The Assessment Service

This fifth design aims at defining and implementing the fourth agility service. This service is in charge of agility assessment (to bring agility to the agility tools). This task should define relevant KPI and also the way to improve or change the rules and mechanisms of detection and adaptation services.

Expected Impacts

By implementing the research framework previously described, this research work should be able to propose a concrete solution to support the collaborative value chain by facilitating the diagnosis of any source of divergence of the collaboration with regard to expected situation. Moreover the project will be able to support the adaptation of the stakeholders' behaviors by implementing reaction mechanisms based on global and local optimization algorithms. The research work will facilitate the coordination between stakeholders by connecting them efficiently. Particularly, this will eliminate superfluous, inaccurate or irrelevant information regarding the monitoring of the current situation. It will also automate some analysis or actions based on pre-defined business rules in order to support local or global decisions. The results of the C2NET project will mainly apply to both large enterprises and SMEs in Industry and Non-financial services. Practically, such a contribution should allow increasing drastically the competitiveness of Supply Chains by improving: Consumers' On Time Delivery, Total Lead-Time, Time-to-Market, Inventories, Carbon footprint, Profitability ratio, Efficiency ratio…

Fig. 1 .

 1 Fig. 1. Overview of the C2NET Project (platform and use cases).

  [START_REF] Charles | A model to define and assess the agility of supply chains: building on humanitarian experience[END_REF] justifies that agility requires the combination of:-Effectiveness: ability to satisfy the customer demand; -Completeness: ability to satisfy totally the customer demand; -Reliability: ability to respect the customer delivery lead time;

-Responsiveness: ability to respond quickly which requires to: (i) detect quickly changes [Visibility], (ii) decide quickly on the adaptation to make using flexibility [Reactivity], and (iii) implement quickly the decisions [Velocity]. Another definition has been proposed by (Benaben, 2012): Agility = (Detection + Adaptation) x (Effectiveness + Responsiveness) In the following we will keep this definition. Recently various initiatives have appeared for analyzing and supporting the deployment of agility in supply chain. Such initiatives are SOA and WebService based (Ahn et al., 2012; Ameri and Patil, 2012; Zhang et al., 2012). Accorsi, (2011) describes notably a specific SaaS, the Business Process as a Service (BPaaS). Ahn et al., (

2012

) discuss moreover the slow adoption of XML standards such as ebXML and RosettaNet in agile supply chains and identifies three pitfalls: (i) these standards are presently not adapted to agile supply chains which constrained by high market volatility and short customer lead times; (ii) lack of stringent, vendor-independent business process standards that create a barrier to achieving the high level alignment and flexibility; (iii) technologies for the management of online relationships are hardly accessible to SMEs because of a wide variety of partnering options that might be required, a large number of trading partners, product diversity, and strategic diversity.

[START_REF] Benaben | Conception de systèmes d'information de médiation pour la prise en charge de l'interopérabilité dans les collaborations d'organisations[END_REF]

proposes a framework for differentiating the various strategies of workflow agility:

Acknowledgement

The research leading to these results has received funding from European Community's H2020 Programme (H2020/2014-2020) under grant agreement n°636909, "Cloud Collaborative Manufacturing Networks (C2NET)".