Safety critical sensors in cars

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 and in which Mentor Embedded is very active: automotive.

Modern cars are stuffed with microprocessors and microcontrollers, which perform a variety of functions, which vary in their importance from convenience to safety critical. It is interesting to consider how these different type of systems are implemented …

Systems in cars may be broadly divided into 3 categories, depending on their safety requirements:

  1. 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.
  2. 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 electronic stability control [ESC].
  3. 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. Although I focus on embedded software in this blog, an understanding of how such sensors are organized is useful. But, before I get on to looking at each kind of system, a [true] story …

Some years ago, my friend/colleague 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, he was driving at some speed on the freeway, where the vehicle suddenly started to pull hard to one side. 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 he 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 ESC sensor was faulty and triggered the system unnecessarily. This sensor is located under the driver’s seat and detects rotational movement of the car; the braking is intended to offset that motion to avoid the car going into a spin.

My friend 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. I will explain by describing how each of the 3 types of system I categorized above should work, in terms of sensors:

  1. A convenience system needs a single sensor. If it malfunctions and the user notices, they can switch off the system and have it repaired at their convenience.
  2. A non-critical safety system needs a pair of sensors. The system compares their signals and, if they agree within a defined margin, it takes appropriate action. If the signals disagree, the system shuts down and displays a yellow indicator, which tells the driver that the system should be fixed sometime soon.
  3. A critical system needs 3 [or a larger odd number] of sensors. The system compares their signals and, if they all agree, it takes appropriate action. If one signal disagrees, the system takes action based on the other two, but illuminates a red indicator to advise the driver that urgent attention is required. If all 3 sensors disagree, the system inhibits further use of the vehicle immediately.

My friend’s car’s ESC system was a non-critical safety system, which had a single sensor instead of two, so it could not “fail safe”.

I suggested that a critical system needs 3 sensors. This is acceptable in automotive and industrial systems. For mil/aero, 5 sensors are likely to be required. For space systems, 7 is more likely. The space shuttle orbiter, for example, had 7 sensor/servos controlling each flying surface, each with its own computer, which was supplied and programmed by a different contractor. Is that overkill?

Post Author

Posted January 13th, 2014, by

Post Tags

, , ,

Post Comments

2 Comments

About The Colin Walls Blog

This blog is a discussion of embedded software matters - news, comment, technical issues and ideas, along with other passing thoughts about anything that happens to be on my mind. The Colin Walls Blog

Comments

2 comments on this post | ↓ Add Your Own

Commented on 13 January 2014 at 18:32
By Dan Weese

Is it overkill? Not if failure will get a human killed. Da Vinci: “Although nature commences with reason and ends in experience it is necessary for us to do the opposite, that is to commence with experience and from this to proceed to investigate the reason.”

With rare exceptions, nature duplicates critical functionality, often with massive redundancy.

Commented on 14 January 2014 at 11:48
By Colin Walls

Dan: Of course, human safety is the priority. Fair comment about nature. My concern in this case is two-fold. First, a simultaneous failure in 3 independently designed, equivalent sub-systems would suggest some kine of systemic or systematic design flaw, which is more worrying than a random failure. Second, I wonder if the added complexity involved in adding this amount and variety of redundancy might in itself contribute to possible failure.

Add Your Comment

You must be logged in to post a comment.

Archives