当前位置:首页 >> >>

A Framework for Achieving Safety in Model-Based Design

A Framework for Achieving Safety in Model-Based Designs
Frantz Iwu High Integrity Systems Engineering Group, Department of Computer Science, University of York, York, United Kingdom E-mail: iwuo@cs.york.ac.uk

1. Introduction
Over the years many techniques and approaches have evolved to support safety analysis processes. Many of these techniques, if applied manually, are tedious and repetitious as the system design becomes more complex. The problem is worse for software as there is still no consensus on what approaches to determining software safety are effective [4]. A software safety process involves identifying safety requirements, achieving safety and safety assurance. This paper, supported by the MATISSE1 project, presents a software safety process, which provides a framework to enable derived safety requirements (DSRs) for software systems to be largely produced automatically. These DSRs are produced from software designed in model-based environments such as Matlab Simulink given a set of overall safety requirements (OSRs).

2. General Approach
Model-based approaches for designing embedded control system software have been successfully implemented for satellites and many aerospace applications. However, designers of these classes of software face difficult challenges because of the level of development cost and tight schedules. In addition, they need to provide predictable performance, competitive features and, most importantly, evaluate software designs without the need to produce prototype products. In traditional approaches, the verification process of embedded software is normally performed at a later stage when actual or prototype products and real-time embedded targets become available. This can be costly in terms of time and resources as during system integration errors may be discovered that could have been found during the early stages of the design. Another important issue is the reduction in the cost of managing changes during the design process. A model-based approach is one approach for achieving these cost reductions. Model-based development is posited as useful for explicitly capturing architectural assumptions and design decisions, which are essential in performing safety analysis of the design. At this level where the functional model of the software is described, we can perform a hazard analysis on each model to determine how they respond to omission, commission, timing or value failures propagated by other models as well as how internal logical defects within each model can affect the output of the model. Model-based environments such as Simulink (from The Mathworks) allow the design of these classes of software and involve behaviour modelling and simulation to accurately predict and optimise performance. Figure 1 gives an overview of the approach used in our framework for modelling and performing safety analysis. The design of the system shown in the left

Models And Techniques for Integrated System Safety Engineering

hand side is partitioned based on functional decomposition - top down design. The highlevel and subsystem functions are identified and the software architecture is organised in terms of these functions. A HAZOP-like analysis is performed on these functions producing a table structure, which form the basis for automatically generating cause consequence diagrams.
System M odel Hazard Analysis Automatic Synthesis

high-level system architecture

1st level subsystem

2nd level subsystem

Automatically generated Cause Consequence Diagram for the system

HAZOP-like analysis of high-level system and subsystems

Figure 1: Safety Analysis for Model-Based Systems

3. Safety Analysis Process
The growing role of software in safety critical systems and the complexity associated with these systems [4] makes clear the need to propose a framework for automating software safety processes. This is because carrying out safety analysis by hand becomes less tractable. Ideally for safety-critical systems and software development processes to achieve safety in a "top down" fashion, the process should include stages shown in figure 2. Usually in practice feedback occurs between setting OSRs, identifying DSRs and apportioning DSRs to subsystems.
System requirements and concept Identification of top-level design Identification of derived safety requirement Implementation & integration

Hazard Identification & Risk Assessment

Setting overall safety requirement

Apportioning derived safety requirement

Verification of safety requirement

Figure 2: Safety Analysis for Model based Systems This paper is concerned with the modelling of failure modes and failure propagation through a Matlab Simulink model. This includes identifying and apportioning DSRs to subsystems and components, which are the two main elements of the preliminary system safety assessment (PSSA) in ARP4761 [2]. We assume that system requirements are known, the system top-level design has been identified and the associated hazards and OSRs are known. The OSRs are initially assumed to be defined in terms of outputs from the system. The valid and complete identification of derived safety requirements, if

shown to be satisfied and verified, ensure that the safety requirements are met. Related work in this field, has involved adding failure annotations by hand to Simulink models, automatically generating fault trees from those models and automatically generating possible failure modes [1]. In this paper we are interested in generating, as automatically as possible, Simulink level failure modes and fault propagation, using HAZOP-like analysis on flows. In addition, we are interested in generating cause-consequence diagrams for the hazards (which are equivalent to a failure to meet the OSR) based upon the failure modes of the Simulink model. We propose a framework that can be used to assess the generation, propagation and transformation of failures over the component’s input and output connections. In our framework, the safety analysis is performed at the component level where each component provides a service to other components. Hence a failure in one component can cause a failure in other components. Each component output is examined for potential deviation from the intended behaviour, based on a classification of failure types such as omission, commission, time (early, late) and value. The concepts of software HAZOP on flows are combined with the techniques of software fault and event tree analyses to enable safety assessment of the system at the architectural level. Our framework automates part of the analysis at this level. Table 1 shows the result of the failure behaviour of the analysed component of figure 3. The output failure mode is described logically in terms of its input failure mode (shown in column 3). For each output failure a safety function is defined and triggered when an error occurs. In each safety function (shown in column 5 of table 1), observation variables are measured and residual values are computed as the difference between the observations and the predicted normal behaviour. A deviation from the expected residual value implies that there is a fault in the system and this triggers the appropriate alarms. We can then construct various event paths based on triggered and non-triggered alarms. Experimental or estimated derived failure rates can also be allocated for each output failure for reliability analysis (shown in column 4).

Figure 3: Component Analysed
Output Failure Mode O-s out_1 Des cription Error of om is s ion: failure to provide the intended output Error of com m is s ion: provis ion of an output not required Error of tim ing: provis ion of an output at the wrong tim e Error of value: provis ion of the wrong output valve Input Failure Mode O-input_1 and O-input_2 C-input_1 or C-input_2 T-input_1 and T-input_2 V-input_1 or V-input_2

λ (f/h)
2 × 10 -7

Safety Function O_Alarm

Saf ety Function Trigger Condition

The alarm is triggered when an error of om is s ion has occurred The alarm is triggered when an error of com m is s ion has occurred The alarm is triggered when an error of tim ing has occurred The alarm is triggered when an error of value has occurred

C-s out_1

1 × 10 -6


T-s out_1

2 × 10 -7


V-s out_1

1 × 10 -6


Table 1: Hypothetical Component and Hazard Analysis

4. Tool Support
To enable the realisation of this framework for automating safety analysis in a pragmatic process, we propose the tool architecture shown in figure 4. The architecture supports the

proposed framework and a cause-consequence synthesis algorithm. In this section we describe the principles and the architecture of the tool. The tool will consist of a XML generator, a Cause-Consequence synthesis tool and a Z specification generator. The XML generator is written in the Matlab language (m-script) and generates an XML file to provide an easy interface with other modelling tools. The Cause Consequence synthesis tool reads the XML file produced from the annotated Simulink model and generates a Cause Consequence diagram based on the HAZOP-like analysis performed on the flows. The synthesis tool produces an output in a suitable format for tools such as Fault Tree+. Similarly, the Z generator reads the XML file produced from the annotated Simulink model and generates Z conjectures of the failure conditions. The output produced can then be fed into a Z tool such as CADiZ for interactive proof of conjectures and reasoning.
Annot at ed Simulink Model XML Generat or

XML File

Input Module

CC Synt hesis Module

Z Generat or Module

Out put Module

Out put Module

Fault Tree +


Figure 4: The Architecture of the Tool

5. Conclusion
In this paper, we proposed to extend the concept of model-based synthesis of fault trees from Matlab Simulink models to support the synthesis of cause-consequence analysis and the generation of failure conjectures in Z. We proposed a framework for analysing flows using HAZOP-like techniques, which includes defining safety functions using alarms, thus enabling event paths to be constructed, based on triggered and non-triggered alarms. Finally, we present a tool architecture to support the proposed framework. Future work, will involve tool development and applying the framework to existing case studies [3], which we hope will help us gain a better understanding of the potential, practicability and limitations of this approach to safety analysis.

6. Reference
[1] Papadopoulos Y., Maruhn M. “Model-Based Synthesis of Fault Trees from MatlabSimulink models”, DSN 2001 Int. Conf. On Distributed Systems and Networks Gothenburg, Sweden, July 2001, pages(s): 77–82. [2] ARP4761. “Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment”, Society of Automotive Engineers, 1996. [3] McDermid J.A. “Software Hazard and Safety Analysis”, Tutorial at the FTRTFT 2002 Oldenburg Germany, 9th September 2002. [4] Galloway, A., McDermid, J.A., Murdoch, J. & Pumfrey, D.J. “Automation of System Safety Analysis: Possibilities and Pitfalls”, Proceedings of the 20th International System Safety Conference, Denver, USA.



All rights reserved Powered by 甜梦文库 9512.net

copyright ©right 2010-2021。