Artykuły :: Transport :: Conference papers
|Modelling of safety properties of a control system|
AleĹĄ JANOTA, Karol RĂSTOÄNĂ, JiĹĂ ZAHRADNĂK
Safety-critical system is a system the wrong functioning of which can cause personal injury, significant material loses, environment damage or other undesirable consequences. Many safety-control systems are typically fail-safe systems, i.e. once a fault has occurred the system must remain in the previous state (provided that this state does not represent a hazard to the controlled system) or must enter a pre-defined safe state. It is useful to base development of such a system on application of modelling methods (for certain development phases it is necessity). In principle it concerns design of a process model; model of a structure and functions of the system; and safety and reliability model.
These models play an important role in user requirements analysis and system requirements specification, design of structure and the system itself as well as system verification and validation. Fulfilling these tasks usually requires combination of proper modelling methods and modelling tools.
One of the basic standards related to safety-critical systems is the standard  considering the safety-critical system through its life-cycle, which is generally defined as a set of activities performed from the moment of initial stimulation (concept design) to decommissioning of the system and its disposal. This standard defines procedures and tasks for individual phases to be performed in order to ensure ability of the system to work in regard to Reliability, Availability, Maintainability, Safety
and their mutual effects. Life-cycle is divided to phases and development process represents only a part of the system life-cycle.
2. MODELLING OF FUNCTIONAL AND SAFETY SYSTEM REQUIREMENTS
Definition of system requirements is one of most important activities in development of safety-critical systems. It is an obligatory document agreed between a provider and customer. System specification represents one of basic documents the system development is based on. It must be unambiguous, understandable, complete, consistent and controllable.
Mistakes made during specification phases are often detectable as late as during the integration tests. Then their removal often requires additional extra cost. If errors remain undetected, they become potential sources of systematic faults during system operation.
Therefore it is recommended to analyse user requirements in initial development phases and create a model that makes possible testing of completeness and soundness of functional specification and remove potential inconsistencies. Model design should be based on full understanding of user requirements and use of a proper method and modelling tool.
Generally, natural language or other informal notations have many disadvantages when used for technical descriptions. Usually there is a problem to create specification so precise that it could be unambiguously transformed to SW or HW solution of the system. Model of the system based on semiformal and formal methods (usually supported with SW-tools) helps to create complete, unambiguous and logical descriptions of functional system properties . Creating of such a model is time-consuming so such methods and procedures should be used to make the model usable in successive phases of the system life-cycle (e.g. for partial or complete generation of a source code). For this purpose object-oriented (OO) modelling can be successfully applicable, partially the Unified Modelling Language (UML) that is one of the most wide-spread and often used standards of OO modelling , .
The standard UML 2.0 offers various modelling and visualisation elements to capture and model system requirements and defines 13 diagrams classified into 3 categories :
• Structure diagrams – Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram, Package Diagram, Deployment Diagram;
• Behaviour diagrams - Use Case Diagram, Activity Diagram, State Machine Diagram;
• Interaction diagrams – Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction Overview Diagram.
Fig.1. Model of the system in the Rhapsody SW-tool environment
The Unified Modeling Language is implemented and supported by many SW-tools (e.g. Rational Rose, Rhapsody, Enterprise Architect…) that make possible source code generation directly from the diagrams, animation of the model and linking it to the Graphic User Interface (GUI). Fig.1 shows an example of visual display of selected diagrams in the Rhapsody SW-tool environment, a part of the generated source code and GUI of the controlled process.
Contributions resulting from application of OO modelling in the field of design of safety-critical systems can be summarised as follows.
• It gives a chance to get alternative solutions and select the best of them;
• It gives a possibility to create basis model usable for creation of a future real system and simplify software design process;
• It unifies principles and procedures for creation of unique documentation;
• It gives a chance to check correctness just before creating of the system itself;
• It produces an environment suitable for communication not only between development teams, but also towards other subjects involved in the process of system verification and approval;
• It simplifies future realisations of possible system modifications.
This approach to system design makes the process of design, development and approval of new systems significantly more effective, increases their quality and is in accordance with requirements of European standards.
Fig.2. Description of a state diagram to the ladder logic
Advantages of formal methods can also be utilised in design of SW for programmable logical controllers (PLCs) that also become to be used more and more in control of safetycritical processes. If the control system may be seen as a sequential circuit, its operation may be described (modelled) through an algebraic system – finite automaton.
The finite automaton M is an ordered quintuple
where X is a set of input words (inputs), S is a set of states and Y is a set of output words (outputs); u and v are the following mappings:
u:S×X → S (2)
ν:S×X → Y(or ν:S→Y),
where mapping u is called a transient function and mapping v is an output function. The finite automaton may be represented by an oriented graph called a state diagram (statechart) or a transition diagram. Nodes of the graph represent states of the automaton. Oriented edges represent transitions between states and may be quantified using input symbols of the automaton initiating its transition from one state to another. Fig.2 shows a state diagram transformed to the ladder diagram – ladder program  where each state is represented by one diagonal. The ladder logic is most spread way of PLC programming. It is a graphical method of programming based on techniques applied for relay circuits.
Regarding achieved level of knowledge and limited technical and economic resources the safety requirements cannot be understood absolutely. We must really admit existence of a certain risk resulting from operation of safety-critical systems that really cannot be completely eliminated.
To define safety system requirements means to know risk resulting from system application and to know an acceptable risk. Therefore in initial phases of the system life-cycle we must create a process model that helps us to identify hazards associated with a process to be controlled, to assess intensities of their occurrences and resulting consequences. Combination of intensities of hazard occurrence and hazard consequences represents the risk associated with system operation. Based on knowledge of this risk and knowledge of acceptable risk (user requirement), we can define requirements for Safety Integrity Level (SIL) of the system .
There is dependence between risk resulting from a failure of individual control functions and safety requirements for providing of these functions. If we define safety requirements for individual control functions, concurrently we also define system requirements and subsequently requirements for individual parts of the system according to how they are connected with performance of these functions.
3. MODELLING AND CHOOSING OF A STRUCTURE
Choice of a system structure is one of the most important decisions taken during the development process. When choosing a structure, we must proceed very warily since a compromise between a price of system on one side and safety integrity and system availability on the other side must be found. . The decision on system structure choice cannot be based on intuition of a developer only, but results of RAMS parameters modelling. Using a created model the most proper solution must be chosen to respect user requirements related to particular RAMS system parameters.
Meeting RAMS requirements (concerning real values of reliability parameters of commercially available structural elements) usually needs application of different forms of redundancy (hardware redundancy, information redundancy, time redundancy) on different levels of the system. Finally choice of a proper structure is influenced by requirements on testing diagnostics of the system.
Safety-critical systems realised on the base of processor technique use technique of composite fail-safety that can be characterized by the fact that required function is multiplesolved with mutual data comparison between individual channels (hardware or software comparison of input data, output data, and intermediate data of individual operations…). Their correct and safe functioning assumes mutual independence of channels (i.e. one cause cannot give rise to faulty or hazardous activity of multiple channels), early fault detection and follow-on negation of its consequences. Systems realised on the base of composite fail-safety are called systems m out of n where n represents a total number of channels realising the required function and m represents a minimal number of these channels that must be functional to assure functionality of the whole system. Generally the systems may have channels realised identically (the same hardware and software) or differently. What’s more, individual channels may utilise different forms of reservation or different basic structures applied on different system levels. Modelling process must also respect the fact that fault occurrence may result in change of the system structure.
Model designed in this phase of life-cycle may be gradually developed and used for verification of results achieved during the development process of the system. Regarding the fact that individual RAMS parameters may influence one another, we must use such a method that makes possible complex modelling of RAMS parameters. For that purpose we can successfully use for example Markov chains or Petri nets.
4. MODELLING OF FAILURE EFFECTS ON SYSTEM SAFETY AND AVAILABILITY
Analysis of what are failure effects on system safety aims at creating the model that will enable to identify the process of system transition from a safe state (there is no need to define this state as a fault-free state) to a hazardous state and to calculate probability of occurrence of the hazardous state of the system or of the controlled process as a consequence of faults influencing the system operation , .
When analysing failure effects on system safety, different methods may be used (including methods originally designed for analysis of parameters of system reliability – RBD , FTA , FMEA , Markov models , Petri nets...). Selection of an individual method or combination of methods must be considered in the frame of particular case of analysis.
In practice there are several principally different approaches applicable to analysis of stochastic models. They differ one from another in accuracy of results, applicability and computation demandingness. We can talk about the following approaches:
• Simulation; a stochastic model is emulated by a simulator that simulates time spent in individual states; accuracy of calculations depends on time simulator running which indicates a certain limit for practical application;
• Numeric solution; accuracy of calculation depends on a properly chosen method of calculation and on numerical accuracy of computers, therefore the use of proper software tools is usually necessary (e.g. BQR reliability engineering , RELEX software , ITEM software , CARMS  ....); a number of model states is a limiting factor for the reason of computing demandingness;
• Analytical solution; properties of individual states are expressed in the form of complete relations containing parameters of the model; this solution is the most accurate but in the case of complex models very demanding and difficult.
Generally, analysis of failure effects on system safety must mostly deal with failures caused by environment effects; systematic failures; and random failures caused by system ageing.
Essential majority of computer system elements is represented by electronic elements that are not subject to mechanical wear. Occurrence of random failures caused by ageing of these elements may effectively be described by exponential distribution. Availability A(t) and safety Q(t) of the control system depends (inter alia) on failure rates of system elements λ, diagnostic coverage c, detection-and-negation rate δ and recovery rate μ.
A(t) = f(λ,δ,μ,c,t) (3)
Q(t) = g(λ,δ,μ,c,t) (4)
Fig.3 shows a Markov diagram representing a simplified example of modelling of random failure effects of one system element. State 1 represents a failure-free state. After occurrence of failure the element may enter the state 2 (occurrence of a detectable failure), or the state 3 (occurrence of a non-detectable failure). The state 4 is a safe state of the system after failure detection. The system may get back to the failure-free state using one of two possible mechanisms of the control system recovery. The first mechanism takes account of concurrent diagnostics and recovery rate μ1, the second mechanism takes account of periodical diagnostics aimed at detection of masked failures and recovery rate μ2. In the case of the second mechanism of recovery we do not consider time of failure detection since interval of periodical checks is significantly longer than time of failure detection.
Fig.3. Markov diagram
Fig.4. Combined model of availability for the control system 2 out of 3
When analysing failure effects, individual analysis methods may properly be combined in order to simplify significantly the whole process of failure effects analysis. For example, Fig.4 shows the block diagram of availability of the control system 2 out of 3. In each block of this diagram (blocks represent system elements A, B, C) there is a schematic representation of a Markov diagram according to the Fig.3. Availability of the control system can be calculated in such a way that at first availability of individual elements will be calculated and then these values will be used to calculate availability of the whole system.
Except that modelling applied in the process of development of a safety-critical system can increase effectiveness of the development process, in certain moments modelling seems to be necessity. It should be noted that strict requirements for safety-critical systems with a high safety integrity level (e.g. according to  systems with continuous operation and SIL 4 have a tolerable value of the hazardous failure rate less then 10-8 h-1) cannot be proved by tests or results gained from real operation only (frequency of hazardous state occurrence is very small and the value of average time between two hazardous failures is many times higher than time of useful life of one system). Giving a proof that safety requirements are met and final risk is acceptable is impossible without using proper modelling methods and tools. The paper was elaborated with a support of the APVT agency through the grant No. APVT-20-P00705 and with a partial support of the grant within the MVTS project No. Mad/Slov/Ĺ˝U/05/GVOP.
 JANOTA, A. - RĂSTOÄNĂ, K. - ZAHRADNĂK, J., UML - based Specification of a Railway Interlocking and Signalling System, Fortschritt Berichte - VDI Reihe 12 Verkeherstechnik Fahrzeugtechnik, Braunschweig, Publischer VDI-VERLAG GHBH, pp. 131- 142, 2003, ISSN 0178-9449
 RĂSTOÄNĂ, K. – Ĺ˝DĂNSKY, J., PouĹžitie koneÄného automatu pri programovanĂ PLC, AEEE, Vol. 3/2004, No. 1, pp. 45-49, (in Slovak)
 RASTOÄNĂ, K - JANOTA, A – ZAHRADNĂK, J., The Use of Development of a Railway Interlocking Integration of Software Specification Techniques for Applications in Engineering, Springer-Verlag Heidelberg, 2004, ISBN 3-540-23135-8.
 RĂSTOÄNĂ, K – ZAHRADNĂK, J., Relation between Structure of an Interlocking System and Test Diagnostics Requirements, Periodica polytechnica, ser. transp. eng., Vol. 27, No. 1-2. (1999) Budapest University, pp. 29-41, ISSN 0303-7800.
 RĂSTOÄNĂ, K., Modelling of Failure Effects to Integrity of System, AEEE No. 2 Vol. 3/2004, Ĺ˝U v Ĺ˝iline, pp. 91-94, ISSN 1336-1376.
 RĂSTOÄNĂ, K: AnalĂ˝za rizĂk ĹželezniÄného signalizaÄného systému, AEEE No. 3-4 Vol. 2/2003, Ĺ˝U v Ĺ˝iline, pp. 24-29, ISSN 1336-1376, (in Slovak)
 CSN IEC 165, PouĹžitĂ MarkovovĂ˝ch metod. 1995, (in Slovak)
 STN EN 61078, MetĂłdy analĂ˝zy spol'ahlivosti. MetĂłda blokového diagramu spol'ahlivosti. 2001, (in Slovak)
 STN EN 61508, FunkÄnĂĄ bezpeÄnost elektrickĂ˝ch / elektronickĂ˝ch / programovatel'nĂ˝ch elektronickĂ˝ch bezpeÄnostnĂ˝ch systémov, 2002, (in Slovak)
 STN IEC 1025, AnalĂ˝za stromu poruchovĂ˝ch stavov, 1995, (in Slovak)
 STN IEC 60812, MetĂłdy analĂ˝zy spol'ahlivosti. Postup analĂ˝zy spôsobu a dôsledku porĂşch (FMEA), 1992, (in Slovak)
AleĹĄ JANOTA, Karol RĂSTOÄNĂ, JiĹĂ ZAHRADNĂK
Faculty of Electrical Engineering, University of Ĺ˝ilina