Safety critical systems - the basics
Designing any kind of system to be truly safe is a challenge. The first requirement is to define the term “safe” and consider the implications of it being unsafe. A system is a combination of hardware and software and these each contribute to the safety and integrity of the system as a whole. This article looks at the basic considerations for designing for safety.
A number of industry segments demand systems that comply with specific safety requirements. Obvious examples are mil/aero and medical and, of course, one which we bump into every day: automotive.
A true story
Some years ago, this guy – we will call him “R” - got a new car. It is not useful to identify the make/model here, as things will have changed, but suffice it to say that it was an up-market, expensive vehicle, where quality would be expected. Soon after taking delivery of the car, R was driving at some speed on the freeway, when the vehicle suddenly started to pull hard to the right. He quickly realized that the brakes on one side of the car were being applied automatically! He got the car under control and drove it straight to the dealers who had sold it, demanding immediate attention.
A day later, they returned the car to him, admitting that they had not found a fault, but had replaced a bunch of stuff and assured him that it should be fine now. It was not fine. Next time R drove at speed, the problem occurred again. Once again, he returned the car and said that he would not accept it back until they had unambiguously identified the fault and rectified it. It took a couple of days. They discovered that the ESP sensor was faulty and triggered the system unnecessarily. This sensor is located under the driver's seat and essentially detects rotational movement of the car; the braking is intended to offset that motion to avoid the car going into a spin.
R was not really the victim of a faulty car. It was a major design flaw, which is so elementary that the manufacturers of the car should be deeply ashamed.
Garbage in, garbage out
In the world of data processing, there is an old jargon term: GIGO – garbage in, garbage out. This simply explained that a system, however well implemented, will only produce valid results if it has valid input data.
A typical safety critical embedded system has essentially two parts: sensors to gather data and software to process it. For a system to be safe, each of these must given due attention.
Modern cars are stuffed full of microprocessors and microcontrollers that perform a variety of functions, which vary in their importance from convenience to safety critical. It is interesting to consider how each of these different type of systems is implemented.
Systems in cars may be broadly divided into 3 categories, depending on their safety requirements:
- Convenience systems, which add to the comfort and pleasure of using the vehicle, but are only an inconvenience if they malfunction; an example is climate control.
- Non-critical safety systems, which add to the safety of the vehicle, but do not render the vehicle unsafe if switched off, but may introduce problems if they malfunction; an example is an electronic stability program (ESP).
- Critical systems, the correct functioning of which is essential to the safe operation of the vehicle; the braking system is a good example.
All of these systems will have software control but rely on sensors to determine their operation.