Romaric Guillerm
email: guillerm@laas.fr

Hamid Demmou
email: demmou@laas.fr

Nabil Sadou
email: nabil.sadou@supelec.fr

Safety evaluation and management of complex systems: A system engineering approach

Keywords: system engineering, safety, requirements, EIA-632, SysML

This paper addresses the problem of safety evaluation of complex systems. It proposes an original and rigorous approach that integrates safety analysis in system engineering processes. The approach is based on system engineering (SE) principles and uses the famous industrial SE standard ANSI/EIA-632. The objective is to help designers and safety engineers in safety management of complex systems. For an efficient design, the model driven design is adopted through the definition of an information model. The system language SysML (System Modeling Language) is used to address requirements definition and their traceability towards the solution and the Verification and Validation (V&V) elements. This common language allows sharing information between the different persons involved in the design project like system engineer and safety engineer.

Introduction

Complex systems are systems with numerous components, interconnections, interactions or interdependencies that are difficult to describe, understand, predict, manage, design, and/or change [START_REF] Magee | Complex System Classification[END_REF]. In these systems, a change in one part may have effects on other parts of the system.

Most of modern systems are inherently complex (Bar-yam, 2005). This complexity makes the systems engineering processes (including acquisition and supply, technical management, system design and technical evaluation processes) more critical and difficult. So, performing of important system level proprieties such as reliability, safety and security (Avizienis and al, 2004) become difficult. Indeed, safety of complex systems relies heavily on the emergent properties (Levenson, 2004), (Black and Koopman, 2009) that result from the complex interdependencies that exist among the involved systems and their environments. It is necessary to address safety properties in an overall study, early in the design phase.

For an effective analysis, safety processes have to consider some constraints. The most important ones, listed in [START_REF] Guillerm | Information model for model driven design of complex system based on system engineering approach[END_REF], are:

1. The emergent aspect of safety properties imposes to consider safety not only in the small but also in the large (at system level). 2. Different persons involved in the project need to work with different views of the system (e.g. systems engineer's view, safety engineer's view). It is necessary to guaranty the consistence of these different views. 3. Requirement engineering is a critical process in system engineering. So, safety requirements and their traceability need a particular attention. Taking into account these constraints allows to improve complex system development and to overcome the limitation and weakness (Rasmussen, 1997) of the actual safety evaluation processes.

Requirements engineering (RE) (Sommerville, 2006) is a critical system engineering process [START_REF] Juristo | Is the European Industry Moving Toward Solving Requirements Engineering Problems[END_REF]. It is a key problem area in the development of complex systems (Brooks, 1987). A common classification defines two types of requirements; functional and non-functional [START_REF] Robertson | Mastering the Requirements Process[END_REF]. Functional requirements describe the services that the system should provide. Nonfunctional requirements are related to emergent system properties (such as safety) and cannot be attributed to a single system component. This shows the necessity of a global approach for safety management, from the requirements definition to the system verification and validation, which is fundamental for the success of the system design project.

To deal with these different aspects, we propose a global approach for safety analysis. Indeed, safety must be addressed as a global property and safety requirements [START_REF] Gotel | An analysis of the requirements traceability problem[END_REF]) must be formulated not only in the small (sub-system level) but in the large (system level). Two aspects of requirements engineering are considered: the requirements development (including elicitation [START_REF] Goguen | [END_REF], documentation, analysis and validation processes), and the requirements management (including maintainability management, changes management and requirements traceability processes [START_REF] Parviainen | Requirements Engineering: Dealing with the Complexity of Sociotechnical Systems Development[END_REF].

A literature review shows some works that attempt to address the safety evaluation of complex system. For example, safety standards (as the ARP-4754) are useful to understand activities related to safety evaluation, but they don't define a unified approach with the nominal conception activities. This means that safety activities are not integrated in the system engineering processes. Recent projects like ESACS (Bozzano & al., 2003), ISAAC (Akerlund, 2006), ASSERT (Conquet, 2008) which deal with safety of complex systems don't provide a real global approach. They are focused on methods and tools that can be used in safety evaluation. In other works like those presented in [START_REF] Leveson | [END_REF], in addition to the fact that safety aspects are separated from the design activities, the proposed methodology is clearly oriented to software domain.

This paper presents two aspects of our work on safety evaluation of complex system. The first part concerns the integration of safety management in system engineering process. The objective is to help engineers by proposing a new approach based on system engineering best practices. It uses the recommendation of the system engineering standard EIA-632 [START_REF] Guillerm | Information model for model driven design of complex system based on system engineering approach[END_REF].

The second part presents an information model based on SysML language [START_REF] Sanford | A Practical Guide to SysML The Systems Modeling Language[END_REF] to address requirements definition and their traceability [START_REF] Gotel | An analysis of the requirements traceability problem[END_REF], (Sahraoui, 2005) towards the solution elements and the V&V (Verification and Validation) elements. Safety requirements are integrated on RE activities, including management activities related to maintenance, and traceability.

The paper is structured into five sections. The second section introduces the design framework. The integration approach is then presented in the third section. In the fourth section, the information model is proposed for efficient management of safety requirements. The last section gives some conclusions and future works.

The systems engineering framework for complex system development

System engineering is a methodical and disciplined approach for the design, realization, technical management, operations, and retirement of a system. It is a collaborative and interdisciplinary process of resolution of problems, supporting knowledge, methods and techniques resulting from the sciences and experiment for defining a system. System engineering concepts are adequate specifically for complex problems; research issues undergone can bring a solution [START_REF] Sahraoui | Issues in systems engineering research[END_REF].

In this part, we introduce some concepts of system engineering and the standard EIA-632 which are the basis of our safety global approach.

System engineering concepts

System engineering (SE) is the application of scientific and engineering efforts to transform an operational need into a design solution, with a description of system performance parameters and system configurations, through an iterative process of definition, synthesis, analysis, design, test and evaluation. SE is an interdisciplinary approaches that: 1. Encompasses the scientific and engineering efforts related to the development, manufacturing, verification, deployment, operations, support and disposal of systems products and processes. 2. Develops needed user training, equipment, procedures and data. 3. Establishes and maintains configuration management of the system. 4. Develops work breakdown structures and statements of work, and provides information for management decision-making.

SE is an appropriate combination of methods and tools for suitable methodological process and systems management procedures.

We distinguish three levels in SE, as illustrated in Figure 1. The first level, "SE processes", focus on high-level issues, high-level requirements such as business needs and strategic needs and methods.

The second level, "SE methodologies and methods", deals with all technical issues such as systems requirements and design methodologies.

The third level, "SE tools or technologies", covers the implementation issues concerning the tools to be used, the required technologies to respond to the various assets of requirements such as reliability costs, maintainability and enabling technologies. These entities, such as processes, methods and tools, are the conceptual basis of our approach taken from SE best practice. In the first step, the processes can be identified with respect to the accumulated know-how. The second step concerns the methods to be used. The methods can be either developed or may be existing methods. Implementing the process, one method cannot be chosen for its flexibility or popularity, but only if it reflects the semantics of the process. No taxonomy has yet been developed for corresponding processes and methods. The third step concerns the tools that do not correspond to the processes but to the methods; hence in this approach we cannot use a tool to implement a process without first identifying the associated methods.

EIA-632 standard

The beginnings of systems engineering can be traced back to the Bell Telephone Laboratories in the 1940s (Auyang, 2004). Thirty years later, the first U.S. military standard was published (MIL-STD-499A, 1969.). It is focused on systems engineering, providing the first definition of the scope of engineering management. Nowadays, the standard ANSI/EIA-632 "Processes for Engineering a System", which provides a typical systems engineering Work Breakdown Structure [START_REF] Valerdi | [END_REF], is one famous standard, currently used in the industrial and military fields. This standard covers the product life-cycle from the needs capture to the transfer to the user. The processes are well described by the following Electronic Industries Alliance (EIA) standard (Figure 2). It is constituted by 13 processes (EIA-632, 1999) covering the management issues, the supply/acquisition, design and requirement, verification and validation processes:

1. Technical management processes (three processes): these processes monitor the whole process ranging from the initial idea to building a system until the delivery of the system. 2. Acquisition and supply processes (two processes): these processes ensure the supply and acquisition (and are very close to logistics). 3. System design processes (two processes): these processes deal with the elicitation and the acquisition of requirements and their modelling, the definition of the logical design and its physical solution. 4. Product realisation processes (two processes): these processes deal with the implementation issues of the system design and its use. 5. Technical evaluation processes (four processes): these processes deal with verification, validation and testing issues. In the work presented in this paper, we focus on the system design process and the technical evaluation process. Note that other processes will be considered in future works.

Integration approach

As said in the introduction, safety of complex systems relies heavily on the emergent properties. System Engineering is an ideal framework for the design of complex systems and the need for systems engineering arose with the increasing complexity of systems and projects. This work for safety integration in SE processes (system engineering approach) is based on the assumption that the safety property can only be treated adequately in their entirety, taking into account all variables, social and technical aspects [START_REF] Kotovsky | Why are some problems hard? Evidence from Tower of Hanoi[END_REF]. This basis for system engineering has been stated in the principle that a system is more than the sum of its parts. The starting point of the work presented in this paper is the following note provided in EIA-632 standard:

Note: Standard does not purport to address all safety problems associated with its use or all applicable regulatory requirements. It is the responsibility of the user of this Standard to establish appropriate safety and health practices and to determine the applicability of regulatory limitations before its use. (EIA-632, 1999).

So, following this note, this section provides the approach that aims to guide designers in addressing safety problems. It describes for each process, how the safety must be considered.

Note that, in reference to SE chain, the proposed approach is illustrated in term of process, which must be defined independently to methods and/or tools. Other projects are focused on methods and tools (see (Akerlund, 2006) and (Bozzano and al, 2003) for example).

The Safety management must follow all steps (processes) of SE from the requirements definition to the verification and the validation of the system. This paper is focused only on:

• System Design processes in which we address requirements definition processes and the solution definition processes. • Technical Evaluation processes with the system analysis process, the requirements validation process and the system verification process. The implementation of the approach consists in identifying and indicating how safety must be considered for each sub-processes of EIA-632.

System design processes

The System Design Processes are used to convert agreed-upon requirements of the acquirer into a set of realizable products that satisfy acquirer and other stakeholder requirements (EIA-632, 1999). Two processes are involved: the Requirements Definition process and the Solution Definition process. The interaction between these processes is shown in Figure 3.

Requirement definition process

The objective of the Requirements Definition Process is to transform the stakeholder requirements into a set of technical requirements. For functional and nonfunctional requirements, if this distinction is not possible at the requirement elicitation process level, an analysis may be done in order to categorize requirements. Two types of requirements are defined: the Stakeholder Requirements and the System Technical Requirements.

Concerning Stakeholder Requirements, the developer shall define a validated set of acquirer requirements for the system, or portion thereof.

Generally, safety requirements correspond to constraints in the system. It is necessary to identify and collect all constraints imposed by acquirer to obtain a safe system. A hierarchical organization associates weight to safety requirements, following their criticality.

For Technical Requirements, the developer shall define a validated set of system requirements from the validated sets of stakeholder requirements. For safety requirements, the system technical requirements traduce system performances. It consists on defining safety attributes (Determine risk tolerability, SIL level, MTBF, MTTR for example). Safety requirements can be derived from different sources. The first source is the stakeholders. In this case classical requirements elicitation methods can be used [START_REF] Coulin | Towards a collaborative and combinational approach to requirements elicitation within a systems engineering framework[END_REF]. The second source is constituted by standards which guide designer to define safety requirements. For example, safety critical systems within the civil aerospace sector are developed subject to the recommendations outlined in (ARP-4754, 1996) and (ARP-4761, 1996). These standards give guidance on the 'determination' of requirements, including requirements capture, requirements types and derived requirements. The third source is outputs of risk analysis. The identified hazards are evaluated in terms of likelihood and severity by means of risk assessment. Architectural design decisions are then made upon choosing appropriate risk mitigation strategies or actions, and safety requirements are defined in response to the chosen mitigation mechanisms [START_REF] Wu | Deriving Safety Requirements as Part of System Architecture Definition[END_REF].

When requirements are defined, it is possible to define some attributes to facilitate their management, for example with an expression of requirements using SysML [START_REF] Sysml | SysML Merge Team, Systems Modeling Language (SysML) Specification[END_REF], (Bock, 2006) or UML 2 (Friedenthal and Kobryn, 2004). It is possible to link requirements to the design solution. This point will be presented in the 4 th section.

Solution Definition Process

The Solution Definition Process is used to generate an acceptable design solution.

For Logical Solution Representations, the developer shall define one or more validated sets of logical solution representations that conform with the technical requirements of the system. Formal or semi-formal models (UML, SysML, Petri net, finite-state machine…) are recommended in this process for the solution modeling. The use of formal methods allows the automation of verification and analysis. In this processes, safety analysis techniques will be used to determine the best logical solution.

The Physical Solution Representations are derived from logical solution representation and must respect all requirements, particularly safety requirements. The same safety analysis may be done when the physical solution representation is available. The same recommendations than for logical solution remain true. However, when approaching the physical solution, it appears that the semantics of SysML does not seem quite complete. So it is possible to use architecture languages such as AADL (Aer, 2004), VHDL-AMS [START_REF] Verries | From design with SysML to VHDL-AMS simulation[END_REF]al, 2008) (Vhd, 1999), SystemC-AMS… As this design process progresses, details of the system are obtained. So, the hazards analysis will be refined and new hazards may emerge. The Chosen mitigations may themselves bring new safety problems. Therefore, new risk mitigation actions may need to be identified and safety requirements refined. The process evolves (see System design process) until all identified hazards have been mitigated sufficiently in an acceptable manner.

Technical Evaluation Processes

The Technical Evaluation Processes are intended to be invoked by one of the other processes for engineering a system. Four processes are involved: Systems Analysis, Requirements Validation, System Verification, and End Products Validation. The relationship between these processes is shown in Figure 4.

System Analysis Process

The Systems Analysis Process is used to: (1) provide a rigorous basis for technical decision making, resolution of requirement conflicts, and assessment of alternative physical solutions; (2) determine progress in satisfying system technical and derived technical requirements; (3) support risk management; and (4) ensure that decisions are made only after evaluating the cost, schedule, performance, and risk effects on the engineering or reengineering of the system (EIA-632, 1999).

In this process safety is involved at each item. Indeed, (1) in the case of requirement conflict, higher priority requirements must be safety ones. These requirements are used in the assessment of alternative physical solutions. (2) The designer has to determine the satisfaction of system technical requirements and derived technical safety requirements. The interest of using semi formal model for requirement traceability analysis becomes obvious. (3) The risk management is used to develop risk management strategies of the design project. (4) Safety aspect can generate additional cost. The designer has to evaluate this cost.

Fig.4. Technical evaluation processes

Requirements Validation Process

Requirements Validation is critical to successful system product development and implementation. Requirements are validated when it is certain that they describe the input requirements and objectives such that the resulting system products can satisfy them.

In this process, a great attention is given to traceability analysis, which allows verifying all the links among Stakeholder Requirements, Technical and Derived Technical Requirements, and Logical Solution Representations. Like other requirements, safety requirements must be validated.

Frequently, specifications are written in natural language and are the base of the design, test and validation phases. The natural language can be ambiguous. The consequence is that the requirements can be differently interpreted. It is thus necessary to propose a method of progressive refinement of the requirements towards models with known semantics allowing their formalization.

To facilitate the step of requirements validation, semi-formal solutions, like UML (Booch and al, 1998) or SysML (Bock, 2006) can be used for good formulation of requirements. Indeed, the diversity of people concerned by design project can have limited knowledge concerning the structure of the future system, that's why industryscale requirement engineering projects are so hard. Thus, the UML or SysML languages, with their different diagrams, can be helpful.

System Verification Process

The System Verification Process is used to ascertain that the generated system design solution is consistent with its source requirements, in particular, safety requirements.

In case of safety verification, when the agreement between designers and safety teams is obtained, a last safety analysis called System Safety Assessment (SSA) is done to consolidate the product from the safety point of view. Some traceability models allow defining the procedure of verifying safety requirement. These procedures are planned at the definition of safety requirement. Simulation [START_REF] Zeigler | Theory of modelling and simulation[END_REF] is an appropriate method that can be used to achieve system verification. Other methods like test, virtual prototyping or model checking are also used.

Requirements engineering is an important phase in a system design. It is important to perform it correctly for project success [START_REF] Juristo | Is the European Industry Moving Toward Solving Requirements Engineering Problems[END_REF]. This activity is difficult in case of complex systems. Requirements formalization can help the designers in their requirements engineering activities. The introduction of models can be useful to achieve the formalization task. Model-driven engineering, in which models are the main artifact during system development, is an emergent approach that tries to address system complexity by the intensive use of models. In this part we present an information model based on SysML to properly define and manage requirements and particularly safety requirements.

Requirements management

In complex systems engineering, an important number of documents is produced specially during the system definition phase. Statistical studies show that the success of a project depends strongly on the definition and the management of requirements. Requirements management allows to collect requirements, to facilitate their expression, and to validate them. It must also ensure that each requirement is properly declined, allocated, monitored, satisfied, made verifiable, verified and justified.

Figure 5 presents an overview of the requirements relationships as defined in the EIA-632 standard. The proposed information model follows this pattern. We see that other stakeholder requirements, when added to the acquirer requirements, make up a set of stakeholder requirements that are transformed into system technical requirements. The logical and physical solution representations are derived from technical requirements. Design solution and specified requirements are defined by completing the solution definition Process.

Role of the information model

The information model can be considered as a database used to share and capitalize knowledge. It is accessible for the persons involved in the design project and aims to guide the design process. It is also used to manage requirements changes, and then evaluating the project progress.

When different views exist in the design team as it is often the case (design engineer's view, safety engineer's view for example) the information model makes the system more understandable as it is based on a common language.

When transforming needs into system definition, modeling can help to properly achieve this task. Indeed, during this transformation, we will gradually go from abstract concepts to a rigorous definition of the system.

In modeling, there are 2 separate areas: the problem area and the possible solutions area. At the beginning of the project, the representation of the problem area is more important than the representation of the possible solutions area. During the progress of the design, representation of possible solutions area will be enriched to achieve the strict definition of the system. In parallel the overall representation of the problem area will be enriched to better define the expectations of the system (needs/requirements) and will stabilize itself. The transition between the problem domain and the solution domain is a very delicate point of system engineering. It must be expressed by allocating requirements/properties/constraints on possible solutions. These allocations will generate traceability links, which are crucial for the system verification and validation activities. We propose an information model, based on SysML language that will be compatible with the requirements management of the standard EIA-632, to takes into account safety and risk management aspects.

Systems Modeling Language (SysML)

SysML is a systems modeling language that supports specification, analysis, design, verification and validation of a broad range of complex systems. The language is an evolution of UML 2.0 and is defined for systems that may include hardware, software, information, processes and personnel. It aims to facilitate the communication between heterogeneous teams (mechanical, electrical and software engineers for instance). The language is effective in specifying requirements, architecture, and behavior. It allows the allocation of elements to models and the definition of constraints on system properties to support engineering analysis. SysML allows the modeling and supports different views:

• The requirements view: using requirements diagram and use case diagram,

• The structure view: based on block diagram (internal/external),

• The behaviour view: using statechart diagram, activity diagram, and sequence diagram, • The constraints view: with parametric diagram. SysML seems to be an excellent candidate for a common language. It allows sharing specifications of a complex system between different trades, between design engineers and safety engineers in our case. SysML allows expressing the requirements using the requirements diagram. It also defines some relationships that link a given requirement to other requirements or elements of the model. With SysML, it is possible to have:

• A definition of hierarchy between requirements,

• requirement derivation,

• requirement satisfaction by a model element,

• requirement verification by a test case (TestCase) or • requirement refinement.

With SysML we can create traceability links between requirements and system components. These links allow performing impact analysis of requirements change or modification. Thus, it is possible to assess the consequences of a requirement change on the system safety using the links defined between requirements, functions and components.

SysML Extension

The SysML language proposes basic concepts (like requirements or blocks) for which some attributes are associated. The Semantic of SysML is enriched through the extension mechanism, in order to adapt it to our approach. We define more detailed requirement element, several types of requirements, and also additional traceability links.

Enriched requirement

The concept of requirement is fundamental in system design. In SysML a specific diagram is dedicated to requirements with a possibility to define traceability links for requirements. The objective is to guide the development (by linking needs to the design solution) and to facilitate the verification and validation phase or the management of requirements changes. Figure 6 shows SysML stereotype requirement definition. Requirement in SysML is composed by two attributes: an identifier (Id) and the description of the requirement (Text). The definition of stereotype requirement is enriched in order to adapt it for our need. This is done by adding some new attributes that are inspired form the RPM profile (Requirement Profile for MeMVaTEx) (Albinet and al, 2008), the recommendation of AFIS (the French association of system engineering) (AFIS, 2005) and the Snow Card Volere (Roberston, 2010). As shown in the Figure 7, these attributes are:

• Category: shows if the requirement is functional or non-functional (reliability, availability, safety, performance, cost or maintainability…), • Justification: description of the justification of the requirement (why this requirement?), • Source: acquirer, other stakeholder, standard, regulatory authorities, risk analysis, • Target: end product or enabling products (development, production, test, deployment, training, support or disposal product…), • Maturity: to inform about the life phase (or status) of the requirement: original, defined, validated or verified, • Criticality: low, medium or high, used to characterize the importance of the requirement in terms of risk, • Flexibility: low, medium or high, • Priority: low, medium or high, used to differentiate a mandatory requirement from an optional one. We define new stereotypes for requirements (see Figure 8). These stereotypes are based on the classification of requirements in system engineering (particularly in the standard EIA-632, see figure 5). So, it is possible to create and define requirements of "acquirerReqt", "otherStakeholderReqt", "systemTechnicalReqt" or "specifiedReqt" stereotype. These new requirements stereotypes facilitate the distinction between the different types of requirements.

Risk stereotype

Concerning safety requirements, which can be derived from risk analysis, a block risk is defined and is linked to safety requirements (see figure 9). In fact, identification of risks is the starting point for many studies about safety/reliability. Thus, defining a block "risk" in the information model and linking it to the safety requirements, allows to improve the comprehension of the presence of some safety requirements and to justify them. The ultimate objective is to improve the safety analysis of the system.

Presentation of the information model

As said previously, the information model is based on SysML and follows the SE process (EIA-632 standard). It is considered as the "system" knowledge basis of the design project, allowing data sharing between all different trades (mechanical, hydraulic, thermal, electrical...). Therefore, it is intended to model the "system" level, showing the interactions between the system and its environment and also the connections between subsystems. The 3 basic concepts of system design are: requirements, design solution and V&V (Validation and Verification). All these concepts are included and represented in the information model.

Safety authorities impose a separation of system design concepts (requirements, design solution and V&V). They must be developed independently. From this observation, the proposed approach allows the expression of these concepts, with a clear separation between them. However Traceability mechanisms are provided to link these concepts in order to facilitate impacts analysis. We propose a way to use SysML that allows structuring the elements of the design project with respect to the concepts separation (see Figure 10). In other words, our approach allows a rigorous organization of the project design. Indeed, different diagrams manage different concepts.

Fig.10. Package diagram of concepts separation

In the information model (Figure 11), we can see that all types of requirements are represented. We see that they follow the EIA-632 standard recommendations. All traceability links required by the EIA-632 are present in this model, and the distinction between logical solution (functional part) and physical solution (component part) appears.

Fig.11. Information model

In this model, we highlight the definition of interfaces, which are components themselves and which links several components together. The concept of interface is essential for a proper system design. Indeed, some problems encountered during development can result from a bad definition of interfaces.

The last important element included in this model, other than requirement and solution element, is the "TestCase". These elements of V&V are included in the model to be directly connected to the requirements that must be satisfied by the TestCase.

Conclusion

In this paper we presented a new approach for safety evaluation of complex systems. The contribution consists of two main points. The first one concerns the integration of safety in system engineering processes. The proposed methodology is based on EIA-632 system engineering standard and aims to help engineers involved in a design project to manage the safety aspect of the system in parallel to other design activities. It allows an explicit consideration of safety in systems engineering process by defining the specific activities related to safety. All system engineering processes, from requirements definition process to verification and validation process, are concerned by the integration approach. As the approach is based on the EIA-632 standard and follows the different processes and sub-processes of this one, it can be incorporated easily into systems engineering concepts. This gives a framework for safety management showing that the SE concepts are adequate, specifically for complex problems.

Requirements engineering is a crucial activity in the design of complex system. The second contribution of the paper is the proposition and the definition of an information model based on the SysML language. It is done by an extension of this language by adding new stereotypes and new attributes to requirements. We also defined new links (specify and treat) between specified requirements and the elements of the model.

The proposed information model allows the expression of the handled concepts (requirements, design solution and V&V), and the creation of traceability links between these concepts in order to facilitate the comprehension and/or the impacts analysis. The proposed approach formalizes the practice of systems engineering through the use of models. The objective is to improve quality/productivity and to reduce risk by introducing rigor, precision, and communications among system/project stakeholders and managing complexity.

The approach is demonstrated through an example from aeronautic domain and presented in (Guillerm, 2011). However, the approach needs an additional work for its validation and application.

Future work will consist on considering other EIA-632 processes. Indeed in the present paper we considered only the processes of system design and evaluation. The consideration of processes like technical management or acquisition and supply will complete the integration approach.

With regard to information model, we are studying the interest of using OCL (object constraint language) in order to formalize the requirements. The objective is to integrate this possibility in the information model. Another point concerns the definition of some analysis from the information model, such as the generation of traceability matrix.

Fig. 1 .

 1 Fig.1. Three levels of system engineering.

Fig. 2 .

 2 Fig.2. System engineering processes (source EIA-632)

Fig. 3 .

 3 Fig.3. EIA-632 System design process.

Fig. 5 .

 5 Fig.5. Requirements relationships: EIA-632 model.

Fig. 6 .

 6 Fig.6. The requirement stereotype in SysML.

Fig. 7 .

 7 Fig.7. Proposed requirement model

Fig. 8 .

 8 Fig.8. Requirements stereotypes

Fig. 9 .

 9 Fig.9. From risk to safety requirements

 (Aer, 2004) FM 2003. Pisa, 8-14 September 2003(Brooks, 1987) Brooks, F.P. Jr. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer, 10-19, April 1987.


R Guillerm
email: rguiller@laas.frdemmou@laas.fr

H Demmou

N Sadou

System engineering approach for safety management of complex systems

Keywords:

This paper presents a system approach for safety management of complex system. System engineering which is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed is the framework of the approach. It allows taking into account the safety requirements in system engineering process to facilitates traceability of these requirements throughout the life cycle of the system. Processes of EIA-632 system standard are used to guide the proposed approach.

Introduction

The system engineering process becomes more critical as our systems increase in size and complexity. Important system-level properties, such as safety and security [START_REF] Avizienis | Basic Concepts and Taxonomy of Dependable and Secure Computing[END_REF], must be built into the design of these systems from the beginning; they cannot be added on or simply measured afterward. Systems are changed. These changes are stretching the limits of current safety engineering approaches and techniques. These changes are challenging both safety processes, methods and tools. They concern: • Changing regulatory and public views of safety Rasmussen has argued that major accidents are often caused not by a coincidence of independent failures but instead reflect a systematic migration of organizational behavior to the boundaries of safe behavior under pressure toward cost-effectiveness in an aggressive, competitive environment [START_REF] Rasmussen | Risk Management in a Dynamic Society: A Modelling Problem[END_REF].

•
Weaknesses of the current safety processes (figure 1) can be resumed in the following points (non exhaustive list):

• Safety analysis involve some degree of intrinsic uncertainty. So, there is a degree of subjectivity in the identification od safety issues.

• Different groups need to work with different views of the system (e.g. systems engineers view, safety engineers view). This is generally a benefit but it can be a weakness if the views are not consistent.

• Definition of the safety requirements and their formalization.

• Traceability of safety requirements.

• Existing / traditional safety analysis techniques are difficult to use on modern, complex systems.

• Textual description of failure modes is often too ambiguous.

• System models are developed in electronic form, but no use is made of this for Safety/ Reliability analysis. Ideally there should be a common repository of all requirements, design and safety information.

Some points are due to the absence of a safety global approach. Indeed, safety must be addressed as global property and safety requirements (3) must be formulated not only in the small but in the large. For example, the Ariane 5 and Mars Polar Lander losses are examples of system accidents. In both of these accidents, the components did not fail in terms of not satisfying their specified requirements. The individual components operated exactly the way the designers had planned the problems arose in the unplanned or misunderstood effects of these component behaviors on the system as a whole, that is, errors in the system design rather than the component design, including errors in allocating and tracing the system functions to the individual components. The solution, therefore, lies in systems engineering. A global approach is so necessary. Indeed, safety is clearly an emergent property of systems. Some of these points are addressed by ESACS and ISAAC projects. ESACS project (4) developed a methodology and a platform that helps safety engineers automating certain phases of their work.

The ESACS platform can be used as a tool to assist the safety analysis process from the early phases of system design to the formal verification and safety assessment phases. It gives a partial response for the weakness cited above but it focused on the use of formal methods for safety assessment and does not propose a global approach do achieve it. For example, traceability of safety requirements and Human risk analysis are not considered. ISSAC European project (5) which is the continuation of ESACS project proposes to take into account human errors analysis. It is achieved by injecting human errors in the formal model. Nevertheless, these two projects are essentially concentred on formal method for safety assessment and not really in a global approach to achieve it. ASSERT is another project, but, like above projects (ESACS and ISSAC), it focused on the method and tool. Moreover, only software failures are considered.

The norme IEC 1508 ( 6), [START_REF] Brazendale | IEC 1508: Functional Safety: Safety-Related Systems[END_REF] consider the overall lifecycle. It is considered as for the management of the safety throughout the entire life of the system, but it concerns only systems that require safety functions. It is guide for the implementation of the relevant safety functions. This work is part of a project in deploying System Engineering (SE)(11) [START_REF]Systems Engineering Fundamentals[END_REF] . We address the integration of safety management in system engineering process. The paper is structured into five remaining parts. The second part gives a brief introduction of the emerging discipline of system engineering in matter of key processes and the standard EIA-632 [START_REF]processes for engineering systems[END_REF]. The third part presents briefly the integration approach. In the forth part, an original approach for safety integration in system engineering process is proposed.

The system engineering framework for complex system development

System Engineering is an interdisciplinary approach, which provides concepts that make it possible to build new applications. It is a collaborative and interdisciplinary process of problems resolution, supporting knowledge, methods and techniques resulting from the sciences and experiment. system engineering is a framework which helps to define the wanted system, which satisfies identified needs and is acceptable for the environment, while seeking to balance the overall economy of the solution on all the aspects of the problem in all the phases of the development and the life of the system. SE concepts are adequate specifically for complex problems; research issues undergone can bring a solution [START_REF] Sahraoui | issues in systems engineering research[END_REF].

System engineering concepts

System engineering is the application of scientific and engineering efforts in order to:

• Transform an operational need into a description of system performance parameters and a system configuration through an iterative process of definition, synthesis, analysis, design, test and evaluation.

• Integrate reliability, maintainability, availability, safety, survivability, human engineering and other factors into the overall engineering effort to meet cost, schedule, supportability and technical performance objectives.

System engineering is an interdisciplinary approach that:

1. Encompasses the scientific and engineering efforts related to development, manufacturing, verification, deployment, operations, support and disposal of systems products and processes.

2. Develops needed user trainings, equipments, procedures and data.

3. Establishes and maintains configuration management of the system.

4. Develops work breakdown structures and statements of work and provides information for management decision-making.

System engineering is a management methodology to assist designer through the formulation, analysis and interpretation of the impacts of proposed policies, controls or complete systems upon the need perspectives, institutional perspectives and value perspectives of stakeholders to issues under consideration. System engineering is an appropriate combination of the methods and tools of a suitable methodological process and systems management procedures. We distinguish three levels in System engineering as illustrated in figure 2. The first level, SE processes, focus on high-level issues, high-level requirements such as business needs and strategic needs and methods.

The second level, System engineering methodologies and methods, deals with all technical issues such as systems requirements design methodologies standards. The third level, System engineering tools or technologies, covers the implementation issues concerning the tools to be used, the required technologies to respond to the various assets of requirements such as reliability, costs, maintainability and enabling technologies. System engineering assists designer who desire to develop policies for management, direction, control and regulation activities relevant to forecasting, planning, development, production and operation of total systems Figure 2.

In System engineering best practice, we have the following chain: Processes → Methods → Tools These entities, such as processes, methods and tools, are the conceptual basis of our approach taken from System engineering best practice. In the first step, the processes can be identified with respect to the accumulated knowhow, and can also be taken from a standard as the thirteen generic processes proposed in standard EIA-632. The second step concerns the methods to be used. The methods can be either developed or used by the existing one, which implement the process as we cannot choose a method for its flexibility or popularity but only if it reflects the semantics of the process. No taxonomy has yet been developed for corresponding processes and methods. The third step concerns the tools that do not correspond to the processes but the methods; hence in this approach we cannot use a tool to implement a process without first identifying the associated methods.

EIA-632 standard

One famous standard, currently used in the industrial and military fields, is the EIA-632. This standard covers the product life cycle from the needs capture to the transfer to the user. It gives a system engineering methodology trough 13 interacting processes grouped into 5 groups, covering the management issues, the supply/acquisition, design and requirement, realization and verification/validation processes. Figure 3 shows the interaction between all the 5 groups of processes, whose roles are (13):

1. Technical management processes (three processes): these processes monitor the whole process ranging from the initial idea of building a system until its delivery.

2. Acquisition and supply processes (two processes): these processes ensure the supply and acquisition (and are very close to logistics).

3. System design processes (two processes): these processes are on the elicitation and acquisition of requirements and their modelling, the definition of the solution and its design.

4. Product realization processes (two processes): these processes deal with the implementation issues of system design and its use.

Technical evaluation processes (four processes):

these processes deal with verification, validation and testing issues.

Briefly, the operation of the proposed processes is:

• One acquisition request arrives and is treated by the supply process by establishing an agreement,

• The acquirer requirements are then transmitted to the System Design processes in charge of the elaboration of the logical solution, then the physical one, and also lots of sets of specified technical requirements, where each set is associated to a sub-system.

• The acquisition process is in charge to buy (if available in the market) or to make build the subsystems responding to the different sets of specified requirements.

• Once the sub-systems received, the realization of the final product can begin, based on the design solution previously established and chosen.

• To finish, the final system will be transferred to the user, just after tests and final validation.

In parallel, all the previous processes are managed, rated and controlled by the technical management processes.

And the technical evaluation processes allows to do system analysis (like risk analysis), requirement validations or system verification, during the development and when needed.

In fact, one or several sub-processes are defined for each 13 processes and the developer should decide which of the all 33 sub-processes apply. In this paper, only the system design processes and the technical evaluation processes are considered. These processes appear as the most important for safety management.

Figure 3: System engineering processes

Safety in system engineering process

Safety

Safety is an important system-level property, and must be built into the design of these systems from the beginning.

The safety assessment process can be decomposed into three main phases:

• preparation phase which initiates the assessment (Safety Target are defined)

• conduct phase in which the assessment is performed

• conclusion phase in which the assessment results are delivered.

System Engineering is the ideal framework for the design of complex system. In this work It is considered as a framework to manage safety.

A system engineering approach to safety starts with the basic assumption that the safety propriety, can only be treated adequately in their entirety, taking into account all variables and relating the social to the technical aspects ( 9). This basis for system engineering has been stated as the principle that a system is more than the sum of its parts. The Safety management must follow all steps of SE From the requirements definition to the verification and the validation of the system. If we consider, for example, a reliability requirement defined for a global system, its formalization and analysis must allow ensuring that the technical solutions selected with design progression deals with this reliability requirement at sub-systems level and after their integration. Note that this paper illustrates the proposed approach in term of process which must be defined independently to methods and/or tools (other projects which are focused on the methods and tools (4) and ( 5) for example). These different works will be exploited in the safety management from a global point of view.

Integration approach

The integration of safety must concern all system engineering processes. This paper is focused only on:

• System Design processes,

• Technical Evaluation processes.

The safety requirements must be taken into account in requirements definition process. It allows the formulation, the definition, the formalization and the analysis of these requirements. Then a traceability (10) model must be build to ensure the taking into account of the requirements throughout the development cycle of the system. These Safety requirements influence acquirer requirements, stakeholder requirements, system technical requirements, logical solution representations and physical solution representations. Technical Evaluation processes define 12 types of subprocesses going from requirement statements validation to enabled product readiness. The sub-processes (The task associated to each sub-process can be consulted in ( 13)) considered are:

• requirements statements validation,

• acquirer requirements validation,

• other stakeholder requirements validation,

• system technical requirements validation,

• logical solution representations validation,

• design solution verification.

The implementation of the approach consists in identifying and indicating in which way the safety must be considered for each sub-processes of EIA-632. In other words, the sub-processes of EIA-632 standard are translated or refined in terms of safety and included in system design process.

EIA-632 sub-process to safety refinement

In this section we address EIA-632 processes with safety point of view.

System design processes

The System Design Processes are used to convert agreed-upon requirements of the acquirer into a set of realizable products that satisfy acquirer and other stakeholder requirements. Two processes are involved: the Requirements Definition Process and the Solution Definition Process. The relationship between these two processes is shown in Figure 4.

Figure 4: System design processes

Requirement definition process

The goal of the requirements definition process is to transform the stakeholder (the acquirer and all other stakeholders who have an interest in the system) requirements into a set of technical requirements. For functional and no-functional requirements, if this distinction is not possible at the requirement elicitation process level, the analyzer may do it to categorize requirements. To perform this task, 3 sub-processes are associated with this process: the Acquirer Requirements, the Other Stakeholder Requirements and the System Technical Requirements sub-process. The Requirements Definition Process is re-accomplished, if necessary.

a. Acquirer Requirements

The developer shall define a validated set of acquirer requirements for the system, or portion thereof.

In the safety framework, acquirer requirements, generally, correspond to constraints in the system. It is necessary to identify and collect all constraints imposed by acquirer to obtain a dependable system. A hierarchical organization associates weight to safety requirements, following their criticality. Some Standards are available to guide designer to define safety requirements. For example, for safety critical systems within the civil aerospace sector are developed subject to the recommendations outlined in ARP4754 ( 14) and ARP4761 [START_REF]Guidelines and methods for conducting the safety assessment process on civil airborne systems and equipment[END_REF]. These standards give guidance on the 'determination' of requirements, including requirements capture, requirements types and derived requirements.

When the requirements are defined ( 16)some attributes can be used to facilitate their management.

b. Other Stakeholder Requirements

The developer shall define a validated set of other stakeholder requirements for the system, or portion thereof. The same approach applied to acquirer requirements is applied to Other Stakeholder Requirements.

c. System Technical Requirements

The developer shall define a validated set of system technical requirements from the validated sets of acquirer requirements and other stakeholder requirements. System technical requirements must be unambiguous, complete, consistent, achievable, verifiable, and necessary and sufficient for a system design. For safety requirements, the system technical requirements traduce system performances. It consists on defining safety attributes (5. Determine risk tolerability, MTBF, MTBR, failure rate for example). Among all requirements formulated by the acquirer and other stakeholder, some of them are safety requirements. For example, critical events define reliability requirements in the sense that their taking into account must leads to a design of a system able to avoid these events.

Solution Definition Process

The Solution Definition Process is used to generate an acceptable design solution. This solution satisfies:

1. the system technical requirements resulting from the Requirements Definition Process, 2. the derived technical requirements from the Solution Definition Process.

Three sub-processes are associated with the Solution Definition Process.

a. Logical Solution Representations

The developer shall define one or more validated sets of logical solution representations that conform with the technical requirements of the system. In order to do this, he must in particular (1) do some tradeoff analysis, (2) identify and define interfaces, states and modes, timelines, and data and control flows, ( 3) analyze behaviors, and ( 4) analyze failure modes and define failure effects.

Formal models can be used for logical solution representations. The use of formal methods allows for automation of verification and analysis and for a tighter integration between system design and safety analysis.

The model can automatically enriched with failures in order to perform safety analysis.

b. Physical Solution Representations

The developer shall define a preferred set of physical solution representations that agrees with the assigned logical solution representations, derived technical requirements, and system technical requirements.

The physical solution representations are derived from logical solution representation and must respects all requirements, particulary, safety requirements.

c. Specified Requirements

These requirements concern the design solution. The designer must ensure that the design solution is consistent with its source requirements. The safety analysis process allows the validation of these requirements.

Technical Evaluation Processes

The Technical Evaluation Processes are intended to be invoked by one of the other processes for engineering a system. Four processes are involved: Systems Analysis, Requirements Validation, System Verification and End Products Validation. The relationship between these processes is shown in Figure 5.

In this paper, we focus only on 3 processes of the technical evaluation:

1. Systems Analysis Process, which contains a Risk Analysis sub-process,

Systems Analysis Process

The Systems Analysis Process is used to:

1. Provide a rigorous basis for technical decision making, resolution of requirement conflicts, and assessment of alternative physical solutions;

2. Determine progress in satisfying system technical and derived technical requirements;

3. Support risk management;

4. Ensure that decisions are made only after evaluating cost, schedule, performance, and risk effects on the engineering or reengineering of the system.

a. Risk Analysis sub-process

The developer shall perform risk analysis to develop risk management strategies, support management of risks and support decision making. Several techniques can be used to analyze risks, for example: fault tree, or Failure Mode, Effect, and Criticality Analysis. This step is very important, because it determines the risks of the system. The step of risk analysis can generate safety requirements other than that defined by the acquirer and stakeholder. These new requirements must be taken into account.

Requirements Validation Process

Requirements Validation is critical to successful system product development and implementation. Requirements are validated when it is certain that they describe the input requirements and objectives such that the resulting system products can satisfy them. The Requirements Validation Process helps to ensure that the requirements are necessary and sufficient for creating design solutions appropriate to meet the exit criteria of the applicable engineering life cycle phase and of the enterprise-based life cycle phase in which the engineering or reengineering efforts occur. In this process, a great attention is done to traceability analysis, which allows verifying all the links among Acquirer and Other Stakeholder Requirements, Technical and Derived Technical Requirements, and Logical Solution Representations.

Like other requirements, safety requirements must be validated. The validation allows to design safe system. to facilitate this step, semi-formal solutions, like UML [START_REF] Booch | The Unified Modeling Language User Guide[END_REF] or SysML [START_REF]SysML: Source Specification Project[END_REF] (which is an UML profile for systems engineering), can be used for good formulation of requirements. Indeed the diversity of people concerned by the system design project can have limited knowledge concerning the structure of a future system makes industry-scale requirement engineering projects so hard. So the UML or SysML with their different diagrams can be helpful.

System Verification Process

The System Verification Process is used to ascertain that:

1. The generated system design solution is consistent with its source requirements.

2. End products meet their specified requirements at each level of the system structure implementation (from the bottom up).

3. Enabling product development or procurement for each associated process is properly progressing.

4. Required enabling products will be ready and available when needed to perform.

Simulation is a good and current method used to achieve system verification. Other methods like virtual prototyping, model checking and other ones can be used.

Conclusion

The approach presented in this paper concerns safety integration in system engineering process. It allows to give some guidelines to address efficiently safety of complex systems in all phase of system design. The approach is based on EIA-632 standard and can be resumed as follows:

• Elements of the approach: process → methods → tools

• System engineering processes handled using EIA-632 standard

• Integration of safety analysis in system engineering process

The paper addresses some processes of the standard EIA-632 independently to methods and/or tools. The processes addressed are system design process and technical evaluation process. The work is in progress and other processes will be used and defined in the integration approach. The next step of the deploying system engineering project is to propose appropriate methods and tools for achieving each subprocesses of the EIA-632 standard.

  Fast pace of technological change • Changing Nature of Accidents • New types of hazards • Increasing complexity and coupling • Decreasing tolerance for single accidents • More complex relationships between humans and automation

Figure 1 :

 1 Figure 1: Safety integration

Figure 2 :

 2 Figure 2: Three levels of system engineering.

Figure 5 :

 5 Figure 5: Technical evaluation processes.


R Guillerm
email: rguiller@laas.frdemmou@laas.fr

H Demmou

N Sadou

ESA PetriNet: Petri net Based Tool for Reliability Analysis

Keywords: Embedded systems, Feared scenarios extraction, Petri nets, reliability, Dynamic systems

This paper describes the critical (feared) scenarios derivation tool ESA PetriNet (Extraction Scenarios Algorithm from Petri Net) available from : http://www.laas.fr/ESA. ESA PetriNet allows to derive scenarios leading to critical (feared) situation in embedded systems. The system model is given by a Petri net. To derive critical scenarios and to avoid the state space explosion, the solution is to use directly the Petri net model. Linear logic (which does not appears in this paper) offers a theoretical framework to interpret the Petri net model and to extract the scenarios. ESA PetriNet provides all minimal scenarios which contain strictly necessary and sufficient events to reach a specified state. ESA PetriNet can be used with classical Petri net modelling or in its objects oriented version.

I. INTRODUCTION

The growing complexity of embedded systems [START_REF] Henzinger | The embedded systems design challenge[END_REF], including more and more ECU (Electronic Control Units), makes it difficult to perform the dependability analysis of such systems. Considering mechatronic systems in the automotive domain and focusing on dependability analysis, one way to help designers is to identify critical scenarios and define corrective actions to avoid them as early as possible in the design stage. This means that when some event affecting the safety of the system occurs, a reconfiguration action is executed in order to maintain the vehicle in a safe degraded state. If the reconfiguration fails then the system will reach a critical (dangerous) state with dramatic consequences for the passengers. So it is important to understand how the system reaches such critical states at the early design stage of the system in order to set up the reconfiguration actions.

The safety analysis [START_REF] Dufour | Dynamic Reliability: A new model[END_REF] of dynamic embedded systems starts with a qualitative analysis, the objective of which is to determine the catastrophic or unacceptable behavior of the system.

For static systems the most popular approach for reliability analysis is based on fault trees with its associated tool [START_REF] Sinnamon | Fault trees and binary decision diagrams[END_REF]. Static fault trees use traditional Boolean Logic functions to represent the combination of component failures (events) that cause system failure. One interesting aspect of fault trees is that a set of minimal cutsets [START_REF] Rauzy | Mathematical Foundation of Minimal Cutsets[END_REF] can be derived. However, to deal with the complexity of dynamic systems, fault trees are not sufficient: safety analysis of such systems must include timing considerations and the order of events [START_REF] Garret | The Dynamic Flowgraph Methodology for Assessing the Dependability of Embedded Software Systems[END_REF].

To overcome these limitations, Dugan [START_REF] Dugan | Diagnostic expert systems from dynamic fault tree[END_REF] introduces a new type of gate in order to differentiate the static aspects from the dynamic ones. The dynamic gates allow Markov analysis. One drawback is that it is not possible to derive a qualitative analysis, and moreover some produced feared scenarios can lead to non-permanent feared states.

Simulation is another popular method, in particular the Monte-Carlo simulation [START_REF] Labeau | A Survey on Monte Carlo Estimation of Small Failure Risks in Dynamic Reliability[END_REF]. Good results can be obtained when simulation is applied. Nevertheless, when used for dependability analysis simulation methods have to deal with the so-called "rare events problem".

Other methods based on the exploration of the state graph, like the Markov graph or the Petri net accessibility graph [START_REF] Codetta-Raiteri1 | Stochastic Petri Nets Supporting Dynamic Reliability EvaluationStochastic Petri Nets Supporting Dynamic Reliability Evaluation[END_REF], are limited by the problem of state space explosion.

So, to achieve the qualitative analysis we propose an approach focused on the search for critical scenarios in order to propose a way to avoid the problem of state space explosion. The basic idea is to use a Petri net model and directly extract the critical scenarios without building the accessibility graph.

Linear logic [START_REF] Demmou | A method for deriving critical scenarios from mechatronic systems[END_REF], [START_REF] Girard | Linear Logic[END_REF] offers a formal framework to interpret the Petri net model and to extract the scenarios. The key point of this approach is equivalence between reachability in the Petri net and linear logic sequent provability [START_REF] Pradin-Chzalviel | Scenario duration characterization of t-timed Petri nets using linear logic[END_REF]. Linear logic thus makes it possible to analyze these cause-effect relations.

To model Embedded systems, temporal Petri nets are used. They allow to model some continuous aspects of these systems. This modelling approach has the advantage of clearly separating the continuous aspects (time modelling) from the discrete ones. It allows a logical analysis using linear logic based on the causality of events leading to a critical state.

Starting from a critical state, it is possible to go back through the chain of causalities and to point out only those scenarios leading to a critical situation. Each scenario is a 978-1-4244-2794-9/09/$25.00 c 2009 IEEE SMC 2009 representation of the partial order of events necessary for the occurrence of the critical outcome. The final objective is to determine minimal scenarios. Indeed, a critical scenario can contain events (the consequence of other events of the scenario) which are not strictly necessary to reach the final critical state. Such a scenario is not minimal. To deal with the concept of minimality of a scenario we introduce a formal definition of a minimal scenario. This definition has been used in our algorithm to derive automatically critical scenarios, but only the minimal ones. Another application of the proposed approach is the verification of behavioral properties like safety. This paper is organized as follows: section 2 presents briefly the deriving scenarios extraction approach. Section 3 describes ESA PetriNet tool. In section 4 an example illustrates the capabilities of the tool. Finally, section 5 draws a number of conclusions and future work.

II. SCENARIO EXTRACTION APPROACH

A. Critical scenario

Critical scenario is a set of events (transition firings for a Petri net model) verifying a partial order and leading from one partial state corresponding to normal behavior (partial marking) to another one that represents a dangerous situation of the system.

In this part we present briefly the approach for deriving critical scenarios for dynamic reliability analysis.

B. System modelling

The system modelling is based on Petri net [START_REF] Murata | Petri Nets: Properties, Analysis and Applications[END_REF] using or not the object-oriented concepts [START_REF] Sadou | Object oriented approach for deriving feared scenarios in hybrid system[END_REF], [START_REF] Booch | The Unified Modelling Language User Guide[END_REF]. Object oriented approach can be used to facilitate the modelling and analysis of complex systems.

There are several proposals incorporating the notion of time into different components of the Petri net framework, namely tokens, transitions, places, and arcs [START_REF] Ghezzi | A General Way to Put Time into Petri Nets[END_REF]. In this work we use a temporal Petri net where the durations are associated with transitions . Let us now give the formal definition of the temporal Petri nets.

Definition [temporal Petri net]: A Temporal Petri net is a pair N tl =< N, D > where N is a Petri net < P, T, P re, P ost > and D is a function that associates to each transition t i a static temporal interval d(t i ) = [dimin(t i ), dimax(t i )] that describes the enabling duration.

C. Principles of the approach

The method is based on a qualitative analysis stemming from the Petri net model. The objective is to extract and clearly identify the critical scenarios (leading from one partial state corresponding to normal behavior to another one that represents a dangerous situation of the system) starting from a model that contains the necessary knowledge to make the analysis. The initial partial knowledge of the critical state is progressively enriched while analyzing the components necessary to its occurrence. This method is made up of two steps: a backward and a forward reasoning process. The backward reasoning starts from the partial critical state in order to derive the events that are necessary to reach it, and gives the last nominal states preceding the critical behavior. The forward reasoning starts from these nominal states, and determines the components at the source of the critical scenario. To determine the complete context in which the critical scenario occurs, the concept of context enrichment is introduced. The context enrichment is carried out by adding tokens to some places (empty input places of potentially enabled transitions) that can have an impact on the critical scenario that is being explored (adding one token in the place p 0 to make the transition t 0 , initially potentially enabled, enabled in the example of the Figure 1)).

D. Principles of scenario extraction algorithm

The deriving scenarios algorithm (both backward and forward reasoning) [START_REF] Sadou | Object oriented approach for deriving feared scenarios in hybrid system[END_REF] can be considered as a Petri net player, but not classical Petri net player (occurrence graph). It is a player based on linear logic that guides the construction of the partial orders between events [START_REF] Demmou | A method for deriving critical scenarios from mechatronic systems[END_REF].

E. Steps of the method

1) Determining the nominal states 2) Determining the target states (partial critical states or states to be analyzed). 3) Backward reasoning starting from the partial critical state. 4) Forward reasoning starting from the objects that contain the conditioning state.

1) The first step is to determine the places that, when marked, represent a normal operation state. These 'nominal' places will be used as "stop criteria" for backward reasoning. This step can be achieved in two ways: by using a priori knowledge of the normal operation states of the system, or by a Monte Carlo simulation of the model (in a short temporal window) in order to determine the marking probabilities of the places of the Petri net. The places that will have a significant marking probability will be considered as nominal places.

2) The second step determines the target states to be analyzed. This target states can be either a partial critical state or another partial state with a direct or indirect link to the critical state (for example a place that represents the availability of a SMC 2009 resource that allows operating even with presence of a fault, and avoids the occurrence of the critical event).

3) Backward reasoning: The aim of this step is to determine the "conditioning states" that correspond to the last normal operation state of the system. It generates the sets of paths that lead to the partial critical state. Backward reasoning is carried out on the reversed Petri net model. In this reversed Petri net, the initial marking corresponds to each minimal Cutset of the Boolean function that represents a critical state. We search for all the minimal scenarios (only the necessary transitions are fired) that lead from the initial marking to a final marking, containing only places that are associated with normal operation. During this step, starting from the initial context that concerns one or more objects, in most cases we have to enrich the initial context.

4) Forward reasoning: This step is carried out on the initial Petri net with the 'conditioning states' as initial marking. The goal is to determine the reachability of the critical state and to identify the scenarios that lead to it, or to prove that the critical state will never be reached. It aims also to identify the bifurcations between the normal behavior and the critical one and also to set the conditions (marking of some places and introduced objects) associated to these bifurcations. The analysis of these bifurcations (that correspond to transitions) gives information about the occurrence of events which are the causes of the critical state.

III. TOOL PRESENTATION

A. Objectives of ESA PetriNet tool

ESA PetriNet (Figure 2) implements the deriving critical scenarios algorithm. It allows to generate critical scenarios leading the system from normal working to critical situation.

For designers the interesting scenarios are minimal ones. Minimal scenario [START_REF] Sadou | Minimality of critical scenarios in Petri net model[END_REF] means that it contains only necessary events to reach one marking from another one. So minimality analysis [START_REF] Sadou | Minimality of critical scenarios in Petri net model[END_REF] is implemented in to ESA PetriNet. It allows to derive only consistent scenarios.

Another functionality of ESA PetriNet is the verification of behavior properties. Indeed, it is possible to prove that one scenario respects some temporal constraints. In this paper the approach for verification is not presented. The principles of the approach can be found in [START_REF] Demmou | Symbolic temporal constraint analysis, an approach for verifying hybrid systems[END_REF].

B. Input files 1) Petri net models and structural analysis:

The input files of the tool correspond to a textual description of the temporal Petri net model of the system. To edit these files, the tool TINA (TIme Petri Net Analyzer) [18], [START_REF] Berthomieu | Time Petri Nets Analysis with TINA[END_REF](Figure 3) is used. The definitions of the nominal states and the target states (referring to step 1 and 2 of the method) are also done in these files, through the labels associated to the places of the Petri nets.

The Petri net models can be modified directly from ESA PetriNet by editing TINA files in their textual or graphical description.

More specifically, the input files corresponding to the textual description of the Petri nets are the result files of the structural 1 Fig. 2. ESA PetriNet Screen snapshot analysis (Figure 5) offered by TINA. These files are used because they contain both the descriptions of the Petri nets and the marking invariants necessary for marking enrichments. Indeed, marking enrichments are carried out during the feared scenario research algorithm, but they are not always possible. And to preserve the system consistency, that's the marking invariants which determine if the marking enrichments are possible or not.

2) Communication file: For the object oriented approach, each object is modelled by one Petri net and the communication between objects is specified. Figure 4 shows communications between objects of the case study. It will be commented later.

C. output files 1) Result File:

The single output file provided by an analysis with ESA PetriNet is the result file. It contains a textual description of the generated feared scenarios.

But a common way to represent scenarios is in the form of graphs, because they clearly show the sequence of events, partial orders and the parallelism between some events. Indeed, a precedence graph is a directed acyclic graph defined by a set of events (those of the scenario) and a precedence relationship that corresponds to the partial order of the scenario created by the various links between the events. Consequently, ESA PetriNet offers the possibility to display the scenarios in the forme of precedence graphs starting from the result file by clicking on the "Precedence Graphs" button.

D. User interface

In order to obtain the critical scenarios with ESA PetriNet, we must indicate some files through the user interface (Figure 2). Firstly, all the Petri net objects that we need must be given to the software. Each Petri net that models one object is specified. We have already seen that these files are created and obtained with another tool: TINA. Next, we must define a communication file in order to keep the consistency of the model, eventually by using the editor provided with ESA PetriNet. The last file that must be defined trough the interface is the result file.

Once all the needed files have been specified, we run the extraction of the critical scenarios by clicking on the dedicated button: "Generate Scenarios". Finally, the precedence graphs are displayed by using the "Precedence Graphs" button.

E. Installation

ESA PetriNet can be downloaded from www.laas.fr/ESA. ESA PetriNet is coded in Java language, so a Java virtual machine is needed. Windows OS version is available. The Linux version will be developed later.

IV. EXAMPLE AND APPLICATION

The case study (inspired from automotive industy) is based on a volume regulation system of two tanks (Figure 6). It consists of a computer, two pumps, three electrovalves, two

Tank1 EV2 V 2L V 1S Computer V 2min V 2max EV3 ds 1 ds 2 Sensors EV1 Pump2 Pump1 V 1max V 1min V 2S V 1L Tank2 Fig. 6. Case study
The control strategy of the computer is such that the electrovalve is closed whenever the volume of the controlled tank exceeds the upper limit Vimax (in the conjunction phase). On the other hand, the computer commands the opening of the electrovalve each time the value of the volume in the controlled tank is lower than the limit Vimin (in the disjunction SMC 2009 phase). We distinguish two normal phases of the system, corresponding to the state of the electrovalve:

• A conjunction phase when the electrovalve is open. The volume in the tank is increasing during this phase, no matter what is the value of the outgoing flow to the user (the ingoing flow to the electrovalve is much higher than the outgoing flow).

• A disjunction phase when the electrovalve is closed. The volume in the tank is decreasing during this phase. This system must supply the user while avoiding the overflow of the tanks. A relief electrovalve is added to the system in order to drain the tanks in case of overflow. This third electrovalve is viewed as a shared resource between the two main tanks, and it can be used for only one tank at a time. When the volume of one tank exceeds the high security limit (ViL), the computer commands the opening of the relief electrovalve. As we focus our study on critical scenarios, and in order to simplify the problem we consider that only the electrovalves can have failures. A typical failure of the electrovalves one and two corresponds to a stuck open (or closed) state in which the electrovalve does not react to a closure (or opening) command of the computer. These two electrovalves can be repaired after failure occurrence. When the electrovalve 3 has a failure it is definitively out of service.

A. Modelling

We propose 3 object classes for the modelling of this system: one tank class and two electrovalve classes. We define two objects (tank1 and tank2) instances of tank class, two objects (EV1 and EV2 electrovalves) instances of the first electrovalve class and one object (relief electrovalve) instance of the third class. In order to deal with the continuous aspects of the system, the volume thresholds (Vimin, Vimax, ViL, Vis) that correspond to the enabling functions of the Differential Predicate Transition Petri Nets are replaced by temporal thresholds (Timin, Timax, TiL, Tis). These temporal thresholds are obtained by temporal abstraction of the continuous dynamic associated to places Vi cr and Vi dec.

1) Model of the tanks: (Figure 3) shows the model of Tank1 (the model of the tank2 is identical). Place V1 dec represents the disjunction phase (the volume is decreasing), and the place V1 cr represents the conjunction phase in which the volume is increasing. When the volume exceeds V1max (temporal interval [START_REF] Henzinger | The embedded systems design challenge[END_REF][START_REF] Henzinger | The embedded systems design challenge[END_REF]) the tank calls a 'close electrovalve 1' method (associated with transition T11) provided by the electrovalve EV1. The method 'Open electrovalve 1' (associated with transition T12) is called by the Tank1 when the volume becomes lower than V1min (interval [START_REF] Henzinger | The embedded systems design challenge[END_REF][START_REF] Henzinger | The embedded systems design challenge[END_REF]). When the volume in the Tank1 exceeds the high security limit V1L (interval [START_REF] Dufour | Dynamic Reliability: A new model[END_REF][START_REF] Dufour | Dynamic Reliability: A new model[END_REF]), the 'open electrovalve 3' method (transition T14) provided by the relief electrovalve is called in order to drain Tank1. This phase lasts the time necessary for the volume to reach the low threshold V1min. A conjunction phase is started again (place V1 cr is marked) by firing transition T15.

There is overflow on the Tank1, when the volume in this tank exceeds V1S (V1S reached in the interval [START_REF] Sinnamon | Fault trees and binary decision diagrams[END_REF][START_REF] Sinnamon | Fault trees and binary decision diagrams[END_REF] is higher than V1max and V1L). In this case, transition T13 is fired and place E red1 is marked. The firing of T13 is considered as the critical event.

2) Model of the electrovalve 1 (EV1): The electrovalve 1 (EV1) when opened supplies the Tank1 in the conjunction phase (Figure 7). 3) Model of the relief electrovalve 3: The relief electrovalve is shared between the two tanks and its model is presented in (Figure 8). The place EV3 OK represents the availability of the valve. The transition t14 (respectively t24) is the 'open electrovalve 3' provided method that can be called by the Tank1 (respectively Tank2) when the volume exceeds V1L (respectively V2L). The electrovalve 3 can fail (firing of the transition def3). In this case, place EV3 HS is marked and the electrovalve is out of order. Remark: 1) We can see in figure 4 (textual file which represents the communications between objects). For example, the transition T11 of the tank1 calls the transition t11 of the electrovalve 1.

SMC 2009

2) In figure 5 we can see the results of the structural analysis. For example, for the object tank1, there is a Pinvariant that corresponds to the places : E red1 V1 cr V1 dec V1 dec s. So when one of these places is marked, it is not possible to enrich the other places.

B. Application of the method and results

ESA PetriNet tool derives 2 minimal critical scenarios (Figure 9) leading to the critical state E red1 (overflow of the tank1).

The first scenario is composed by the events: failure of electrovalve 1, failure of the relief electrovalve (EV3), followed by the overflow of tank1 (figure 9).

The second scenario is composed by the events: failure of electrovalve 1 and failure of electrovalve 2, the use of the relief electrovalve (EV3) to drain tank2, followed the overflow of tank1. System modelling is based on temporal Petri net. The objects oriented approach allows to facilitate system modelling and scenario analysis.

Another important aspect is the minimality of derived scenarios. The tool allows generating only pertinent scenarios. It takes into account the notion of minimal scenario [START_REF] Sadou | Minimality of critical scenarios in Petri net model[END_REF] which is the relevant information for designers and facilitates analysis.

In order to deal with complex dynamic (hybrid systems) and overcome the limitation of temporal abstraction (used for continuous dynamic approximation), future works will introduce the possibility of integrating complex differential equation (one way is to connect the tool to a dynamic solver).

Another extension we have to work on is the quantitative analysis. Monte Carlo simulation appears as the technique that will be used to achieve quantitative analysis and will be implemented in ESA PetriNet.

Current software development concerns improving the interface tool specially its English version. An English web site will be dedicated for it.

1

 1

Fig. 1 .

 1 Fig. 1. Marking enrichment

1 1Fig. 3 . TINA snapshot 1 Fig. 4 .

 1314 Fig. 3. TINA snapshot

1

 1

Fig. 5 .

 5 Fig. 5. Structural analysis results file

1

 1

Fig. 7 .

 7 Fig. 7. Petri net model of the electrovalve 1

1

 1

Fig. 8 .

 8 Fig. 8. Petri net model of the relief electrovalve.

Fig. 9 .

 9 Fig. 9. Generated scenarios