Jean M Simão

Hervé Panetto

Yongxin Liao

Paulo Cézar Stadzisz

A notification-oriented approach for systems requirements engineering

Keywords: Systems Requirements Engineering, System Specification, Notification Oriented Paradigm

Systems Engineering (SE) is an approach for designing complex systems in a multidisciplinary universe, based on concepts from the systemic paradigm and promoting languages, methods, and standardized processes. Requirements engineering is one of the main steps in SE processes. The current research presented in this paper aims at focusing on the open issue related to the formalization of systems requirements for their verification, ensuring the coherence of the whole set of requirements in each contextual engineering domain and their validation against the initial stakeholders' needs. Moreover, requirements coming from different domains are generally linked by non-formalised traceability relationships. It is even difficult to trace any change in their definition and their impact to the whole set of specifications. The paper discusses and proposes an approach for systems requirements engineering based on a rule and notification oriented approach for ensuring the effective coherence and understanding of these requirements throughout the life cycle of any complex system. This proposed notification approach is derived from the so-called Notification Oriented Paradigm (NOP), a new rule and event driven approach for software and hardware specification and execution.

Introduction

Currently, in order to face globalization and the resulting increased competition, enterprises have specialized in specific domains and have established partnerships with other companies to complement their initial skills. These enterprises are thus forming a so-called collaborative and distributed network. These approaches have allowed them to develop complex systems and collaborative activities in many industrial domains like aeronautics, nanotechnology, aerospace, and bioengineering.

According to [START_REF]:2012 -Systems and Software Engineering -Software Life Cycle Processes[END_REF], it is important, for succeeding in these collaborative engineering processes, to formalize how different partners can work with others and, through their interactions, how they can achieve a common objective within different perspectives.

These engineering processes follow best practises generally defined in the so-called systems engineering domain.

Systems Engineering (SE) is an approach for designing complex systems in a multidisciplinary universe, based on concepts from the systemic paradigm and promoting languages, methods, and standardized processes (ISO/IEC 15288) [START_REF]:2012 -Systems and Software Engineering -Software Life Cycle Processes[END_REF]. It aims at consolidating, identifying, and formalizing new methods and frameworks that support engineering phases in a better consistent way [START_REF] Lopes | Model Based Systems Engineering for Smart Grids as Systems of Systems[END_REF]. It is "an interdisciplinary approach and means to enable the realization of successful systems" [START_REF] Incose | INCOSE Systems Engineering Handbook: A Guide for Life Cycle Processes and Activities[END_REF]. One of the SE processes is dedicated to analysing users' and systems' requirements.

Requirements Engineering (RE) refers to the activity of formulating, documenting and maintaining systems requirements [START_REF] Young | The Requirements Engineering Handbook[END_REF] in order to produce, from users' needs, a set of specification related to what the final system should be. Requirements provide the basis for all phases of the development system. Thus, it is necessary to control these requirements in all phases of the development cycle and in all domains to avoid some misinterpretation and mistakes committing the final results.

A requirement is a statement from the stakeholder's needs in order to define a product, a system or a process and it must be unambiguous, clear, unique, consistent, stand-alone, and verifiable [START_REF] Bkcase | The Guide to the Systems Engineering Body of Knowledge (SEBoK)[END_REF]. Each requirement matches a single part of the future product, system or process and it is grouped in an appropriate combination of textual statement views. Whereas approaches such as the Model-Based Systems Engineering (MBSE) have been studied [6] [START_REF] Mazón | A Model-Driven Goal-Oriented Requirement Engineering Approach for Data Warehouses[END_REF] for improving the definition and the coherency of requirements [START_REF] Szejka | Towards a conceptual framework for requirements interoperability in complex systems engineering[END_REF], there is still difficulties to ensure that coherency from a semantic point of view and to identify all impact relationships when any of these requirements change during the system development lifecycle.

Related Works

Requirements Engineering has long been recognized as critical activity in systems and software development processes [START_REF] Roman | A taxonomy of current issues in requirements engineering[END_REF][10] [START_REF] Sommerville | Requirements engineering: processes and techniques[END_REF]. A large amount of studies addresses theoretical aspects and propositions of techniques and recommended practices for RE [START_REF] Daneva | Empirical research methodologies and studies in Requirements Engineering: How far did we come?[END_REF]. Hofmann and Lehner [START_REF] Hofmann | Requirements engineering as a success factor in software projects[END_REF] identified RE practices that clearly contribute to (software) project success and concluded that successful projects allocate a significantly higher amount of resources to RE (28%). Many (37%) of projects failures [START_REF] Locatelli | Systems Engineering to improve the governance in complex project environments[END_REF] are caused by the problems of requirements misinterpretation among stakeholders. Most studies have focused on requirements elicitation, modelling, and processes/methods [START_REF] Ratchev | Knowledge based requirement engineering for one-of-a-kind complex systems[END_REF] [START_REF] Valaski | Environment for Requirements Elicitation Supported by Ontology-Based Conceptual Models: A Proposal[END_REF].

A number of researches reported in the literature focus on the elicitation of requirements. According to [START_REF] Bernard | Requirements management within a full model-based engineering approach[END_REF], this activity is the process of seeking, uncovering, acquiring, and elaborating requirements for (software) systems. It concerns learning and understanding the needs of the customer with the aim to communicate these needs to the developers [START_REF] Zowghi | Requirements elicitation: A survey of techniques, approaches, and tools, in: Engineering and Managing Software Requirements[END_REF]. Additionally, there is a general agreement [START_REF] Davey | Requirements elicitation problems: a literature analysis[END_REF] that fixing the results of poor requirements elicitation is more expensive than for other mistakes. It is a common sense in most studies that systems requirements have to satisfy the customer´s (i.e. stakeholders) intents. The ISO/IEC/IEEE standard uses the expression "in a way that is (the requirement) acceptable to the customer" [START_REF]ISO/IEC/IEEE 24765:2010 -Systems and software engineering -Vocabulary[END_REF] to emphasize that the requirements must achieve the customer´s intentions. Thus, some authors propose to validate the specified requirements by determining their conformity with stakeholders´ needs [START_REF] Hofmann | Requirements engineering as a success factor in software projects[END_REF]. The term "need" is often employed to refer to the cause or reason that justifies the specified requirements [START_REF] Zowghi | Requirements elicitation: A survey of techniques, approaches, and tools, in: Engineering and Managing Software Requirements[END_REF]. The needs would be the source of the requirements. Some authors, inspired by INCOSE2 observe that the stakeholders' needs in turn contribute to the solution of some real-world problems [START_REF] Wieringa | Requirements Engineering: Problem Analysis and Solution Specification[END_REF] [START_REF] Bourque | Guide to the software engineering body of knowledge (SWEBOK (R))[END_REF].

In the context of systems engineering, the deep understanding of a system's intents and how they maps to systems requirements is as important as for software engineering, and the underlying concepts are also analogous. INCOSE employs the terms "Problem or Opportunity" to refer to the issues underlying the gaps in the organization strategy with respect to the desired organization goals or objectives [START_REF] Bkcase | The Guide to the Systems Engineering Body of Knowledge (SEBoK)[END_REF]. In spite of the large number of studies and approaches proposed to specify systems requirements, for any "complex system" development (e.g. software, aerospace, automotive), it is a common agreement that requirements engineering remains an unclear and challenging task. Terms used in scientific literature and even in the industry (as pointed out in this section) are not convergent creating a lack of understanding on the subject. Analysts may feel confused when trying gathering information from the stakeholders and other sources in the business or application domain. Therefore, the specification of the studied system may become incomplete or incorrect because of an inadequate understanding of the project intents.

Generally speaking, the various works on requirements engineering show that there are two unsolved main issues/questions [START_REF] Roman | A taxonomy of current issues in requirements engineering[END_REF] that this paper tackles in the proposed approach: (1) how to "semi-automatically" model a set of requirements taking into account their strong inter-relationships? (2) How to identify/formalise these interrelationships that are generally domain-dependent and thus related to some deep and implicit knowledge of the related skills of the stakeholders? [START_REF] Liao | Semantic annotation for knowledge explicitation in a product lifecycle management context: A survey[END_REF] This paper discusses and proposes a solution only for the first question. Indeed, the model of all requirements of a system and their inter-relationships can be seen as a bigraph of interrelated notifications where each requirement is a logical premise manipulating some systems attributes and notifying some functional entities which, in turn, forward new attributes values to any impacted requirement. This operational semantics is quite analogue of the so-called NOP paradigm that we will discuss briefly in the following section.

Notification-Oriented Paradigm (NOP)

A new technique, called Notification Oriented Paradigm (NOP), was proposed as new software programming and developing approach. NOP presents a new concept to develop and execute applications. Its essence is an inference process based on small, smart, and decoupled pieces of software (i.e. entities) that collaborate by means of notifications. This solves redundancies and centralization problems of the causal processing, thereby solving processing capacity misuse and coupling issues. In NOP, causal expressions are represented by a set of logic-causal rules and dealt by entities called Rules. A Rule entity, represented as a logical and causal expression, is illustrated in Figure 1(a

Proposed Approach for Systems Requirements Engineering

NOP Modelling Primitives

According to the NOP specification [START_REF] Simão | Inference Based on Notifications: A Holonic Meta-Model Applied to Control Issues[END_REF], the NOP modelling primitives essentially includes Rules, FBEs, and Notifications. These building blocks allow describing the entire logic of software systems. Additional primitives may be employed to specify particular constraints, aspects of software flow control, and conflict solving, among other features of the system being modelled. In the proposed approach for systems requirements engineering, the authors make use of the three main NOP primitives in order to describe those requirements at the same level of detail then those sentences expressed previously by the system engineer, according to the information expressed by the stakeholders. The meaning of the three NOP primitives in the context of this paper are described in the next topics.

Rule -A Rule in NOP is defined as a logical unit, which commands a set of actions when its conditions are satisfied. In the proposed approach, a Rule represents part of or an entire system requirement, including the constraints with regard the needed conditions (i.e. Rule preconditions) for that requirement and the effects or actions to be accomplished (i.e. Rule post-conditions) according to that requirement. Depending on the system requirement complexity, one or more rules may be composed to express each requirement. The notation to draw a Rule is depicted in Figure 2 (a).

Fact Base Element (FBE) -In NOP, an FBE represents a software element, which may contain Attributes, can carry out functions in Methods, and can interface with external elements (e.g. user interface, sensors, and devices) also by means of Methods. In this paper, when specifying systems requirements, authors also propose to use FBE to represent system elements identified in the requirements statements. This way, FBEs are limited to the elements known at the requirements specification phase. FBEs are drawn as dashed rectangles in the proposed notation as illustrated in Figure 2 (b). They must contain one or more exposed Attributes that represent notified events or variables. A FBE may also contain incoming arrows that represent functions called by other FBEs.

Notification -A notification is an explicit advice from a NOP element to another one, indicating that a change in the system state occurred. This may means that an entity changed its value or an event happened, for instance. In this paper, authors consider that a notification represent a link between Rules and FBEs. These links may have two meanings, according to the link direction. A notification from a FBE to a Rule (i.e. FBE → Rule) describes a given precondition for that Rule related to the indicated Attribute of the FBE. A logical expression from a defined algebra must be assigned over the link to describe the logical condition. Figure 2 (c) illustrates this type of link. On the other hand, a notification from a Rule to a FBE (i.e. Rule → FBE) describes that the Rule invokes a function from a Method of an FBE. A reference to the Action is to be written over the link as illustrated in Figure 2 (d).

NOP Based Requirements Modelling

From the primitives established in the previous section, authors propose to construct the system requirements specification in the form of a system requirements model. This model may include a single or multiple diagrams using the NOP notation. The input for the modelling process is the system requirements sentences. A general view of the adopted modelling technique follows.

For each requirement statement in the system requirements specification: 1. To analyse the requirement sentence aiming at: i. Identifying the functional or non-functional request in the requirement. ii. Identifying the Conditions for the functional or non-functional request. iii. Identifying the Attributes involved in the Conditions. iv. Identifying the Actions for the functional or non-functional request v. Identifying the functions related to Methods instigated in the Actions. Step 1 involves analysing every requirement sentence in order to identify the specific request inside the stated requirement. Commonly, it should exist only one request per requirement. However, sentences in natural language expressing requirements for a system may explicitly or implicitly refer to more than one request. Additionally, the request may specify an intended action to be carried out by the system (referred to as functional request) or it may specify constraints, properties or conditions for the system (referred to as non-functional requests). In this step, the elements related to the conditions and actions of the request are also identified considering the references to aspects, objects, devices or interfaces with the external elements. Steps from 2 to 4 are related to the construction of the requirements model from the elements identified in step 1, i.e. the identified Rules, FBEs and links. Step 5, particularly, concerns integrating models constructed from each system requirement. This may involve merging Rules and FBEs and reconnecting links between them.

To illustrate the proposed modelling technique it is taken into account the following example of system requirement statement: "The system shall activate the fire alarm when the temperature sensor indicates more than 60 o C in the room". Analysing this requirement sentence, the system analyst can identify "activate the fire alarm" as the stated functional request. The condition of the Rule for that request is "temperature more than 60 o C" and the element associated to this condition is "temperature sensor". The FBE temperature sensor shall expose an Attribute that contains the current temperature in the room. Finally, the element responsible for the function "activate" is the "Fire Alarm" instigated by the action of the rule. Thus, following the steps 2, 3 and 4 of the proposed technique, the resulting model is presented in Figure 3.

Case Study: Access Security System

This section presents the modelling example of an "Access Security System" extracted from the INCOSE SE Handbook v3.2 [START_REF] Incose | INCOSE Systems Engineering Handbook: A Guide for Life Cycle Processes and Activities[END_REF]. This study is based on six system requirements that specify the intended functional and non-functional characteristics of the system.

Case description

According to the SS11 Stakeholder Requirement presented in [START_REF] Incose | INCOSE Systems Engineering Handbook: A Guide for Life Cycle Processes and Activities[END_REF], the secure areas (i.e. rooms that have limited access) are to be protected by two independent security checks. One of them is based upon an employee ID and the other one is based upon biometric data. The time between the two independent security checks shall not exceed a configurable period. The user is allowed three attempts at biometric and/or card identification before access is completely disabled. Any denied access attempt is to be sent to the administrator.

The system requirements statements are:

 SS11a: Secure areas shall be protected by security check based upon employee ID.  SS11b: Secure areas shall be protected by a second independent security check based upon biometric data.  SS11c: The time between the two independent security checks shall not exceed a configurable period.  SS11d: The user shall be allowed three attempts at biometric identification.  SS11e: The user shall be allowed three attempts at card identification.  SS11f: Any denied access attempt shall be sent to the administrator.

NOP-Based Requirements Models

This section applies the proposed technique showing the main phases of the Access Security System requirements modelling.

Requirement SS11-a:

This requirement indicates that the system shall "protect secure areas" what means that the system shall meet two requests: enabling and disabling access to the secure area. As consequence, the system will have to command an element (e.g. a blocker) that carry out these two actions. This requirement also states that a "security check based upon employee ID" will provide the condition to enable or disable access to secure areas. The identified attribute for this condition is the "employee ID" read from an external element (i.e. an ID card reader). Figure 4 shows the model of this requirement where three Rules and two FBEs are identified.

Requirement SS11-b:

This requirement is similar to SS11-a and its model will also include two FBEs and three Rules. The first FBE represents the Biometric Reader element and the second the Entry Blocker. The last is the same FBE indicated in the model of SS11-a because the Entry Blocker will be obviously the same. The first Rule will represent request for checking the employee biometric. The two other Rules represent the request to enable and disable access to the secure area as modelled to SS11-a.

Because of their inter-relationship, SS11-a and SS11-b models can be integrated, as illustrated in Figure 5. The Rule "Protect Secure Areas" receives a <<disjunction>> operator to indicate that any or both conditions enable this Rule. The Rule "Allow Access" in turn receives a <<conjunction>> operator to indicate that both conditions must be satisfied to enable this rule. These requirements are very similar once both limit the number of user attempts. The request in both requirements can be merged in a single request that counts the number of ID and BIO checking attempts. A new FBE (User Attempts Counter) is created and new conditions about the status of the user attempts are inserted for the Rules that represent the request to enable and disable access to the secure area as illustrated in Figure 6.

Requirement SS11-f:

This last requirement defines a new functional request for notifying the administrator when a user access attempt is denied. This leads to a new Rule to represent this notification. However, because the conditions for that Rule are identical to those of the "Protect Secure Areas" Rule, they can me merged and a new link is create to command the notification action by the Administrator Interface FBE. Figure 6 illustrates the final system requirements model for the considered example.

Conclusions and Future Works

This paper proposed a novel approach for systems requirements modelling that makes use of concepts and the notation of the previously developed Notification Oriented Paradigm (NOP). NOP has been successfully applied for modelling, programming, and executing software applications based upon three fundamentals primitives: Rules, FBEs, and notifications. Based on these concepts, this paper presented a technique for constructing a graphical model of the expressed system requirements. An example of an access security system illustrated the proposed approach.

The presented approach uses a graphical notation, thus facilitating the analysis of the requirements and identifying hidden knowledge. Additionally, this approach makes explicit the logical dependencies (Rules with their conditions and actions) between the requirements through linked and shared Attributes and Methods of involved elements (FBEs). These characteristics allow modelling the whole set of requirements taking into account their inter-relationships. In the context of larger scaled systems, the proposed approach should provide means and tools for semi-automatically generating systems requirements models.

However, the proposed approach does not yet take into account the meaning behind the requirements in order to identify hidden semantics inter-relationships. Indeed, this semantics is generally domain-dependent and thus related to some deep and implicit knowledge of the related skills of the stakeholders. Authors' working in progress explore using ontologies as a suitable solution for expressing these aspects of requirements together with the modelling approach presented in this paper.

  ). Structurally, a Rule entity has a Condition entity and an Action entity which respectively concern the decisional part and the execution part. Each element evaluated by a Rule set is represented and dealt by an entity called Fact Base Element (FBE). In the considered example, the FBEs are the Security_System and User_Reader. A FBE comprises one or more Attribute entities that store data. Examples of Attributes are the Status in the FBE Security_System and the Bio in the FBE User Reader. The values of Attributes are analysable, in an inference process, by the Conditions of Rules, using other collaborative entities called Premise. In the considered Rule (Figure 1 (a)), its Condition comprises two Premises. When each Premise of a Condition is inferred as true, the related Rule becomes enabled and it can activate its Action composed of entities called Instigation. In the considered Rule, the Action has one Instigation. In fact, Instigations are linked to Methods of FBEs to execute services. In the Action of that Rule, the Method Activate_Alarm() is instigated. Commonly, instigating a Method of an FBE changes the values of Attributes [24][25].

Figure 1 .

 1 Figure 1. (a) The Representation of a NOP Rule. (b) NOP Components and Notification Chain. The NOP inference process is innovative. Indeed, the Rules do not become enabled by matching Attribute values by means of some usual search approach, but by evaluating their Conditions when they are notified by FBEs that Attributes' values changed. Inference happens in the following way: for each change in an Attribute value of a FBE, based on the new value, just the very pertinent Premises are notified and make its logical analysis; for each change in a Premise logical state, it notify just the very pertinent Conditions. In turn, Conditions enable new Rules that may execute Actions by notifying Instigations which in turn execute Methods of FBEs. The collaboration between NOP elements by means of notifications is illustrated in Figure 1 (b). This notification chain is created during the software compilation phase [24][25].

Figure 2 .

 2 Figure 2. Notation used for drawing systems requirements models.

Figure 3 .

 3 Figure 3. System requirement model example.

Figure 4 .

 4 Figure 4. Model of the SS11-a requirement.

Figure 5 .

 5 Figure 5. Model of SS11-a and SS11-b requirements. Requirement SS11-c: This requirement adds a new time constraint with respect the secure checking of ID and BIO. It leads to a new functional request involving checking the elapsed time between the ID and BIO secure checking. It also sets new conditions for enabling or disabling access and establishes two new Attributes for the current system time (Cur_Time) and system configured time period (Conf.Period). This way a new Rule (Check Elapsed Time) and two new FBEs (System Clock and System Config) are inserted in the model as illustrated in Figure 6. Requirement SS11-d and Requirement SS11-e:

Figure 6 .

 6 Figure 6. Final system requirements model.

  To merge FBEs and Rules with analogous FBEs and Rules previously created.

	vi. Identifying the FBEs related to the Attributes for the request.
	vii. Identifying the FBEs related to the Methods indicated by the request.
	2. To create a Rule for every request identified in step 1.
	3. To create a FBE for every entity identified in step 1.
	4. To create links (i.e. notifications between Rules and FBEs according to the
	Conditions and Actions related to rules) identified in step 1
	5.
		precondition	requirement to be met Identification of the <<Rule>>	post condition	call ID	<<FBE>> Element ID	attribute
			(a) Rule notation			(b) FBE notation
	<<FBE>> Element ID	attribute	precondition expression	requirement to be met <<Rule>> Identification of the	requirement to be met <<Rule>> Identification of the	post condition call	<<FBE>> Element ID
	(c) Precondition notification notation		(d) Post condition notification notation

Corresponding Author. Jean Marcelo Simão -UTFPR <jeansimao@utfpr.edu.br>

International Council on Systems Engineering, http://www.incose.org

Acknowledgement

This research was partially supported by CAPES (Coordenação de Aperfeiçoamento de Pessoal de Nível Superior) from Brazil.


Gabriel S S Leal

Wided Guédria

Hervé Panetto

Wided Guedria

Mario Lezoche

Towards a comparative analysis of interoperability assessment approaches for collaborative enterprise systems

Keywords: Networked Enterprise, Transdisciplinary, Collaborative Enterprise System Interoperability, Interoperability Assessment

Towards a comparative analysis of interoperability assessment approaches for collaborative enterprise systems

Introduction

Nowadays, the dynamics of the socio-economic environment leads enterprises to face a variety of challenges such as globalization, new technologies, financial crisis, new markets, etc. These challenges are change-drivers that require transformation within enterprises and their environments [START_REF] Proper | Enterprise Architecture: Informed steering of enterprises in motion[END_REF]. To deal with that, enterprises are progressively shifting their boundaries and collaborating with other companies and participating in a so-called Networked Enterprise (NE) [START_REF] Leal | Towards a Meta-Model for Networked Enterprise[END_REF]. The companies that compose a NE can have different sizes (e.g. small, medium and large enterprises), they can be geographically distributed (e.g. collaborations between regional, national and international enterprises), and also can be field-specific enterprises (e.g. a NE composed by only marketing agencies) or transdisciplinary enterprises [START_REF] Curran | Transdisciplinary Lifecycle Analysis of Systems[END_REF] (e.g. collaboration among different disciplines such as marketing, production engineering, financial, healthcare, etc.). Considering this collaborative and transdisciplinary context, i.e. NE context, and based on [START_REF] Curran | Transdisciplinary Lifecycle Analysis of Systems[END_REF], [START_REF] Figay | Resolving Interoperability in Concurrent Engineering[END_REF], [START_REF] Verhagen | Challenges of CE[END_REF], [START_REF] Chen | Architectures for enterprise integration and interoperability: past, present and future[END_REF], [START_REF] Panetto | Towards a Classification Framework for Interoperability of Enterprise Applications[END_REF], we argue that one of the difficulties enterprises may face, regarding effective collaboration, is the development of interoperability among their collaborative enterprise systems (CESs). The term CESs, in this paper, represents the enterprise systems that collaborate with systems from other enterprises within the NE.

In light of this, the Networked Enterprise meta-MOdel (NEMO) [START_REF] Leal | Towards a Meta-Model for Networked Enterprise[END_REF] has been proposed to address the importance of the interoperability within a NE, describing it as a crucial requirement that needs to be verified when starting a new collaboration [START_REF] Mallek | The application of interoperability requirement specification and verification to collaborative processes[END_REF], [START_REF] Roque | Interoperability in Collaborative Processes: Requirements Characterisation and Proof Approach[END_REF]. As soon as this requirement is not achieved, interoperability becomes a problem that must be solved [START_REF] Naudet | Towards a systemic formalisation of interoperability[END_REF]. Interoperability problems are mainly related to incompatibilities that obstruct the sharing and exchanging of any kind of information, but mainly contextual information, between CESs [START_REF]ISO: Advanced automation technologies and their applications -Part 1: Framework for enterprise interoperability[END_REF]. To deal with this kind of problem, specific evaluations can be performed to have a clear view about strengths and weaknesses of the considered NE in terms of interoperability, at an early stage [START_REF] Leal | Towards a Meta-Model for Networked Enterprise[END_REF]. Numerous methods and approaches have been proposed in the literature regarding interoperability assessment [START_REF]C4ISR Architecture Working Group Final Report -Levels of Information System Interoperability (LISI)[END_REF], [START_REF] Clark | Organizational interoperability maturity model for c2[END_REF], [START_REF] Tolk | The levels of conceptual interoperability model[END_REF], [START_REF]Framework for the Establishment and Management Methodology[END_REF], [START_REF] Guédria | Maturity model for enterprise interoperability[END_REF], [START_REF] Doumeingts | Decision modelling GRAI grid[END_REF], [START_REF]methods for testing and specification (MTS), automated interoperability testing, methodology and framework[END_REF], [START_REF] Ford | The Interoperability Score[END_REF], [START_REF]Guidelines and Best Practices for Applying the ATHENA Interoperability Framework to Support SME Participation in Digital Ecosystems[END_REF], [START_REF] Yahia | Formal measures for semantic interoperability assessment in cooperative enterprise information systems[END_REF], [START_REF] Lezoche | Conceptualising and structuring semantics in Cooperative Enterprise Information Systems Models[END_REF], [START_REF] Fu | Analysis of interacting BPEL web services[END_REF], [START_REF] Papakonstantinou | Incremental validation of XML documents[END_REF]. Some surveys can be found in [START_REF] Panetto | Towards a Classification Framework for Interoperability of Enterprise Applications[END_REF], [START_REF] Guedria | Interoperability maturity modelssurvey and comparison[END_REF] and [START_REF] Ford | Interoperability Measurement[END_REF].

Among these methods and approaches, three kinds of interoperability measurements can be identified [START_REF] Guédria | Maturity model for enterprise interoperability[END_REF], [START_REF] Chen | An Approach for Enterprise Interoperability Measurement[END_REF]: the measurement performed (1) before the interoperation starts and when partners are unknown; (2) before the interoperation starts and when partners are known; and (3) during the interoperation between two known partners. This latter measurement is out of scope of this paper, because it is performed only during interoperation, meaning that it is too late to identify interoperability problems at this stage. To our best knowledge, despite the variety of these evaluation methods, none addresses both (1) and (2) types of measurements at the same time, considering all interoperability aspect [START_REF]ISO: Advanced automation technologies and their applications -Part 1: Framework for enterprise interoperability[END_REF]. Therefore, identifying interoperability aspects to be assessed, and the related key features is mandatory to support the NE interoperability development, including the detection and prediction of problems at early stage. Thus, the following questions are raised: "How can we assess the interoperability of CESs within a collaborative and transdisciplinary context, when dealing with different interoperability aspects?" and "Which method(s) is (are) to be chosen in this context?"

The objective of this paper is to propose a comparative analysis of the main relevant evaluation methods regarding interoperability. This needs, first of all to identify evaluation criteria to be taken into account, considering the related works and the context of our research. The proposed analysis is essential and will serve as a first step towards proposing a new approach for assessing CESs interoperability within a NE.

The rest of the scientific paper is organised as follow -Section 1 presents the relevant related works on interoperability within a NE. Section 2 shows the analysis of interoperability evaluation methods. Also in this section the findings are discussed and some perspectives highlighted. The conclusion and future work are brought forward in Section 3.

Related Work

This section gives an overview of the NEMO meta-model, highlighting the core concepts of NE and interoperability, as well as, relationships between them. This overview leads to identify the main properties that need to be considered when assessing interoperability. Thereafter, related works on interoperability assessment are presented.

NEMO: Networked Enterprise Meta-Model

NEMO [START_REF] Leal | Towards a Meta-Model for Networked Enterprise[END_REF] aims at providing a common understanding of the NE and interoperability concepts, based on a systemic approach. It defines a NE as: "a system composed of at least two autonomous systems (enterprises) that collaborate during a period of time to reach a shared objective". This meta-model considers two views of interoperability: as a requirement that needs to be met when at least two systems are willing to collaborate together and as a problem when this requirement is not fulfilled. Figure1 gives a simplified view of NEMO and its main elements. More details can be found in [START_REF] Leal | Towards a Meta-Model for Networked Enterprise[END_REF].

Figure1. Simplified view of NEMO elements [START_REF] Leal | Towards a Meta-Model for Networked Enterprise[END_REF] In order to better describe the interoperability concept and its elements within a NE, NEMO is based on the interoperability dimensions, previously defined by the Ontology of Enterprise Interoperability [START_REF] Naudet | Towards a systemic formalisation of interoperability[END_REF] and the Framework for Enterprise Interoperability [START_REF]ISO: Advanced automation technologies and their applications -Part 1: Framework for enterprise interoperability[END_REF]. Here, we present the two most important concepts that will be considered in the analysis of section 3. The first one is the interoperability aspects which describes the different facets of interoperability. The second concept is interoperability barriers representing the related problems. The considered interoperability aspects and related barriers are: 1) Conceptual interoperability deals especially with knowledge and information sharing among CESs [START_REF]EIF European Interoperability Framework[END_REF]. Hence, Conceptual barriers are concerned with the syntactic and semantic incompatibilities of information to be exchanged between CESs [START_REF]ISO: Advanced automation technologies and their applications -Part 1: Framework for enterprise interoperability[END_REF]. 2) Technical interoperability covers the technical issues of linking computer systems and services. [START_REF]EIF European Interoperability Framework[END_REF]. Thus, the Technical barriers are concerned with the lack of compatible ICT platforms and standards allowing the use of heterogeneous computing techniques for sharing and exchanging information between two or more CESs [START_REF]ISO: Advanced automation technologies and their applications -Part 1: Framework for enterprise interoperability[END_REF]. 3) The Organizational interoperability deals with bringing collaboration capabilities to enterprises that wish to exchange information and may have different internal structures and processes [START_REF]EIF European Interoperability Framework[END_REF]. Compliance to legislation [START_REF]EIF European Interoperability Framework[END_REF], [START_REF] Zharova | Influence of the principle of interoperability on legal regulation[END_REF] is also considered in this context. Consequently, Organizational barriers are concerned with the incompatibilities of organisation structure, management techniques and legal issues implemented in two or more enterprises [START_REF]ISO: Advanced automation technologies and their applications -Part 1: Framework for enterprise interoperability[END_REF]. It is worth noting that interoperability is a not-bidirectional property [START_REF] Yahia | Formal measures for semantic interoperability assessment in cooperative enterprise information systems[END_REF]. Given two entities A and B and measuring their interoperability level I(x,y) it is structurally coherent to find 𝐼(𝐴, 𝐵) ≠ 𝐼(𝐵, 𝐴) . This structural property doesn't impact the evaluated methods because of its internal feature but it explains the behavioural aspects of the approached property concepts.

Related works on Interoperability Assessment

To support enterprise members of a NE to better interoperate, the interoperability between their CESs requires being assessed and continuously improved [START_REF] Guédria | Maturity model for enterprise interoperability[END_REF]. According to [START_REF] Guédria | Maturity model for enterprise interoperability[END_REF] interoperability assessment methods can be classified based on four properties; (a) the type of interoperability assessment, which are Levelling (defining a basic set of interoperability maturity levels that CESs can achieve) or Non-levelling (not using the maturity model approach). (b) The used measure, which are Qualitative (Subjective methods defined by the general criteria of the CESs evaluation) or Quantitative (Methods that define numeric values to characterise the interoperations between CESs). (c) The used approach, which are Black Box (Methods considering mainly the analysis of the CESs inputs and outputs without worrying about their properties and interactions) or White Box (Methods where the concept for which input-output mappings, the transformation structure as well as the state of the CESs are known). (d) The application context, which can be a priori or a posteriori. The a priori context uses the potentiality measurement which relates to the potential of a CES to be interoperable with a possible future partner whose identity is not known at the moment of evaluation. The a posteriori application context uses two measures: (i) the compatibility measurement is done concerning the identified barriers to interoperability. This measure can only be performed when the two CESs of the interoperation are known. (ii) The performance measurement is to be done during the test or operation phase of two interoperating CESs. As asserted in the introduction, this latter type of measurement is not considered in this paper. Although, it is worth noting that this kind of measurement is relevant when the enterprises want to validate their potential measures i.e. to verify if the potential measures are aligned and coherent with the real ones.

The next section introduces the existing methods and approaches that deal with the interoperability assessment.

Overview on Interoperability Assessment Methods

A variety of assessment methods can be found in the literature. Many of them are defining a maturity model which consists in a framework that describes, for a specific area of interest, a number of levels of sophistication at which activities in this area can be carried out [START_REF] Alonso | Enterprise Collaboration Maturity Model (ECMM): Preliminary Definition and Future Challenges[END_REF]. The main existing interoperability maturity models are the Levels of Information System Interoperability (LISI) maturity model [START_REF]C4ISR Architecture Working Group Final Report -Levels of Information System Interoperability (LISI)[END_REF], the Organisational Interoperability Maturity Model (OIMM) [START_REF] Clark | Organizational interoperability maturity model for c2[END_REF], the Levels of Conceptual Interoperability Model (LCIM) [START_REF] Tolk | The levels of conceptual interoperability model[END_REF], the Enterprise Interoperability Maturity Model (EIMM) [START_REF]Framework for the Establishment and Management Methodology[END_REF] and the Maturity Model for Enterprise Interoperability (MMEI) [START_REF] Guédria | Maturity model for enterprise interoperability[END_REF]. Besides these maturity models, we have identified other methods such as: the GRAI Grid [START_REF] Doumeingts | Decision modelling GRAI grid[END_REF], the European Telecommunication Standards Institute (ETSI) method [START_REF]methods for testing and specification (MTS), automated interoperability testing, methodology and framework[END_REF], the layered interoperability score (i-Score) [START_REF] Ford | The Interoperability Score[END_REF], the Enterprise Interoperability Degree Measurement (EIDM) compatibility matrix [START_REF]Guidelines and Best Practices for Applying the ATHENA Interoperability Framework to Support SME Participation in Digital Ecosystems[END_REF], the Yahia et al. [START_REF] Yahia | Formal measures for semantic interoperability assessment in cooperative enterprise information systems[END_REF] approach based on semantic blocks [START_REF] Lezoche | Conceptualising and structuring semantics in Cooperative Enterprise Information Systems Models[END_REF] and some ICT standard validation methods [START_REF] Fu | Analysis of interacting BPEL web services[END_REF], [START_REF] Papakonstantinou | Incremental validation of XML documents[END_REF].

In the next section we aim at analysing the evaluation methods, taking into account all the properties and interoperability aspects identified on the previous sections.

Analysis of interoperability assessment methods

The objective of this section is not to provide an exhaustive review of existing assessment methods, but rather it is to present relevant methods that are selected specifically for the purpose of the analysis. The analysis considers some of the already reviewed methods in [START_REF] Panetto | Towards a Classification Framework for Interoperability of Enterprise Applications[END_REF], [START_REF] Guedria | Interoperability maturity modelssurvey and comparison[END_REF], [START_REF] Ford | Interoperability Measurement[END_REF], as well as other and more recent evaluation methods. We intend to identify how these evaluation methods are performing interoperability assessment in CESs. This will allow us to verify if these methods address both considered types of measurement (i.e. before and after knowing interoperation partner(s)) and their coverage in terms of interoperability aspects. First, we identify the evaluation criteria and the evaluation methods to be analysed. Furthermore, the analysis considering the identified criteria and methods is performed. Based on that, findings and perspectives are discussed at the end of this section.

Criteria identification

The criteria identified in this section are based on the interoperability assessment domain.

The following criteria were chosen because they often appear when describing an interoperability evaluation method. The first considered criterion is the interoperability aspect. This criterion is related to the interoperability level(s) addressed by the evaluation method(s), i.e. conceptual, technical or/and organisational interoperability. The second criterion is based on the method properties described in section 1.2. It regards the type of interoperability assessment (in this paper we will call it as structure property), the used measures, the used approach and the type of interoperability measurements. Considering the structure property, a method can be a Levelling or a Non-levelling method. Taking into account the used measure property, a method can be described as a Qualitative or a Quantitative method. Considering the used approach property, methods can be described as Black Box or White Box methods. For the last property, we will call it "type of interoperability measurement" instead of "application context". Thus, we will identify which type of measurement the methods adopt rather than classify as a priori or a posteriori. The two considered type are: (1) the measurement before any interoperation starts and the partner(s) is (are) unknown; (2) before any interoperation stars and partner(s) is (are) are known.

Selected evaluation methods

The LISI maturity model [START_REF]C4ISR Architecture Working Group Final Report -Levels of Information System Interoperability (LISI)[END_REF], OIMM [START_REF] Clark | Organizational interoperability maturity model for c2[END_REF] and LCIM [START_REF] Tolk | The levels of conceptual interoperability model[END_REF] are chosen because they cover the technical, organisational and conceptual interoperability aspects respectively. The EIMM [START_REF]Framework for the Establishment and Management Methodology[END_REF] is included in this analysis because it brings forward the enterprise domain, focusing mainly on the organisational aspect. MMEI [START_REF] Guédria | Maturity model for enterprise interoperability[END_REF] is selected because it is based on the previous maturity models and covers all aspects of interoperability. Beside these maturity models, we also include the GRAI Grid [START_REF] Doumeingts | Decision modelling GRAI grid[END_REF] that identify organisational incompatibilities. Furthermore, the ETSI method [START_REF]methods for testing and specification (MTS), automated interoperability testing, methodology and framework[END_REF] and the ICT standards validation methods such as [START_REF] Fu | Analysis of interacting BPEL web services[END_REF], [START_REF] Papakonstantinou | Incremental validation of XML documents[END_REF] are also included in the analysis because they deal mainly with the technical interoperability evaluation. Finally, the i-Score [START_REF] Ford | The Interoperability Score[END_REF], the EIDM compatibility matrix [START_REF]Guidelines and Best Practices for Applying the ATHENA Interoperability Framework to Support SME Participation in Digital Ecosystems[END_REF] and the Yahia et al. approach [START_REF] Yahia | Formal measures for semantic interoperability assessment in cooperative enterprise information systems[END_REF] are included in this analysis because they are quantitative methods.

Analysis considering the Interoperability aspects

The LISI maturity model covers only the technical interoperability between CESs. Considering its limitations, LISI was extended by OIMM and LCIM to cover the organisational and conceptual aspects respectively. LCIM intend to link the technical and conceptual CESs design. EIMM deals with enterprise modelling assessments, which mainly concerns organisational and conceptual interoperability aspects. It focuses on the use of CES models and the maturity of their usage, which requires a correct syntactic and semantic representation [START_REF]Framework for the Establishment and Management Methodology[END_REF]. Among the reviewed levelling methods, MMEI is the only covering all interoperability aspects [START_REF] Guédria | Maturity model for enterprise interoperability[END_REF], because it is based on the others presented maturity models. Besides these maturity models, we find other methods covering different aspects of interoperability such as the GRAI Grid that focuses on the decisional aspects of the management of CESs, i.e. it deals with organisational interoperability. The ETSI method covers conceptual and technical interoperability as it is designed to check the CESs standards interoperability and conformity. The i-Score addresses the evaluation of organizational processes interoperability. The EIDM compatibility matrix covers all interoperability aspects. However, it does not give a deeper insight on them. The Yahia et al. [START_REF] Yahia | Formal measures for semantic interoperability assessment in cooperative enterprise information systems[END_REF] approach assesses the conceptual interoperability between two CESs. It focuses on the semantic part of it. Finally, the ICT standards validation methods [START_REF] Fu | Analysis of interacting BPEL web services[END_REF], [START_REF] Papakonstantinou | Incremental validation of XML documents[END_REF] cover the technical interoperability and the syntactic issues from the conceptual interoperability. Table 2 summarises the coverage of the reviewed methods with regard to interoperability aspects.

Table 2. The coverage of the reviewed methods with regards to interoperability aspects. The '++' means "addresses the aspect", "+" stands for "relevant to the aspect" and '-' is for "do not addresses the aspect". Inspired from [

Analysis considering the method structure, measures and approach

Considering the structure-property, all the reviewed maturity models are levelling methods. The other approaches are non-levelling ones. Taking into account the used measure-property, the maturity models are considered qualitative methods. In general, they mainly define a five maturity levels' scale, where the lower level represents an adhoc and chaotic interoperation and the higher level represents a fully and effective interoperation. The intermediary levels represent the progression levels which CESs must pass through to achieve the higher level. Moreover, the GRAI Grid, ESTI method and the ICT standards validation methods [START_REF] Fu | Analysis of interacting BPEL web services[END_REF], [START_REF] Papakonstantinou | Incremental validation of XML documents[END_REF] are also considered qualitative methods. GRAI grid provides, as a result, a graph with all decision centres and information flow within the analysed CESs [START_REF] Doumeingts | Decision modelling GRAI grid[END_REF]. The ICT standards validation methods [START_REF] Fu | Analysis of interacting BPEL web services[END_REF], [START_REF] Papakonstantinou | Incremental validation of XML documents[END_REF] provide binary results, i.e. the standard is valid or not. The ETSI method [START_REF]methods for testing and specification (MTS), automated interoperability testing, methodology and framework[END_REF] uses verdicts to classify if the CESs' test results are inconclusive, failed or successful. Furthermore, the identified quantitative methods are: the i-Score, EIDM compatibility matrix and the semantic interoperability approach of Yahia et al. [START_REF] Yahia | Formal measures for semantic interoperability assessment in cooperative enterprise information systems[END_REF]. Indeed, the assessment output of the i-Score is a real number ranging from 0 to 1, where 1 represents the CESs full interoperability. The EIDM approach provides a matrix with 24 interoperability areas where the value "1" is attributed when an incompatibility is found. The degree of compatibility is given by the sum of incompatibilities found, where "0" means higher compatibility and "24" poorest compatibility between the considered CESs. The Yahia et al. approach [START_REF] Yahia | Formal measures for semantic interoperability assessment in cooperative enterprise information systems[END_REF] provides two measures, calculating the potential and effective interoperability. It can also provide a qualitative result, i.e. it organises the numeric values into three categories: "0%" means "systems are not interoperable"; "0 <x< 100%" means "systems are partially interoperable" and 100% stands for "systems are fully interoperable". According to the used approach property, the only methods using the white box perspective are MMEI, the GRAI grid, the Yahia et al. approach [START_REF] Yahia | Formal measures for semantic interoperability assessment in cooperative enterprise information systems[END_REF] and ICT standards validation methods [START_REF] Fu | Analysis of interacting BPEL web services[END_REF], [START_REF] Papakonstantinou | Incremental validation of XML documents[END_REF]. These methods verify in-depth the different relations within the CESs elements, unlike the others (i.e. LISI, LCIM, OIMM, EIDM Compatibility Matrix and i-Score) that only use the black box approach. Table 3 summarises the analysis of the method properties and presents the value scales and metrics used by each assessment method.

Analysis considering the interoperability measurement

According to the type of interoperability measurement, we identify the following methods measuring interoperability after enterprises knowing their partner(s) : LISI, OIMM, LCIM, EIMM, ETSI method, i-Score, EIDM compatibility matrix, Yahia et al. [START_REF] Yahia | Formal measures for semantic interoperability assessment in cooperative enterprise information systems[END_REF] approach and finally the ICT standards validation methods [START_REF] Fu | Analysis of interacting BPEL web services[END_REF], [START_REF] Papakonstantinou | Incremental validation of XML documents[END_REF]. All these methods are capable to assess interoperability when two or more CESs within a NE are known. Moreover, we identify the following methods measuring interoperability before enterprises knowing their partner(s): MMEI and GRAI Grid. Both approaches are designed to assess the enterprises and its CESs capabilities without knowing their future partners. While not their focus, LISI and EIMM can also measure interoperability before interoperation partners are known. Indeed, LISI provides a matrix to calculate the potential technical interoperability of a given ICT system; EIMM states that an enterprise to achieve the maturity level 4 requires dynamic interoperability and adaptation without considering a specific partner. Table 3 also summarises the analysis of the mentioned types of measurements.

Table 3. Analysis of interoperability assessment methods. Where "S" means Structure, "M" means Measure and "A" means Approach. "L" stands for Levelling and "NL" for Non-Levelling. "WB" stands for White Box and "BB" for Black Box. "Qn" stands for Quantitative Method and "Ql" for Qualitative Method. "(1)" stands for "before knowing interoperation partner(s)" and "(2)" stands for "after knowing interoperation partners". The '++' means "addresses the aspect", "+" stands for "relevant to the aspect" and '-' is for "do not addresses the aspect". Inspired on [ The analysis of these methods, allows us to identify their similarities and differences and which assessment type they prioritize. These findings will serve as a basis for the development of an assessment approach for CESs interoperability in the NE context.

Discussion

In order to achieve objectives targeted by a NE and its members, the CESs interoperability management, including the identification of problems, is a necessity. A simpler manner to avoid interoperability problems and consequently corrective actions, is to predict and solve potential problems before they occur [START_REF] Guédria | Maturity model for enterprise interoperability[END_REF]. For that, NE and its members need to plan and be prepared for future interoperations. To this end, enterprises can benefit from the application of an interoperability assessment method. However, as we can observe based on the analysis, MMEI is the only method that sufficiently covers all conceptual, technical and organisational interoperability aspects. Although, it performs only the interoperability measurement before partner are known. We have also found that the majority of the reviewed methods are measuring interoperability after interoperation partners are known, but they deal with a particular aspect of interoperability. Hence, we can assert that there is no method dealing with all interoperability aspects and addressing both types of measurements. Based on that, we propose to elaborate an assessment approach for CESs interoperability. This approach will be developed to be applied in the Networked Enterprise context, regardless the enterprise members' size, discipline, location, etc. It will deal with types of measurements. It will also cover the main aspects of existing maturity models and nonlevelling methods, combining qualitative and quantitative metrics to consider both subjective and objective values. We intend to use a white box view to consider the different interactions and variables of the CESs to be assessed.

Conclusion and Future work

In this paper, we have proposed a comparative analysis of the main relevant evaluation methods regarding the CESs interoperability. Prior to that, an investigation about the relations between interoperability and Networked Enterprise contexts has been done. This allowed the identification of what need to be verified during an interoperability assessment, when considering the different interoperability aspects and its related barriers. Moreover, the identification of the method properties including the different types of measurements has been used to analyse current evaluation methods dealing with multiple interoperability levels. Based on this analysis, we observed that there is no evaluation method addressing sufficiently both considered types of measures as well as not covering all interoperability aspects. As future work, we intend to propose an interoperability assessment approach for CESs covering all interoperability aspects as well as both considered types of measurements. This will be tackled by the extension of MMEI to both considered types of measurement contexts. Quantitative methods will also be used to provide objective results. Furthermore, combining this CES interoperability assessment approach with NEMO, will allow us to build a Framework for Networked Enterprise Interoperability. The NEMO approach has been chosen because deals with all interoperability aspects (c.f. section 1.1) and it covers the two contexts (1) the unknown partners and (2) the known ones. This framework will serve as basis to the development of a decision-support system for preventing and solving Collaborative Enterprise Systems Interoperability problems in a collaborative and transdisciplinary context.

  [START_REF] Guédria | Maturity model for enterprise interoperability[END_REF]

	Name	Conceptual Semantic Syntatic Standard Platform Organisation Legal Technical Organisational
	LISI	-	-	++	++	-	-
	OIMM	+	-	-	-	++	-
	LCIM	++	+	-	-	-	-
	EIMM	++	+	-	-	++	+
	MMEI	++	++	++	++	++	+
	GRAI Grid	-	-	-	-	++	-
	ETSI method	-	+	++	++	-	-
	I-Score	-	-	-	-	++	-
	EIDM -C. Matrix	+	+	+	+	+	-
	Yahia et al. approach	++	-	-	-	-	-
	ICT Standards validation	-	++	++	++	-	-

Gabriel da Silva Serapião Leal, Université de Lorraine/CNRS, CRAN UMR 7039, Boulevard des Aiguillettes, B.P. 70239 F-54506 Vandoeuvre-lès-Nancy, France. Email : gabriel.da-silva-serapiao-leal@univlorraine.fr

Acknowledgements

This work has been conducted in the context of the PLATINE project (PLAnning Transformation Interoperability in Networked Enterprises), financed by the national fund of research of the Grand Duchy of Luxembourg (FNR), under the grant C14/IS/8329172.