What is functional safety? Design solutions for automotive functional safety

Today, the automotive industry is changing rapidly, and the design, use and sales models of cars are evolving rapidly. Driver safety technology, traffic congestion, environmental issues and the basic premise of cars as a means of transportation all affect the development of the next generation of cars. To address these challenges, many automakers are trying to increase computing power to optimize vehicle control. New standards issued by the European New Car Assessment Program (EuroNCAP) stipulate that safety assistance functions such as lane change support are required to obtain a five-star safety rating. The number of on-board processors has steadily increased in all market segments, with an average of 40-50 processors currently, and some high-end models are already equipped with nearly 120 processors. Semicast Research predicts that by 2022, the market size of electronic control units (ECUs) under the engine hood alone will reach nearly $86 billion, a compound annual growth rate of 7% from $53 billion in 2015. Semiconductor manufacturers will have the opportunity to dig a big pot of gold in the field of automotive electronics.

High-tech chips can improve powertrain emissions, enhance safety performance, and use cellular networks to connect vehicles and road infrastructure. However, as the system becomes more complex, ensuring driver safety becomes more critical, and more automated, systematic, and proactive solutions must be created, which is what we usually call "functional safety."

What is Functional Safety?

In short, the ultimate goal of functional safety is to ensure the safe operation of the product, even if problems occur. Based on this concept, ARM regards safety as a top priority, rather than simply following the market trend, and continuously strengthens research and development to launch more functional safety-related products.

All industries develop standards to guide future development and define minimum barriers to entry. In the automotive electronics industry, this standard is ISO 26262, which defines functional safety as:

“Avoid unreasonable risks due to failure of electrical/electronic systems”.

Standards in different fields are not completely consistent. For example, IEC 61508 for electrical and electronic systems and DO-254 for aircraft electronic hardware have their own definitions. What is more noteworthy is that they all have dedicated terminology and provide engineering development guidance including target parameters. Therefore, it is crucial to determine the target market and develop appropriate processes before starting product development, because modifying the development process midway will inevitably lead to inefficiency. Figure 1 shows the different application standards for silicon IP. In actual operation, if multiple sets of standards need to be met, you can seek common ground while reserving differences, list exclusive requirements first, and then implement general principles such as quality management; safety should be put first from the very beginning.

Figure 1: Functional safety standards for silicon IP

In practice, functional safety systems must be certified by independent assessors to comply with all safety standards. Achieving functional safety requires predictive failure modes, which can determine in real time whether the system is fully functional, partially functional, or must be shut down for a reboot or reset.

Not all faults will immediately lead to serious accidents. For example, a fault in the power steering system of a car may cause a sudden wrong turn, but due to the natural time delay of electrical and mechanical design, the fault will not have immediate consequences. This delay is usually more than a few milliseconds. ISO 26262 defines it as a fault-tolerant time interval, and the length of the interval depends on the potential type of accident and system design. Therefore, it is not difficult to understand that the higher the system safety requirements, the more faults that cause unsafe events should be avoided.

Ideally, functional safety will not affect system performance; however, in reality, many current safety measures will seriously affect system performance, power and area (PPA). How to mitigate the adverse effects on system performance and the increase in design and manufacturing costs while ensuring functional safety is a major challenge facing designers.

Why is functional safety necessary?

Functional safety of chip IP used to be a very niche area, with only a few chip and system developers in the automotive, industrial, aerospace and other similar markets interested. However, with the rise of various automotive applications in the past few years, the situation has changed dramatically. In addition to automobiles, there are many other industries that can benefit from the increase in electronic devices, of course, ensuring functional safety is a prerequisite. Medical electronics and aviation are two typical examples.

Autonomous driving has attracted a lot of attention in the past few years, but it has always been a mystery. Now, with the popularization of advanced driver assistance systems (ADAS) and media-rich in-vehicle infotainment systems (IVI), although the era of highly automated driving is still far away, the prospect of autonomous vehicles has become clearer. Drones of various sizes and shapes and the increasingly popular Internet of Things are also areas that urgently need functional safety, and ARM's technology will be a great help.

ARM Functional Safety Technology

Like other technology markets, emerging functional safety applications also need to be driven by semiconductors; this is not just talk, and the ever-changing product innovation has aroused great interest from ARM partners. Most functional safety embedded systems need to have two core elements: safety protection and real-time processing. The ARM Cortex - R series processors are tailored for this demand, providing high-performance computing solutions for embedded systems to ensure high reliability, high availability, fault tolerance, and/or powerful real-time autonomous judgment capabilities of the products. These features lay the foundation for achieving high safety integrity of ADAS and IVI systems. They can not only perform critical behavior processing, respond to safety-related interrupt events, communicate with other systems, but also supervise complex functions with lower integration.

What is a malfunction?

Failures can be systemic (such as human factors in the specification and design process); they can also be related to the tools used. One way to reduce failures is to implement a rigorous quality control process that must include detailed planning, review and quantitative evaluation. Proper planning and tool certification are very important, and the ability to manage and track changes in requirements is equally critical. ARM's Compiler 5 compiler has been certified by TÜV SÜD to facilitate safe development, and customers do not need to perform additional certification on the compiler.

There is another type of fault called random hardware faults. They can be permanent faults such as short circuits as shown in Figure 2, or they can be soft faults caused by natural radiation. This type of fault can be handled by solutions integrated in hardware and software, so system-level techniques are equally important. For example, logic built-in self-test (BIST) can be applied to system startup and shutdown to distinguish between soft and permanent faults.

Figure 2: Fault types

Responses

The selection and design of fault detection and control measures is the favorite part of process designers because they can use both system-level and microarchitecture-level techniques. A good start is to create a failure mode and effects analysis (FMEA) to list all possible failure modes and the severity of their consequences. With this information, plus the designer's deep understanding of the complex system, the most serious failure modes can be identified and countermeasures can be designed.

There are many ways to deal with potential failures, and some of the most common techniques are listed below:

Diversified checker: Use another circuit to check if the main circuit has failed. For example, the checker can count the interrupt controller and keep a record of the total number of interrupts caused by humans and the system.

Full lockstep replication: This technique, mainly used in the Cortex-R5 processor, instantiates an IP element (such as a processor) multiple times, using loops to generate operation delays and generate time and space redundancy. Large-capacity storage is usually shared by multiple instances to reduce the required area. Although this technique is very reliable, it is also extremely expensive.

Selective hardware redundancy: In this scheme, only critical parts of the hardware are replicated, such as the arbitrator.

Software redundancy: Hardware redundancy is often very complex and has indirect costs, and is an inefficient use of resources. An alternative to hardware computing is to run the same calculation on multiple processor cores and check whether the results match.

Error detection and correction codes are another well-known technique, often used to protect memory and buses. There are many different types of codes, but the goal is to achieve higher redundancy through a small number of additional bits without duplicating all the underlying data. In automotive systems, this cutting-edge technology can detect a 2-bit error in a memory word with enough redundancy; and support error correction.

Fault log

Failures must be recorded when they are detected to help supervisory software determine the health and safety of the system. Safe failures (such as memory corrections) and dangerous failures (such as irreversible hardware failures) must be recorded separately.

Fault logging usually starts with fault counting, which can be recorded by the system-level architecture to record the number of signal events (similar to interrupts); or recorded by IP counters. In order to understand the reasons for these events, it is best to use past events as a reference to determine the reasons for the current time. To support this requirement and perform debugging and error correction, some IPs can be allowed to capture additional information, such as the storage address being detected. Because this address is usually saved by soft reset, it can be read during system startup and system self-test.

One thing to keep in mind is that faults can also occur in the safety architecture itself. Unlike hardware faults, which are usually discovered quickly during use, faults in safety checkers can be latent, where they are no longer able to detect dangerous faults, but the faults have already spread quietly. Such faults are called latent faults, and it is a good idea to test the checkers regularly.

Safety Integrity Level

Different standards systems reflect safety levels in different ways, but their main purpose is to intuitively reflect the criticality of the function. For example, the integrity of the ECU that controls the windshield wipers, airbags or brakes must be higher than that of the ECU that controls the speedometer or parking sensors , because the forward vision is critical and sudden braking or airbag inflation may have fatal consequences and the driver will be in danger; while the speedometer or parking sensors are much less important to safe parking.

In other words, the safety integrity level is related to the necessity and ability of people to avoid dangerous situations; and the role of various standards is to guide people on how to define the safety integrity level and provide relevant parameters to help them quantify the integrity of the system.

IEC 61508 divides the safety integrity level (SIL) into 4 levels, with level 4 being the highest integrity. Similarly, ISO 26262 proposes automotive safety integrity levels (ASILs), with the lowest being ASIL A and the highest being ASIL D. In addition, as shown in Table 2, for ASIL B to ASIL D, ISO 26262 proposes recommended parameters for single-point failures, latent failures, and hardware failure probability indicators (PMHF, also known as prompt failures in the industry). The proportion of detectable faults is called diagnostic coverage.

Table 1. Recommended standards for ISO 26262

Although these indicators are often seen as standard requirements, in practice they are generally considered recommendations, and suppliers can set their own target parameters. The most important goal is to create a safe product, not to add a few more numbers to the product parameter sheet. Let's borrow the example mentioned earlier again - windshield wipers, brakes and airbags, these components may have a safety level of ASIL D, while the speedometer and parking sensors may be ASIL B or lower, depending on the overall system safety design.

Regardless of the diagnostic coverage, the right processes must be followed when building functional safety applications - this is the biggest benefit of the standard system. In addition, no matter what functional safety measures are adopted, a strict quality process can improve the overall quality of any application.

Functional Safety IP Design Process

When developing IP for functional safety applications, it is important to “play by the rules.” The process must incorporate safety from the outset, and a culture that supports safety must be created.

A complete development process must include the following important aspects:

Safety management: including team organization structure, such as: clarifying the definition and responsibilities of different positions, building a safety culture, defining the safety lifecycle, and defining the functional safety support level. The safety lifecycle setting includes developing a success plan, selecting appropriate development tools, and ensuring that the team receives adequate training.

· Traceability of requirements management and fault detection and control measures (countermeasures). To accurately achieve requirements traceability, the requirements themselves must be clearly defined, accurate, and unique. The traceability level depends on the requirements of completeness. Documents can be high-level; products need to be comprehensive from fault detection to verification. The planning process cannot be groundless and must be verified in detail.

·Quality management is an extension and extension of demand traceability. Errata sheets must be properly managed and used. ARM has extensive experience in this area. In addition, the recording and communication of processes are equally important.

Security document package

IP development is a way for ARM to support its partners, and our partnership does not end when the customer receives the IP. For IP development related to functional safety, ARM defines two levels of safety file packages:

Supports standards up to ASIL B

Extended support up to ASIL D

Each safety package includes a safety manual that details the procedures to be followed, fault detection and control functions, applicable scenarios and other information. We also provide a "Failure Mode and Effect Analysis Report" and provide case studies to illustrate how to achieve higher diagnostic coverage with IP; we also provide more support at the chip level for customers' independent analysis. In addition, the package also clearly defines the development interface between ARM and the licensee.

Independent safety unit

The establishment and use of security status reports need to be progressive. The report is provided by the chip developer, and the information of all manufacturers must be considered comprehensively before it is finally delivered to the customer for use, which is progressive. The most licensed chip IP is called "Standalone Security Element" (SEooC), and its designers do not need to know how the chip is used later. Therefore, the security manual must state the IP developer's recommendations and instructions for chip use to avoid misuse. Similarly, the OEM's Tier 1 controller supplier can also use the SEooC model to develop security functions. Therefore, IP-level security file packages can be used throughout the value chain and are an important part of IP development.

Functional safety will gradually become a hard requirement

As more and more applications rely on electronic devices, from automobiles to medical to industrial equipment, functional safety is becoming more important and will become a routine requirement. Functional safety is a requirement that IP manufacturers must meet and a necessary condition for the smooth operation of models built on this IP, so IP manufacturers must grant each research result to as many chip partners as possible, and vice versa. With solid quality and reliability, functional safety can bring broader benefits, thereby promoting quality and reliability improvements across the industry. Including driver safety, fuel economy, comfort and in-vehicle infotainment systems, functional safety is the foundation for chip designers to solve higher-level automotive problems.