Vincent Chapurlat
email: vincent.chapurlat@mines-ales.fr

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

System of Systems Architecting: A Behavioural and Properties based Approach for SoS "-ilities" Modelling and Analysis

Keywords: System of Systems, "-ilities", Non-functional Properties, Resilience, SoS behavioural modelling, Dependencies, Formalisation

Architecting a System of Systems (SoS) is a complex task. Capabilities of heterogeneous and interactive sub-systems are composed to fulfil a mission, while preserving, as possible, the autonomy, independence, geographic distribution… of sub-systems and to face up efficiently while remaining as resilient as possible to disturbances and emergent phenomenon. The "-ilities" are relevant non-functional abilities (e.g. robustness, resilience, flexibility, adaptability, survivability, interoperability…) for guiding SoS architects and managers to choose and interface sub-systems. The goal is to become able to increase or decrease the value of these "-ilities" thanks to their interest for the SoS mission. The here presented work aims to support resilient SoS design and, in particular, their architecting by proposing a formalised model of property allowing to define and describe an "-ility" and a behavioural modelling approach to evaluate it.

Introduction

A System of Systems (SoS) is composed of (in most cases, existing) heterogeneous sub systems chosen for their capabilities, assembled and interfaced to interact during a time-frame and to provide capabilities to achieve a mission that each sub system cannot fulfil alone [START_REF] Maier | Architecting principles for systems-of-systems[END_REF]. First, some characteristics of sub systems must be preserved: operational and managerial independence, evolutionary development, geographic distribution, and connectivity. Second, requested interactions induce emergent phenomenon (new properties and behaviours with more or less predictable and unwanted effects) at the SoS level that can favour or affect the achievement of its objectives and mission. Third, it is now recognized, for SoS, the relevance of specific properties called "-ilities". An "-ility" 1 is an "ability to respond to changes, both foreseeable and unforeseeable" focusing on "how the SoS should be and not what it should do" [2]. For a SoS, "-ilities" differ from authors, but essentials ones remain: robustness, resilience, flexibility, adaptability, survivability, interoperability, sustainability, reliability, availability, maintainability and safety; each "-ility" can be strongly dependant or influenced by various causes considering SoS context, evolution period of its life cycle and emerging phenomenon. So, architecting a SoS implies to study these "-ilities" and how to increase or decrease their values thanks to their interest for the SoS purpose. Particularly, SoS has to face up, efficiently and accordingly to its mission, to various dynamic contexts in which disturbances can occur due to disruptive actions (from SoS environment or internal sub-systems failures [2]) or to new and enabled technological evolutions i.e., it has to maximise its resilience. The here presented work aims to help and support resilient SoS design, particularly architecting step of the design. Section 2 introduces two approaches for resilient SoS architecting that can be combined with a behavioural modelling approach named OMAG, briefly introduced. In section 3, retained SoS "-ilities" and their interdependence are discussed and formalised. Section 4 illustrates the proposed contributions before concluding.

Resilient SoS Architecting

Architecting a resilient SoS means to consider various interdependent "-ilities" and new design approaches. [START_REF] Weck | Engineering Systems: Meeting Human Needs in a Complex Technological World[END_REF] insists on "designing for resilience is about creating a system that can bounce back from something no one ever thought would happen". Existing approaches are strongly based on system paradigm and follows Systems Engineering principles [START_REF] Bkcase Editorial | The Guide to the Systems Engineering Body of Knowledge[END_REF]. In the next we discuss about requested "-ilities" and two approaches.

Fig. 1: Overview of "-ilities" dependencies [START_REF] Ross | Towards a Prescriptive Semantic Basis for Changetype Ilities[END_REF] Various "-ilities" definitions can be found [START_REF]ESD Terms and Definitions (Version 12[END_REF] [7] [START_REF] Ricci | Architecting Systems of Systems with Ilities: an Overview of the SAI Method[END_REF]. The concept of "-ility" can be used to characterize both SoS and each of its sub-systems. As illustrated in Fig. 1, it is admitted that an "-ility" dynamically vary and is dependant or influenced all along SoS life cycle depending on 1) its characteristics (properties, behaviours and "-ilities"), 2) the characteristics (properties, behaviours, and -ilities) of its sub-systems, and 3) emergent properties and behaviours from sub-systems' interactions.

For instance DoD [START_REF]ESD Terms and Definitions (Version 12[END_REF] presents resilience as dependant from robustness, flexibility and protection "-ilities". Following the same dependence principles, robustness depends from reliability, availability, survivability and maintainability. In the same way, the DSTA framework [2] considers two levels of SoS "-ilities": Key SoS "ilities" (robustness and evolvability) and Key Enabling "-ilities" (flexibility (operational and design) and interoperability) that have been enriched in Fig. 2 by decomposing interoperability definition.

SoS

Fig. 2: Key SoS "-ilities" and Enabling "-ilities" (inspired from DSTA Framework [2])

In both cases, whatever the definition for "-ility" and its interdependence with other abilities of the SoS, an "-ility" remains difficult to conceptualize from a unified manner (that can be even not expected), to handle and to use in confidence in architecting process [START_REF] Vaneman | An Analytical Approach to Assessing Emergent Behavior is a System of System[END_REF] [11] [START_REF] Dou | An Evolutionary Theory-Systems Approach to a Science of the Ilities[END_REF].

Concerning SoS architecting approaches, first SAI (SoS Architecting with Ilities) [START_REF] Ricci | Architecting Systems of Systems with Ilities: an Overview of the SAI Method[END_REF] focuses on value sustainment of both functional and non-functional requirements. Fig. 3 shows the essential steps of SAI, especially the steps 4 (Generate initial architecture alternatives) and 6 (Evaluate potential alternatives) in which a behavioural model of the SoS architecture is built and executed for evaluating the chosen "-ilities" defined in step 3. Second, DSTA framework [2] is a methodological framework for supporting SoS architecting and a reference framework for choosing the most relevant "-ilities" allowing practitioners and manager to drive and manage efficiently SoS architecting. In both approaches, the SoS architecting phase (i.e., defining strategy, requested operations and scenarios, and specifying architectural alternatives according to a more or less high level of abstraction) is apart from SoS designing phase (for instance, choice and interfacing of sub-systems, validating scenarios). In design phase, several solutions are proposed in [START_REF] Vaneman | An Analytical Approach to Assessing Emergent Behavior is a System of System[END_REF] to improve various "-ilities" to gain resilience e.g. employing redundancy, reducing complexity or improving reparability. Alternatives solutions must be modelled and compared thanks to an expected value (quantitative or qualitative) level for each "-ility". Fig. 3: SAI principles approach [START_REF] Ricci | Architecting Systems of Systems with Ilities: an Overview of the SAI Method[END_REF] To this purpose, the behavioural modelling method OMAG can support both SAI steps and DSTA framework to describe simply and to link the behaviours of a SoS and of its sub-systems. This approach is enriched by the formalisation of a set of "ilities" by properties allowing their checking or evaluation.

SoS Behavioural Modelling: OMAG Method

OMAG (Operating Modes Analysis Guide) [START_REF] Chapurlat | Proposition of a guide for investigating, modeling and analyzing system operating modes: OMAG, Complex Systems Design and Management CSDM[END_REF] is a behavioural and functional modelling and analysis method allowing:

-System architect to select the Operating Modes [START_REF] Wasson | System Analysis, Design and Development: concepts, principles and practices[END_REF] that characterize a system all along its life cycle.

-To determine gradually the expected Properties (functional and non-functional i.e. "-ilities") and Parameters of the system when evolving into a mode.

-To determine gradually and to model various Operational Scenarios. It is question of a functional model describing the dynamic of a system (what are the expected functions or activities and how they are chained and synchronised?) in a given operating mode. Various modelling languages can be used e.g. BPMN, eFFBD, or use case diagram. In OMAG approach, each operational scenario describes a part of the whole expected functional architecture of the system.

OMAG is based on a graphical grid shown in Appendix, detailed and illustrated in [START_REF] Chapurlat | Proposition of a guide for investigating, modeling and analyzing system operating modes: OMAG, Complex Systems Design and Management CSDM[END_REF]. Briefly, the OMAG principles are summarized in Fig. 4. Considering a system, OMAG requires defining first systems' attributes and to gather them into a ParametersAndPropertiesSet. An attribute is modelled as a Parameter, a valued and typed data describing time (temporal aspect e.g. maximum delays for reaction), shape (structure e.g. geometric constraints) or space (situation e.g. non-functional expectation) characteristics of any element from the system or its environment. The ParametersAndPropertiesSet is set up and grows up gradually all along the architecting process. The set of generic Operating Modes and Transitions is then formalised by the grid and the architect must select those relevant for the system and to be studied. Each transition is characterized by a couple (condition/event) allowing system evolving from an operating to the next. For each mode and transition, architect has to model what are the expected operational scenarios allowed in the studied Mode or induced / expected to fire the transition. Fig. 4 shows the main elements of a grid OMAG allowing to describe and link operating modes, operational scenarios associated to each mode, parameters and properties of a system. The result is a behavioural model of the studied system conforms to the underlying mathematical formalism (inspired from Finite State Machine model [START_REF] Cheng | Automatic functional test generation using the Extended Finite State Machine Model[END_REF]). Each operating mode is modelled as a state and each mode transition as a state transition. An operational semantic of OMAG grid is given in [START_REF] Chapurlat | Proposition of a guide for investigating, modeling and analyzing system operating modes: OMAG, Complex Systems Design and Management CSDM[END_REF] specifying formally with no ambiguity the interpretation and execution rules of an OMAG grid. This allows then defining and implementing OMAG grid simulation and proof mechanisms not detailed here. These mechanisms allow to model and verify properties (modelling properties as nonfunctional properties), to approximate "-ilities" values, or to highlight rapidly some disturbing or awkward situations the SoS has to face. This can be helpful for SoS architect who intends to test and compare various SoS architectural alternatives as requested, for instance, in SAI approach.

SoS -ilities and -ilities Dependence Modelling: Property Concept

A 'property' is defined in [18] as "an entity that can be predicated of a thing or, in other words, attributed to it (also called 'attribute', 'quality', 'feature', 'characteristic' or 'type')". [START_REF] Micouin | Toward a Property Based Requirements Theory: System Requirements Structured as a Semilattice[END_REF] introduced a Property-Based Requirements (PBR) theory based on semi-lattices on which a property formalizes a portion of a well-formed requirement (denoted wf-requirement) and be owned by a system. In this case, a property is interpreted as a variable to be quantified or qualified to evaluate the relevance and adequacy of a system solution; such an evaluation is to be carried out by using a model of the system here, an OMAG grid. [START_REF] Qamar | Dependency modeling and model management in mechatronics[END_REF] postulates that a property is any descriptor of an artefact (i.e., a modelling artefact of the system). The property is represented as a mathematical function defined for this artefact, associating a (set of) value(s) allowing evaluating the solution described by this artefact. [START_REF] Dasgupta | A roadmap for formal property verification[END_REF] and [START_REF] Bérard | Systems and Software verification: model checking techniques and tools[END_REF] define a property as "the formal statement of an expectation by using a formal language, i.e., in the form of a logical formula to be proved later". These definitions are merged as follows and adopted in the CREI property modelling language (Cause Relation Effect Indicators) proposed in [START_REF] Chapurlat | UPSL-SE: A Model Verification Framework for Systems Engineering[END_REF][17]:

[A property is] a provable or evaluable (i.e., quantifiable or qualifiable) characteristic of an artefact [that is 1) a system S, or 2) a model M of S built for achieving a design objective] that translates all or part of stakeholder expectations to be satisfied by this artefact. The goal is to help managers, architects and designers to formalise "what is" and "how" can evolve an "-ility" of a SoS i.e., how it can be influenced or dependent from 1) other characteristics of SoS, 2) conditions taking into account external and internal events, but also 3) characteristics related to each sub-systems of SoS or resulting from their interactions.

A CREI property is formalized as a composite entity made up of a group of causes (C) correlated with a group of effects (E) via a parameterized and constrained relation (R) between C and E describing the condition and the expected effects under which the property is satisfied. This relationship formally describes how the set of causes C induces a modification in the entire set of effects E. Moreover, a set I of indicators can be associated with R to make property assessable. These indicators are the observation variable and Design variables2 [START_REF] Qamar | Dependency modeling and model management in mechatronics[END_REF]. For the formalization, we define the set Φ as the set of user-defined or predefined properties of the studied system. A CREI Property CP is defined as:

CP ::= < reference cp , C , R , E , checkingValue cp , [I , evaluationValue cp ] > With:

reference cp ∈ S is a handle (unique) for property proof traceability.

-C = {v i / v i ∈ ParametersSet ∪ Φ, i ∈ [0 ; card(ParametersSet ∪ Φ)]}, i.e., C can
be empty (C = ∅): the property is then considered to be an own property 3 , otherwise (C <> ∅) as a composite property 4 .

-

E = { v j / v j ∈ F ∪ Φ, j ∈ ]0 ; card(F ∪ Φ)]} i.e., E <> ∅.
-R ::= <T p , θ c , θ e , relationType, θ i >, where:

-T p = C ∩ E is the set of variables that may be simultaneously used for describing causes and effects.

θ c : T p k x C m x ℝ +*n → { True, False } defines the Boolean function describing the condition under which the causes of C are interpreted. By default, the function θ c returns True (denoted θ c = True in the next):

(t 1 , … , t k , c 1 , … , c m , r 1 , … , r n ) → θ c (t 1 , … , t k , c 1 , … , c m , r 1 , … , r n ) ∈ { True, False }
θ e : T p o x E p x ℝ +*q → { True, False } defines the Boolean function describing the condition under which the effects of E are interpreted. By default, the function θ e returns False (denoted θ e = False in the next): (t 1 , … , t o , e 1 , … , e p , r 1 , … , r q ) → θ e (t 1 , … , t o , e 1 , … , e p , r 1 , … , r q ) ∈ { True, False } -At this stage, relationType models the relation to be checked: 'C implies E', 'C is equivalent to E', or 'C influences E' formalized as follows: ° 'C implies E' is defined as the logical function: θ c ⟹ θ e ° 'C is equivalent to E' is defined as the logical function: θ c ⟺ θ e ° 'C influences E' is defined as the function: θ c ⇢ θi θ e . This relation is defined by [START_REF] Pearl | Reasoning with cause and effect[END_REF] as "in knowing with certainty C, we can then deduce E with certainty", i.e., knowing the values (and their variation) of the causes defined in C allows to deduce the possible values (and their potential variation) of effects defined in E by defining an influence factor θ i ∈ [-1,1] allowing to interpret a beneficial vs. harmful influence as follows:

° θ i → 0: the influence exists between the causes and effects remaining more or less neutral (by default, θ i = 0); ° θ i → 1: each variation of the variables used in C induces a variation of the variables used in E, interpreted as beneficial for the system;

° θ i → -1: each variation of the variables used in C, induces a variation of the variables used in E, interpreted as harmful for the system; -checkingValue cp is set to True, else False (i.e., if a checking technique can be applied on the model for proving the property CP and can conclude CP is satisfied, False otherwise, thus providing a counterexample). -(optional) [I, evaluationValue cp ] I ⊆ ParametersSet is a set of indicators that can be evaluated to characterize the truthfulness of the property CP (e.g. in case of simulation or for guiding the appraisal): I = {i j / i j ∈ ParametersSet, j ∈ [0, card(ParametersSet)]}, where i j is a Modeling Variable extracted from the system model. In case of I is defined, then CP.evaluationValue cp =μ(I), where μ is the aggregation function chosen for the evaluation, e.g. μ can be defined by μ ::= 1/card(I)*∑ I (i.value). CP can be considered as satisfied as proposed in [19] i.e. As an illustration, we focus on the next on the interoperability of each sub-system making up the SoS, considering the 'key enabling -ility' role of this characteristic [2] and its direct influence on the objectives of resilient SoS architecting project.

For this, we consider (see Fig. 5) there are some dependencies to respect (evaluated by using 5 levels of dependencies from preferred to forbidden) between the operating modes of the SoS and the operating modes of sub-system at each moment, taking into account their dynamical evolution. For instance, when the SoS works and fulfil the mission (SoS is in Operating Mode O3), it seems important (++) that a maximum of sub-systems can be able to provide their own mission, and to operate efficiently (sub-systems have to be preferably in Operating Modes O1 to O5). Some of these sub-systems can also (+) be under deployment (operating Mode D1) for instance if these sub-systems have to replace existing sub-systems at a given moment, assuming then architectural evolution of the SoS. Conversely, it seems inacceptable (--) that a sub-system must be in dismantling operating mode (EL1 or EL2). These interdependencies are, of course, indicative: architect can modify them without any impact on the property formalisation and analysis that follows. Other tables can be built for maintainability, resilience or robustness as expected in [2]. -------------------------------* --EL2 ----------------------------------

++ + * - -- Prefered Acceptable Neutral Not recommended Forbidden SoS SS R D1 D2 D3 O1 O2 O3 O4 O5 DM1 DM2 DM3 ME1 ME2 ME3 ME4 EL1 EL2 R * -------------------------------
V++ V+ V* V- V-- --0 0 0 0 1 + 0 1 0 0 0 -0 0 0 1 0 * 0 0 1 0 0 ++ 1 0 0 0 0 ++ 1 0 0 0 0 ++ 1 0 0 0 0 ++ 1 0 0 0 0 ++ 1 0 0 0 0 -0 0 0 1 0 -0 0 0 1 0 -0 0 0 1 0 -0 0 0 1 0 -0 0 0 1 0 -0 0 0 1 0 -0 0 0 1 0 --0 0 0 0 1 --0 0 0 0 1

Sub systems

Fig. 5: operating modes dependencies considering requested interoperability

The interoperability characteristic of the SoS is formalized as the property P as follows:

1. Cause := ∀OM SoS ∈ OperatingModes(SoS) ; OMAG grid behaviour is translated into symbolic logico-temporal formulae. Each transition between Operating Modes selected by architect is modelled as an Elementary Valid Formula (EVF) [START_REF] Chapurlat | Analysis and formal verification of Grafcet (FCCS) using Interpreted Sequential Machine[END_REF] modified as follows 5 :

EVF ::= ( OM i ∧ event j ∧ condition k ⊃ oOM l ∧ scenario m ) With:
-OM i and OM l are propositional variables modelling the source and destination operating modes of the transition, and set to True if the studied system is in the corresponding operating mode, false otherwise.

event j and condition k are propositional variables set to True if event and condition associated to the transition are True, false otherwise. The entire list of EVFs defines a symbolic and formal description of the behaviour of the OMAG grid. Similarly, a Unified Valid Formula (UVF) is computed by taking EVFs into consideration. Here considered, an UVF is the set of conditions i.e. θ c which specifies how a given Operating Mode OM can be activated: (denoted V++, V+, V*, V-and V-) are computed regarding each state of the SoS for a top down analysis of the dependence relations. We focus on the preferred states of the sub-system i.e., those characterized by a dependence relation '++'.

The state vector V of the SoS (resp. sub-system) is 1x18 vector defined as follows:

(there are 18 possible operating modes in the current OMAG grid and the sub-system SS i must be in one and only one operating mode OM k ) So θ e is defined as follows:

Where:

-T k is the set of output transitions from the preferred operating mode OM of the sub-system SS i that is preferred when SoS is in operating mode OM SoS . -==1 iff SS i is in the state OM and will stay in this state at the next moment or if the state OM will be activated at the next moment. The same computation process is used for determining θ e in the case of dependence relation that indicates the operating mode of SS i is acceptable, neutral, not recommended or forbidden. In the same way, the same computation approach is used in a bottom-up analysis regarding the dependence relations between each operating mode of each SS i and SoS operating mode.

Simulation (following operational semantics given in [START_REF] Chapurlat | Proposition of a guide for investigating, modeling and analyzing system operating modes: OMAG, Complex Systems Design and Management CSDM[END_REF]), evaluation of parameters and the generation of counter examples provided by checking technique proposed in [START_REF] Chapurlat | Analysis and formal verification of Grafcet (FCCS) using Interpreted Sequential Machine[END_REF] and developed in [START_REF] Nastov | A verification approach from MDE applied to Model Based Systems Engineering: xeFFBD dynamic semantics, Complex Systems Design and Management CSDM[END_REF] are suitable for allowing architect to detect 1) modelling errors or mistakes, 2) unwanted or unexpected behaviour inducing nonfunctional properties variation. Fig. 6 shows a big picture of the overall approach consisting to use OMAG and properties modelling, checking and evaluation in SAI approach.

Conclusion and Perspectives

A demonstrator of the OMAG grid and properties modelling tool is currently being tested. The automated properties building, taking into account various version of dependence tables, properties checking and OMAG grid simulation techniques are under development by using framework developed in [START_REF] Nastov | A verification approach from MDE applied to Model Based Systems Engineering: xeFFBD dynamic semantics, Complex Systems Design and Management CSDM[END_REF]. The goal is now to test the overall approach on relevant case studies. The perspective is to enrich the two aforementioned analysis techniques when facing problematic of growing up models' size and complexity (e.g. due to number of OMAG to be considered).

Fig. 4 :

 4 Fig. 4: OMAG main elements meta model (simplified view)

  ---D1 * + + + + + + + + + + + + + + + * * D2 * + + + -----* * * * * * * * * D3 * + + + * * * * * * * * * * * * * * O1 * + + + ++ ++ ++ ++ ++ * * * * * * * * * O2 * + + + ++ ++ ++ ++ ++ * * * * * * * * * O3 * + + + ++ ++ ++ ++ ++ * * * * * * * * * O4 * + + + ++ ++ ++ ++ ++ * * * * * * * * * O5 * + + + ++ ++ ++ ++ ++ * * * * * * * * * DM1 * --------* * * * * * * * * DM2 * --------* * * * * * * * * DM3 * --------* * * * * * * * * ME1 * --------* * * * * * * * * ME2 * --------* * * * * * * * * ME3 * --------* * * * * * * * * ME4 * --------* * * * * * * * * EL1 -

2 .

 2 Relation := (influences) ; Indicators are user-defined and computed including parameters associated to sub-systems e.g. the latency time or interoperation time as proposed in[START_REF] Billaud | Interoperability as a key concept for the control and evolution of the System of Systems (SoS) , 6th International Workshop on Enterprise Interoperability[END_REF]. 3. Effect := SS i ∈ SubSystems(SoS) ; Fig.5shows how dependency vectors

Modelling (steps 4 Fig. 6 :

 46 Fig. 6: Overview of the approach (big picture)

An "-ility" (plural "-ilities")[START_REF]INCOSE, System Engineering (SE) Handbook Working Group, System Engineering Handbook, A Guide For System Life Cycle Processes And Activities Version 3.2.1[END_REF] is "a developmental, operational, and support requirements a program must address (e.g. availability, maintainability, vulnerability, reliability, supportability" which are generally non-functional requirements.

An observation variable allows modelling an expected performance level or an expected "ility" level. A design variable allows to handle and to set up values corresponding with potential design choices.

[START_REF] Timothy | It Depends: Systems of systems engineering requires new methods if you are talking about new kinds of systems of systems[END_REF] An own property models expected values of a (set of) Parameter(s

).[START_REF] Weck | Engineering Systems: Meeting Human Needs in a Complex Technological World[END_REF] A composite property is to be characterized by the causal relation.

The formula oA means that the propositional variable A will be true at the next moment in a common logical and unified time scale.

Acknowledgement. The authors thank A. Monfouga and R. Blainvillier for their involvement in the development of a demonstrator for modelling OMAG grid.

Appendix: OMAG grid


Wenxin Mu
email: wxmu@bjtu.edu.cn

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

Herve Pingaud
email: herve.pingaud@univ-jfc.fr

An Ontology based Collaborative Business Service Selection -Contributing to Automatic Building of Collaborative Business Process

Keywords: business process management, model-driven engineering, interenterprise collaboration, ontology

With the world wide inter-enterprise collaboration and interoperability background, automatic collaborative business process deduction might be seen as a crucial researching subject. We design a methodology of deducing collaborative process by only collecting collaborative objectives and partners' business services. The two key problems are: i) selecting corresponding business services for a set of collaborative objectives; ii) ordering business services with serializations and parallelization. This paper aims to present solution of business service selection. In order to solve the problem, we defined a collaborative ontology, which contains numerous instances of business services and processes of MIT process handbook. The collaborative ontology contains essential concepts in collaborative situation, and owns process deducing rules and algorithms. We provide a brief illustration of implementation within a SaaS toolkit called Mediator Modeling 2ool.

Introduction

In collaborative situation, all the partners come with collaborative objectives and their own objectives to achieve and business services to share. They expect to combine their own business services with suitable ones from other partners to work towards their common objectives. In addition, collaborative business process is a combination of business functions, which is inter-linked and filled with sequences and orders. With these needs, objective-oriented business service selection and collaborative business process creation are absolute essentials in collaboration world. Considering selfupdating and re-building of collaborative business process, we shall design an automatic way to deal with service selection and process creation in design level. Further more in implementation level, first because the software tool deals with a collaborative situation, all the partners may use the software in the same time or individually. Secondly, in order to interact with other software tools (which is developed in our lab), the software should be able to deploy in ESB (Enterprise Service Bus). These lead that the software tool involved in the methodology should be a web service. SaaSs (Software as a Service) seems to be a good solution.

In our lab, Vatcharaphun Rajsiri has created a knowledge-based system for collaborative process specification [START_REF] Rajsiri | Knowledge-based system for collaborative process specification[END_REF]. This system deduces a BPMN (Business Process Modeling Notation) based collaborative process model automatically with the help of collaborative objective model and MIT process handbook [START_REF] Malone | Organizing business knowledge: the MIT process handbook[END_REF]. But this system has weaknesses. First, the system collects only the main goal of whole collaborative network. It leads to lack of partners' objectives and sub-network information. Designing a model, which models all above information, is necessary. Second, the deduced BPMN collaborative process covers only operational level. If in a complex collaborative situation, partners come from different departments and management level. An operational collaborative business process couldn't satisfy partners. According to [START_REF]NF EN ISO 9000 Systèmes de management de la qualité -Principes essentiels et vocabulaire[END_REF] and [START_REF]NF EN ISO 9000 X50-130 Systèmes de management de la qualité -Principes essentiels et vocabulaire[END_REF], business process covers strategy, operation and support levels. We arrive at conclusion that target collaborative process should contain strategy, operation and support levels.

A model-driven and ontology based methodology, which take collaborative objectives, partners' objectives and business services as input and deduce collaborative business process as output as automatically as possible, seems to be a good solution in this situation.

For the input, we define objective model and function model to collect basic collaborative knowledge from partners. For the deduction method, collaborative ontology and a set of algorithms and transformation rules is defined. The algorithms manage to link business objectives with business services. The transformations rules help to deduce sequences among business functions. For the output, BPMN based collaborative process cartography is deduced. The collaborative process cartography has three types: strategy, support and operation.

In this paper, we focus on introducing solution of business service selection (dashline box in Figure 1). Section II first presents definition of objective model and function model. Then it provides a simple example to explain the directions for use of models. Section III provides a brief introduction of collaborative ontology. Section IV gives definitions of business services selection algorithms. Section V is a sketch for collaborative process model and collaborative process creation method. Section VI draws some concluding remarks, discusses the feasibility of our work and outlines our future investigations.

Objective Model and Function Model

This section explains the input part of Collaborative Business Process Deduction methodology (CBPD). In Section II-A, we first address the definition of objective modeling elements. Section II-B presents the definition of function model. And finally Section II-C illustrates examples of objective model and function model.

Objective Model

"An objective model is required to facilitate: i) identification, communication and structuring of business objectives, and ii) measurement of the level of success in achieving objectives. But individual modeling methodologies focus primarily on selected aspects of objectives representation and measurement." [START_REF] Neiger | Business Objectives Modelling[END_REF] For our individual needs, the objective model here should collect both collaborative main goals and partners' individual objectives. For each collaborative goal, partners are regrouped as sub-collaborative network. Partners also have their own objectives. We come up with a result: a real collaborative situation is like a multi-level pyramid: each level could be decomposed to sub-network until partner, and each level could be abstracted to higherlevel collaborative network until the whole collaborative network. With supplementary illustration, because the goal of CBPD is to deduce collaborative process cartography (including strategy, operation and support sub-collaborative processes), we consider that the objectives collected in objective model may set to three types: strategy/operation/support objective.

To summarize, the objective model presented here should be able to (Figure 1 presents modeling elements and links):

• Model collaborative network, collaborative sub-network and partners' relationships.

• Model collaborative networks' objective, sub network's objectives and partners' objectives. Classify objective into strategy, operation and support objective.

Function Model

The requirements for the function model are to get partners' functions, to simplify user's modeling tasks and to decrease user's workload. The function model just collects functions that partners want to share and which can be published to other partners. We defined an IDEF1 (Integration Definition for Function Modeling) based function model to gather partners' business services.

Standard function model: IDEF0 [START_REF] Menzel | The IDEF Family of Languages[END_REF] is reused to present partners' functions. The standard IDEF0 modeling unit is shown in Figure 2 After analysis and evaluation, we found out that the function main model could be partially transferred from objective model. Objectives of collaborative network could be seen as main function. User only fulfills control messages among abstract functions. Transformation equations from objective model to main function model are defined in first-order logic [START_REF] Smullyan | First-order logic[END_REF].

Due to particularity of transformation rules, first order logic still needs to be expended as followed : i) Element:

X is Collaborative Network → CollaborativeNetwork(X); ii) Relationship: Y is Objective Relationship which is between CollaborativeNetwork X 1 and Objective X 2 → Objective- Relationship(Y)(CollaborativeNetwork(X 1 ), Objective(X 2 )). ∀CollaborativeNetwork(X) (∀ObjectiveRelationship(CollaborativeNetwork(X),
Objective(X 1 ))) → ∃MainFunctionModel(X) ∧ ∃MainFunction(X 1 )∈MainFunctionModel(X) 1

Collaborative Ontology

The collaborative ontology defined in CBPD aims to support business service selection and collaborative process creation. This ontology defines the concepts and relationships involved in collaborative situation. The collaborative ontology must be fulfilled with instances from different business domains (for example, MIT process handbook from manufacture, Score Model from Supply Chain and instances from crisis management). In collaborative ontology, collaborative concepts part serves to match collaborative objectives to partners' business capabilities. Mediation concepts part is based on Mediation [START_REF] Benaben | Mediation Information System Design in a collaborative SOA context through a MDD Approach[END_REF] concept. In this paper, our vision is on business service selection. So process creation part will not be detailed.

Business Service Selection Method

In this section, we provide the explanation of business service selection. Section IV-A presents basic theory of business service selection. The example in Section II-C is reused. Section IV-B provides official algorithms of selecting business service.

Business Service Selection Principal

The principal of business service selection in CBPD is based on collaborative ontology, which has been introduced in last section. In the ontology, there are large numbers of Objective and Function instances with relationship: achievedBy. If we could link business objectives and business function in the model to Objective and Function instances in collaborative ontology, then we could indirectly link business objective to business function by the help of relationship: achievedBy. With above theory, we can complete business service selection task.

As shown in Figure 4, there are two parts: ontology and model. In ontology part, we choose several instances of Function and Objective in ontology. In model part, we take the objective and function model example in Section II-C. Here for each business objective and function in the model, we want to find same or close instances in ontology. For example, in the model, "Book van & driver" is same or close to "Book transportation" in the ontology, then we make a link: Same As/Near By between them. With all the relationship: Same As/Near By in Figure 4, suitable business functions are selected for business objectives. Figure 5 shows all the results. Business objectives is linked to business functions by relationship: achievedBy.

Even though the basic principal of business service selection is defined, there are still some remarks to consider:

• Making relationship: Same As/Near By for each business objective and function is quite hard for user. So we provide an Instance Suggestion Mechanism, which could provide suggested ontology instance for user. Section IV-B algorithm (1) presents the Instance Suggestion Mechanism algorithm. • Business objectives and functions defined in the model could also be seen as Business and Function instances in collaborative ontology for future uses.

There should be a self-update mechanism to enlarge the collaborative ontology. Section IV-B algorithm (3) explains self-updating mechanism.

Business Service Selection Algorithms

1) Instance Suggestion Algorithm. Instance suggestion algorithm deals with selecting same or nearest ontology Objective or Function instances for each business objective and function. Algorithm(1) takes keyword of business objective as input, uses collaborative ontology as data and provides a list of suggested ontology instances. This algorithm has three main parts:

• Line 3: finding an Objective instance in collaborative ontology which owns the same keyword: objective key as business objective, the instance is added to suggestion list: L suggestion ; • Line 6-Line 17: Taking frontal parts of keyword as a new list of keyword:

L word [START_REF] Rajsiri | Knowledge-based system for collaborative process specification[END_REF] to L word [i] (for example, keyword: "send products to distributing center", new keywords: "send products to distributing" and "send products to"), for each new keyword, if finding an Objective instance's keyword in collaborative ontology which starts with or contains the new one or contains, then the Objective instance is added to suggestion list; Line 18-Line 23: Taking related two words, which are contained in keyword as a new list of keyword: L 2words (for example, keyword: "send outsourcing order", new keywords: "send outsourcing" and "outsourcing order"), for each related two words, if finding an Objective instance's keyword, which contains the two words, then the Objective instance is added to suggestion list. 2) Objective-Function Mapping. Objective-Function mapping algorithm is the main part of buiness service selection. The principal has been explained in Section IV-A. As shown in Algorithm [START_REF] Malone | Organizing business knowledge: the MIT process handbook[END_REF], it takes list of business objectives and list of business functions as input, uses collaborative ontology as data, and outputs list of relationships: achievedBy. The algorithm is explained as followed:

Algorithm (1) Instance

• Line 3-Line 5: starts the mapping from business functions side.

Implementation

Nowadays, SaaS [START_REF] Sun | Software as a service: An integration perspective[END_REF] is very widely used. It allows users to use application in a Web Client as rich application. No complex client site installation is required. According to [START_REF] Wu | Reference Models for Saas Oriented Business Workflow Management Systems[END_REF], compared with the traditional way which software is purchased for and installed on personal computers, SaaS has advantages: e.g., investment reduction, performance improvement, time saving, easier collaboration, global accessibility, etc. Considering our own needs, the software tool should be able to deploy on ESB [START_REF] Endo | Model-Based Testing of Service-Oriented Applications via State Models[END_REF], which means the software must be a web service. Because the software deals with a collaborative situation, all the partners may use the software in the same time or individually. This leads to a conclusion. SaaS is a quite good solution for our tool: Mediator Modeling 2ool.

Mediator Modeling 2ool bases on GWT [START_REF] Gupta | Accelerated GWT: Building Enterprise Google Web Toolkit Applications[END_REF] and GeasyTools1 . Mediator Modeling 2ool supports objective and function modeling. It implements business service selection and collaborative process creation.

Figure 6 is the screen shot of Mediator Modeling 2ool. On the left, there are modeling palette and file explorer. On the right, there are element properties and collaborative ontology instances' tree. In the middle, it is modeling place. We could create objective and function model here. Web browser can directly launch Mediator Modeling 2ool. In the property window in Figure 6, if we click on the button beside text field, a window with collaborative ontology instances' tree comes out. User chooses the same as or near by ontology instance for modeling element by dragging the instance form ontology tree to same as or near by lists' windows. After modeling and choosing same as or near by ontology instance, a XML file which contains all the modeling information is saved on the server side. User could save the XML file on local machine too.

For business function, the property also contains semantic annotation. The semantic annotation classifies business function to Service Task, Send Task, Receive Task, User Task and Business Rule Task. Business functions combined with semantic annotations are reused to semantically select web services, which could implement business functions. This part of work is presented in [START_REF] Bénaben | Semantic Reconciliation in Interoperability Management through Model-Driven Approach[END_REF].

Conclusion

Collaborative business process deduction methodology (CBPD) aims to provide a collaborative process cartography, which manages process orchestration and business service selection in collaborative situation. The strong points of CBPD are summarized as followed: i) objective model defines objectives and sub-networks. We could easily verify the small group of partners to complete the task; ii) objective model could model different levels of partners; iii) functional table is separated by columns of partner. This allows each partner to fill its own column independently; iv) collaborative process model is deduced automatically. It saves repeated work and eases heavy workload of user. It also crosses different enterprise modeling standard: from IDEF to BPMN. However, any system has its weak points. They are summarized as followed: i) business service selection is half manual and half automatic method. User has to create Same As/Near By relationship from model to ontology instances manually. And then Mediator Modeling 2ool automatically links partners' business functions to collaborative and partners' objectives. ii) This system bases on collaborative ontology, it means that a collaborative ontology, which holds numerous instances and covers different domains is required.

With the accomplishment of business service selection, the next task is business process creation. It remains the formalization of transformation rules and definition of gateways in BPMN based collaborative process model. Further more, function model of CBPD defines only business function. We did not consider non-functional characterization (security, privacy and speed). Miss is working on non-functional characterization. [START_REF] Zribi | Towards a Service and Choreography Governance Framework for Future Internet[END_REF] As introduced in [START_REF] Mu | A Model-Driven BPM Approach for SOA Mediation Information System Design in a Collaborative Context[END_REF], CBPD is only the first step of MISE 2.0 project (Mediation Information System Engineering). Beside CBPD, another two main tasks are semantic web services and BPEL transformation. First, MIS deployment bridges the semantic gap between business functions and technical services. Second, it transfers collaborative process model to BPEL (Business Process Execution Language) based collaborative workflow. Last but not least, the collaborative workflow and technical services are deployed on ESB and executed. This part of work is detailed explained in [START_REF] Bénaben | Semantic Reconciliation in Interoperability Management through Model-Driven Approach[END_REF].

Fig. 1 -

 1 Fig. 1 -Objective Model Elements Definition

  left part. The modeling unit has input and output message. Controlling message and mechanism controls and support function. The function also could send call message to invoke another function. As shown in the middle of Figure 2, function main model reuses function unit and controlling message. As shown on the right of Figure 2, partner columns separate function model. Partner lists its shared functions in correspondence column. Function model reuses function unit, input and output message, controlling message and call message of standard IDEF0 modeling unit.

Fig. 2 -

 2 Fig. 2 -Function Model Elements Definition[START_REF]Announcing the Standard for INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0)[END_REF]

Fig. 3 -

 3 Fig. 3 -Collaborative OntologyAs explained in Section II, the collaborative concepts part of collaborative ontology is seen as two relationships and three main concepts: Same As/Near By relationship, Network, Objective and Function. They are detail explained as followed:• Same As/Near By relationship contains two parts: Same As and Near By. If concept A is Same As with concept B, then concept A equals to concept B. Concept A and Concept B presents the same concept. If concept A is Near By concept B, then concept A and concept B are similar. Concept A may present part of concept B. Concept A and concept B may crosse. • Network means all the involved partners and relationships among them. Another close concept is Sub Network. • Objective presents business goals of collaboration and partners. Objective has relationship: Same As/Near By with another Objective. • Function equals to business services or function, which are provided by partners. Function may own input and output Message. Both Function and Message have self-related relationships: Same As/Near By.In collaborative ontology, collaborative concepts part serves to match collaborative objectives to partners' business capabilities. Mediation concepts part is based on Mediation[START_REF] Benaben | Mediation Information System Design in a collaborative SOA context through a MDD Approach[END_REF] concept. In this paper, our vision is on business service selection. So process creation part will not be detailed.

Fig. 4 -Fig. 5 -

 45 Fig. 4 -Making Links among Models and Ontology Instances

Fig. 6 -

 6 Fig. 6 -Mediator Modeling 2ool Main Frame

  Suggestion: provide suggested collaborative ontology instances for business objective. Input: objective key , keyword for the business objective Data: Collaborative Ontology: CO Output: L suggestion , list of suggested ontology instances 1 A objective , array of all Objective instances of CO; 2 L suggestion ← Null; 3 if A objective contains objective.keyword = Objective key then W. Mu et al.

	5 else
	6	L word , list of words contained in objective key ;
	7	i, counter for loop ← L word .length;
	8	word, store a part of keyword ← Null;
	9	for i from L word .length to 3 //Check first three words
	10	word = from L word [1] to L word [i] ;
	11	if A objective contains objective.keyword starts with word then
	12	L suggestion adds objective;
	13	end;
	14	if A objective contains objective.keyword contains word then
	15	L suggestion adds objective;
	16	end;
	17	end;
	18	L 2words , list of 2 words contained in Objective key ;
	19	while L 2words has next element: word do
	20	if A objective contains objective.keyword contains word then
	21	L suggestion adds objective;
	22	end;
	23	end;
	24 end;
	25 return L suggestion ;

  If one business function: E function owns relationship: Same As/Near By with one ontology Function instance: O function . • Line 6-Line 7: if O function owns relationship: achievedBy with one ontology Objective instance: O objective , and if O objective owns relationship: Same As/Near By with business objective: E objective , then as result: E objective has relationship: achievedBy with E function . • Line 8: the relationship is added into the list: L achievedBy . • Line 13 and Line 16: if there is an E function , which doesn't find E objective , then a relationship: achievedBy from Null to E function is created. The relationship is added to L achievedBy . • Line 21: if an E objective is never achieved, then a relationship: achievedBy from E objective to Null is created. The relationship is added to L achievedBy . Ontology updating algorithm deals with inserting business objectives and functions in collaborative ontology as Objective and Funtion intances with relationship: Same As/Near By. As shown in algorithm (3): • Line 2 and Line 3: for each E objecitve , if E objective owns relationship: Same As/Near By, then get O objective which is related to E objective . • Line 4 and Line 5: create new ontology instance: O new for E objective and add O new into collaborative ontology. • Line 6: creats new Relationship: Same As/Near By between O new and O objective , and adds the relationship to collaborative ontology also.

	2 L relatedObjectives , list of objectives with achievedBy ← Null;
	3 while L function has next element: E function do
	4	if E function .sameas/nearby!=null then
	5	O function = E function .sameas/nearby;
	6	O objective = O function .achievedby;
	7	if L objective contains element E objective .sameas/nearby = O objective then
	8	L achievedBy adds achievedBy(E objective , E function );
	9	if L relatedObjective doesn't contain E objective then
	10	L relatedObjective adds E objective ;
	11	end;
	12	else
	13	L achievedBy adds achievedBy(null, E function );
	14	end;
	15	else
	16	L achievedBy adds achievedBy(null, E function );
	17	end;
	18 end;
	19 while L objective has next element: E objective do
	20	if L relatedObjective doesn't contain E objective then
	21	L achievedBy adds achievedBy(E objective , null);
	22	end;
	23 end;
	24 return L achievedBy ;
	3) Ontology Updating. Algorithm (3) Ontology Updating: insert business objectives into ontology as
	instances and created relationship: Same As/Near By.
	Input: L objective , list of business objectives
	Data: Collaborative Ontology: CO
	1 while L objective has next element: E objective do
	2	if E objective .sameas/nearby!=null then
	Algorithm (2) Objective-Function mapping: find correspondence business 3 O objective = E objective .sameas/nearby;
	functions for each business objective and create relationship: achievedBy. 4 O new = change E objective to ontology instance;
	Input: L objective , list of business objectives 5 CO adds O new ;
	6	L function , list of business functions CO adds SameAs/NearBy(O objective , O new );
	Data: Collaborative Ontology: CO 7 end;
	Output: L achievedBy , list of relationship 8 end;
	1 L achievedBy ← Null;

L suggestion adds objective;

GeasyTools is an open source GWT based API. PetalsLink develops it. The tool helps create graphic elements. It is available on website: http://research.petalslink.org/display/geasytools/GEasyTools+Overview