With the push for cars to include ever more safety features, the importance of functional safety is growing.
Driver safety technologies, traffic congestion, environmental concern, and the fundamental premise of how we use our cars are influencing the design of next-generation vehicles. As a sign of the times, Euro NCAP (New Car Assessment Programme) continues to push the vehicle manufacturers by regularly evolving the five star rating to include more and more safety assist features. These include:
Vehicle makers get relatively little warning as more and more features are required to gain a top safety rating, and that encourages the industry to continue to innovate and include the technology in as wide a range of vehicles as possible.
Most, if not all, of the safety innovations being developed depend on the safe and reliable operation of the electronics. With high-end cars containing around 120 processors focused on improving powertrain emissions, enhancing safety and providing connectivity, these systems require a foolproof way to keep drivers safe. This is called functional safety. Functional safety’s importance is growing as electronics starts to move from driver warning and assistance to taking over full control of the vehicle in the race toward autonomous driving.
In a nutshell, functional safety is about ensuring that products operate safely and continue to do so even when they go wrong. Each industry typically has a standard to guide developments and set minimum expectations, and for automotive electronics it is ISO 26262, which defines functional safety as: “The absence of unreasonable risk due to hazards caused by malfunctioning behaviour of electrical / electronic systems.” Safety requires predictable failure modes which could be with full functionality, graceful degradation in functionality or a clean shutdown followed by a reset and restart.
Not all faults will lead to hazardous events immediately. For example a fault in a car’s power steering might lead to incorrect sudden steering action. However, since the electronic and mechanical designs will have natural timing delays, faults can be tolerated for a specific amount of time, often many milliseconds or more.
Failures can also be systematic to the design itself, such as human errors in specifications and design, or due to the tools used. One way to reduce these errors is to have rigorous quality processes that include a range of plans, reviews and measured assessments.
Another class of failure is random hardware faults; they could be permanent faults such as a short circuit between wires, pins or tracks. Alternatively, they could be soft errors caused by exposure to the natural radiation all around us. While such faults can be detected by countermeasures designed into the hardware and software, system-level approaches are also important. For example, Logic Built-In-Self-Test (BIST) can be applied at start up or shut down in order to distinguish between soft and permanent faults.
A good way to start is with a concept-level Failure Modes and Effects Analysis (FMEA) to identify the list of possible failure modes in the system and how significant their effects are. Armed with that list and an understanding of the system’s complexity, the most significant failure modes can be identified and countermeasures designed.
Some of the common techniques are:
Within the standards there are different levels of safety defined to reflect the function’s criticality. For example, ECUs controlling the windscreen wipers, airbags or brakes need to have a higher integrity than those controlling the speedometer or parking sensors because vision through the windscreen is essential, and unintended braking or air bag deployment could be fatal. On the other hand, neither the speedometer nor parking sensors is essential to a human in order to stop the car safely.
The level of integrity needed is therefore linked to the necessity and ability of a human to avert an unsafe situation, and the standards provide guidance to help qualify the level of integrity needed and metrics to quantify the integrity of systems. ISO 26262 proposes metrics for so called single point faults, latent faults and a Probabilistic Metric of Hardware Failure (PMHF) – known by the enterprise market as failure in time – for ASIL B to ASIL D. Going back to the examples given previously, windscreen wipers, braking and air bag deployment could be classified as ASIL D, whereas the speedometer and parking sensors might constitute ASIL B or lower depending on the overall system design and the safety case.
Key to functional safety is the preparation of a safety case. This is a structured argument, supported with evidence, which justifies why the system is acceptably safe in its specific operating environment. Safety cases are also usually hierarchical. The case composed by chip developers requires input from each IP supplier which then enables their customer and so forth. Most licensable silicon IP will be developed as a so-called Safety Element out of Context (SEooC), where its designers will have no specific understanding of how it will be used. Hence the safety manual must also capture insight from the IP developers about their expectations in order to avoid inappropriate use; likewise Tier-1 suppliers of controllers to OEMs may also develop using the SEooC model. The availability of a safety documentation package at IP level is therefore enabling throughout the value chain and so is a very important part of any IP offering.
With its roots in the realm of quality and robustness, work done to enable functional safety also has widespread benefits and is a catalyst for improved quality and product resilience across the industry. It is a foundation upon which chip designers can develop systems to address the need for higher performance in the car, for driver safety, fuel efficiency, comfort and in-car infotainment.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply