Abstract
This article 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 principles and uses the famous industrial system engineering standard American National Standards Institute/Electronic Industries Alliance 632:1999. 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 “System Modeling Language” is used to address requirements definition and their traceability toward the solution and the verification and validation elements. This common language allows sharing information between the different persons involved in the design project like the system engineer and safety engineer.
Keywords
Introduction
Complex systems are systems with numerous components, interconnections, interactions, or interdependencies that are difficult to describe, understand, predict, manage, design, and/or change (Magee and de Weck, 2004). 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 et al., 2004) become difficult. Indeed, safety of complex systems relies heavily on the emergent properties (Leveson, 2004) 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 (Guillerm et al., 2010), are as follows:
The emergent aspect of safety properties imposes to consider safety not only in the small but also in the large (at system level).
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.
Requirement engineering is a critical process in system engineering (SE). So, safety requirements and their traceability need 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) is a critical SE process (Juristo et al., 2002). It is a key problem area in the development of complex systems (Brooks, 1987). A common classification defines two types of requirements: functional requirements, which describe the services that the system should provide, and non-functional requirements, which 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 (V&V), 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 (Gotel and Finkelstein, 1994) must be formulated not only in the small (subsystem level) but also in the large (system level). Two aspects of RE are considered: the requirements development (including elicitation (Goguen and Linde, 1993), documentation, analysis, and validation processes) and the requirements management (including maintainability management, changes management, and requirements traceability processes; Parviainen et al., 2004).
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 do not define a unified approach with the nominal conception activities. This means that safety activities are not integrated in the SE processes. Recent projects like Enhanced safety assessment for complex systems (ESACS) (Bozzano et al., 2003), Improvement of Safety Activities on Aeronautical Complex Systems (ISAAC) (Akerlund, 2006), and Automated proof-based System and Software Engineering for Real-Time systems (ASSERT) (Conquet, 2008), which deal with safety of complex systems do not 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 (Leveson et al., 2007), in addition to the fact that safety aspects are separated from the design activities, the proposed methodology is clearly oriented to the software domain.
This article presents two aspects of our work on safety evaluation of complex system. The first part concerns the integration of safety management in SE process. The objective is to help engineers by proposing a new approach based on SE best practices. It uses the recommendation of the SE standard Electronic Industries Alliance (EIA) 632:1999 (Guillerm et al., 2010). The second part presents an information model based on SysML language (Friedenthal et al., 2009) to address requirements definition and their traceability (Gotel and Finkelstein, 1994) toward the solution elements and the V&V elements. Safety requirements are integrated on RE activities, including management activities related to maintenance and traceability.
This article 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
SE 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 experimentation for defining a system. SE concepts are adequate specifically for complex problems; research issues undergone can bring a solution (Sahraoui et al., 2004). This part introduces some concepts of SE and the standard EIA632:1999, which are the basis of our safety global approach.
SE concepts
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
Encompasses the scientific and engineering efforts related to the development, manufacturing, verification, deployment, operations, support, and disposal of systems products and processes;
Develops needed user training, equipment, procedures, and data;
Establishes and maintains configuration management of the system;
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. The first level, “SE processes,” focuses on high-level issues and 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 and 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.
EIA632:1999 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 US military standard was published (MIL-STD-499 Engineering Management). It is focused on systems engineering, providing the first definition of the scope of engineering management. Nowadays, the standard American National. Standards Institute (ANSI)/EIA632:1999 “Processes for Engineering a System,” which provides a typical systems engineering work breakdown structure (Valerdi and Wheaton, 2005), 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 EIA standard (Figure 1). It is constituted by 13 processes covering the management issues, the supply/acquisition, design and requirement, verification, and validation processes:
System engineering processes.
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.
Acquisition and supply processes (two processes). These processes ensure the supply and acquisition (and are very close to logistics).
System design processes (two processes). These processes deal with the elicitation and the acquisition of requirements and their modeling and the definition of the logical design and its physical solution.
Product realization processes (two processes). These processes deal with the implementation issues of the system design and its use.
Technical evaluation processes (four processes). These processes deal with verification, validation, and testing issues.
In the work presented in this article, 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. SE is an ideal framework for the design of complex systems, and the need for systems engineering arose with the increasing complexity of systems. This work for safety integration in SE is based on the assumption that the safety property can only be treated adequately in their entirety, taking into account all variables and social and technical aspects (Kotovsky et al., 1985). This basis for SE 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 article is the following note provided in EIA632:1999 standard:
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 the SE chain, the proposed approach is illustrated in terms of process, which must be defined independently to methods and/or tools. Other projects are focused on methods and tools (e.g. Akerlund, 2006; Bozzano et al., 2003). The safety management must follow all steps (processes) of SE from the requirements definition to the verification and the validation of the system. This article is focused only on (a) system design processes in which we address requirements definition processes and the solution definition processes and (b) 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 of the subprocesses of EIA632:1999.
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 (EIA632:1999, 1999). Two processes are involved: the requirements definition process and the solution definition process. The interaction between these processes is shown in Figure 2.
EIA632:1999 system design process.
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 non-functional 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 of defining safety attributes (e.g. determine risk tolerability, safety integrity level (SIL), mean time between failures (MTBF), and mean time to repair (MTTR)).
Safety requirements can be derived from different sources. The first source is the stakeholders. In this case, classical requirements elicitation methods can be used (Coulin et al., 2005). 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) and (ARP-4761). 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 (Wu and Kelly, 2006).
When requirements are defined, it is possible to define some attributes to facilitate their management, for example, with an expression of requirements using SysML (Friedenthal et al., 2009) or Unified Modeling Language (UML) 2.0 (Friedenthal and Kobryn, 2004). It is possible to link requirements to the design solution. This point will be presented in the fourth 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, etc.) 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 as for logical solution can be considered. 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 Architecture Analysis and Design Language (AADL) (SAE Aerospace, 2006), VHDL-AMS (Verries et al., 2008), Vhd, SystemC-AMS, and so on.
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. Figure 3 shows the relationship between these processes.
Technical evaluation processes.
System analysis process
The systems analysis process is used to (a) provide a rigorous basis for technical decision making, resolution of requirement conflicts, and assessment of alternative physical solutions; (b) determine progress in satisfying system technical and derived technical requirements; (c) support risk management; and (d) ensure that decisions are made only after evaluating the cost, schedule, performance, and risk effects on the engineering or reengineering of the system (EIA632:1999, 1999).
In this process, safety is involved at each item. Indeed, (a) in the case of requirement conflict, higher priority requirements must be safety ones. These requirements are used in the assessment of alternative physical solutions. (b) 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. (c) The risk management is used to develop risk management strategies of the design project. (d) Safety aspect can generate additional cost. The designer has to evaluate this cost.
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 toward models with known semantics allowing their formalization.
To facilitate the step of requirements validation, semiformal solutions, like UML (Friedenthal and Kobryn, 2004) or SysML (Friedenthal et al., 2009), 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 is why industry-scale 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 (Zeigler et al., 2000) is an appropriate method that can be used to achieve system verification. Other methods like test, virtual prototyping, or model checking are also used.
Information model
RE is an important phase in a system design. It is important to perform it correctly for project success (Juristo et al., 2002). Requirements formalization can help the designers in their RE 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 of complex systems.
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 4 presents an overview of the requirements relationships as defined in the EIA632:1999 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.
Requirements relationships: EIA632:1999 model.
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 in evaluating the project progress. As different views exist in the design team (e.g. design and safety engineer’s views), the information model makes the system more understandable as it is based on a common language. When transforming needs into system definition, modeling 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 two 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 the 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 SE. 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 EIA632:1999, to take into account safety and risk management aspects.
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 like the requirements view (requirements diagram and use case diagram), the structure view (block diagram (internal/external)), the behavior view (statechart diagram, activity diagram, and sequence diagram), or the constraints view (with parametric diagram).
SysML seems to be an excellent candidate for a common language. It 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) a definition of hierarchy between requirements, (b) requirement derivation, (c) requirement satisfaction by a model element, (d) requirement verification by a test case (TestCase), or (e) 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 5 shows SysML stereotype requirement definition. Requirement in SysML is composed by two attributes: an identifier (Id) and the description of the requirement (Text).
The requirement stereotype in SysML.
The definition of stereotype requirement is enriched in order to adapt it for our need. For this purpose, we introduced some new attributes that are inspired from the RPM profile (Requirement Profile for MeMVaTEx) (Albinet et al., 2008), the recommendation of Association Française d’Ingénierie Système (AFIS; the French association of SE), and the Snow Card Volere (Robertson, 2010).
As shown in Figure 6, these attributes are, for example, the category (functional or non-functional requirements), the justification (why this requirement?), the source (acquirer, standard, regulatory authorities, risk analysis), and the target (end product or enabling products). For more details, see (Rasmussen, 1997).
Proposed requirement model.
New requirement stereotypes
Stereotypes allow extending the semantic of SysML. They allow defining new types of blocks. We define new stereotypes for requirements (see Figure 7). These stereotypes are based on the classification of requirements given in the standard EIA632:1999 (see Figure 4). 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.
Requirements stereotypes.
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 8). 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.
From risk to safety requirements.
Presentation of the information model
As said previously, the information model is based on SysML and follows the SE process (EIA632:1999 standard). It is considered as the “system” knowledge basis of the design project, allowing data sharing between all different trades (mechanical, hydraulic, thermal, electrical, etc.). 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 three basic concepts of system design are requirements, design solution, and V&V. 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 9). In other words, our approach allows a rigorous organization of the project design. Indeed, different diagrams manage different concepts.
Package diagram of concepts separation.
In the information model (Figure 10), we can see that all types of requirements are represented. We see that they follow the EIA632:1999 standard recommendations. All traceability links required by the EIA632:1999 are present in this model, and the distinction between logical solution (functional part) and physical solution (component part) appears. 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.
Information model.
Conclusion
In this article, 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 SE processes. The proposed methodology is based on EIA632:1999 SE 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 SE processes, from requirements definition process to V&V process are concerned by the integration approach. As the approach is based on the EIA632:1999 standard and follows the different processes and subprocesses 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.
RE is a crucial activity in the design of complex system. The second contribution of this article 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 EIA632:1999 processes. Indeed, in the present article, 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 object constraint language (OCL) 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.
Footnotes
Funding
This research received no specific grant from any funding agency in the public, commercial or not-for-profit sectors.