Fabien Bouffaron
email: fabien.bouffaron@univ-lorraine.fr

Pascale Marange
email: pascale.marange@univ-lorraine.fr

Gérard Morel
email: gerard.morel@univ-lorraine.fr

Checking models based on an iterative co-specification process of a critical system

Keywords: model based systems engineering, cospecification, verification/validation, model-checking, dependability requirements, I

Recurrent incident reports indicate that critical systems such as power plants exhibit unintended emergent behaviors outside of acceptable limits, despite of the increasing development of dependable automation technologies as well as of a lot of techniques related to dependability issues. Among many causes, the role of human for operating technical artefacts is of importance, but also for designing them from the early stages of specification in order to check the basic property of wholeness of any system. A mean is to ensure a continuum of compliant models to component integration through an iterative process between all the disciplines involved to engineer these systems as whole all along their life cycle. However, a human-based process to check the "right-system requirements-right" remains not fully adequate at the scale of real systems engineering projects and in any case to critical issues. This paper explores the formal checking compliance of architecting models with dependability requirements. These models are refined iteratively by specialist and specialty engineers interoperating with a system engineer through a co-specification process on a particular case study of a critical power-plant subsystem.

INTRODUCTION

Because of the resilient nature of human operators to face unintended emergent behaviors [START_REF] Hollnagel | Joint cognitive systems: Foundations of cognitive systems engineering[END_REF], a generation of power plant remains largely under human control. They are assisted in their work by automation technologies that provide the least important part of the overall control information. Control room operators and field operators interoperate together to perform documented procedures in order to align a lot of devices only partly automated to process energy flows. The increasing readiness level of automation technologies embedding somewhat of a technical intelligence is expected to enlarge the part of digital control information in order to offer new services to field operators. This last objective is addressed by some R&D programmes for the next generation of power plant as well as for the revamping of current ones technical and ecological issues. Its purpose is to design innovative architectures compliant with the main advances in component solutions for distributed industrial automation systems. To meet the main objective of increasing the dependability integrity levels of the overall process, the systems engineering (SE) framework is a model-based integrative approach. Its aim is to check how the system parts, and consequently the related engineering ones, interoperate such that they reproduce or transform a whole. The expected result, "in contradistinction with traditional control engineering approaches focusing first on separate parts" 1 , is to check the "right-system requirements-right" between all the stakeholders involved throughout a power plant life cycle, including the enabling systems, and especially the automation system engineering. The use of models for verification and validation of dependable requirements to component solution integration is compliant with the last recommended best practices in industry [START_REF] Fanmuy | Requirements verification in the industry[END_REF].

The role of the system architect beyond technical aspect remains challenging and issues presented in this paper and others related ones [START_REF] Bouffaron | Revisiting the interoperation relationships between Systems Engineering collaborative processes[END_REF], [START_REF] Bouffaron | Integrative construct for Model-Based Human-System Integration: a case study[END_REF] are in line with those of this R&D programme. Section 2 contextualizes our CISPI-AFW case study reflecting on a lab-platform some critical features of power plant automation. It also presents the co-specification process used to engineer this system. Section 3 details a particular co-specification scenario to design a logical architecture in order to highlight the set of models refined iteratively by specialist and specialty engineers interoperating with a system engineer. Section 4 formally checks the consistency of the overall models with dependability system requirements at different stages of the studied cospecification process. To conclude, section 5 highlights on going works related to others engineering domains involved in a broader cospecification process for critical power plant control. Moreover, some perspectives are drawn on how to combine model-checking and co-simulation techniques for verification and validation issues.

II. CO-SPECIFICATION PROCESS OF THE STUDIED

SYSTEM

Our case study reflects, on the one hand, some features of an auxiliary feedwater (AFW) system in emergencies. It is historically recognized as a critical sub-system [START_REF] Casada | Auxiliary feedwater system aging study[END_REF] [6] of some power-plant generations. AFW aim is to maintain an adequate water level in the steam generator (SG) by providing feedwater to the latter, during normal operations (startup and shutdown evolutions) as well as for emergency issues (Fig. 1). Fig. 1. AFW sub-system in emergencies (adapted from [START_REF] Duco | Accidents nucléaires. Three Mile Island (Etats-Unis)[END_REF] ) Then, our co-specification process reflects, on the other hand, a set of engineering domains involved in the automation design of such AFW sub-system. Systems engineering play an integrative role as a concurrent, iterative and recursive problem-solving process when architecting a system solution through feedbacks (Fig. 2).

A. Studied Critical Sub-System

Our CISPI lab platform2 is composed of three tanks, one of which may be associated with the feedwater storage tank and another with a steam generator. SG tank leakage output aims to simulate the flow of steam released relaxation into the atmosphere. These two tanks are interconnected by two redundant lines consisting of a manual valve, a flow meter and a control valve (Fig. 3). The architectural concept is to distribute around a fieldbus a set of "intelligent actuation and measurement systems" (IAMS) within an integrated system of control, maintenance and technical management (CMMS), including control by human operators [START_REF] Dobre | Improving humansystem digital interaction for industrial system control: some systems engineering issues[END_REF]. This paper highlights some dependability issues related to the preliminary logical definition of this architecture by several specialist and specialty engineering. This step is before the allocation of the specified function blocks to human operators and/or to automation components.

B. Studied Co-Specification Process

We revisited in previous works [START_REF] Bouffaron | Revisiting the interoperation relationships between Systems Engineering collaborative processes[END_REF] the nature of these SE feedbacks focusing mainly on the System Breakdown Structure. (Fig. 2). Following and extending the problem-frame approach for software engineering [START_REF] Jackson | Problem frames: analysing and structuring software development problems[END_REF] related to the meaning of requirements specification [START_REF] Jin | Revisiting the meaning of requirements[END_REF], we argue that the basic driver of these feedbacks is first the quest of knowledge by the system architect from specialist engineering domains at each level, which is then reiterated through the system breakdown structure. Let's consider such a knowledge-based iteration 3between the problem-space (PS SE ) of the SE domain and a solution-space (SS AE ) of the Automation Engineering domain. We argue that the added knowledge (K_SS AE ) from the AE solution-space (1) contributes iteratively to achieve the satisfaction of an automation (software-based) system specification (S AE ) from system requirements (S SE ) described by an SE problem-space (2) according to entailments:

K_SS AE , S SE  S AE (1) K_PS SE , S AE  S SE (2)
At the scale of an overall SE process restricted to our case-study, we generalize this iterative cospecification process between all the problemspace/solution-space of the engineering domains (

W OP , S SE  R OE (1)
where W OP represents the operational environment knowledge of the target system and R OE is a set of requirements described by the related operational engineering problem space (PS OE ).

Note that each specialist specification may be verified, for example by execution of models, within its own solution-space but must be validated by the related problem-space. In order to improve a lean management of the overall engineering workflow, we suggest distributing this co-specification process around a bus (Fig. 4). A main interest is that engineers from various domains can use their own tools, methods, technics to interoperate with each other by the mean of a common language, such as the de-facto standardized SysML [START_REF] Omg | OMG Systems Modeling Language (OMG SysML)[END_REF] in our case-study. Indeed, maturity of digital technologies for modeling and simulation allows considering the exchange and model coexecution through standardized interfaces for connecting different simulation environments. The "Functional Mockup Interface" [START_REF] Blochwitz | Functional mockup interface 2.0: The standard for tool independent exchange of simulation models[END_REF] defined by the European ITEA2 Modelisar project is a promising candidate to become the industry standard for cosimulation models and cross-company collaboration [START_REF] Bertsch | The Functional Mockup Interface-seen from an industrial perspective[END_REF]. The validation of a co-specification by coexecution of models can replace current technics of code generation and integration that are dependent on interoperability levels between tools. Thus, in our R&D framework, various domains and their respective tools (process engineering: Dymola ® , automation engineering: Matlab ® /Simulink ® , system engineering: IBM Rational ® Rhapsody) interoperate through a co-simulation bus 4 .

Section III, describes a co-specification scenario between SE problem space (PS SE ) and specialist engineers who prescribe specification models (S model ) from the system specification (S SE ). As addressed in section IV, a special attention should be paid to the transversal dependability engineering solution space (SS DE ) to check more formally theses specification models satisfying:

K_PS SE , S model , K_SS DE  S SE .
(2)

III. LOGICAL ARCHITECTURE CO-SPECIFICATION

We focus our scenario on the study of systems engineering activities during the co-specification of logical architecture. At this point, we consider the following set of system requirements (S SE ) satisfying the set of stakeholder requirements (R OE ) during an accident situation (W OP ) (Fig. 1) according to the entailment (3):

Stereotype ID Text

Functional

S SE1

The water level shall be maintained at 50 cm in the steam generator tank

Functional

S SE2

The emergency water flow shall be 20 L.min -1

Dependability S SE3

The feedwater system shall satisfy single failure criterion System engineer has to prescribe a logical architecture (LA SE ) requiring knowledge of several specialist solution spaces (process and automation engineering) in order to meet system requirements.

A. Specification of the AFW process

A first iteration is to specify the physical process to be controlled. From this task, there is an emergent problem about the specification of a process observing the laws of physics. Indeed, system engineer does not have the expertise to perform this task. In this sense, system engineering problem space formalizes this problem into requirements. These are then broadcast on the co-specification bus, pending a specialist engineer can address it. Process engineering solution space (SS PE ) being able to meet this problem (S SE ) specifies CISPI-AFW process (S PE ) according to:

K_SS PE , S SE  S PE (3)
S PE prescribes a process with two alignment functions (Water_Supply) providing transport of water between two storage functions (Water_Storage). So that the process engineer can interact with the system engineer, it is important that both share a common representation of the solution in a common language. In this sense, the process engineer has to externalize his specification (S PE ) by transcribing it in SysML language (red in Fig. 5 and Fig. 7). Once done, process solution space engineer prescribes S PE to SE problem space for validation. CISPI-AFW being a critical system, systems engineer must formally validate at least that S PE is compliant with dependability requirement S SE3 . However, systems engineering domain does not necessarily have the skills to formally perform this task. In this sense, a second iteration is drawn on the expertise of dependability engineering solution space to formally validate S PE . This validation task is described in the next section.

B. Specification of the AFW control functions

Once the CISPI-AFW process validated, it remains to specify the control thereof.

As with process engineering domain, control functions specification requires a third iteration between SE problem space and automation engineering solution space (SS AE ). As addressed by [START_REF] Blochwitz | Functional mockup interface 2.0: The standard for tool independent exchange of simulation models[END_REF], automation as a specialist engineering has to broaden its traditional disciplinary domain in order to prescribe a control functions specification (S AE ) compliant with both process specification (S PE ) and system requirements (S SE ) according to entailment: K_SS AE , S SE , S PE  S AE [START_REF] Bouffaron | Integrative construct for Model-Based Human-System Integration: a case study[END_REF] This specification S AE consists in the definition of two control functions (Control_Water_Height) and one observation function (Observation_Height) (blue in Fig. 5). In the same way as for the validation of S PE , systems engineer draws again on the expertise of DE solution space to formally validate S AE . This validation task is also described in the next section.

C. Specification of the AFW logical architecture

In this stage, the CISPI-AFW process specification (S PE ) and the control functions specification (S AE ) are validated by systems engineering domain.

Taking into account dependability engineering specification S DE ("adding an observation function" see next section), SE problem space (PS SE ) must logically architecting process and control components in order to provide a logical architecture of CISPI-AFW system (LA SE ) according to the entailment: K_PS SE , S PE , S AE , S DE  LA SE [START_REF] Casada | Auxiliary feedwater system aging study[END_REF] This task requires to compromise between specialist and specialty specifications in order to prescribe LA SE . Indeed, systems engineering solutions has to check that the resulting architecture of logical architectural design process is compliant with systems requirements (S SE ). Thus, a last iteration with dependability engineering solution space is required to verify the specified architecture (LA SE ).

IV. CHECKING CO-SPECIFIED MODELS

Through the integrative system engineering processes, it is important to perform validation process [START_REF] Pyster | Guide to the Systems Engineering Body of Knowledge (SEBoK). Version 1.0[END_REF]. This is in order to check that any engineering products resulting from engineering processes are compliant with given system requirements models according to the predicate (4). This is particularly true with critical systems and dependability requirements where the use of formal techniques is strongly recommended [START_REF] Fanmuy | Requirements verification in the industry[END_REF] by safety standards.

The dependability requirement (S SE3 ) of our case-study is about the single failure criterion. Critical systems satisfy this criterion if their aim is ensured in the presence of any single component failure. CISPI-AFW system being used for short term during emergencies, only the single active failures must be taken into account, i.e. alignment, control and observation components. In other words, the system requirement S SE3 can be expressed as following: "if a failure is present on one of components, is there an alternative (another way) to achieve the system aim?" This led us to use reachability analysis method to check the compliance of the different specialist specification models with S SE3 . Indeed, the reachability analysis is a particular model checking method, which determines in a state-space (behaviour) if there is a way that respects a given property. Moreover, model checking methods allow producing a counterexample when a model fails to satisfy a desired property. "This faulty trace provides a priceless insight to understanding the real reason for the failure as well as important clues for fixing the problem" [START_REF] Cassandras | People In Control[END_REF].

To express the property, the language that we have chosen for formal checking is Computational Tree Logic (CTL) [START_REF] Clarke | Design and synthesis of synchronization skeletons using branching time temporal logic: Springers[END_REF] because it is sufficient to formalize the requirements of our case study into properties. The tool used is UPPAAL [START_REF] Behrmann | A tutorial on uppaal[END_REF] which is an integrated tool environment for modelling and model-checking timed automata.

A. Checking of CISPI-AFW process specification (S PE )

For model checking and reachability analysis purposes, the dependability requirement S SE3 has to be refined as a formal property. During the first iteration between system specialist engineering and dependability specialty engineering, the checking should determine whether the specified CISPI-AFW process (S PE ) is compliant with S SE3 . In other words, "if a failure is present on one of alignment functional components, is there a way to achieve the system aim?" This is represented by an observer (Fig. 6) with an initial state, followed one state representing the occurrence of a failure and followed by another state representing the system aim satisfaction. For each failure, the property to check is: "Is there a way to reach the system aim after the failure occurrence?" In the CTL, this property is written:

E <> (failure i == 1) && (Observ.aim) (6)
This property must be checked considering that each process function may have a failure. Two results are possible:  The property is satisfied: this result allows concluding that CISPI-AFW process specification (S PE ) is compliant with system requirement (S SE3 ).  The property is not satisfied: this result allows concluding that CISPI-AFW process specification (S PE ) is not compliant with system requirement (S SE3 ). However, by analysing the counterexample returned by the model checker, dependability specialist is able to identify where the problem is.

Note that the checking this property, allows also checking the compliance with systems requirements S SE1 and S SE2 . Indeed, from a point of view of the process, we assume that if the upstream flow of the SG tank is greater or equal to the downstream flow (20 L.mn -1 ), the system can ensure to maintain the level in the SG tank (Fig. 6). This is implemented in automaton diagram by the guard: flow_SG>=0 && (Alignment_Performed_way1 + Alignment_Performed_way2) where flow_SG = downstream_flow_SG -upstream_flow_SG (Fig. 9).

Thus, with SE problem space and DE solution space knowledge (K_PS SE , K_SS DE ) we are able to check the compliance of CISPI-AFW process specification (S PE ) with systems requirements (S SE ) according to the instance of entailment (4):

K_PS SE , S PE , K_SS DE  S SE (7)
To perform the checking, the specified behavior of functional process components must be modeled in UPPAAL. For this, the DE solution space has to translate behavior described by SE problem space in SysML statechart diagram into timed automata diagrams. Note that for reasons of size, the models presented in this paper do not represent the complete system. We focus for this study to the alignment function (Fig. 7 and Fig. 8) and to the formalization of the logical architecture (Fig. 9). Many studies deal with the passage from statechart to automata diagrams [START_REF] Knapp | Model checking timed UML state machines and collaborations[END_REF] [START_REF] Ji | Slicing hierarchical automata for model checking UML statecharts[END_REF]. However, to apply these rules, several iterations between dependability and systems engineers have been necessary for the interpretation of the semi-formal SysML statechart diagram. Thus, each SysML states are represented by automaton states. Note that the state Operational does not appears in the automaton but it includes in the states {Aligned, Misaligned, Aligning, Misaligning}. Moreover, in the automaton diagram the state Init_State is included in the state Init. Therefore we add two transitions to the state Init to initialize the alignment component either in state Aligned or in state Misaligned. Finally, the specified process architecture (red in Fig. 5) needs to be also modeled by an automaton (Fig. 9). This automaton represents the link between functional process components through water flows exchanged between them. Moreover, it allows updating water flow values at each evolution of the system. From these models, we are able by model checking to check that the property ( 8) is satisfied. Therefore we can affirm that the CISPI-AFW process specification S PE is compliant with systems requirements S SE according to predicate [START_REF] Faisandier | collection : Engineering and Architecing multidisicplinary systems, Sinergy'Com[END_REF].

B. Checking of CISPI-AFW control functions specification (S AE )

As for the checking of process specification (S PE ), the same approach can be applied to check the compliance of control function specification (S AE ) with systems requirements (S SE ) according to the instance of predicate (4): K_PS SE , S AE , K_SS DE  S SE [START_REF] Pyster | Guide to the Systems Engineering Body of Knowledge (SEBoK). Version 1.0[END_REF] The property [START_REF] Pyster | Guide to the Systems Engineering Body of Knowledge (SEBoK). Version 1.0[END_REF] to check is the same as previously, however the observer has to be redefined to take into account control and observation functions. Indeed, the satisfaction of S SE1 requires to observe and to control process in order to maintain level in SG tank. Thus, the observer (Fig. 10) consists on an initial state, followed of a state representing the occurrence of a failure, and by another state representing the system aim satisfaction if system is able to control and to observe the water level in the SG tank. Following the same method as previously, dependability engineer transforms statechart diagrams of control and observation functional components into automaton diagrams. Diagrams are not presented in this paper for space limitations. Once all models have been updated, dependability engineer checks the property (8) for each components failure. For functional control component failure, the single failure criterion is satisfied. Indeed, if a failure occurs on Control_1component, the Control_2 component on waterway 2 (with its associated process) components can ensure the CISPI-AFW system aim. As against, for functional observation component, if a failure occurs there are no other functional observation component to observe the water level in SG tank. Therefore, it is no longer possible to ensure the CISPI-AFW system aim. In this sense, DE solution space prescribes to systems engineering problem space that the AE specification (S AE ) is not compliant with systems requirements (S SE ). It prescribes also that another functional observation components is required to ensure the compliance of S AE with S SE . A new iteration between SE problem space and AE solution space is necessary to satisfy the predicate [START_REF] Dobre | Improving humansystem digital interaction for industrial system control: some systems engineering issues[END_REF].

V. CONCLUSION AND PERSPECTIVES

We would point out that UPPAAL is not yet integrated into our co-simulation framework but it could be in future works. This means that the verification/validation process remains humanbased (properties formalization, models transformation) with the aid of an automated checker. On contrary, it is important to emphasize the role of the co-specification process to aid also human checking modeller to ensure the correctness of its own dependability engineering models through several iterations with the system engineer in order to exhibit the right properties to the satisfaction of S SE . A future work will focus on the use of SCADE ® tool for checking with the advantage to automatically import IBM Rhapsody ® statechart diagrams.

Others ongoing works continue to experiment the powerful role of this co-specification framework based on the quest of knowledge from the systems engineering domain to others specialistengineering domains. For example, we are working with human-centred engineering (4) in order to satisfy operational requirements when field operators perform some control tasks but also with automation engineering in order to define a new kind of intelligent controller for CISPI-AFW [START_REF] Fliess | Model-free control[END_REF]. A future work will also improve this cospecification process to fully define a logical architecture and then a technical one. All these works, sometimes exploratory, are based on sound modelling rather than drawing for systems engineering, and aim in-fine to contribute to Human System Integration, both in operation and Design, as addressed by [START_REF] Boy | Unifying Human Centered Design and Systems Engineering for Human Systems Integration[END_REF].

Fig. 2 .

 2 Fig.2. Systems engineering and management paradigm[START_REF] Pyster | Guide to the Systems Engineering Body of Knowledge (SEBoK). Version 1.0[END_REF] [START_REF] Faisandier | collection : Engineering and Architecing multidisicplinary systems, Sinergy'Com[END_REF]

Fig. 3 .

 3 Fig. 3. Piping and instrumentation diagram of CISPI AFW-like process

Fig. 4 .

 4 Fig. 4. Distributed co-specification process



Fig. 5

 5 Fig. 5 Internal Block Diagram representing control functions specification (S AE ) (blue) of AFW process (red).

w aterway_1:Water_Supply 1

 1 Operati ons Water_T ransportation(fl ow _setpoint:doubl... orage(flow:double):V o... i o n(he ight _measure :double,he ight _se t point :int ):flo ... i on(he ight _measure :double,he ight _se t point :int ):flo...

Fig. 6 .

 6 Fig. 6. Observer for process specification (S PE )

Fig. 7 .Fig. 8 .

 78 Fig. 7. SysML statechart diagram of alignment function (Water_Supply)

Fig. 9 .

 9 Fig. 9. Logical architecture of AFW process represented in timed automaton

Fig. 10 .

 10 Fig. 10. Observer for control specification (S AE )

  PS OE SS OE , PS SE SS SE , PS PE SS PE, PS AE SS AE PS DE SS DE ) interoperating to satisfy the originating operational entailment:

TABLE I .

 I DRIVING CISPI-AFW SYSTEM REQUIREMENTS (S SE )

http://www.collegepublications.co.uk/systems/syt/

http://safetech.cran.univ-lorraine.fr/

"K_PS iE " and "K_SS jE " notations correspond respectively to the knowledge of problem space i (PS iE ) and solution space j (SS jE ) for the next sections

http://site.cosimate.com/


David Gouyon
email: david.gouyon@univ-lorraine.fr

Fabien Bouffaron
email: fabien.bouffaron@univ-lorraine.fr

Gérard Morel
email: gerard.morel@univ-lorraine.fr

Specifying some key SE training artifacts

HAL is

Introduction

There is a growing interest in Systems Engineering (SE) [Haskins et al. 2011], as the discipline of engineering a system as a whole [START_REF] Bertalanffy | General System Theory: Foundations, development, applications[END_REF]. The objective is to address the increasing complexity caused technically by multiple system component architectures as well as caused behaviorally by multiple interacting agents under control. Classical engineering disciplines have to broaden their respective theoretical and technical domains to meet this crosscutting challenge in order to define, to develop and to deploy a system satisfying stakeholder requirements.

For SE to be recognized as a full discipline by the industrial and academic worlds, the BKCASE 1 international project (Body of Knowledge and Curriculum to Advance Systems Engineering) aims at proposing a worldwide knowledge repository, composed of two major deliverables. The first one is the SEBoK (Systems Engineering Body of Knowledge) [Pyster et al. 2012a], which purpose is to "provide a widely accepted, community based, and regularly updated baseline of SE knowledge". It is available as a wiki which describes precepts about Systems Science, System Thinking, and mainly about Systems Engineering. The second deliverable is the GRCSE (Graduate Reference Curriculum for Systems Engineering) [Pyster et al. 2012b], which is a set of "recommendations for the development and the implementation of a systems-centric professional master's degree program in Systems Engineering", compliant with the SEBoK.

With the same objective than the SEBoK, the AFIS 2 , the French chapter of the INCOSE 3 , has proposed in parallel a SE reference book [Fiorèse & Ménadier 2012]. The presentation approach used is to describe basic concepts ("with what?", "why?", "what?"), before describing SE processes, methods and tools ("how?"). Our eight years of experience in teaching SE within a master's degree in Complex Systems Engineering 4 convinced us that, indeed, it is important for students to understand first how SE basic precepts are structured. In this sense, considering the SE domain as the pivotal domain between the trainer domain and concurrent specialist engineering domains (Fig. 1) [START_REF] Bouffaron | Revisiting the interoperation relationships between Systems Engineering collaborative processes[END_REF], we prescribe that satisfying systems requirements as well as functionally and physically architecting a solution rely mainly on a logical ORM-based 5 specification process. The objective of this paper is to propose SE training recommendations based on this specification process as driver, before to assess them on Model-Based Systems Engineering (MBSE), in particular with SysML [OMG 2012].

SE training problem statements

Systems Engineering teaching is gradually being implemented in some schools and universities, but is not unified. It is often taught by experienced engineers and professors, who are rather autodidacts and trained by years of practices on large projects. These engineering projects pushed them to cope with different types of problems, to find solutions, and to formalize "best practices" to implement on future projects. As a result, SE approaches are mostly based on feedbacks rather than on sound scientific foundations. Furthermore, in function of trainers' experience and tendency, some complementary points of views can be followed, with advantages and drawbacks, to teach SE: ensuring compliance with SE standards, following MBSE methods, and applying project management concepts.

Indeed, a major effort has been done since years to standardize SE processes 2007]). As a result, agreement, enterprise, project and technical processes involved within system life cycle are highlighted and defined. This enables to realize which processes have to be applied, how they can be applied, and what their outcomes are. This way, trainees can verify if they have well applied SE processes in order to "solve the problem right", but the main drawback is that the compliance to these processes does not guarantee that they have worked "the right problem" [START_REF] Martin | Systems Engineering Guidebook: A process for developing systems and products[END_REF]].

The implementation complexity of these standardized processes grows in function of the number of systems functionalities, which increases rapidly with the growing use of software. The traditional document-centric approaches come then to theirs limit [Pyster et al. 2012 a]. One answer seems to be Model-Based Systems Engineering (MBSE) [START_REF] Estefan | Survey of model-based systems engineering (MBSE) methodologies[END_REF]], which seems to be better suited to manage complexity, including that of software [START_REF] Cépaduès | A practical guide to SysML: the systems modeling language[END_REF]]. The objective of MBSE is to support system life cycle activities, including requirements engineering, high-level architecture, detailed design, testing, usage, maintenance, and disposal, with models. In practice, if trainees are not well guided to apply MBSE, graphical representations are used to replace traditional textual documents. The result is a set of diagrams representing aspects of the system, but which can present inconsistencies. In this case, students have only "drawn" rather than "modeled".

Even if the management of SE processes can not be dissociated from project management [PMI 2008], it is also clear that a senior project manager (Fig. 2a or Fig. 2c) has previously managed technical processes in several projects as junior manager (Fig. 2b). In other words, the trainer is in charge of the strategic project management according to a training development cycle, while trainees are in charge of the operational management of SE tasks as well as of their execution. This interoperation relationship between trainer and trainees (Fig. 3) must be also contextualized in a common domain-ofinterest, from which the system-of-interest must be specified. This system-of-interest must have a scale factor and a complexity justifying that various disciplines (system, specialties…) are involved as well as that different roles are allocated to trainees.

Fig. 3 Interoperations between trainers and trainees within SE training projects

As example of training context, the CISPI lab platform reflects some requirements of the large-scale R&D programme aiming to innovate in power-plant control system-architectures for technical as well as ecological issues. CISPI system-of-interest reflects the main principles of a steam generator Auxiliary Feedwater System (AFS). The purpose of such an AFS is to participate in the cooling of the primary circuit, in case of emergency. Its mission is to feed steam generators with water in order to get the necessary conditions for the use of a Shutdown Cooling Heat Exchanger (SCHE). The main objective is to maintain a sufficient water flow rate into the steam generators, so that they can ensure heat transfers in safe conditions. Student training projects impact modifications of the current CISPI platform related to an integrated Control, Maintenance and technical Management System [START_REF] Morel | Reliability, Maintainability, Safety[END_REF]] as well as fluid circuits.

Specification as a SE training driver

The problem statements we pointed out in the previous section brought us to formalize the contractual specification relationship between trainers and trainees, as a pivotal driver to logically organize SE artifacts within training projects.

Problem-Solution spaces interoperation

In Fig. 3, Trainer [Project_Manager] and Trainee [Systems_Engineer] can be associated to problem spaces. Trainee [Project_Engineer] and Trainee [Specialist_Engineer] can in turn be associates to solution spaces. Indeed, problem space describes its problem and solution space prescribes a solution in return. If the solution proposed solves the problem, this solution is seen as a specification result. In this sense, as underlined by [START_REF] Hall | Relating software requirements and architectures using problem frames[END_REF] the interoperation between problem space and solution space is seen as a specification process producing this specification result. This is consistent with previous work [START_REF] Bouffaron | Revisiting the interoperation relationships between Systems Engineering collaborative processes[END_REF] wherein the specification process is seen as a descriptive-prescriptive interoperation relationship between problem space and solution space. This formalization (Fig. 4) allows clarifying the use of the "specification" word (which is used for referring to the specification process as well as the result of this process [START_REF] Van Lamsweerde | Formal specification: a roadmap[END_REF]) and the emergence of a key SE artifact which is the separation of problem and solution spaces.

Thus, Trainee [Systems_Engineer] and Trainee [Specialist_Engineer] would not be the same person. Therefore, trainees would be specialized in either system engineering domain, or in specialist domains.

Fig. 4 Problem-solution spaces interoperation artifacts

Source-Sink objects interoperation

In a more general way, the interaction between two spaces highlights that the specification process treats stakeholder requirements (Problem) as source objects, to specify system requirements (Solution) as sink objects. We noticed that the specification process evolution is clocked by the different roles of the objects handled by the processes composing the specification process: an object produced by a process with a sink role will have a source role when it will be consumed by another process (Fig. 5). A main interest in the Source-Sink artifact is that it can be useful to perform traceability between source objects and sink objects during process execution. In this sense, trainer and trainee would trace all actions performed during process specification execution to ensure traceability between problem and solution.

Optative and indicative moods interoperation

The process formalization (Fig. 6) can be put in relation with works by Jackson in the software engineering domain, who formalized the concepts of optative and indicative moods [START_REF] Jackson | The meaning of requirements[END_REF]. During the specification process, optative objects (representing requirements at different levels of abstraction) undergoes several transformations performed by processes according to indicative objects belonging either to the problem space or to several specialist solution spaces. Optative object expresses conditions over the problem space that have to become true. Indicative objects represent the known properties (skills) of a domain which are validated by experts regardless of the behavior or given properties of the solution. Thus, domains can act as solution spaces if they have skills to solve a problem, or as problem space if they don't [START_REF] Czarnecki | Generative programming: Principles and techniques of software engineering based on automated configuration and fragmentbased component models[END_REF]. This highlights that some students would be involved at the system level, and some other students would be specialized in engineering domains.

Fig. 6 Optative and indicative moods interoperation artifacts

Verification and Validation processes interoperation

The relationship between problem and solution spaces appears as a contractual process involving validation and verification [Pyster et al., 2012a] (Fig. 7). "Validation is used to ensure that one is working the right problem, whereas verification is used to ensure that one has solved the problem right" [START_REF] Martin | Systems Engineering Guidebook: A process for developing systems and products[END_REF]. In this sense, we propose a formalization of the verification and validation processes by interpreting Jackson's works [START_REF] Morgan Kaufmann Gunter | A reference model for requirements and specifications[END_REF] about optative and indicative moods, and con-sidering the predicate: W ⋀ S ⇒ R, where the specification S (Optative object Sink) must satisfy the requirement R (Optative object Source) considering the domain knowledge W (Indicative Object). Thus, the verification process performed by solution space consists in the satisfaction of the predicate:

W solution space ⋀ Optative_object Sink ⇒ Optative_object Source
In a similar way, the validation process performed by problem space has to satisfy the predicate:

W problem space ⋀ Optative_object Sink ⇒ Optative_object Source
This shows that trainees would not valid by themselves their solution. Their work would be evaluated by the corresponding problem space. It can be either the trainer for the system level, or other trainees for specialists.

Fig. 7 Verification and Validation processes interoperation artifacts

SE training solution assessments

To illustrate the potential benefits of the recommendations expressed in the previous section, we focus on the specification of the CISPI platform modifications. In order to specify it, a set of projects are proposed by relevant trainers (problem space) to student teams (solution spaces), as parts of their SE training curriculum.

The first set of observations we make is that, with such formalizations and explanations, trainees understand more easily SE concepts and the relative positioning of SE processes. They are aware of their respective roles within problem and solution spaces, and establish contractual interoperations they should have between them, and with trainers. They clearly make the difference between requirement definition and analysis processes, and between verification and validation processes.

The second set of observations we make concerns the application of the recommendations on MBSE, more specifically with SysML [START_REF] Holt | SysML for Systems Engineering[END_REF]. We proposed to students to interpret SE recommendations into SysML modeling recommendations or rules, in order to facilitate diagram authoring and to improve SysML semantics [START_REF] Ober | UML/SysML semantic tunings[END_REF]]:  The problem / solution spaces partitioning of SysML models can be done using packages: "problem space package" and "solution space package". This has a main interest for requirement definition and analysis, for example to clearly separate stakeholder requirements and system requirements;  The source & sink concept is closed to UML customer & supplier roles used in dependencies to ensure traceability between objects. Given that SysML is a UML profile, we propose to use dependencies for the traceability during the requirement specification process, as presented in Table 1. Note that during the requirement analysis process, we have identified 4 types of transformations: refinement, decomposition, composition and induction [START_REF] Bouffaron | Revisiting the interoperation relationships between Systems Engineering collaborative processes[END_REF];  As transformations rely on skills, it is very important to trace their use in models. We propose to include skills into models using SysML "Rationales". Such rationales can be linked to dependencies between requirements to justify and trace the transformation performed.  Although verification and validation processes can be executed according to skills, which can be traced using SysML rationales as presented before, they are usually performed according to SysML "Test Cases". Problem and solution spaces do not have necessarily similar test cases to verify and validate requirements. Thus we propose to link solution space test cases to requirements with a "verify" dependency as the indicative mood for the verification process, and to create the "validate" dependency for the validation process in order to clearly make the difference between verification and validation. To illustrate this second set of observations, we focus on the following stakeholder requirement, extracted from a student project: "CISPI-AFS shall produce a sufficient water flow rate for the return of the primary circuit to SCHE conditions". Considering the work of students who are not guided by the recommendations made in section 3, the resulting requirement diagram is very poor, presenting only a stakeholder requirement and a system requirement tracing it (Fig. 8).

Process

Fig. 8 Requirement diagram made by students without rules application

Considering now the work done by students guided by section 3 recommendations (Fig. 9), the approach is the following: once expressed in the trainer problem space (represented by a package), the stakeholder requirement is described to the trainees' system level solution space (also represented by a package). To transform (refine) this requirement into system requirements, as well as to verify the requirements they produce, trainees need skills that they can have or that can be required to specialist engineering solution spaces. These skills are then traced in models with rationales. The validation of system requirements is done by the trainer in the problem space using a test case which is traced in models. The comparison of the requirement diagrams of Fig. 8 and Fig. 9 shows that recommendations improve the traceability because requirements are clearly classified into packages, and because skills used for requirement transformations and verification are traced into models. The verification of student work is also simpler, which is important in a learning context in which teachers can be at the same time the contracting authority and the support of student assessment. More detailed dependencies links (verify validate…) helps the mutual understanding of models, and accelerates the specification process in decreasing the number of iterations before converging on validated system requirements.

Note that this training process based on a reference specification process enable to rationally extend the project structure of SysML based tools as the one 7 for the CISPI project, as well as their metamodel for the relevant use of required SE artifacts. To return to the conditions : T <180 °C and P < 30 bars, the flow rate must be 80 t/h.

«verify»

SCHE_Conditions

«rationale,Operational_Domain» SCHE conditions for primary circuit is characterized by : T < 180 °C and P < 30 bars

«verify»

Conclusions

In order to cope with the large amount of "best-practices" required to face any SE project with the limited amount of training resources (time, platforms, trainers' skill and knowledge, trainees' knowledge heterogeneity…), we decided to share a common model of understanding of the process of engineering a system as a whole. This is a prerequisite to logically train mainly the technical processes and their related SE artifacts based on the specification process considered as a key SE driver.

ORM diagrams presented in this article are parts of a metamodel under development for training as well as for engineering purposes. This SE specification-based metamodel will be used as a pivotal reference in order to map systems modeling languages and tool artifacts with best SE artifacts.

Fig. 1

 1 Fig. 1 Collaborative specification process applied to SE training

Fig. 2

 2 Fig. 2 Overlap of the project roles, adapted from [Pyster et al. 2012]: trainer and trainees share the project processes

  Fig. 5 Source-sink objects interoperation artifacts

Flow_RateFig. 9

 9 Fig. 9 Requirement diagram made by students applying rules

7

  IBM® Rational® Rhapsody® supporting Model transformation Based Systems Engineering processes.

  a sufficient water flow rate for the return of the primary circuit to : T < 180°C and P < 30 bars Sufficient_Flow_Rate_SolS «Requirement» ID = CISPI 1 AFS shall produce a sufficient water flow rate for the return of the primary circuit to SCHE conditions

IEEE 1220 [IEEE 2005], ISO/IEC 15288 [ISO/IEC 2008], ISO/IEC TR 24748-2 [ISO/IEC 2011], ISO/IEC 26702 [ISO/IEC

(ANSI/EIA 632 [ANSI/EIA 1999],

Table 1 . SysML dependencies used to model source and sink relations

 1

		Source	Sink	SysML
				dependencies
	Description	Stakeholder requirement	Stakeholder require-	trace
		-Problem space	ment -Solution space
	Prescription System requirement -	System requirement -	trace
		Solution space	Problem space
	Requirement	Requirement level n	Requirement level n+1 Refine, Derive,
	Analysis			Requirement
				containment re-
				lationship …
	Validation	Stakeholder requirement System requirement	satisfy

David Gouyon, Fabien Bouffaron, Gérard Morel Centre de Recherche en Automatique de Nancy Université de Lorraine, CNRS Boulevard des aiguillettes, BP 70239, 54506 Vandoeuvre les Nancy, France e-mail :{david.gouyon,fabien.bouffaron,gerard.morel}@univ-lorraine.fr 1 http://www.bkcase.org 2 http://www.afis.fr 3 http://www.incose.org 4 http://formations.univ-lorraine.fr 5 http://www.ormfoundation.org/. Note that ORM enables to verbalize our specified training facts


Fabien Bouffaron
email: fabien.bouffaron@univ-lorraine.fr

Jean-Marc Dupont

Mayer Frédérique
email: frederique.mayer@univ-lorraine.fr

Gérard Morel
email: gerard.morel@univ-lorraine.fr

Integrative construct for Model-Based Human-System Integration: a case study

Keywords: Human-System Integration, Model Based Systems Engineering, Human-Machine Interaction, Requirements specification

A significant feature of critical systems such as power plants is their control by human operators. For that, they are placed at the field level where they perceive, process and provide the necessary information, which is partially digitalized. Another significant feature of the engineering of these systems is to focus mainly on technical requirements that are further checked by human factors and ergonomics specialists. Improving the cospecification process of these systems as a whole requires providing measurable requirements in order to bring together human and technical aspects of these systems. The resulting issue is to check the balance between the two types of specifications from an early project stage. In that way, we propose a system co-specification framework based on an integrative construct enabling to check the compliance of system requirements with automation and physiological requirements by co-execution of models. This framework is applied on a case-study in order to propose physical-physiological pre-requirements of a sound perception artefact by a field operator. These exploratory works aim to contribute to Model-Based Human-System Integration.

INTRODUCTION

Many critical systems, such as power plants, are largely under human control at the field level even if automation mediates some tasks. It is due to the resilient nature of the human i.e. the capacity of operators to face non-nominal situations presented as the most important characteristic of safety oriented organizations [START_REF] Hollnagel | Resilience: the challenge of the unstable[END_REF].

These critical systems with their enabling supports have to satisfy more and more requirements related to the dynamic nature of the physical process to control, the regulation rules imposed by safety even ethical and ecological standards and various control situations as the return to operational conditions after maintenance actions.

Thus, an important issue is the necessary evolution of current systems engineering (SE) frameworks (Ruault, Vanderhaegen, & Luzeaux, 2012) in order to early balance technical and ergonomic feasibilities to master human-machine task sharing in control operation [START_REF] Millot | Authority and cooperation between humans and machines. Handbook for Human-Machine Interaction[END_REF]. That leads automation engineering to interoperate with Human-Centered Engineering (HCE) [START_REF] Boy | The handbook of human-machine interaction: a human-centered design approach[END_REF] within Systems Engineering [START_REF] Pyster | Guide to the Systems Engineering Body of Knowledge (SEBoK)[END_REF] from early specification stages, in order to keep the system behaviour within an accepted domain of performances whatever the context of use.

This consensus to treat such socio-technical systems as engineering systems [START_REF] Kroes | Treating socio-technical systems as engineering systems: some conceptual problem[END_REF] requires to unify (SE) and (HCE) in order to meet Human System Integration (HSI) [START_REF] Boy | Human-System Integration: Unifying Systems Engineering and Human-Centered Design[END_REF], to which these works could contribute.

Section 2 presents the studied user-automation soundperception interaction within the real context of our domain of interest. Section 3 focuses on a functional construct of this interaction as integrative driver of our requirements co-specification process. Section 4 presents the framework of the integrative physiology in order to model the studied interaction. Section 5 details a particular scenario leading to check the compliance of a co-specification of this interaction with some physical-physiological pre-requirements between the domains of systems and ergonomics engineering. We present in section 6 our ongoing works and future developments in order to improve the readiness level of these exploratory works for meeting real operational HSI issues.

USER-AUTOMATION INTERACTION CASE-STUDY

Some critical power plants, exhibit complex control interactions where operators, i.e control room operators and field operators (FO), interoperate together to perform documented procedures by the means of partially automated devices. The goal is to master the dynamics of a physical and partly 'natural' process by providing the information representation of the plant state to control room operators in order to properly make decisions during normal as well abnormal operations. This representation is partially achieved by the instrumentation and information control systems. However, for business and technical requirements, it is not possible to instrument all components at plant level and about 80 % of the information reported in the control room is not automated but is provided by local operators (FO, chemists, maintenance operator…). For example, the number of manual valves in a power plant is estimated at 20000 units while motorized and pneumatic valves represent only 1350 units of the overall equipment. That highlights the fundamental role of FOs in close control loop with the process as addressed by [START_REF] Galara | Roadmap to master the complexity of process operation to help operators improve safety, productivity and reduce environmental impact[END_REF] to specify the interactions I AU between the automation artefact 1 and the user, to I AP between the automation artefact and the process, and to I UP between the user and the process to control (Fig. 1).

Artefact-Process Interaction I AP

I AP is supported by instrumentation and information control systems aiming "to measure thousands of variables and to process the data to activate pumps, valves, motors, and other electromechanical equipment that control the plant" as addressed by [START_REF] Tsvetkov | Nuclear Power -Control, Reliability and Human Factors[END_REF]. Furthermore, they contribute to form a partially information representation (in the world of logic) of the process part (in the world of physics) but restricted to what can be perceived by instrumentation with the remaining problem of its location.

1 According to [START_REF] Kroes | Treating socio-technical systems as engineering systems: some conceptual problem[END_REF], Artefact to be designed is an object with a specific technical structure embedded in a use plan

User-Process Interaction I UP

Missing information to form a more complete representation of the process to control is collected by FOs. Moreover, FOs work closely to the physical system to actuate a lot of devices which cannot be instrumented [START_REF] Dobre | Improving digital interaction for operatordriven process-plant operation[END_REF]. This I UP stands on human senses (viewing, hearing, smelling, touching) restricted to the external perception of some manifestations of the process, for example the shape, the colour, the perceptible temperature and vibration, and the direct manipulation of valves, pumps,… [START_REF] Galara | Roadmap to master the complexity of process operation to help operators improve safety, productivity and reduce environmental impact[END_REF]. By so doing, FOs perceive and interpret many physical phenomena and provide the necessary amount of information which consequently is not digitalized. In others words, the supervisory tasks could be automated but not the FOs activities, so that it is of importance to check that FOs perceive right to right acting, as studied in another maintenance context [START_REF] Lieber | Improving physical-physiological interaction requirements for maintenance enabling systems specification[END_REF]. So, mastering I UP is vital to face a lot of non-nominal situations which are not under the artefact control.

Artefact-User Interaction I AU

From the past when "control room operators interact with technical parts throughout a large control panel, taking reading from gauges and adjusting knobs and levers, many of today's control rooms have been upgraded, replaced or augmented with visual display units" [START_REF] Carvalho | Human factors approach for evaluation and redesign of human-system interfaces of a nuclear power plant simulator[END_REF]. I AU provides the interface between operators and the related automated/digitalized devices at plant level, including for warning purposes. Nevertheless, the use of such enabling information technology to increase field operators information capabilities remains under debate waiting the assessment of their HSI readiness level.

This overall description of the real context of our domain of interest is compliant with the AUTOS framework [START_REF] Boy | The handbook of human-machine interaction: a human-centered design approach[END_REF], even if some definitions such

as artefact remains open to debate between the HSI communities. Our case-study focus on improving the specification of the interaction I AU of a field operator in the particular situation of maintaining operational an auxiliary feedwater subsystem (AFW) of a power plant when a sound warning occurs (Fig. 2).

Fig. 2. Some I AP , I AU and I UP interactions of our CISPI 2 AFW-like process to control

MODEL-BASED CO-SPECIFICATION FRAMEWORK OF THE STUDIED INTERACTION

A recent study for SE industrial issues [START_REF] Fanmuy | Requirements verification in industry[END_REF] highlights the use of models beyond current practical guidelines in requirements specification to improve the engineering performance of a project.

We pointed out in previous works [START_REF] Lieber | Improving physical-physiological interaction requirements for maintenance enabling systems specification[END_REF] that checking by execution of models the compliance of system technical requirements with ergonomic requirements at an early stage of co-specification could contribute to improve the HSI performance. So, we explored the measurability of physicalphysiological requirements to model an interaction of visual perception such as I AU in a real maintenance situation. These works suggested that the overall system specification process is led by iterative relationships of description and prescription of requirements between the operational domain and the SE domain and between the SE domain and two main specialist domains of ergonomics and automation engineering. The SE domain is responsible to orchestrate these causal specification relationships between problem-spaces (PS) in charge of integrating sub-systems and solution-spaces (SS) in charge of designing sub-systems for satisfying the originating 2 CISPI reflects on a lab-platform some critical features of a real AFW system http://safetech.cran.uhp-nancy.fr/ operational requirements of the desired system as a whole.

In order to improve a lean management of the overall model-centric workflow, our on-going works distribute this co-specification process around a bus (Fig. 3). A main interest is that engineers from various domains can use their own tools, methods, technics in order to interoperate by the mean of a common language, such as the de-facto standardized SysML3 in our case-study The checking of specifications with requirements is performed by co-execution of models in order to replace current technics of code generation and integration which depend on interoperability levels between tools.

Fig. 3. SE-centric distributed co-specification process

In the same way that the 'problem frame approach' of [START_REF] Jackson | The meaning of requirements[END_REF] in software engineering but at the scale of an overall SE process and beyond for HSI, we suggest that the driver of this co-specification process is an early quest for knowledge as design property from any specialist to the system engineer. As revisited by [START_REF] Jin | Revisiting the meaning of requirements[END_REF], we argued that this quest for knowledge explains the role of any concurrent domain knowledge in the overall co-specification iterative process and where these knowledge must be used.

Let's consider some iterations of the co-specification of our studied interaction I AU . The SE solution space (WS SE ) is responsible for the system specification S SE to satisfy requirements R OP from the operational problem space (WP OP ) according to the entailment:

WP OP , S SE  R OP (1)
By keeping in mind HSI issues, a further stage of our iterative co-specification consists for the quest for knowledge from the ergonomics solution space (WS EE ) which is responsible for sub-system specification S EE to satisfy requirements R SE from the SE problem space (WP SE ) according to entailment:

WP SE , S EE  R SE (2)
The same rationale is applied for the quest for knowledge from the automation solution space (WS AE ) for sub-system specification S AE. The balancing checking of these specialist specifications with R SE is performed by co-simulation of models. Thus, by proposing such a distributed iterative co-specification process, we suggest a possible collaborative work, through the SE problem space (WP SE ) , between specialists of ergonomics (WS EE ) and automation (WS AE ) domains to obtain measurable HSI specifications (S EE and S AE ) that satisfy originating operational requirements R OP .

The overall specification effort implies to well define the context where the system under specification will behave and interact with the related entities of this context before to derive its internal structure.

A special attention must be paid to model the external manifestations that the required system has to stand up with its environment entities. The set of phenomena contained in an interaction can change dynamically its behaviour, so that it is important to make explicitly an entity from the interaction [START_REF] Ducroq | Concept of semantial and phenomenon of emergence[END_REF]. Nevertheless, even formal methods depend on cognitive abilities and technical capabilities of the modeller for structuring any overall domain knowledge. So, we suggest using a pattern (Fig. 4) in order to turn the interaction specification into a substantive construct.

The goal is to well define the necessary physical properties of the source automation part (Alarm artefact) which are propagated through the studied interaction to the sink user part (Field Operator). We argue that it is an early pre-requirement of the interaction, even if not sufficient from the overall human factors. Interactions are now entities embedding some domain knowledge (WS EE ) to be structurally and behaviourally specified. Next section focuses on the physical-physiological nature of the studied sound-perception interaction (I AU ). Section 5 illustrates the iterative use of this construct to check the compliance of the studied interaction specification (S EE ) with the problem statement (R SE ). Ergonomics knowledge about the nature of the sound perception interaction I AU focuses on works related to the understanding of the human perception process in order to specify measurable requirements. This integrative physiology framework is mainly based on the works of perception and action physiology by [START_REF] Berthoz | Bases neurales de la décision. Une ap-proche de neurosciences cognitives[END_REF] and more generally on works dealing with Mathematical Theory of Integrative Physiology (MTIP) by [START_REF] Chauvet | Hierarhical functional organization of formal biological systems: a dynamical approach, I to III[END_REF].

Our rationale of selecting the MTIP is linked to the functional representation of a living system which related framework supports a physiological processbased modeling, like others technical process-based modeling. These physiological processes are hierarchically organized within space and time scales and stimulated by a set of functional interactions such I AU that spread over structural discontinuities (Fig. 6).

Such discontinuities modify the nature of I AU that is of importance when transmitting a physical flow from a source entity to a sink physiological entity. We argue that I AU is a physical-physiological interaction, meaning that a physical flow is propagated from a physical environment to a physiological one before to be transmuted into a biological flow.

Fig. 6. Perceptive Functional Interaction I AU between a source (sound signal) located in r' and a sink (human organic unit) located in r.

From our precedent works on the visual perception [START_REF] Lieber | Improving physical-physiological interaction requirements for maintenance enabling systems specification[END_REF], we revisit the nature of the physicalphysiological interaction modeling in terms of power in order to unify HSI modeling with current technical modeling. More generally, and whatever the nature of sensory perception, a transduction mechanism leads to converse the physical-physiological interaction as an electrical current, that propagates through the cerebral tissue [START_REF] Purves | Neuroscience[END_REF]. The electrical dynamics can be treated in terms of transported power through circuits (Emanuel, 2010) and therefore some functional interactions could be regarded as a transported power.

Depending on the available biological data, we focus to identify the right physiological entity (Sink) to specify the right physical flow required by the technical entity (Source) in order to stimulate the cognition. Fig. 5 depicts the physiological point of view of our case study.

Fig. 5: A technical source (Alarm) located in the physical environment interacts with a physiological sink (eardrum) located in the biological environment.

CO-SPECIFICATION OF THE STUDIED PHYSICAL-PHYSIOLOGICAL INTERACTION

The modeling of the studied physical-physiological interaction is constraint by our functional construct (Fig. 4) into three SysML blocks related to the Artifact-Source, the Interaction Sink-Source and the User-Sink.

According to entailment (2), each block provides a part of the specification S EE from which the compliance with the system requirement R SE is checked by execution of models.

Sound User Block

The human ear can detect sounds in a frequency range from about 16 Hz to 20 kHz (between the infra and ultra -sounds) within a frequency-dependent power (usually expressed in log units known as decibels, abbreviated dB) and represented by a specific human hearing area (Human Hearing Ranges) [START_REF] Goldstein | Encyclopedia of Perception Sage Publications[END_REF]. The pressure wave quantity received by the eardrum through the external auditory meatus is transmitted to the inner ear before to be transmuted into an amount of electrical power.

The effective auditory perception (at the sink level) needs also a sufficient duration of hearing according to the measurable requirement U 11 [START_REF] Müller | Handbook of Engineering Acoustics Springer Editions[END_REF].

(Part: Hearing_System_Sink:Human_To_Perceive_Situation in Fig. 8).

And to facilitate the hearing of the sound source location, the binaural system (having or relating to two ears) should satisfy the geometrical (or space) measurable requirement U 12 [START_REF] Warren | Auditory Perception -An Analysis and Synthesis[END_REF].

Note that this last requirement is source of an interoperation with another ergonomics sub-specialist within the HCE domain acting as architect for human factors [START_REF] Lieber | Improving physical-physiological interaction requirements for maintenance enabling systems specification[END_REF].

Sound Interaction Block

For sound perception, the interaction is a pressure wave (wave behavior of the interaction). Its intensity can be evaluated the decimal logarithm of the ratio of two pressures, the first one is the RMS (Root Mean Square) sound pressure or effective sound pressure and the second one is the standard reference sound pressure in air (equal to 20 µPa). The square of the pressure is proportional to the sound power measured in W.m -2 [START_REF] Müller | Handbook of Engineering Acoustics Springer Editions[END_REF]. (Part: Sink_Source:Interaction_IAU in Fig. 7) Some of its physical proprieties as velocity could be modulated, or altered by some environmental characteristics, as temperature or humidity [START_REF] Müller | Handbook of Engineering Acoustics Springer Editions[END_REF]. Moreover, as human operators are immersed in a noisy environment within the most of industrial sites such as critical power plant, this background noise or ambient noise could be regarded as a sound interaction. This noisy pollution can go in competition with other intelligible sound interactions (as an audible alarm) and therefore can mask them. A new measurable requirement UA 1 can be directly specified from French security standard (NFS 32011).

Sound Artefact Block

The required quantity of 'pressure waves' depends directly of the propagated one from the sound source (alarm for example) according to the measurable requirement A 1 (Müller, & Möser, 2012) (Part: Alarm_Source:Technical_To_Actuate_Situation in Fig. 7).

The interaction construct allows ergonomics engineer to design and to structure its specification S EE as a set of requirements related to each block: S EE = {U1, U11, U12, UA1, A1}. This specification S EE is structurally represented with the system engineer by a SysML Internal Block Diagram (IBD) (Fig. 7). Note that an ergonomics solution space doesn't have the knowledge to specify the bloc "Alarm_Source". This task will be performed by automation engineer according to system engineering requirement (R SE ) but also ergonomics engineering specification (S EE ) which prescribes the necessary physical requirements to perceive an audible alarm.

Checking specification S EE

In order to verify and to validate the S EE specification, the static resulting SysML block must be dynamically executable by simulation (Fig. 7). SysML diagrams (IBM Rhapsody®) and functional block diagrams (Matlab/Simulink®) which implements the physicphysiological behaviors can be co-executed.

Sound Duration Sink

«Functional» ID = U11
Duration of the heard sound shall be at least equal to period that is the inverse of the frequency (for a pure sound and expressed in second)

Sink_From: Ergonomics_Engineering_SS Source _To: Systems_Enginnering_PS Sound Anthropometric Alignement Sink «Functional» ID = U12
The anthropometric axes shall be aligned in order to satisfy the binaural system in the localization of the sound source The sound source shall generate sound waves within a frequency w between 16Hz and 20kHz and a sufficient frequency-dependent power E.

Sink_From: Ergonomics_Engineering_SS

Source _To: Systems_Enginnering_PS The behavior of the User-Sink Block is simulated with current available date in order to define the area of right perception of the hearing field (Fig. 8).

CONCLUSION AND FUTURE WORKS

We propose an integrative construct in order to orchestrate the iterative co-specification of an Artefact-User Interaction between a system engineering domain and two main ergonomics (physiology) and technical (automation) specialist domains. These works are based on the physicalphysiological modeling of this type of interactions in order to check its compliance with a system specification by co-execution of models. Although this approach depends on the available biological data, others related environments are providing physiological models4 and can be integrated within our co-simulation environment.

Others works within the same co-specification framework are focusing on the interpretation of the sensory functional interactions I AU and I UP in terms of power and in terms of the main senses (viewing, hearing, smelling, touching) involved in a real context of critical power plant control. We are also exploring to enlarge the definition of the User-Sink Block behaviour by others modeling techniques such as design of experiments in order to better check the compliance of the interactions specification with operational requirements.

Proof of concept of these exploratory works is actually performed on the CISPI lab-platform environment and must be developed to meet higher levels of technology readiness to an operational environment. These increasing levels of maturity imply to refine the external conditions which modify the behaviour of sensory interactions.

These works, as well as our co-specification and cosimulation environment with the use of SysML could contribute to meet HSI issues

Fig. 1 :

 1 Fig.1: Interactions between process, user and automation parts during process control

Fig. 4 .

 4 Fig.4. Interaction and control constructs of our control pattern related to Fig.2

  shall generate sound waves with a sound intensity (dB) at least a sound intensity greater than 10 dB with respect to the intensity (dB) of the background noise

Fig. 7 :

 7 Fig.7: Specification S EE of audible alarm (Source) perception by a human (Sink) represented in SysML IBD

Fig. 8 .

 8 Fig.8. Current human hearing range depending on the frequency and the intensity of the sound wave

OMG Systems Modeling Language (OMG SysML) http://www.omgsysml.org/

http://www.physiolibrary.org/