Safety-related control systems software

In the context of safety-related control systems, the Essential Health and Safety Requirements of the Supply of Machinery (Safety) Regulations 1992 lay down generic requirements that must be considered by suppliers for the safety and reliability of control systems control devices starting and stopping devices mode selection failure of the power supply and the control circuit software and movable guards. 

Close attention to detail is essential in the design of all safety-related control systems, whether they are simple hard-wired systems, or complex systems implemented by software. It is important that safety analysis techniques are used to ensure that the requirements in the specification are met, and that the foreseeable failure modes of the control system do not compromise that specification. Issues of concern, which have been identified, include an over-optimistic dependence on the safety integrity of single channel systems, failure to adequately verify software, and poor consideration of human factors. Good design can also eliminate, or at least reduce, the chance of error on the part of the operator or maintenance technician. ... 

Design and hardware/software engineering of any safety related control system is to be evaluated and matched to required SILs. 

Rae, A. (2007) Helping the Operator in the Loop Practical Human Machine Interface Principles for Safe Computer Controlled Systems, SCS 07 Proceedings of the twelfth Australian workshop on Safety critical systems and software and safety-related programmable systems—Volume 86 Pages 61-70. Australian Computer Society, Inc. Darhnghurst, Australia. 

Modern factory and industrial automation is more flexible and open and meant towards higher productivity. These systems replace conventional relay or solid state control systems, with extensive use of open programmable electronics in all types of scalable and demanding solutions. Modem safety integrated safety-related controllers of various designs with a variety of hardware and software architectures, including PC-based solutions, cover all sectors and types of factory automations. Associated standards for factory automations are ... 

The PSS system has been designed to allow standard (or basic ) control functions to be performed as well as safety related control functions. Safety functions are known as FS and standard are called ST. FS software runs in all three processors using an FS working bus. A separate bus is provided for the A processor to perform ST instructions. The dual function structure of the PSS has fail-safe controls operating with an independent triple voting bus whilst standard or non-safety functions operate only in processor A on a separate working bus. 

The development of computer capabiUties in hardware and software, related instmmentation and control, and telecommunication technology represent an opportunity for improvement in safety (see COMPUTER TECHNOLOGY). Plant operators can be provided with a variety of user-friendly diagnostic aids to assist in plant operations and incipient failure detection. Communications can be more rapid and dependable. The safety control systems can be made even more rehable and maintenance-free. Moreover, passive safety features to provide emergency cooling for both the reactor system and the containment building are being developed. 

Software need not be treated any differently than the other parts of the system. Most safety-related software problems stem from requirements flaws. The system requirements and system hazard analysis should be used to determine the behavioral safety constraints that must be enforced on software behavior and that the software must enforce on the controlled system. Once that is accomplished, those requirements and constraints are passed to the software developers (through the black-box requirements specifications), and they use them to generate and validate their designs just as the hardware developers do. 

Expert analysis of NPP safety related computer-based automatic control systems algorithms and software expediently to perform simultaneously. Besides, tasks of V V assessment are need to divide on the ... 

During the 1990s the concept of Safety Integrity Levels (SIL) was developed [1]. It serves to assess safety-related systems and concerns aU components and subsystems required to realize safety functions from the sensor to the final element. Apart from that it applies to application software, which was developed for systems with limited variability language (no branching) or programmable logic controllers (PLC). 

A well-defined design and integration process for the safety related hardware and control system (inch software) is required. 

Both lEC 61508 and DEF STAN 00-55 mandate software development processes, with the implication that following the prescribed development process is essential to developing software of the required integrity. The use of Commercial off-the-shelf (COTS) software is increasingly prevalent in safety-related systems. However, the approaches prescribed by lEC 61508 and DEF STAN 00-55 cannot be used for COTS software, for which the system developer has little or no control over the development processes adopted. Furthermore, source code may not be available for COTS software, and hence many of the verification techniques recommended cannot be used. 

What should be covered in the safety specification The initial consideration will be to identily the safety-related systems and the safety-related functions. It is of course possible for the safety of some computer-controlled plant to be adequately ensured by conventional means, but it is more usual for at least some of the safety-related systems to be also programmable. These may be either control systems or protection systems which are specifically designed to come into operation in the event of a mishap or malfunction. It is highly desirable that wherever possible, control and protection systems are separated. This has the advantage that the amount of software affecting safety is minimized and also ensures that failure of the control system does not precipitate a consequent failure of its own protection system. Leveson 6 suggests several software control faults that may adversely affect system safety ... 

At the center of this is the EN 50126, which deals with reliability, availability, maintainability, and safety for railway systems. EN 50129 applies to safety-related electronic control and protection systems. And EN 50128 applies to safety-related software for railway control and protection systems. These CENELEC standards cova all railway design, operations, and certification in the EU though there are other related and applicable standards, these are the most important... 

One of the most important software safety standards is the International Electrotechnical Commission lEC 61508, Functional Safety of Electrical/ Electronic/Programmable Electronic Safety-Related Systems. It applies to all industries that use safety-critical systems that are electronically or software controlled. It uses safety processes described in Chapter 4 and in other safety analysis... 

A safety-critical system is a system that can cause undesired loss or harm to human life, property, or the environment, whereas safety-critical software is software that can contribute to such loss or harm [1]. A software cannot directly cause loss or harm, but it may control some equipment that may cause accidents [2]. Therefore, many examples of safety systems which have failed due to software related faults the loss of Ariane 5 [4], Therac-25 [3], and more recently Boeing 777-200 [8] and the Toyota Prius. Many software related accidents and major losses are the result of incompleteness or other flaws in the software requirements, not coding errors [1]. Safety is a system problem therefore, to understand the safety aspects of software, it is necessary first to understand the general field of system safety. 

Functional safety engineering involves identifying specific hazardous failures whieh lead to serious consequenees (e.g., death) and then establishing maximum tolerable frequency targets for each mode of failure. Equipment whose failure contributes to eaeh of these hazards is identified and usually referred to as safety related. Examples are industrial process control systems, proeess shut down systems, rail signaling equipment, automotive controls, medical treatment equipment, etc. In other words, any equipment (with or without software) whose failure ean eontribute to a hazard is likely to be safety related. 

These standards closely mirror the requirements of IEC80001 but require a proportionate set of controls reflecting the less critical nature of advisoiy or safety related software systems. There is no regulatory requirement for this class of systems. All assurance is conducted by accreditation of supplier process and subsequent inspection of safety deliverables. In this respect it was hoped to avoid the burdens of a compliance scheme such as the medical devices directive (which in its current form is felt by suppliers to be burdensome and overly bureaucratic for this category of software). 

To further complicate matters, there are significant advantages in ensuring that suspension design continues to be the domain of vehicle dynamicists. The use of domain specialists in the production of control systems means that safety-related software development techniques need to be readily accessible to non software specialists. The commonly proposed safety critical related techniques, such as formal methods, are undoubtedly required in this domain. However, they must be presented as part of an environment which is acceptable to the target user. The CBASS environment will therefore have usability as a prime requirement. 

There are many definitions of safety, and sometimes a distinction is made between systems being safety critical and safety related, dependent on the degree of harm they can cause. We take the view that safety is concerned with absolute harm, that is irremediable or irrecoverable damage. The damage can be to individuals, to property, or to the environment. Safety is a systems issue. Computer systems, and hence software, can only influence safety if they are used to control some physical process which can lead to harm. Thus, although we wish to build computer based tools to support safety analysis, our aim is to support safety cases about systems implemented in a mixture of technologies, and involving humans, not simply implemented as computer systems or in software. 

Malcolm 92a] Malcolm, R E "Software in safety-related systems basic concepts and concerns" In Bennett, P.A. (Ed.) "Safety aspects of computer control" Heinemann-Butterworth, 1992... 

Interlocks provide logical constraints within control systems and often provide a safety related function. These functions may be embedded within the basic control system in the form of software or they may be relay or mechanical interlocks directly linked to the equipment. They can therefore be considered as providing a layer of protection and their degree of independence must be evaluated in each particular application - in each application decide if the interlock is part of the control system, an independent safety device or part of the SIS. 

---