Utilizing UML and patterns for safety critical systems

This article discusses methods of object-oriented analysis and design in UML suitable for the specific needs developing safety critical software systems, and to which degree safety can be related to components. Different patterns, typical for safety related software, are mapped into UML models. The safety aspects are characterized by that the focus is not only on the fulfillment of functional requirements for the process but also on fulfillment of patterns such as diversity, diagnostics, safety layers and on development quality. These safety patterns can be viewed as a feature provided by the system when implementing a functional requirement and not as a primary functionality. This justifies the argumentation that a Safety Quality of Service should be employed and modeled aligned with the proposed standard for modeling resources in UML. Introduction In safety critical systems there are special requirements in order to obtain sufficiently reliability. Capturing requirements, analyze them, design and test the system systematically is demanding when one has to obtain complete complex system where the probability that an error leads to a dangerous situation may be up to order 10 per hour for control in process industry ref. [1]. The standard IEC 61508 ref. [1] will be the main safety standard referred to in this article. Douglass [2] has discussed some patterns and UML for safety-related systems. There is some discussion of requirement capturing and verification using UML for safety critical systems in the literature. In ref. [2] Carpenter addresses the question of requirement verification by focusing on how UML use cases can be used to specify requirements and to verify them. Carpenter is addressing the question on verification of requirements and how to trace these through a project. This is however not unique, only more important for safety critical systems. There exist some software tools intended to help tracking requirements through analysis and design of safety critical systems, some discussed in [4]. High quality is also required by safety system but is not unique either. The uniqueness of a safety critical system is that the design usually includes hardware redundancy, some type of software redundancy, software fault tolerance and substantial self-supervision diagnostic software. The system must be analyzed by one or more acknowledged hazard analysis methods to verify that the redundancy and diagnostic is sufficient. One method for obtaining some of the safety critical functionality is a monitor system as discussed in ref. [5]. There are an increasing number of computer and software systems that is of high-dependability and safetycritical type [6] and since UML is becoming the main design language it is important that UML provide the safety-critical software developers with well developed methods. There is progress in the effort to standardize both real-time and scheduling and also fault-tolerance in UML, ref. [7]. The hardware part of a system is usually well modeled by stochastic processes and it is well known that these can be quantified. The focus here is therefore on the software part where less is known. Safety is a system concept and lifetime concept, and it is a huge simplification to assume it can be fully modeled as low-level components. However, to some degree it can be done this way and a final system safety analysis will rely mostly on safety aspects in the components. There is a slight distinction between safety systems that has a safe state, e.g. chemical industry where the process can be stopped or a train that can slow down, and safety systems with no safe state, e.g. commercial airplanes. We have here the main focus on systems with a safe state. Diversity of software How safe a system is, is depending on how reliable the functionality is that ensures that the system is not entering a dangerous state. When we discuss a computerized control of a physical system, this translates to the reliability that the electronics and computer do not set output values that turns the system under control into a risk situation where life, environment, or equipment could be damaged. One important way to increase reliability is redundancy. This is the traditional way to increase reliability of hardware. Some type of functional redundancy is also often used for software. The requirement for a safety system will often include diversity functionality. This can be in the form of a diverse code execution, or in form of handling a COTS (Commercial Of The Shelf) SOUP (Software Of Uncertain Pedigree) problem with a protection function solution as sketched in the fault trees in Figure 1 (a) and (b). The main requirement for the system is in fact the functionality one software version in Figure 1 (a) is providing, or the COTS functionality in Figure 1 (b). The redundancy shown here is a mean to provide a sufficient level of safety or reliability. Safety Quality of Service The ideal way to provide the functional requirements with the proper safety level would be to introduce a Quality of Service (QoS) for safety. This might be done in the same manner as in ref. [8] where properties related to time are modeled. In Figure 2 there is sketched such a resource providing a QoS for a functionality requiring safety. COTS handling COTS/SOUP software Protection function & Hazardous event Diverse code Software version A Software version B & Hazardous event