In System Engineering, one of the most critical process is the requirement management, particularly when it deals with the safety requirements. These one are non-functional requirements and are related to emergent properties, which come from the integration of the different system components. They must be identified as soon as possible, because they are guards to validate or not the system, which can require changes in system architecture. Moreover, they are formulated at system level and need to be declined at sub-system level. The objective of this paper is to propose a global safety management method based on well-known safety methods, in order to organize the different tasks to make the system safe. The method focuses mainly on the definition of the system safety requirements following risk and hazard analysis, and also on their declination according to a top-down approach. It is based on the famous Failure Mode, Effects, and Criticality Analysis (FMECA) and the use of Fault Trees and Event Trees.
Modern systems are increasingly complex [
Requirements Engineering (RE) is one of the System Engineering (SE) processes. RE is a crucial process within the development of complex system. Safety requirements are classified as non-functional requirements and are related to emergent system properties. They cannot be attributed to a single system component. Furthermost, nonfunctional requirements are fundamental to determine the success of a system. Two activities are defined in RE. The first one concerns requirements development including the processes of elicitation, documentation, analysis and validation of requirements. The second one concerns requirement management which includes the processes of maintainability management, changes management and requirements traceability.
The work presented in this paper concerns a part of our approach for the integration
of safety in system engineering processes [
In this part, the context of our work is exposed. The first section presents the System Engineering notion. Then, the standard that we adopt is presented with its useful concept of building block that devises the design in different system layers. To finish, a focus is done on the safety requirement management. 2.1
System Engineering (SE) is an interdisciplinary approach, whose objective is to
assist the development of new systems. It contains collaborative and interdisciplinary
processes of resolution of problems, supporting knowledge, methods and techniques
resulting from the sciences and experiment to define a system, which satisfies an
identified need, and is acceptable for the environment, while seeking to balance the total
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 [
SE is the application of scientific and engineering efforts 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, safety, maintainability, expandability, survivability, human engineering and other factors into the total engineering effort to meet cost, schedule, supportability and technical performance objectives.
2.2
A standard currently used in the industrial and military fields is the EIA-632 standard
[
Briefly, this standard covers the product life cycle from the needs capture to the transfer to the user. It is constituted by 13 processes grouped into 5 sets (see Figure 1): 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 realization processes (two processes): these processes deal with the implementation is-sues of the system design and its use. 5. Technical evaluation processes (four processes): these processes deal with verification, validation and testing issues. The EIA-632 standard adopts an original and interesting system decomposition based on the concept of "building block". A building block is the association between one (or several) final product and a set of enabling products, as shown in Figure 2.
In fact, the system is seen as a hierarchy of building blocks. The solutions defined in the upper layer (level) blocks, described by a set of specified requirements, are allocated as input requirements for the lower layer blocks (see figure 3). Finally, the building block decomposition is stopped when blocks correspond to on-the-shelf components or when their realization can be subtracted. With this description, we identified the need of deriving the safety requirements through the hierarchical decomposition. To clearly situate the position of the method for deriving safety requirements, the Figure 4 gives an overview of the involved EIA-632 system engineering processes.
Among the different possible sources of safety requirement we can find the requirement provided by some dependability analysis as shown in the Figure 4. In this paper we consider this source of requirements. The proposed approach is used to define, derive and decline safety requirement with different safety analysis. In this second part, the global safety management method is presented. First, an overview of the method is given, following by an explanation about the different kinds of safety requirements that are taken into account in the current version of the method. Afterwards, the 9 steps of the method are explained in details. The method assumes that a complex system is composed of some subsystems (the principle of Building Block of the EIA-632 standard). It combines FMECA, fault trees and event trees, and has the objective to define all safety requirements at system level and to decline them locally at subsystems level with a goal of traceability. The Figure 5 summarizes the process associated to the method and illustrates how the different steps are integrated together. The method enables to identify and deals with several kinds of safety requirements. We have classify these requirements into subcategories, which are : – Reliability requirement, that claims a quantitative objective in term of reliability properties. – Architectural requirement, that defines an architectural design to deal with safety (like redundancies). – Active functional security requirement, that is related to an additional security equipment (protective barrier) that can participate to reduce the probability of an accident. – Passive functional security requirement, that is related to an additional protective or mitigation equipment that can reduce the severity of an accident. The first step is to identify and classify all the system risks. These can be human actions, external failures, internal failures (those of the system) or environmental conditions. The classification must be done in two groups: the risks representing internal failure modes and the other risks. 3.4
The second step is to begin the analysis of risks that correspond to system failure modes.
The recommended method is the FMECA [
In fact, we also propose some changes in the classical FMECA to clarify the method, visible in the Table 1. A distinction is made between the probability and the detectability of the failure modes and those of the effects. Indeed, between a failure mode and an effect (accident), there is a set of involved cofactors (protection barrier, environmental condition ...), recorded in the "condition" column of the table. These conditions will be identified during the step of consequences analysis.
The assessment of the probability of the risk and the assessment of the severity, probability and criticality of the effect will be done during the step of risk assessment. The corrective actions will be proposed at the risk mitigation step. This step is similar to the previous step of system failure modes analysis, but focuses on the other risks (external). The recommended method is to use the principle of an FMECA, that we can call here RECA (Risks, Effects, and Criticality Analysis) (see Table 2). This step is to complete few columns of the RECA table (others than severity, probability, criticality and corrective action). The effects are also the potential accidents.
The same remarks as for the FMECA remain true concerning the probability, the detectability and the severity of the failure modes and the effects, and the conditions. 3.6
In this step, the consequences of all the identified risks (system failure modes and
others) must be analysed. This step is to identify how the risks contribute to an accident.
It can be done using event trees [
A generic example is given in Figure 6. The effects correspond to accidents, whereas the term consequences refers to events or factors involved in the causes to consequences relationship, starting from the analysed risk. 3.7
The fifth step is to conduct an internal analysis of the system by identifying the causes
of system failure modes. These causes analysis must lead to subsystems failure modes.
For this step, the use of fault trees [
So, the top event of each tree corresponds to a system cause. The objective is to determine the causes of the top event (using logical operators such as AND and OR) in the sub-systems. The leaves of the fault tree correspond to sub-systems failure modes (see Figure 7).
In fact, the system failure modes analysed correspond either directly to a system risk (defined in the first step), or to a cofactor of an event tree which is a system failure mode. 3.8
An analysis of the subsystems failure modes should be leaded in parallel, using FMECA. The subsystems failure modes used in step 5 re-appears (the principle of the FMECA analysis). This FMECA will define the corrective actions at the sub-systems level that are representative of subsystem reliability requirements. The seventh step is the central one. It deals with risks assessment and risks mitigation with definitions of corrective actions.
Assessment The risk assessment consists in defining the severity and the probability of the identified accidents, in order to evaluate the criticality. This information must be recorded in the various FMECA and the RECA tables. Concerning the probability, this one must be evaluated based on the fault trees and the event trees. Finally, it must be decided whether the risks are acceptable or not.
Mitigation The risk mitigation consists in advocating corrective actions (to be filled in the FMECA and the RECA) for the risks qualified as "non-acceptable" during the risk assessment step, in order to make them become "acceptable". The corrective actions can: – Reduce the probability of the accident, by: • Fixing an objective of reliability with a reliability requirement (at system or subsystem level). • Modifying the system architecture for a better reliability (with redundancies for example) with an architectural requirement, that derives from the reliability requirement of the objective. • Adding an additional security equipment (protective barrier) with a active functional security requirement, that derives from the reliability requirement of the objective. During the next iteration of the method, reliability requirements will be defined for this security equipment based on the analysis of the failure modes in which it participates.
– Try to satisfy a criterion, for example: • A single failure criterion, adding a security equipment (barrier) to increase the number of failures before the occurrence of an accident, with an active functional security requirement. • A spatial dispersion criterion, with an architectural requirement. • A redundancy with separate development criterion, with an architectural requirement. – Reduce the severity of the accident • Adding a protection or mitigation equipment, with an passive functional security requirement.
Note: This is not the only possible corrective actions (preventive maintenance for example). Other types of corrective actions will be incorporated in future work to improve the process. 3.10
Before eventually transferring the change requests to modify the system, this step will
summarize the results in terms of requirements, declination of requirements, and
traceability links between requirements and accidents, or requirements and requirements. As
in the first version of the method [
3.11
The process is finish once all the risks are considered as "acceptable". If this is not the case, a change request must order to modify the system and the method must be reapplied from the beginning by updating the different analysis. 4
The method provides a support framework to define system safety requirements with
an objective of traceability and requirements declination and derivation. The
interest is multiple for the safety field: the method deals with the safety elements (failure
modes, safety requirements...) and it is done with a comprehensive system engineering
(with traceability and requirements declination) which is a factor contributing to safer
systems. This method is compatible with the standard EIA-632 [
In this work, several safety attributes are taken into account, like reliability,
passive security and active security. They correspond to the given classification of safety
requirements, which are themselves defined from the corrective actions. Other
requirements concerning maintainability or availability should also be considered in further
study. The probability, the severity and the criticality was treated through the FMECA.
However, the work still doesn’t consider the detectability aspect. We also should update
the tool that implements the first version of the method presented in [