A safer, cleaner & smarter automotive industry

The automotive industry is driving towards a zero accident and zero emission world, an exciting paradigm shift that could be a reality in just 20-30 years. Today, more than 90% of all car accidents are caused by human error. Removing human error through introducing (semi) autonomous driving stands to significantly reduce the number of traffic accidents and road deaths. A number of technologies already exist to enable the shift to (semi) autonomous driving. These technologies can be summarised under the umbrella terms:

• Car-to-X: Car-to-car, car-to-infrastructure and car-to-‘other’ communications (Figure 1);

• X-by-wire: Throttle-by-wire, Brake-by-wire, Steer-by-wire and other advancements;

• ADAS: Systems Adaptive Cruise Control (ACC), lane departure warning and blind spot detection systems and more.

All three technology systems already exist, will grow rapidly in the mid-to-long term and will ultimately become commoditised. There is no doubt that the combination of the three systems stand to make (semi) autonomous driving a reality in years to come. The zero emission ambitions of the automotive industry, shared by governments and driven by the dwindling amount of recoverable oil worldwide, will be realised in the longer term. Electrical vehicles with batteries recharged by renewable energy, such as wind energy, will be a reality in the longer term. In the mid-to-long term hybrid vehicles in all their different varieties will pave the way.

Figure 1 - Connecting the car

Safety is critical as we strive for zero accident and zero emission vehicles. In a world where cars are (semi) autonomous, the electronic systems controlling vehicles must have failsafe reliability and security. Any failure could be life threatening, and standards such as ISO26262 have an important role to play. Minimising the risk to security caused by possible vulnerability to hacking in X-by-wire, ADAS and especially Car-to-X Systems is also critical. Currently vulnerability to hacking is not covered by ISO26262; efforts to address the inclusion of security vulnerability related to hacking, and the current role of ISO26262, will be discussed later in this article.

Electrical and hybrid vehicles face a different safety challenge, which is also being addressed. The high voltage board net that is introduced in these vehicles, in conjunction with the 12V board net and high voltage batteries need special safety measures to remove the risk of explosions or fire.

A standard approach

Initially the automotive industry was implementing safety-related applications according to the IEC61508 standard. However, this umbrella standard was designed to be used as a platform for individual industries to build their own standards, as has been demonstrated by mechanical engineering and the nuclear power industry. For the automotive industry it was quickly realised that the ‘catastrophic events’ covered by IEC61508 don’t apply. It is also not possible for the automotive industry to distinguish between one and more fatal injuries, as defined in the IEC61508 standard. Finally, the Safety Integrity Levels (SILs) as defined in the IEC61508 needed adjustment. As it turned out, the automotive systems often needed a safety classification between SIL2 and SIL3.

The ISO26262, released in November 2011, was designed specifically for the automotive industry, applying to passenger cars and light utility vehicles. The standard defines Automotive Safety Integrity Levels (ASILs) from ASIL A to ASIL D with ASIL D being the highest safety level. The levels represent an acceptable residual risk level and apply to a full system only and cannot be assigned to an individual component. However, this is starting to become common practice. Therefore, the level associated with an individual component can be understood as ‘the component is suited/prepared to be applied in an ASIL x system’.

The targeted/required ASIL level is achieved by the reduction of systematic and random failures. Systematic failures are caused by human errors and can be prevented by a proper design process. Random failures, for example those caused by ageing or thermal wear-out, can be detected in the system by introducing appropriate safety measures, like the addition of redundancy, monitoring, and self-tests. Software failures will always be of systematic nature, while hardware failures can be random or systematic.

Figure 2 - Key phases in the development of an ISO26262-compliant system

The main phases in developing an ISO26262 compliant system are depicted in Figure 2.

Generic safety architecture

Figure 3 shows a generic solution that can be applied in systems that need to comply with ISO26262. The solution is neither linked to a particular ASIL classification of the system nor to a particular application. Rather, the overall ASIL level that needs to be fulfilled determines the system architecture as well as the definition of the individual components. For example, the safety switch in Figure 3 is required to achieve a failsafe state in systems with an ASIL B level or higher.

The MCU is available in many different types, for example on different implementation levels of safety (monitoring) functionality. These MCUs contain, in most cases, two cores that execute the same code in lockstep mode. A compare unit compares the calculation results of the two cores and in case of a difference, the MCU_error_n signal is activated and the system is put in failsafe state, while the safety switch is now opened and actuators cannot be (erroneously) activated anymore.

However, this approach still has a weak spot because common cause failures that affect both cores will not be detected by the compare unit. Therefore additional measures, like an external watchdog, temperature sensors and special layout rules are also necessary to achieve the highest Safety Integrity Levels. The memory is in most cases secured by the addition of error detection and correction codes. The peripherals, when part of the system safety functionality, can also include safety monitoring, e.g. monitors that read back the signals that are sent via the ports.

Figure 3 - A generic ISO26262-compliant architecture

System-Basis-Chips (SBCs), such as the families UJA107x and UJA116x from NXP Semiconductors, form the basis of many electronic control units. The safety elements implemented in the SBC are the WatchDog (WD), the Voltage Monitor (VM) and a temperature monitor. The purpose of the WD is to supervise the correct operation of the MCU and in case of an incorrect behaviour of the MCU detected by the WD the MCU is put in reset and the system in failsafe state.

The VM can detect under- as well as over-voltage on the supply voltage to the MCU, it can also include self-checking functionality. The VM and the Voltage Supply may each have a dedicated supply reference. The temperature monitor measures the temperature inside the SBC and compares that with a predefined threshold, when this threshold is exceeded an over-temperature is detected. It is also possible that the temperature monitor generates a warning at a lower temperature first.

When either the WD, VM or over-temperature monitor detects an error, the SBC_error_n signal is activated and the system is put in a failsafe state. The Safety Switch is activated by the SBC, and not via intervention of the MCU as the MCU might not be able to activate the Safety Switch. In addition, in most cases a warning light to inform the driver is turned on when the safety switch is activated (not shown in Figure 3).

The power devices as well as the drivers that go with it also contain diagnostics for safety purposes, covering undercurrent and overcurrent detection in driver-on state, as well as open- load detection in driver-off state and over-temperature detection. It follows that the safety monitoring functionality be implemented in all three main components in the system, the SBC, the MCU and the Power devices (especially the drivers).

Finally, we consider higher levels of integration - the SBC as well as power devices and drivers integrated in one piece of silicon. This solution can result in lower system costs, but care needs to be taken, because the safety functionality (especially the part that activates the safety switch) needs to be functional and available under all conditions.

The automotive industry is on the brink of a zero accident and zero emission revolution. Exciting developments in technologies driving the design of (semi) autonomous vehicles will help reduce the 90% of car accidents caused by human error. While hybrid vehicles and the evolution towards electrical vehicles that use renewable energy will help address dwindling oil supplies.

Safety is critical to the realisation of a zero accident and zero emission vision. The introduction of ISO26262 is an important step towards addressing safety, while further efforts will help to answer the increased need for security in ‘Car-to-X’ implementations. The journey towards safety is ongoing, and will need to continue in the mid-to-long term.