Complex approach to corporate fleet safety risk management. PepsiCo Russia. Oleg Smolyaninov
System engineering approach for safety management of complex systems
24
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR ESM'2009, October 26-28, 2009, Holiday Inn Leicester, Leicester, United Kingdom
description
ESM'2009, October 26-28, 2009, Holiday Inn Leicester, Leicester, United Kingdom. System engineering approach for safety management of complex systems. Romaric GUILLERM Hamid DEMMOU LAAS-CNRS. Nabil SADOU SUPELEC/IETR. Outline. General context and motivation System engineering - PowerPoint PPT Presentation
Transcript of System engineering approach for safety management of complex systems
Romaric GUILLERM
Hamid DEMMOULAAS-CNRS
Nabil SADOUSUPELEC/IETR
ESM'2009, October 26-28, 2009, Holiday Inn Leicester, Leicester, United Kingdom
OutlineGeneral context and motivation
System engineering
Safety integration approach
Conclusion and perspectives
2
General contextNowadays systems are complex
More and more functionalitiesMore and more technologies
design process more and more complexStronger constraints of dependability (Standards,
…)Hard competition (cost and time…)
3
General contextPerforming of important system level properties, such as
safety and security, become difficult.
These properties must be built at the beginning of system design; they cannot be added on or simply measured afterward.
Dependability of complex systems relies heavily on the emergent properties that result from the complex interdependencies that exist among the involved systems and their environments.
It seems that the dependability properties of these systems must be addressed in an overall study.
4
General contextWeaknesses of the current safety processes can be
resumed in the following points (non exhaustive list) :Safety analysis involves some degree of intrinsic uncertainty.
So, there is a degree of subjectivity in the identification of safety issues.
Different groups need to work with different views of the system (e.g. systems engineers’ view, safety engineer’s 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.
Solution: take into account the safety with a general point of view, early in the design.
5
MotivationProposition of complex systems conception
framework:Complete Coherent
Integration of safety evaluation activities and the design (development) activities
Proposal approach:System Engineering as frameworkglobal approach of safety in this framework
6
System EngineeringDefinition
System Engineering is a general methodological approach that encompasses all activities appropriate to design, develop and test a system providing efficient and economical solution to client's needs while satisfying all stakeholders.
Paradigm : processes-methods-tools
7
Processes Methods ToolsRely on Rely on
System EngineeringStandard EIA-632
8
System EngineeringStandard EIA-632
9
Safety integration approachThe 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.
Approach:Guide for the consideration of the safety in each sub-processes
of the EIA-632 standard: translate or refine in terms of safety the processes of the EIA-632 standard.
10
Safety integration approach
11
Safety integration approach
12
R.14 – Acquirer Requirements
R.15 – Other Stakeholder Requirements
R.16 – System Technical Requirements
The developer shall define a validated set of acquirer (other stakeholder) 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.
Safety requirements can be derived from certification or quality requirements or can be explicitly expressed by acquirer or other stakeholder.
Safety integration approach
13
R.14 – Acquirer Requirements
R.15 – Other Stakeholder Requirements
R.16 – 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.
Concerning safety: System technical requirements traduce system performances It consists on defining safety attributes (SIL level, MTBF(1), MTTR(2), failure
rate,…) Technical requirements can be derived from a preliminary hazard analysis. Some standard can help designer to define safety requirements.
Example in civil aerospace sector: ARP4754 and ARP 4761.
(1) Mean Time Between Failure, (2) Mean Time To Repair
Safety integration approach
14
Safety integration approach
15
R.17 – Logical Solution Representations
R.18 – Physical Solution Representations
R.19 – Specified Requirements
The developer shall define one or more validated sets of logical solution representations that conform with the technical requirements of the system.
The recommendation is to use semi formal / formal models for the solution modeling. The use of formal methods allows for automation of verification and analysis.
In this processes, safety analysis techniques will be used to determine the best logical solution.
Safety integration approach
16
R.17 – Logical Solution Representations
R.18 – Physical Solution Representations
R.19 – Specified Requirements
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, particularly safety requirements.
The same safety analysis may be done for the physical solution representations. The same recommendations than for logical solution remain true.
Safety integration approach
17
Safety integration approach
18
R.22 – Effectiveness Analysis
R.23 – Tradeoff Analysis
R.24 – Risk Analysis
The developer shall perform risk analyses to develop risk management strategies, support management of risks, and support decision making.
Techniques: Fault tree ; Failure Mode, Effect, and Criticality Analysis; …
Determines the risks of the systemCan generate safety requirements other than that defined by the
acquirer and other stakeholders.
Safety integration approach
19
Safety integration approach
20
R.25 – Requirement Statements Validation
R.26 – Acquirer Requirements Validation
R.27 – Other Stakeholder Requirements Validation
R.28 – System Technical Requirements Validation
R.29 – Logical Solution Representations Validation
Requirements Validation is critical to successful system product.Requirements are validated when it is certain that they describe
the input requirements and objectives such that the resulting system products can satisfy them.
A great attention is done to traceability analysis.Like other requirements, safety requirements must be validated.
The validation allows designing safe system.To facilitate this step, semi-formal solutions, like UML or SysML,
can be used for good formulation of requirements.
Safety integration approach
21
Safety integration approach
22
R.30 – Design Solution Verification
R.31 – End Product Verification
R.32 – Enabling Product Readiness
The System Verification Process is used to ascertain that: The generated system design solution is consistent with its source
requirements, in particular safety requirements.Some traceability models allow defining the procedure of
verifying safety requirement. These procedures are planned at the definition of safety requirement.
Simulation is a good and current method used to achieve system verification
Other methods: virtual prototyping, model checking,…
Conclusion and PerspectivesApproach integrating safety in system
engineering processBased on the EIA-632 StandardProcesses -> Methods -> Tools
MDE (Model Driven Engineering) approachUsing SysML and AADLFocusing on traceability, with a SysML data
model
23
