Toinon Vigier
email: toinon.vigier@univ-nantes.fr

Josselin Rousseau
email: josselin.rousseau@univ-nantes.fr

Matthieu Perreira
email: matthieu.perreiradasilva@univ-nantes.fr

Da Silva

Patrick Le Callet
email: patrick.lecallet@univ-nantes.fr

A new HD and UHD video eye tracking dataset

Keywords: CCS Concepts, Information systems → Multimedia databases, •General and reference → Evaluation, Eye tracking, video, UHD

The emergence of UHD video format induces larger screens and involves a wider stimulated visual angle. Therefore, its effect on visual attention can be questioned since it can impact quality assessment, metrics but also the whole chain of video processing and creation. Moreover, changes in visual attention from different viewing conditions challenge visual attention models. In this paper, we present a new HD and UHD video eye tracking dataset composed of 37 high quality videos observed by more than 35 naive observers. This dataset can be used to compare viewing behavior and visual saliency in HD and UHD, as well as for any study on dynamic visual attention in videos. It is available at http://ivc.

INTRODUCTION

UHD TV standard defines new video technologies as an increasing resolution from HD (1920 × 1080) to UHD, i.e. 4K (3840 × 2160) or 8K (7680 × 4320). The emergence of UHD potentially provides a better immersion of the user thanks to a wider visual angle with appropriate larger screens [START_REF] Bt | Parameter values for ultra-high definition television systems for production and international programme exchange[END_REF]. Indeed, ITU defines the optimal viewing distance as the dis-Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.

MM'Sys '16 Klagenfurt am Wörthersee, Austria

© 2016 ACM. ISBN 123-4567-24-567/08/06. . . $15.00 DOI: 10.475/123 4 tance at which scanning lines just cannot be perceived with visual acuity of 1'. It is thus set to 3H for HD and 1.5H for 4K-UHD where H is the height of the screen [START_REF] Bt | Parameter values for an expanded hierarchy of LSDI image formats for production and international programme exchange[END_REF]. Figure 1 shows the increase of stimulated visual angle along with a better resolution. This increase of resolution and stimulated visual angle can modify visual attention deployment and visual patterns of people looking at HD and UHD videos. Visual attention is a widely developed topic for many years, which finds a variety of applications as image and video compression, image and video objective quality metrics, computer vision and robotics, eye controlled display, attentionbased video content creation, etc. In these applications, visual attention can be directly studied from gaze data tracked in subjective experiments or predicted using visual saliency models based on top-down or bottom-up factors. However, these prediction models most often elude viewing conditions. Therefore, the changes of viewing conditions in the transition from HD to UHD raise several issues on the impact of visual attention deployment and viewing behavior in videos, and on the performance of visual saliency models. Eye tracking experiments can provide very useful information to tackle these issues. In this paper, we propose a new eye tracking dataset in HD and 4K UHD of 37 high quality videos observed by more than 35 naive observers. The rest of this paper is organized as follows. Section 2 describes two related datasets on visual attention in UHD. Section 3 presents a new eye tracking setup adapted to UHD viewing conditions and used to create our dataset. Section 4 describes the proposed dataset. Section 5 gives dataset usage for future research works. Section 6 concludes the paper. In the following, UHD exclusively refers to 4K resolution.

HD

H α ≈ 30 • α 3 × H UHD H α ≈ 60 • α 1 . 5 × H

RELATED DATASETS

To our knowledge, only two recent datasets are used to study the effect of transition from HD to UHD on visual attention [9, 10, 7].

Ultra-eye

Ultra-eye is a publicly accessible dataset composed of 41 UHD and HD images [10]. HD images are downsampled from UHD with Lanczos filter. For each image, the dataset provides the list of fixation points and the fixation density maps. Eye movement data are recorded with the Smart Eye eye tracker using 20 naive subjects in two session (UHD then HD or HD then UHD). Images were presented in random order during 15 seconds in a test laboratory which fulfills the ITU recommendations. The viewing distance was respectively 1.6H and 3.2H, in UHD and in HD. From the eye tracking data, the authors pointed out that viewing strategy and visual attention are significantly different in these two cases: UHD images can grab the focus of attention more than HD images. Moreover, several models of visual saliency were compared in HD and UHD scenarios, showing a reduction of model performance in UHD [9]. However, viewing behavior in video differs from static images, preventing the straightforward use of these observations for dynamic content.

UHD video saliency dataset of Shangai University

To our knowledge, the first and unique UHD video saliency dataset was published in [START_REF] Li | Ultra high definition video saliency database[END_REF]. These data come with a comparison of viewing behavior in UHD and HD scenarios. Eye movement data were recorded with the Tobii Eye-tracker X120 using 20 naive subjects in two sessions (UHD then HD). Fourteen videos of the SJTU 4K video sequences were used in native format (UHD) and downscaled to HD [11].

To analyze the gaze data, the new concept of aggregation maps (AGM) was introduced. It consists in the aggregation of all fixation points of one viewer for a video sequence in a unique map. With the AGM, an aggregation score (AGS) was computed which is an indicator of fixation concentration at the center of the screen. Thus, it was shown that viewer attention was more focused on the center of the screen in HD context. However, the viewing distance in UHD and HD was constant, equal to 3H. It does not comply with ITU recommendations and stimulated visual angle is unchanged. Moreover, the fact that people always started with UHD scenario can skew the results because of memorization. Therefore, we propose to construct a new HD/UHD visual attention video dataset regarding ITU recommendations.

THE EYE HEAD TRACKER: A NEW EYE TRACKING SYSTEM FOR UHD

In this section we present a new eye tracking system adapted to large stimulated visual angle and used in our new dataset.

Description of EHT

Because of the larger stimulated visual angle in UHD, observers can need to move more their head and eye tracking systems may not be accurate enough at the edges of the screen. We developed a new setup to address this issue: the Eye Head Tracker (EHT). EHT is a combination of the mobile SMI eye tracking glasses and of the head tracker OptiTrack ARENA. We implemented an application which collects these two data in order to provide the gaze position in the screen plane as it is explained in Figure 2. The EHT frequency is 30 Hz in binocular mode.

Evaluation of EHT

This setup was internally evaluated on 21 viewers along with two other systems: the remote SMI RED and the SMI Hi-Speed (HS) on a 65" UHD TV Panasonic TX-L65WT600E. The viewing distance was 1.5H, i.e. 120 cm. During the test, observers looked successively at 22 points displayed on the screen for two seconds. Performance of eye trackers was mainly assessed through three metrics:

Accuracy: euclidean distance (in visual angle) between measured point and display point on the screen.

Robustness: euclidean distance (in visual angle) between measured point and centroid of all measured points for one display point on the screen.

Recording rate: the ratio between real measured points and expected points (according to setup frequency). Figure 3 shows that EHT improves the number of recorded points mostly in border areas with a better robustness without loss of accuracy. To summarize, the advantages of the EHT are the non restriction of head movements, a large ocular field and a good accuracy at the edges.

DATASET DESCRIPTION

In this section, we describe the new HD and UHD video eye tracking dataset, freely available at http://ivc.univ-nantes. fr/en/databases/HD UHD Eyetracking Videos/.

Video content

The dataset is composed of 37 native UHD high quality video sequences from seven content provider: SJTU Media In HD, the original sequences were downscaled with Lanczos-3 algorithm which was proven as the best filter both in terms of performance and perceptual quality [START_REF] Li | Comparing upscaling algorithms from HD to Ultra HD by evaluating preference of experience[END_REF].

The frame rate of the original sequences varies from 25 to 120 fps. They were uniformly played frame by frame with 25 fps in our test, causing some movements to appear a bit slower than in reality. We did not use temporal downscaling methods because they often introduce more artifacts than the slowdown effect, particularly for non-integer ratios. Each source was cut to clips with a length of 8 to 12 seconds, producing a total of around 300 frames each. Spatial perceptual information (SI) and temporal perceptual information (TI), as described in ITU-T P.910 recommendation [START_REF]Subjective video quality assessment methods for multimedia applications[END_REF], were computed for each sequence and are shown Figure 4. The spatial and temporal information as well as number of frames and native frame rate of each video sequence are available on the website of the dataset.

Eye tracking experiments

Experimental setup

The experiment was conducted in a test environment set as a standard subjective quality test condition according to ITU-R BT.500 [START_REF]Methodology for the subjective assessment of the quality of television pictures[END_REF]. The HD display used was a 46" Panasonic Full HD Vieta and the 4K display used was a 65" Panasonic TX-L65WT600E. The viewing distance was 1.5H, i.e. 120 cm, in UHD and 3H, i.e. 170 cm, as recommended in ITU-R BT.1769 [START_REF] Bt | Parameter values for an expanded hierarchy of LSDI image formats for production and international programme exchange[END_REF]. We used the EHT eye tracker presented Section 2.

Observers

70 remunerated viewers participated in this subjective in two independent sessions for HD and UHD conditions. In HD, there were 17 males and 17 females, aged between 19 to 44 with an average age of 24.4 (SD = 5.08). In UHD, there were 18 males and 18 females, aged between 19 to 56 with an average age of 27.

Procedure

UHD and HD were assessed in two different sessions with different observers to avoid any effect of memorization. We adopted a free-looking approach in these experiments. Sequences were randomized for each observer. They were 2 seconds spaced out. The whole test lasted approximately 25 minutes.

Gaze data

For each video and each observer, the following gaze data are stored: eye identifier (0 for left eye and 1 for right eye) ; time (sec) ; eye position in X axis (px) ; eye position in Y axis (px). The origin (0,0) is in the upper left corner of the frame. If the eye was not tracked by the eye tracker, the X and Y positions are set as NaN.

The mean of successive left and right eye positions might be calculated to obtain binocular information.

Fixation points and saccades

A fixation is defined as the status of a region centered around a pixel position which was stared at for a predefined duration. A saccade corresponds to the eye movement from one fixation to another. Most often, saliency maps are computed from fixation points rather than gaze points. Thus, we extracted fixation points and saccades from the gaze data following the method explained in [12]. More precisely, fixations are detected according four parameters:

• the fixation velocity maximum threshold, set as 30°/s;

• the maximum time between separate fixations, set as 75 ms ;

• the maximum visual angle between separate fixations, set as 0.5°;

• the minimum fixation duration, set as 100 ms.

For each source, we provide the following data about fixations: starting time of fixation (ms) ; end of fixation (ms) ; fixation position in X axis (px) ; fixation position in Y axis (px) ; number of gaze points in the fixation ; observer number.

We also provide saccade data between fixations as follows: starting time of saccade (ms) ; end of saccade (ms) ; position of start of saccade in X axis (px) ; position of start of saccade in Y axis (px) ; position of end of saccade in X axis (px) ; position of end of saccade in Y axis (px) ; saccade length (px) ; saccade orientation (°) ; observer number.

DATA USAGE AND FUTURE WORKS

The main goal of this dataset is the comparison of visual attention and viewing behavior in HD and UHD. Different kind of analyses can be done: impact of viewing conditions and resolution on distribution of gaze points and fixations (Figures 9 and 10), comparison of saliency through fixation density maps (Figures 7 and8), comparison of distribution of saccades (Figures 5 and6), etc. Different indicators and metrics can be computed from these data as proposed in [START_REF] Meur | Methods for comparing scanpaths and saliency maps: strengths and weaknesses[END_REF],

in order to compare results in HD and UHD. Moreover, this dataset can be used to evaluate the performance of visual saliency models in HD and UHD, by comparing fixation density maps computed from acquired data with simulated saliency maps. Futhermore, this dataset provides useful data for any researcher working on dynamic visual attention in videos (dynamic visual attention modelling, visual attention and quality of experience, saliency-based video compression, etc.).

The main qualities of the dataset are the large number of sources and observers compared to previously published video saliency database, as well as the high quality of professional videos.

CONCLUSION

In this paper, we presented a new HD and UHD video eye tracking dataset on 37 high quality video sequences, respectively seen by 34 and 36 observers in HD and UHD. For each video sequence, gaze point, fixation and saccade data are provided.

The main objective of this dataset is the comparison of visual attention and viewing behavior in HD and UHD. Indeed, the emergence of UHD video format induces larger screens and involves a wider stimulated visual angle. Therefore, its effect on visual attention can be questioned since it can impact quality assessment, metrics but also the whole chain of video processing and creation. Thanks to the variety of video sequences and the large number of observers, these data can be really useful for any study on visual attention in videos.

Quality of

Figure 1 :

 1 Figure 1: The increase of stimulated visual angle from HD to UHD.

  (a) EHT operating scheme. (b) EHT setup in the viewing environment.

Figure 2 :

 2 Figure 2: The Eye Head Tracker.

Figure 3 :

 3 Figure 3: Performance comparison of eye trackers. (Bars represent the standard errors.)

  Lab [11], Big Bug Bunny (Peach open movie project), Ultra Video Group, Elemental Technologies , Sveriges Television AB (SVT), Harmonic, Tears of steel (Mango open movie project).

Figure 4 :

 4 Figure 4: SI and TI of video sequences.

Figure 5 :Figure 6 :

 56 Figure 5: Polar distribution of saccades between 0 et 20°length in the whole video sequence Beauty. (Distributions are calculated following the method presented in [6].)

Figure 9 :

 9 Figure 9: Gaze points (red) and fixations (blue) for all observers (Big Bug Bunny, sequence 1, frame 40).

Figure 10 :

 10 Figure 10: Gaze points (red) and fixations (blue) for all observers (Big Bug Bunny, sequence 2, frame 100).

Figure 7 :

 7 Figure 7: Example of fixation density maps in HD and UHD. Video sequence News ProRes, frame 50.

Figure 8 :

 8 Figure 8: Example of fixation density maps in HD and UHD. Video sequence Traffic and Buildings, frame 150.

  French equivalent of Jaeger chart) for near vision. All the viewers had either normal or corrected-to-normal visual acuity. The Ishihara plates were used for color vision test. All of the 70 viewers passed the pre-experiment vision check.

7 (SD = 11.24). Correct visual acuity and color visions were assured prior to this experiment. The visual acuity tests were conducted with Monoyer chart for far vision and with Parinaud chart

(

  Multimedia Experience (QoMEX). IEEE, 2014. [9] H. Nemoto, P. Hanhart, P. Korshunov, and T. Ebrahimi. Impact of Ultra High Definition on Visual Attention. In Proceedings of the ACM International Conference on Multimedia -MM '14. ACM Press, 2014. [10] H. Nemoto, P. Hanhart, P. Korshunov, and T. Ebrahimi. Ultra-eye: UHD and HD images eye tracking dataset. In 2014 Sixth International Workshop on Quality of Multimedia Experience (QoMEX). IEEE, 2014. [11] L. Song, X. Tang, W. Zhang, X. Yang, and P. Xia. The SJTU 4K video sequence dataset. In 2013 Fifth International Workshop on Quality of Multimedia Experience (QoMEX). IEEE, 2013. [12] Tobii Technology. User Manual -Tobii Studio. 2014.

ACKNOWLEDGMENTS

This work is part of the UltraHD-4U project financed by the DGCIS through the European CATRENE program CAT111.


Emna Moones
email: emna.moones@irt-systemx.fr

Thomas Vosgien
email: thomas.vosgien@irt-systemx.fr

Lyes Kermad
email: l.kermad@iut.univ-paris8.fr

Mouloudi El

Abderrahman El Dafaoui

Nicolas Mhamedi

Figay

El Mouloudi Dafaoui
email: e.dafaoui@iut.univ-paris8.fr

Abderrahman El Mhamedi
email: a.elmhamedi@iut.univ-paris8.fr

Nicolas Figay
email: nicolas.figay@airbus.com

PLM Standards Modelling for Enterprise Interoperability: A Manufacturing Case Study for ERP and MES Systems Integration Based on ISA-95

Keywords: Enterprise Architecture, Enterprise Interoperability, Manufacturing PLM standards, ERP/MES, ISA-95

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

Introduction

Nowadays in order to remain competitive within a global economic context where the complexity of products is still increasing, enterprises have been developing new strategic approaches such as the PLM approach. PLM is defined, by CIMDATA [START_REF] Cimdata | About PLM -CIMdata[END_REF], as a strategic approach aiming at setting-up appropriate processes related to production and consumption of product data, all along the different product lifecycle phases and across the whole supply chain. Along the product lifecycle phases, enterprise business functions and processes are supported by different PLM solutions including the Information System (IS) such as Product Data Management (PDM) systems for design engineering activities and configuration management, ERP and MES for manufacturing, business planning and logistic operations. PLM solutions include PLM Hubs, such as BoostAerospace 1 . In such a context, efficient, agile and interoperable IS and interfaces are required in order to ensure the continuity, consistency and integrity of the different /shared exchanged product and process data.

Governance of standards, as addressed by ASD SSG 2 , is facing difficulties when elected eBusinessPLM standards and associated PLM standardization enterprise policies have to be applied. New challenges related to factories and support taking advantage of emerging technologies are also to be considered in order to support competitiveness of enterprises. To deal with the context of PLM standards and their complexity, the Standard and Interoperability PLM (SIP3 ) project was launched within the frame of the IRT-SystemX 4 . The adopted approach in this project is based on a federating framework for interoperability of technical enterprise applications [START_REF] Figay | Interoperability of Technical Enterprise Application[END_REF]. While different projects such as INTEROP[3] and ATHENA [START_REF]Interoperability Framework v2[END_REF] has addressed the interoperability of enterprise applications relying on a common Application Interoperability Framework (AIF), our approach also relies on a federative interoperability framework defined by [START_REF] Figay | Interoperability of Technical Enterprise Application[END_REF]. This framework defines a pragmatic methodology for preparing and building operational interoperability (as defined by System Of System Interoperability (SOSI) [START_REF] Morris | System of Systems Interoperability (SOSI): final report[END_REF]) at an acceptable price for Dynamic Manufacturing Network (DMN) [START_REF] Figay | Dynamic Manufacturing Network, PLM Hub and Business standards test bed[END_REF] [START_REF] Moones | Towards an extended interoperability systemic approach for Dynamic Manufacturing Networks : role and assessment of PLM standards[END_REF].

SIP project aims at extending the federative network by addressing new identified brakes, in particular the importance to be able to assess standards and their implementations to support DMN collaboration. It introduces and analyses the ArchiMate standard as a way to properly rely on enterprise modelling as a key enabler for dealing with the specification and simulation of DMN business collaboration scenarios in order to better prepare enterprise interoperability. The SIP methodology relies on the use of a test bed allowing execution and simulation of DMN models. The testbed is built on top of a collaborative platform constituting a hub for interconnection of technical enterprise applications. It integrates enterprise collaboration technical solutions (enterprise portal, enterprise service bus, enterprise workflow system, etc.) using appropriate open standards. It also integrates PLM standard-based technical solutions for product data exchange and sharing, with appropriate applicative services. On such a platform, the test bed introduces testing specification, development and management of capabilities applying Model-Based System Engineering (MBSE).

The issue addressed in this paper concerns the reasons for modelling PLM standards and the way to model these standards so that we can re-use these models to specify and simulate standards-based collaboration scenarios. The idea is also to investigate the use of such approaches to specify testing procedures and related validation properties for assessing standards implementations.

In this context, we propose to apply and extend the SIP methodology on business manufacturing data exchange business cases and particularly for enabling efficient data integration between ERP and MES systems.

Section 2 hence provides a state of the art about enterprise modelling approaches languages and tools. Based on the literature, it also explains how the interoperability of business processes could be achieved by using models. A second sub-section of the state of the art present the used ISA-95 standard for ERP and MES systems integration. Section 3 introduce our proposal and illustrates how we managed to model different aspects of the ISA-95 standard. Finally we also introduce in this section the DEKENZ case study in which we specify a data exchange and integration scenario between an ERP system and different MES systems re-using and instantiating the ISA 95 standard model. Conclusions and future work are presented in section 4.

State of the art

Interoperability is the ability of several systems, whether identical or radically different, to communicate without ambiguity and operate together [START_REF] Bourey | Report on Model Driven Interoperability[END_REF]. Considering a PLM strategy in a DMN context, standardized interfaces between processes and supporting resources (human and ICT resources) are required in order to ensure the continuity, consistency and integrity of the different shared/exchanged product and process data all along the product lifecycle and across business domains. As a result PLM Standards have largely been identified in the literature as interoperability enablers [START_REF] Rachuri | Information sharing and exchange in the context of product lifecycle management: Role of standards[END_REF] [START_REF] Figay | Interoperability of Technical Enterprise Application[END_REF]. A PLM standard is not only a technical solution for product data exchange but also a strategic answer that has to consider:

 The strategic business motivations of the organizations involved in the DMN;  The business engineering needs of the addressed collaboration processes;  The human and applicative resources supporting these business processes that intend to become interoperable;  The ICT systems in which standards will be implemented;  The technological solutions for using standardized data format;  The infrastructures permitting to organizations to connect their applications and to share/exchange their standardized process and product data.

Therefore, PLM standards are very complex and hence difficult and costly to implement. One way to address this complexity is to model these standards and related business cases using Enterprise Architecture Modelling considering these different dimensions. One of the goal of this paper is to study these frameworks to use and/or to extend them in view to specify and model standards-based business collaboration scenarios. The finality is then to be able to simulate these scenarios to prepare and build the interoperability of future DMNs.

Enterprise architecture modelling for PLM interoperability

An enterprise architecture (EA) description is usually very complex, because it comprises a large set of components and relationships between them. EA is a coherent whole of principles, methods and models that are used in the design and realisation of the enterprise's organisational structure, business processes, information systems, and infrastructure [START_REF] Lankhorst | Enterprise architecture modelling -The issue of integration[END_REF]. However, in practice, these domains are not approached in an integrated way. Every domain speaks its own language, draws its own models, and uses its own techniques and tools. According to [START_REF] Chen | Architectures for enterprise integration and interoperability: Past, present and future[END_REF], architecture allows managing complexity and risks due to various factors such as technology, size, interface, context and stakeholders. Therefore, it is important that EA can be represented with relevant information and at the appropriate level of detail for individual stakeholders. More generally, EA must show properties that can be verified with respect to user needs (e.g. open or closed architecture, interoperable or not, centralized or decentralized, etc.) [START_REF] Chen | Architectures for enterprise integration and interoperability: Past, present and future[END_REF]. It must be simple so that business people can easily understand, check, analyse, discuss in a 'language' shared at the corporate level. According to [START_REF] Chen | Architectures for enterprise integration and interoperability: Past, present and future[END_REF] enterprise architecture models describe the EA from various viewpoints to allow specifying and implementing the systems. For this purpose, numerous approaches, methods and frameworks (e.g. Zachman [START_REF] Zachman | The Zachman Framework For Enterprise Architecture, Primer for Enterprise Engineering and Manufacturing[END_REF], CIMOSA [START_REF] Kosanke | CIMOSA: Enterprise engineering and integration[END_REF], TOGAF[14]) have been developed to consider these different viewpoints related with different stakeholders. In literature, it is possible to distinguish between simple methods of representation (SADT, IDEFx, GRAI, IEM, etc.) and reference architectures (CIMOSA, ARIS, PERA, GERAM, GIM, etc.). These latter offer a set of structured methods with a methodology to be followed to build the model. But, these methods are, in most cases, difficult to implement. In other cases, we note the existence, according to the viewpoints, of different languages that must be studied and mastered. Moreover, the models defined according to these different viewpoints are related and when a change occurs on one model, the consistency of the impacted related models must be insured. However, due to the heterogeneity of the methods and techniques used to document the architectures, it is very difficult to determine how the different domains are interrelated. Still, it is clear that there are strong dependencies between the domains [START_REF] Lankhorst | Enterprise architecture modelling -The issue of integration[END_REF]. Also, it should be possible to visualise models in a different way, tailored towards specific stakeholders with specific information requirements.

For all these reasons, we propose a modelling methodology based on the TOGAF framework and the ArchiMate 5 enterprise architecture language due to its ability to model an enterprise system interrelating domain specific architectures and crossdomain relationships. The ArchiMate language divides the enterprise architecture into a business, applicative and technological layer. In each layer, three aspects are considered: active elements that exhibit behaviour (e.g. Process and Function), an internal structure and elements that define use or communicate information. The use of ArchiMate language in our methodology allows us to model different system architectures. First it is used to model the standard architecture itself and related test procedures. Secondly it used to specify business collaboration processes and their related applicative and technological chains. Finally it also used to specify the as-is and to-be applicative and technological integration platforms as well as the different SIP "test beds".

ISA-95 a standard for ERP and MES systems integration

While addressing the role of PLM standards it is important to distinguish the different types of standards included in the scope of a PLM approach. Moreover, the interoperability across system information might be addressed distinguishing the product or system taken into account. The global and main role of information exchange standards is to reduce the number of inter-change protocols from the unmanageable multitude of one-to-one interchanges to a finite number of distinct and meaningful compositions of coherent information across time, space and multiple disciplines [START_REF] Rachuri | Information sharing and exchange in the context of product lifecycle management: Role of standards[END_REF].

In our context, we are particularly interested by the ISA 95 standard developed to address interoperability issues between ERP systems and MES. ISA-95 is defined according to [START_REF] Harjunkoski | Sharing data for production scheduling using the ISA-95 standard[END_REF] as the international standard for the integration of enterprise and control systems. It consists of models and terminology that can be used to determine which information has to be exchanged between systems for sales, finance, logistics, production, maintenance and quality. Four functional levels are defined by ISA 95 standard. Levels 0, 1 and 2 are the levels of process control. Their objective is the control of equipment, in order to execute production processes that end in one or more products. Level 3 could be called the level of MES activities, it consists of several activities that must be executed to prepare, monitor and complete the production process that is executed at level 0, 1 and 2. The highest level (level 4) could be called the level of enterprise, including ERP systems and PDM Systems. At this level financial and logistic activities are executed in order to produce the product configuration ordered by the client. Next section, which introduces the proposed methodology, also provides extracts of the ISA-95 standard modelled with the use of the ArchiMate language.

Proposed methodology and case study

In this section, the SIP methodology and the use of ISA-95 standard are introduced. The SIP methodological modelling framework is presented and its application is illustrated first by modelling the ISA-95 standard and secondly specifying/modelling an information exchange scenario between ERP and MES based on ISA-95.

SIP methodology

SIP methodology aims at validating a set of coherent PLM standards and their implementations. The first objective is to develop an innovative interoperability framework (shown in figure 1) in order to provide a model-driven methodology for the development of a PLM standards assessment test bed which will be implemented as a service.

Fig 1. SIP methodological modelling framework

First of all, we have to model the DMN and the strategic motivations of the different stakeholders. Still on the business layer, the second step consists in collecting and modelling interoperability business cases and related exchange and test scenarios. The supporting applicative chains that supports these scenarios are then specified at the applicative layer. Finally the execution model to simulate is modelled to prepare the appropriate test bed infrastructure configuration. In parallel the framework also provides architectural viewpoints to specify the generic and specific applicative and technological components of the test bed. This figure is not fully representative of the SIP framework since it does not include the step consisting in modelling PLM standards. However next section illustrates the way of performing this step using ArchiMate language to model ISA-95.

Moreover, using models instead of text documents enables first to constitute a knowledge base of PLM standards models. These models should include a set of reusable standards-based collaboration templates of the different functional modules of the standard. A PLM standard can specify the supported business processes, as well as the product and process data models to implement in ICT systems., we will have a multi-layer view with the modelling of the processes (organizational layer), the data models (applicative layer) and specifying the software solutions (technological layer).. Cross this way, modelling the standard allow us to show the link between the different layers, the information flow between each layer. Also with this method, we can put in place the exchange protocols described in the documentation of the standard, we can define a validation properties for the implementation of the standard and we will construct a templates of the standard that can be exploited in various specific implementation scenarios. The test and the validation will be based on the generation of recommended practices, test processes with the integration of real applications and single test, all this to generate solutions which implement standards and which can be easily integrated [6][7].

The ISA-95 standard

In this part we will introduce the structure of the ISA-95 standard and the application of the SIP methodology for modelling the standard with ArchiMate.

Content and structure of the standard

The ISA-95 standard is structured in five parts. The first part presents the models and terminologies for analysing and exchanging information between level 4 (ERP) and level3 (MES). The second part shows the data models in order to standardize the structure and the information flows defined by part 1. In part 3 ISA-95 defines the four operations group that it covers in manufacturing activities which are: Production, Maintenance, Quality and Inventory operations. Part 4 specifies the informational flow between the four types of operations defined in part 3. Finally part 5 standardizes the implementation format and transactions data messages which transit between ERP systems and MES systems.

Modelling ISA-95 with ArchiMate

Based on the ISA-95 specifications [START_REF]ISA95, Enterprise-Control System Integration -ISA[END_REF], we have modelled a set of reusable ISA-95-based collaboration templates of the different functional modules of the standard. This templates intend to be re-used in specific business collaboration scenarios requiring a strong ERP-MES integration. Figure 2 represents the functional model of ISA-95 gathering the several functions covered by the MES and the ERP and the information flow between these business functions. Indeed the functions supported by the ERP systems are: Order processing, Product cost accounting, Product shipping admin, Procurement, Research development and engineering. The MES supports the following functions: Production control, Quality assurance, Maintenance management. The rest of the functions which are Production scheduling, Product inventory control, Material and energy control are supported by both the ERP and the MES systems. Our ISA-95 model also includes several levels of abstraction providing more detailed views of these functions which are not shown in this paper. These standardized business functions will be re-used in the frame of case study described in section 4.

Fig. 2. Functional model of ISA-95in ArchiMate

In Figure 3 the business functions of figure 2 have been categorized according to their belonging to the higher level business functions "Business Planning & Logistics" and "Manufacturing operations management" corresponding respectively to level 4 (supported by ERP and PDM system) and level 3 (supported by MES) of ISA-95 mentioned in section 2.2. For instance, the functional level 3 is sub-divided in four subfunctions: Production, Maintenance, Quality and Inventory operations management. Different levels of abstraction appear in this diagram since all these sub-functions are also detailed with activities sequencing diagrams as defined in the ISA-95 standard. According to ISA-95 documentation, four categories of information are exchanged between the business and the manufacturing layers: schedule information, product definition information, performance information and product capability information. Each of these categories is also sub-divided into four sub-categories of data flows corresponding to the information consumed or generated by the level 3 sub-functions. For instance, the schedule information category includes production schedules, maintenance requests, quality test requests and inventory requests. Each of these business objects are also detailed at the applicative layer to represent the various standardized data models defined by ISA-95. Figure 4 shows the product definition model as defined by ISA-95 in part 2 and permitting to define the shared information between product production rules, bill of materials and bill of resources. One limit of ArchiMate we had to deal with when capturing the information model of ISA95, which is formalized in UML, is the missing ability of the language to capture reflexive relationship.

Fig. 4. ISA-95 Product definition object model in ArchiMate

To exchange these data in standardized way, ISA-95 also defines the way to structure the transaction messages which transit between business and manufacturing layers. The different kind of ISA-95 transactions data set are represented in figure 5 where the content, structure and implementation ISA-95 format are defined. An ISA-95 transaction data set is first composed of an "application identification area" which includes information about the origin of the message and where it will be transmitted. It includes a "data area" which includes a "verb area" for sending a demand (get, change, cancel, etc.) or responding to a demand (show, confirm, respond, etc.) and the "noun area" specifying the kind of exchanged data objects (as defined in part 2 of ISA-95). The "noun area" contains the standardized information models as defined in part 2 and implemented in an ISA-95 compliant XML format: the Business To Manufacturing Mark-up Language (B2MML). The transaction message is based on three models, a pull model where a user of data requests the data from a provider of the data, a push model where a provider of data requests an action (processing, changing, or cancelling) on the data by another user and a publish model where the owner of data publishes it to users (subscribers) of the data.

Modelling and specifying ISA-95-based data exchange scenarios with ArchiMate

DEKENZ 6 is a French company specialized in the development, the fabrication and the marketing of pens with the particularity that its labour is mainly ensured by students located in different universities in France. The objective of this concept was to provide to universities an operational training to the functioning of a company. The finished DEKENZ pen showed in figure 6 is a pen mainly composed of Aluminium. It is composed of a cap assembly (itself composed of cap, a cap stopper, a staple and an inner clip), a body assembly (itself composed of a body tube, a quill, a body stopper, a nose and a ring), a quill and a cartridge. As shown on figure 7, the production of the cap and of the stopper as well as the integration of the cap and body assemblies is performed by students at "La Halle Technologique" of the IUT Montreuil 7 . Fig. 7. DEKENZ case study -Map of actors and their roles Figure 8 represents the business layer of the ERP-MES data integration scenario of the DEKENZ case study. The manufacturing process of this product is modelled on the bottom of the figure 8. On top of the figure 8 are represented the business planning and logistics operations of the scenario; i.e. the pen production order creation, the production planning creation according to the Manufacturing Bill of Materials (MBOM) and to the inventory level of the pen components. In the middle of the figure 8, the ISA-95 model shown in figure 3 is instantiated and re-used for this scenario permitting hence to specify the standardized data flows between the IUT ERP system and the IUT and the sub-contractors MES systems. For this paper we first focused on the exchange of MBOMs and production schedules/orders from the IUT ERP system and the MES systems but as well on the exchange of production performance and production capability information from the MES systems to the IUT ERP system. To-Be applicative architecture for the DEKENZ ERP-MES integration scenario One limit of ArchiMate we had to deal with is the missing modelling construct "asis" as we can find it in the Ontology Web Language, e.g. when willing to capture that a software system (ICT layer) is an instance of a software product (Business Layer) with an architecture (Applicative Layer) shared by all the instances of the product.

Conclusion and future work

This paper intends to demonstrate how the use of enterprise architecture modelling languages could contribute to better specify and prepare interoperability business cases. Extending the SIP methodology, this paper introduces a manufacturing case study for ERP and MES systems integration based on the ISA-95 standard. Some extract of the ISA-95 ArchiMate model are shown to illustrate the approach and the interest of reusing templates of these models to be re-used in different collaboration scenarios. Last section shows how the templates have been re-used and instantiated in the context of the DEKENZ ERP-MES integration scenario. The next steps will be:

 To instantiate the ISA-95 object models with the concrete DEKENZ case study data (MBOM, Production schedules, etc.).  To create the related B2MML files to understand and analyse this implementation solution in view to develop the future B2MML converters and quality checkers.  To create the related ISA-95 compliant transaction data messages.  Define the quality control procedures to assess the conformity to the standard and to verify the content of the exchanged B2MML files.

 Perform the mapping with the IUT ERP data model and the MES systems data models in order to further specify and/or develop the B2MML converters.  Specify and/or develop the ISA-95 B2MML quality checkers.  Address the limitations of the ArchiMate language by proposing some extensions to the community.

One of the target of this research work is to be able to simulate the collaboration on the SIP test bed and demonstrate the interest of using models to prepare, build, verify and validate enterprise interoperability with models.

Fig. 3 .

 3 Fig. 3. Generic ISA-95-based ERP/MES business functions and data flows

Fig. 5 .

 5 Fig. 5. ISA-95 Transaction Data Set between ERP and MES model in ArchiMate This section introduced some extracts of the ISA-95 ArchiMate model. This model includes reusable ISA95-based collaboration templates, such as the ones shown in Figure 3. In the next section these templates are re-used to model and specify an interoperability business case study.

Fig. 6 .

 6 Fig. 6. DEKENZ product -Pen sub-components CAD models on the left and the finished product on the right

Fig. 8 .

 8 Fig. 8. DEKENZ Case study -ERP-MES data integration scenario

Fig. 9 .

 9 Fig. 9. To-Be applicative architecture for the DEKENZ ERP-MES integration scenario

http://www.boostaerospace.com/

http://www.asd-ssg.org/

http://www.irt-systemx.fr/project/sip/

http://www.irt-systemx.fr/

http://www.opengroup.org/subjectareas/enterprise/archimate

DEKENZ website: http://pm.flamant.free.fr/dekenz/?p=accueil

IUT Montreuil website : http://www.iut.univ-paris8.fr/

Acknowledgments. This research work has been carried out under the leadership of the Technological Research Institute SystemX, and therefore granted with public funds within the scope of the French Program "Investissements d'avenir".


Vincent Chapurlat

Nicolas Daclin

Stéphane Billaud

An interface pattern model for supporting design of natively interoperable systems

Keywords: System Interoperability, Natively interoperable systems, Design for Interoperability, Interface pattern model

This article focuses on the interoperability feature seen as a specific requirement. Indeed, any complex system (e.g. a train, an organisation or an IT system) need to interact with other systems, thereby forming a heterogeneous environment. All these systems are not necessarily designed to function properly and efficiently with one another, whether from a conceptual, technical, behavioural or organizational standpoint. This paper highlights what seems to be relevant in terms of conceptual definitions and modelling framework whenever a (group) of engineer(s) intends to design what we call here a "natively interoperable system" or, at least, a system maximizing its interoperability capabilities. To proceed, as a first prerequisite, a definition of the concept of interoperability is here proposed for complex system engineering. The second prerequisite consists of establishing the needs of a design team assigned to design such "natively interoperable system". An interface pattern model with sufficient generic, formal and pragmatic qualities is then proposed and illustrated briefly.

Introduction

Many examples from industry have highlight that a lack of interoperability of systems leads to delays, failures, dysfunctions or shortcomings all along these systems' life cycle; problems that can be much more manageable if they are characterized and detected earlier in the system's design stage. So, various research and development were focused on interoperability management problematic particularly over the last decade considering interoperability as an essential feature of any kind of technical or socio technical complex system (e.g. a transportation system or a Collaborative Network of Organisations [START_REF] Camarinha-Matos | Collaborative networks: A mechanism for enterprise agility and resilience[END_REF]). The goal is to design a system able to assume its mission and for this able to maximize and maintain its abilities to interact efficiently with other systems (technical or sociotechnical, more or less complex themselves) in various situations, even more or less unpredictable, throughout its life cycle and without unwanted effects that can affect the behaviour of each systems involved in the interaction. In this sense an interaction, requested or not, consists to exchange and share items from different nature (digital i.e. data/information/knowledge, physical i.e. any kind of energy field, or material e.g. raw material, product, part, or waste). Further, an interoperable system must perform efficiently its mission independently from other systems with which it must interact for achieving this mission. However, lot of systems are currently more or less designed in order to be integrated into a given and fully identified upper-level system. These practices limit drastically the analysis of the real expected system interoperability, for instance, in avoiding unexpected or reverse effects that the interface is unable to prevent or, failing this, to protect the system itself. Last, even if important recommendations and standards are now available for instance concerning Health Care systems [START_REF]European Commission, Annex II -EIF (European Interoperability Framework[END_REF], IT systems [3], or Defence systems [START_REF]DoD) Architecture Framework (DoDAF), version[END_REF] design, the notions of interoperability requirements, interoperability analysis issues, interface or interaction still remain poorly formalised in engineering activities.

This article aims to propose conceptual elements for supporting complex system design stage taking into account requested system's interoperability. The goal is to help engineers' teams to design a so-called "natively interoperable system". First, definitions of system interoperability and interoperability requirements, obviously, of natively interoperable complex system are proposed. Second, an interface pattern model is needed to face design issues of such systems. This is done adopting a set of pre-requisites conceptual and then generic definitions (processor, interaction, effect…) that can be applied to various nature of systems. The goal is to provide engineers with modelling language and, by evidence, a verification tooled approach allowing them to confirm and to check whether the considered system can avoid defects due to its interaction with other systems under all specified conditions via its interfaces.

System interoperability / Interoperability requirements

Definition of interoperability depends of the application domain 1 and authors e.g. [START_REF] Daclin | Methodology for Enterprise Interoperability[END_REF][START_REF] Lavean | Interoperability in Defense Communications[END_REF][START_REF] Clark | Organisational Interoperability Maturity Model for C2[END_REF][START_REF] De Soria | Developing an Enterprise Collaboration Maturity Model: Research Challenges and Future Directions[END_REF][START_REF] Naudet | A Systemic approach to Interoperability formalization[END_REF]. The goal here is to propose and adopt (in this paper at least) a definition of system interoperability for the purpose of system design stage. Classically, interoperability is "connecting people, data and diverse systems. The term can be defined either technically or comprehensively, in taking into account social, political and organizational factors". Then, "two or more devices are said interoperable if, under a set of conditions, the devices are able to successfully establish, sustain and, if necessary, break a link while maintaining a certain level of performance". In technical systems, interoperability is "a property of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, without any restricted access or implementation". In socio-technical systems, it is defined as "a property referring to the ability of diverse systems and organizations to work together", i.e., to inter-operate. For instance, enterprise interoperability is defined as "a cooperative arrangement established between public and/or commercial entities (authorities, parking facility operators, etc.), wherein tags issued by one entity will be accepted at facilities belonging to all other entities without degradation in service performance". In the same manner, interoperability is considered as "the ability of a system or product to work with other systems or products without special effort from the customer". In the military field, NATO defines also interoperability as "the ability of systems, units or forces to provide services to -and accept services from -other systems, units or forces and to use these services so exchanged to enable them to operate efficiently together". Last, in transportation systems, interoperability seems to be achieved when "a transport network [is suitable] for movements without breaking bulk".

Thus we propose defining system interoperability as: "The set of abilities and associated capabilities of a system (namely "S" from now) that allow S to be and to stay able to exchange and work harmoniously with other systems from its upper level all along its life cycle:  To fulfil a common mission (i.e. the main function for which the overall system is designed), possibly time-bounded, while remaining able to perform its own mission and to reach its own objectives through the use of exchanged items with other systems then when S is interacting with these systems whatever may be their nature;  In all specified operational situations (e.g. nominal functioning mode, or functioning modes when facing a risky situation) met throughout its life cycle;  Reflecting the stakeholders' requirements under every specified situation. This capability indicates and allows assessing before, during or after the interactionand when placed in its environment -that S does not require or result in major changes to its operations, structure or behaviour; consequently, its functional and non-functional requirements (performance, security, safety, ergonomics, human factors, etc.) are not altered. Moreover, this does not induce undue adverse effects (dysfunctions, risks) when S is achieving its mission independently of every other system".

As a consequence a natively interoperable system S is "a system designed to maximize its ability to interoperate all along its life-cycle". During S design stage, engineer has to consider carefully this expectation and shall "[...] ensure the compatibility, interoperability and integration of all functional and physical interfaces and then ensure that system definition and design reflect the requirements for all system elements: hardware, software, facilities, people, and data" [10]. To this purpose, one or several interfaces are requested. An interface is defined in [START_REF] Afis | Interfaces techniques et architectures du système[END_REF] as "a boundary across which two independent systems meet and act on or communicate with each other". That requires, at least by adhering to published interface standards or by making use of a 'broker' of services able to assume interface role between S and other systems, possibly, "on the fly". Communication, synchronization or even exchange protocols must be defined and applied.

Interface elements: prolegomena

Let's recall briefly a set of concepts from the literature on system sciences [START_REF] Moigne | La théorie du système général: théorie de la modélisation[END_REF][START_REF] Jean-Michel | La modélisation par les systèmes en situations complexes[END_REF][START_REF] Féliot | Toward a formal theory of systems[END_REF] and some theoretical foundations of Systems Engineering defined as "an interdisciplinary approach and means to enable the realization of successful systems [socio-technical or technical systems]. It focuses on defining customer needs and required functionalities early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem" [START_REF]INCOSE, System Engineering (SE) Handbook, A Guide For System Life Cycle Processes And Activities Version 3.2.2[END_REF][START_REF] Bkcase Editorial | The Guide to the Systems Engineering Body of Knowledge[END_REF][START_REF] Blanchard | Systems Engineering and analysis[END_REF].

A processor aims to transform items (digital i.e. data/information/knowledge, physical i.e. any kind of energy field, or material e.g. raw material, product, part, or waste) transported by input flows, into new items transported by output flows, under the control of other flows and by using resources that support or are involved in processor functioning. As an example, S is a processor, a function, an activity or a process when considering its functional view; moreover, a component or an organizational unit involved in S is a processor when considering physical view (organic, organizational).

Fig. 1. From high abstraction level to low abstraction levels of modelling

Figure 1 shows the links between an abstract modelling language proposed in the SAGACE approach [START_REF] Jean-Michel | La modélisation par les systèmes en situations complexes[END_REF] and some equivalent notations used in various domains such as eFFBD (enhanced Functional Flows Block Diagram) [START_REF] Seidner | Vérification des EFFBDs : Model checking en Ingénierie Système[END_REF], PBD (Physical Block Diagram), BPMN 2.0 (Business Processes Modelling Notation) [START_REF] Omg | Business Process Modelling Notation 2[END_REF], Activity or Internal Block Diagram from SysML [START_REF]System Modeling Language SysML[END_REF]. So, all of the proposed concepts discussed below can be applied independently of the adopted modelling language. This step offers a freedom to the designer in choosing the most relevant modelling language when addressing system S interfaces design.

The processor behaviour is described by a transformation that details the inputs flows/outputs flows treatment provided by the processor. This transformation may be described by modelling the modification induced by the processor on one or more characteristics of each item transported by input flows, so as to obtain new or modified items transported by output flows. More generally, the characteristics of any concept are named formally Space, Shape, Time attributes i.e. SST attributes in the next: Space (e.g. type, definition domain, instantaneous value / default value…), Shape (e.g. optical, electromagnetic, signal, binary, or linked to the aspect of the pointed out item if it can be considered as dependent from one or several of five senses) and Time (update frequency, maximum life cycle before updating…) (Figure 2).

Fig. 2. SST attributes categories and examples in use

Analytical methods can be applied (1) to assess processor performance (e.g. in terms of costs, QoS or response time); and 2), to check some of the functional and/or non-functional requirements (e.g. by evaluating various "-ilities"2 ) the processor must respect in accordance with Stakeholders' expectations and constraints.

An interaction is an oriented relation between an emitter processor P 1 and one or more receiver processors {P 2 , … , P n } denoted {P i } . There is an interaction when (1) an exchange of one or more identified flows or service between P 1 and {P i } is identified and/or (2), one or more fields F generated by P 1 can impact {P i }. An interaction is planned or desired, or alternatively unwanted or unintentional. In all cases, it can cause an effect if the interaction (1) affects one or more P 2 SST attributes, and/or (2), impacts the set of requirements (including interoperability requirements) to respect by {P i }, in one of various characterized ways, that means [START_REF] Mann | Hands on systemic innovation[END_REF]:  Feared / Harmful. At least one characteristic of {P i } becomes inconsistent with the necessary conditions to survive. In this case, the identified relation causes the emergence of behaviours or physical phenomenon that are often inappropriate, such as resonances, electromagnetic interferences and thermal effects, thereby inducing rather risky situations (accident, incident, or malfunction) or damage to operational modes at the source and destination(s). They have to be avoided or simply modified.  Required but absent. The effect should exist but remains absent for various reasons such as design mistakes or errors. In this case, some non-functional requirements concerning P 1 and {P i } have not been verified (performance, safety, security, etc.).  Required and present. The effect exists and moreover is considered necessary. All requirements concerning P 1 and {P i } are checked so this effect cannot be removed or even modified.  Required then appropriate but insufficient or excessive: The effect exists some non-functional requirements concerning {P i } are not checked yet (performance, safety, security, etc.). So, the effect must be analysed in order to be improved or reduced. The effect can be derived from various dimensions, depending on the technical or socio-technical nature of processors P 1 and {P i }. Figure 3 shows the proposed effect model inspired by the substance-field model originally proposed in [START_REF] Altshuller | The TRIZ method: numerous references and a presentation of TRIZ principles are available on[END_REF]. In this model, a field F is from thermal, mechanical, pressure, biological or other nature. A list of available fields is given in [START_REF] Mann | Hands on systemic innovation[END_REF] and [START_REF]Effects data base[END_REF] proposes a database of potential effects that can help designers to identify appropriate solutions for modifying the interaction. After defining these concepts, S must respect [START_REF]INCOSE, Survey of Model-Based Systems Engineering (MBSE) Methodologies[END_REF][START_REF] Nuseibeh | Requirements Engineering: a roadmap[END_REF] stakeholders' requirements separated into functional (i.e. "what must the system do?") and non-functional ("what are the system's expected characteristics of performance, "-ilities" and constraints supposed to do?") requirements. In our case, interoperability might concern both functional and non-functional aspects of S. The next formalizes the notion of interoperability requirement inspired by [START_REF] Mallek | An Approach for Interoperability Requirements Specification and Verification[END_REF] (applied to collaborative processes). There is an effect from P 1 to P 2 when the interaction 1) induces one or more P 2 TSS attributes variation and/or 2) impact requirements of P 2 and/or 3) make appear one or more Fields F that can impact P 2 Flow(s) / Service(s) environment whenever such interactions are needed. This ability is driven by respecting technical standards, communication protocols for technical compatibility or organizational rules and policies for organizational compatibility, described respectively as technical compatibility requirements e.g. required frequency of the exchange and organizational compatibility requirements. These must be recognized by all systems having to interact with S.  Inter-operation. S operates seamlessly with the other systems in its environment by taking into account flows content being exchanged to fulfil its mission; moreover, it is able to control, adapt or anticipate problems promptly. S can also influence, not necessarily intentionally, other systems through both desirable and adverse effects. In this case, the term interoperation requirements could be referenced e.g. lifetime of any item transported before its obsolescence in taking into account states and modes of operation at the origin and relation target (ready, stop, etc.).  Autonomy. S is independent of other system operations and behaviour. Autonomy may be decomposed into decisional autonomy (where S assumes its governance and remains capable of deciding actions) and operational autonomy (where S remains capable of preserving its performance in terms of cost, schedule and quality of service). At this point, it becomes necessary to consider decisional autonomy requirements and operational autonomy requirements.

From
 Reversibility. The relationships between S and the other systems are completely reversible, i.e. S can return to an identified configuration or state without causing any problems (dysfunctions, loss of performance, requirement violations, etc.) requiring difficult to manage changes once S no longer needs to exchange with the other systems in its environment. Relationship reversibility requirement is the term introduced here.

Last, a causality rule exists whereby: "a processor A will be interoperable with processor B if all elements that compose (from different sources) or refine (from the same source) A and are involved in the interaction relationship with B do not cause interoperability problems, i.e. A and B respect interoperability requirements regarding their own role and objectives within the interaction".

Considering these new classes of requirements, requirements checklists classically used in industry can be then enriched as proposed in Figure 4. An interface is "the common logical and/or physical border between two or more components (here, processors) or between the system (a processor) and its environment (a upper-level processor), at which the rules of exchange, compatibility, integrity and non-regression are to be respected throughout the system's life cycle".

From a theoretical point of view, an interface allows P 1 and each P i  {P i } to:  Exchange the requested flow(s) or service(s). In due course, it must consider (in the receiver role) or make available (in the emitter role) the items carried out by the(se) flow(s) or requested by the service(s). Among other abilities, this set-up must:

-Provide functional skills: emit, receive, transport, adapt (e.g. convert the input format of the exchanged flows), separate, protect, authorize the interaction, involve another processor, manage the items (e.g. store, retrieve), etc.

-Respect all stakeholders' requirements, especially, interoperability requirements.  Protect them from, or avoid, the potential effects induced by the interaction, or, at least, be able to contain the inappropriate effects within acceptable limits. To this purpose, its behaviour has to be adapted and/or a set of protection mechanisms or barriers must be designed to limit risky situations, for instance inspired by resilience engineering principles [START_REF]Resilience Engineering in Practice[END_REF]. So we propose in the next an interface pattern model enabling engineers to model and analyse interactions between any type of systems and other systems composing the environment then to build and check interfaces.

An interface is conceptualized as a processor P intending to establish a connection between a processor P 1 (system, component, subsystem, business unit or actor) with its environment composed of a set of processors {P i } in order to (objective 1) transport flows between P 1 and {P i } (or vice versa) and/or (objective 2) protect from, in the sense of avoiding, unwanted effects between P 1 and (at least) one of the {P i } processors resulting from relationship implementation. Considering interface design and following system design principles (e.g. as proposed in [START_REF] Thimbleby | User Interface Design as Systems Design, People and Computers XVI-Memorable yet invisible[END_REF][START_REF] Bkcase Editorial | The Guide to the Systems Engineering Body of Knowledge[END_REF]), three cases must be raised:  Designing a native interoperable processor P induces the design of each needed or potential interface, by considering each interface as a sub-processor of P.  Improving the interoperability of an existing processor P can induce global or partial re-engineering of each of its interfaces, considering that each processor P1 found to play the role of interface can either replace one of the parts of P or be added to P.  Improving the interoperability of processor P, by considering P impossible to modify (e.g. P must be definitively integrated into a more complex processor P', perhaps assumed to be the upper-level system). It induces the design and addition of new interfaces between P and the other processors from the environment.

In accordance with the basic principles of Systems Engineering approach, and as illustrated in Figure 5 an interface can be viewed as a processor characterized by:  Interface purpose: The interface (objective 1) "allow to ensure the exchange of flows or services between two or more systems (components / functions / actors or business units having to be identified), as expected from an efficient (in terms of resources used) and effective (with positive results) way", or (objective 2) "contributes to improve the protection of a system (to be identified) from an efficient and effective way, in taking into account other systems with which the interaction is not mandatory or even inevitable".

Fig. 5. Interface Pattern Model

 Interface mission: An interface (objective 1): "ensures the requested interaction i.e. exchange of flow(s), service(s) (themselves inducing exchange of flows)" or (objective 2) "limits the effects of the interaction between identified processors (systems / components / functions / actors or business units) from an efficient (in terms of resources used) and effective (with positive results) way".  Interface objectives: An interface must respect overall functional and nonfunctional requirements (including interoperability but also, for instance, performance, ergonomics, constraints, or verification requirements). They are induced or come from the identified processors in relation. At least, an interface must improve the identified processors interoperability (i.e. compatibility, interoperation, autonomy and reversibility), reduce effects (having to be detected, identified and then modelled by an effect model) following the interface objectives, interchangeable, reliable, affordable, scalable, manageable and interchangeable (Figure 5).  Interface typology: logical or functional at first during the design process, it will become physical, human-machine (HMI) or organizational interface. So, it is proposed to distinguish the functional or logical interface, from physical, humanmachine and organizational interfaces as follows:

 Functional interface: between functional entities (e.g. functions from functional architecture). The designer creates functional interfaces between functions that model the flows to be exchanged (data, material, energy) in the role of input, output, control (trigger) or resource flows. This notion of function requires determining:  types of carried out items, contents, origin (external of the system of interest or internal), and respective roles in the system;  whether or not a communication protocol and exchange is requested and formalized;  whether a treatment protocol or flow adjustment is needed taking into account interoperability requirements;  whether a synchronization protocol or source and target(s) adjustment is requested. After allocating functions to the processors, the functional interface evolves into the physical, human-machine and/or organizational interfaces, which are then required between the system under design, and its context, or else between subsystems and components.

 Physical interface: between the system to be designed and components or subsystems forming its context [START_REF] Afis | Interfaces techniques et architectures du système[END_REF][START_REF] Thimbleby | User Interface Design as Systems Design, People and Computers XVI-Memorable yet invisible[END_REF][START_REF] Gruhn | Human Machine Interface (HMI) Design: The Good, The Bad, and The Ugly (and what makes them so)[END_REF]. These interfaces are required to: -Enable operating functions on physical flows and hence meeting the functional requirements. For instance, [START_REF] Afis | Interfaces techniques et architectures du système[END_REF] distinguished five types of physical interfaces:

-Spatial: related to physical adjacency for alignment, orientation, serviceability, assembly or weight; -Structural: related to load transfer or content; -Material: related to the transfer of airflow, oil, fuel or water; -Energy: related to the transfer of heat, vibration, electric or noise energy; -Information: related to the transfer of signals or controls; -Respect non-functional requirements (performance, "-ilities" such as interoperability when considering non-functional aspect of interoperability, and abilities, e.g. emission, reception, or transport of a flow);  Human-Machine interface (HMI): The activities required for user interface design are already detailed for instance in [START_REF] Gruhn | Human Machine Interface (HMI) Design: The Good, The Bad, and The Ugly (and what makes them so)[END_REF].  Organizational interface: These interfaces are required between actors and organizational units involved in and required to play roles in the system of interest. Exchanges become necessary in conducting sharing, collaboration, communication and cooperation when performing activities to: produce / manufacture, deliver, store, sell, buy, design, manage, control, verify, plan, teach and organize training periods for stakeholders, qualify actors' profiles, decide, etc. These interfaces can be modelled as a collaborative working process model or a virtual organization model for instance.  Interface SST attributes. The goal is to define what are the requested SST attributes of the requested interface, for instance, in terms of potential physical elements that can be used to implement the interface (communication components, connections, ports, links, etc.) as illustrated in Figure 2 and such as:

-Time e.g. duration for connection,/disconnection, maximum delay before updating value or life cycle duration before obsolescence of the carried out items; -Shape e.g. dimensions (L*H*D), geometry, weight, radiation from various nature (see the list of possible fields in the effect model); -Space e.g. position, speed, transfer speed...  Interface functioning modes / operational scenarios and configurations: As any component, an interface evolves all along its life cycle by passing from a functioning mode to another one, highlighting then various behavioural scenarios and configurations. An approach for discovering and analysing these characteristics are detailed in [START_REF] Chapurlat | Proposition of a guide for investigating, modeling and analyzing system operating modes: OMAG[END_REF].  Interface functional architecture: The interface must transform one or more flows stemming from an emitter system to a (set of) receiver system. This transformation allows avoiding physical effects that may impair the systems in interaction (e.g. disturbing or damaging structure/organization or behaviour) and moreover must verify the interoperability requirements. We propose to model the expected transformation by 1) a model of time, shape and space attribute transformation of the flow and of items transported by the flow, and 2) the effect model proposed above focusing on the potential effects to be avoided and anticipated. In design stage, the functional vision of an interface highlighting these two transformations can be for instance modelled by choosing and using one of the modelling languages introduced in Figure 1 considering the nature of source and targets processors. This completes the interface pattern model with one or more functional architecture patterns models, more or less detailed aiming facilitating design by reusing partially or fully these models.  Interface physical architecture: The interface is implemented by linking various sub-processors (physical subsystems or components, actors, sub-organizational units), on which the functions proposed in the functional architectures are to be allocated et then performed taking particularly into account all non-functional requirements. This description can be generated by using, for instance, any Physical Block modelling language and respecting SE principles.

Conclusion and prospects

This paper has introduced conceptual aspects of an interface model pattern supporting engineers involved in natively interoperable system's design activities. This helps particularly and guides modelling activities but aims also to permit checking and testing conformity, coherence and adequacy [START_REF] Bérard | Systems and Software verification: model checking techniques and tools[END_REF] of proposed interfaces in order to design a system that will be able to maximise its interoperability in various situations even difficult to predict. The goal is now to develop modelling and analysis platform [START_REF] Nastov | A verification approach from MDE applied to Model Based System Engineering: xeFFBD dynamic semantic[END_REF] integrating existing proof and simulation tools [START_REF]Formal verification tools overview web site[END_REF][START_REF]RPG reference document[END_REF] allowing then mixing formal properties proof and simulation as proposed in [START_REF] Bilal | System of Systems design verification: problematic, trends and opportunities[END_REF] when considering systems of systems [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] interoperability analysis.

Fig. 3 .

 3 Fig. 3. Effect model principleThese requirements are split up into 4 categories such as:  Compatibility. S can send and receive flows from other systems in its environment whenever such interactions are needed. This ability is driven by respecting technical standards, communication protocols for technical compatibility or organizational rules and policies for organizational compatibility, described respectively as technical compatibility requirements e.g. required frequency of the exchange and organizational compatibility requirements. These must be recognized by all systems having to interact with S.  Inter-operation. S operates seamlessly with the other systems in its environment by taking into account flows content being exchanged to fulfil its mission; moreover, it is able to control, adapt or anticipate problems promptly. S can also influence, not necessarily intentionally, other systems through both desirable and adverse effects. In this case, the term interoperation requirements could be referenced e.g. lifetime of any item transported before its obsolescence in taking into account states and modes of operation at the origin and relation target (ready, stop, etc.).  Autonomy. S is independent of other system operations and behaviour. Autonomy may be decomposed into decisional autonomy (where S assumes its governance and remains capable of deciding actions) and operational autonomy (where S remains capable of preserving its performance in terms of cost, schedule and quality of service). At this point, it becomes necessary to consider decisional autonomy requirements and operational autonomy requirements.

Fig. 4 .

 4 Fig. 4. Enriched requirements checklist All concepts previously described are requested for designing interfaces as follows.

« developmental, operational and support requirements a program must address (e.g. availability, maintainability, vulnerability, reliability, or supportability) »[START_REF]INCOSE, System Engineering (SE) Handbook, A Guide For System Life Cycle Processes And Activities Version 3.2.2[END_REF][START_REF] Olivier | Investigating Relationships and Semantic Sets amongst System Lifecycle Properties (Ilities)[END_REF] i.e. a kind of non-functional requirement (NFR)