Enabling functional safety in automotive processors

Chipmakers are very clear about what functional safety means for their microprocessor/microcontroller (MPU/MCU) designs for automotive applications. The ISO 26262 functional safety standard for electrical and electronic (E/E) systems in vehicles defines guidelines and a framework to ensure that the automotive components work correctly as intended, minimizing the risk of accidents. Chipmakers, however, are facing bigger implementation challenges with the industry’s increasing shift to electrification, autonomous cars, software-defined vehicles and new E/E architectures.

“The standard itself really gives a broad framework on how to address functional safety, but it doesn’t prescribe specific safety architectures or specific safety implementations,” said Mathieu Blazy-Winning, functional safety director at NXP Semiconductors.

ISO 26262

The foundation of functional safety for automotive systems rests with the ISO 26262 functional safety standard, initially released in 2011, and followed by a second edition in 2018.  The 2018 release, part 11, applies to semiconductors. The next release is planned for the 2024/2025 timeframe.

“Automotive electronic systems not only support the human driver, but they can also take over critical tasks to control the vehicle. This leads to increased risks from systematic failures and random hardware failures of these systems,” said Dejan Kostic, senior manager of the Automotive System Functional Safety Department and Automotive Core Technology Development Division at Renesas Electronics Europe GmbH. “ISO 26262 is the functional safety related standard for the automotive industry to provide guidance on mitigating these risks and serves as a state-of-the-art framework for developers of automotive safety-related systems.”

Francesca Canali, product marketing manager for automotive processors and marketing communication manager at STMicroelectronics (STMicro), explained that designers need to consider safety measures during the development and design of automotive systems and their components to reduce the number of possible errors and to ensure maximum safety in the vehicle.

“Each automotive system and component of a subsystem, including MCUs and MPUs, needs to be developed in a specific way that reduces the potential for errors as much as possible,” Canali said. “It considers dedicated development processes to reduce risk for systematic errors; the introduction of hardware/software safety features in the design phase, such as error detection to detect and control unforeseen errors, [and] in this regard, hardware safety measures like MPUs/firewalls and hardware-based virtualization help to address software errors; safety measures defined to prioritize ease of use and application transparency and system availability designed to manage safety measures.”

On a similar note, David P. Arnold, senior marketing manager of the Automotive and Functional Safety/MCU32 business unit at Microchip Technology Inc., acknowledged the importance of functional safety requirements to ensure failures occur in a safe environment.

“For functional safety, you want the electronics to fail in a safe condition in the event a failure occurs,” Arnold said. “There are different automotive safety integrity levels, or ASILs, ranging from ASIL A to ASIL D. If you look at ASIL D, this requires hardware redundancy to further mitigate the failures. ASIL D is typically used in many applications that can pose a life-threatening situation to the occupants.”

To meet functional safety requirements, chipmakers have integrated the processes and methods from ISO 26262 into their standard development process.

“The ISO 26262 standard defines a process for systematic design of the MCU and MPU,” he added. “Basically, this means when you design to the standard, you design to prevent design/safety errors that would cause a safety violation. Systematic design processes are also used in software development for functional safety.”

Safety, security and connectivity

Functional safety isn’t addressed in a separate silo. Most chipmakers must consider other factors like electrification, security and connectivity. In addition, with the increased demand for advanced driver assistance systems (ADAS) and autonomous driving features, as well as the shift toward software-defined cars and new E/E architectures, these new technologies are creating bigger challenges for OEMs, and tier 1 and tier 2 suppliers.

“The new automotive technologies result in higher integration at the system level with increased complexity,” Renesas’ Kostic said. “Likewise, functional safety realization becomes more difficult as well, and requires huge efforts from designers.”

Another challenge is safety for AI, he added. “In the case of AI processors, lockstep implementation is a simple measure to detect possible random hardware faults affecting the logic executing AI operations with high diagnostic coverage for higher ASIL. This is mainly beneficial when quick detection times are needed, as well as to have a quick solution without needing to analyze in detail the logic being protected.

“However, the issue with AI is that redundancy alone is not sufficient to achieve functional safety, especially considering SOTIF concerns [safe operation when no fault is present],” he said. “A major concern is the safety of the application software and if it can be developed, trained, verified and validated according to an ISO 26262-compliant development process. Considering the high costs associated with lockstep, other solutions may be more suitable.”

NXP’s Blazy-Winning said big shifts in the industry now, particularly with electrification and autonomous features, as well as the interface between electrification, connectivity and autonomous trends, are driving a lot of changes in the overall vehicle architecture.

As a result, NXP is working more directly with OEMs to define the next generation of higher performance system-on-chips (SoCs), which include functional safety and security aspects. It also addresses higher functionality on a single chip and making better use of multi-core SoCs.

Another trend impacting the automotive industry is the software-defined vehicle, which calls for much more standardized hardware platforms that will be used across a much broader set of fleet vehicles for any one OEM, but also over a much longer time, according to Blazy-Winning. When the vehicle is launched into production, you can continually upgrade the software and the features of the vehicle over time—without having to change the underlying hardware, he added.

Yet the question remains: Do the evolving automotive E/E architectures also make it more challenging to comply with safety standards? Many chipmakers say ‘yes.’

“With the increasing importance for OEMs of computational power centralization (domain/zonal E/E architectures, high-performance computing platforms) the integration and co-existence of several applications on a single processor require the use of embedded virtualization—the use of hypervisors or resource managers,” STMicro’s Canali said. “The concurrent execution of different applications on the same processor requires safety firewalling between them while minimizing the need of interaction between the diverse application suppliers.”

Similarly, Blazy-Winning explained that the majority of systems today are discrete and self-contained electronic control units (ECUs), such as braking, powertrain and gateway ECUs with fairly limited interaction between them. “As we move to either domain-based or zonal in terms of vehicle architecture, that’s where the functions are becoming much more distributed and that combines with the trend that there’s a desire to minimize the number of ECUs in the vehicle and consolidate multiple applications onto the same SoC.

“The challenge it brings in terms of functional safety is the need to support mixed criticality because now within the same SoC there are some applications that are not safety related at all and some which have a medium level of safety criticality like up to ASIL-B and then others which have criticality up to ASIL-D,” he added. “So, that’s one of the challenges now—how do we support that integration of what were independent safety applications or even non-safety applications potentially running on the same multi-core SoC or the same central compute with also the functions being distributed between central compute and then zonal aggregators in the vehicle.”

Dealing with faults is another issue, Blazy-Winning explained. “If you have a fault, how are we able to localize and isolate that fault within one function and manage it without impacting other functions. It definitely brings a number of new challenges which we are currently working on.”

While safety and security are two different functions, there is an interaction between the two that have to be considered in automotive design. Safety and security look at things from opposite angles, he said.

For example, security addresses how to prevent outside influences from essentially hacking into a vehicle and influencing the behavior of the system. On the other hand, functional safety ensures that an electronics malfunction or failure doesn’t influence things outside of the system, he added.

“There is absolutely an interaction between safety concepts and architectures and security concepts and architectures, but they’re still approached as two different domains,” he said. “But with this integration of functions, the move to zonal architectures and the increased connectivity of the vehicle, they are starting to come together, so it’s definitely an area of focus for the coming years.”

Renesas’ Kostic noted that there are ongoing standardization activities in the automotive market to define the detailed interactions between safety and security for automotive, for example IEEE. “It is clear that safety and security cannot be separated but both are needed to achieve system safety. We are also closely observing the industry common sense to ensure a consistent state of the art.”

Renesas has a dedicated development process for automotive cyber security that works on top of its QM development processes and with its functional safety development processes.

“Safety goes hand in hand with security as any safety critical system is automatically a security critical system—system safety can be threatened by an intentional security attack—but also as the addition of safety measures may conflict with security targets and vice vera, therefore requires mutual safety/security reviews,” Canali said.

AI capabilities

Currently, AI capabilities are not addressed in the ISO 26262 standard, according to chipmakers. But there is a new standard ISO 21448, or Safety of the Intended Function (SOTIF), that starts to cover AI.

“SOTIF (ISO/PAS 21448) was developed to address the new safety challenges that autonomous and semi-autonomous vehicle software developers are facing,” Microchip’s Arnold said. “This is especially important as AI and machine learning play key roles in the development of autonomous vehicles.”

Kostic agreed, explaining that AI and machine learning play major roles in autonomous capabilities, such as image recognition and routing.

“AI has a constantly increasing role in the development and execution of automotive applications,” Kostic said. “Usages span from supporting design tasks, for example determining optimal place and routing in LSI layouts, to execution of safety-related intended functionality in image recognition. Thus, functional safety is a clear concern, and not only is compliance to ISO 26262 required, but compliance to other safety standards, such as ISO 21448, aka SOTIF, is required as well.”

Kostic also noted there are other emerging standards, such as ISO/PAS 8800: Safety and AI, dedicated to AI. “As ISO/PAS 8800 evolves, it’s possible that its contents will be integrated into the third edition of ISO 26262.”

ISO 26262 looks at failures of electronics components that can be hardware or software related. In terms of how it’s applicable to AI, there isn’t something specific in the standard. In that sense, ISO 26262 doesn’t cover AI, but it does generically cover all hardware and software, according to NXP’s Blazy-Winning. If there is a function where the AI processing is safety related, then that hardware and software—and the whole development process—is now safety related and does come under both ISO 26262 and SOTIF.

SOTIF addresses safety of the intended function where the capability of your system matches the use case that you foresee in the environment, Blazy-Winning added. An example cited is an autonomous vehicle (AV) that can only operate in an airport car park, where the use case matches the capability of the systems that are controlling the AVs. If this same AV is used in a different context—on the street, for example—the capability of that vehicle doesn’t match the complexity of the environment that it needs to interpret, such as pedestrians or moving vehicles.

Evolving standards

A key theme at a leading functional safety conference last year was about taking a holistic approach to functional safety, Blazy-Winning said.

There are many aspects that need to be considered when bringing safe AVs to market, and all of these interplay with ISO 26262, which provides the backbone of a framework to develop safe systems, but it also relies on SOTIF and security standards, he added. “You need all of these different aspects to come together to have a truly safe system.”

But do these standards need to evolve to take into account the higher levels of autonomy?

Blazy-Winning thinks so. A big question for the third edition is how much ISO 26262 should evolve to address full autonomy. He thinks the industry’s position is to keep it “a bit more generic” as the anchor standard. “It will probably continue to evolve, but I think the consensus in the industry is not to overburden or complexify the ISO 26262 as a base standard.”

Chipmakers agree that ISO 21448 starts to cover the higher levels of vehicle autonomy.

“ISO 26262 is the basic tool to address and implement systems that deal with sensors, processing and actuation, and the current state-of-art means an additional layer of standardization on top of ISO 26262, which is ISO 21448—safety of the intended functionality,” STMicro’s Canali said.

“The extensive adoption of assisted driving features and the introduction of autonomous driving is broadening the perspective of functional safety,” she added. “The ISO26262 target is to grant the correct functioning of electric and electronic systems. Nevertheless, ADAS introduces a new computational load of algorithms that crunches a large amount of data […] and the quantity of data coming from sensors are growing at a high rate. Are we sure that algo-based interpretation of sensing data is always correct, and the final decision is always clearly and correctly taken? There could be events in which algorithms do not correctly interpret the received signals, leading to wrong decisions taken by the vehicle.”

Other safety standards that come into play in the automotive industry include UL 4600 for verifying and validating the safety of AVs. There is also a technical review initiated by the ISO 26262 committees on predictive maintenance (TR 9839), which addresses how to better predict when E/E components or systems are about to fail and not just detect failures, according to Blazy-Winning.

“We have much more connectivity so that we’re able to get data back from all of our silicon portfolios in the field and that is similar for the tier ones and the OEMs for their parts in the system so that we can actually now start to get a much better view on how the health of the products vary with the different use cases and different mission profiles,” he said.

Blazy-Winning added that this is particularly valuable for commercial fleet vehicles to ensure the maximum uptime of the vehicle so they don’t have a failure in the field.

A first draft of the ISO 26262 technical review has been released. At this point, the review could remain in this form or added as a new chapter in the third edition of ISO 26262. There also is a possibility that it becomes a separate standard, Blazy-Winning said.

Key differentiators

Being compliant to ISO 26262 gives component suppliers entry into the automotive safety system market. So, how do chipmakers differentiate their products?

“For ISO 26262 Functional Safety, there are definitions, such as Functional Safety Ready, Functional Safety Capable and Functional Safety Compliant,” Microchip’s Arnold said. “When customers are looking at components, they are looking for manufacturers to provide safety collateral for adherence to the ISO 26262 standard. In general, we don’t use the term safety processors, but MCUs/MPUs with functional safety support. The ecosystem of functional safety collateral includes at least FMEDA [Failure modes, effects, and diagnostic analysis], Functional Safety Manual and Diagnostics Software modules.”

Microchip differentiates its products based on the applications for functional safety, such as motor control and capacitive touch. A recent addition is the dsPIC33CK1024MP710 digital signal controller (DSC), which targets applications like OBC and DC/DC converters, Qi charging and car interior safety touch. “We design our devices and optimize our features for applications within the vehicle and maintain compliance with the functional safety standard,” Arnold added.

Renesas also provides standard functional deliverables for safety-related products, according to ISO 26262, such as Safety Case Summary, Functional Safety Assessment Report Summary and FMEDA. Additionally, the company established an Automotive Safety Support Program.

“Automotive system designers need to select components that are developed according to ISO 26262 or otherwise must evaluate if the component can be used as a safety related component according to ISO 26262-8 Clause 13,” Renesas’s Kostic said. “Renesas SEooC [safety element out of context] products are developed according to assumed safety requirements and assumptions of the system design external to the SEooC. These requirements and assumptions are documented in two customer work products: a Safety Requirement Specification and a Safety Application Note. The automotive system designer needs to check the validity of the assumed requirements against their target system conditions, integrate the product, and develop the related software considering the application note.”

For NXP, in terms of feature differentiation, it’s challenging, Blazy-Winning said. In terms of gateway products, for example, the S32 product family for automotive is ISO 26262 compliant and it’s part of their SafeAssure program, which helps customers identify which products are developed for safety, and which ones aren’t. Product differentiation is the high-performance compute, which is related to the higher integration of safety critical functions within the same multi-core SoC than in the past, he added.

Functional safety is very much a system topic, Blazy-Winning explained, and software enablement is a key part of a product’s differentiation. A device needs to be configured for safety, which requires a comprehensive set of software libraries. Chipmakers also can provide a range of design and debugging tools, reference examples and drivers, as well as security and safety software that include structural core self-test (CST) for runtime detection of hardware faults in the MCU core.

While most of the safety measures implemented in processors are hardware based and designed specifically to maximize application transparency, software-based safety measures are also recommended, according to STMicro’s Canali.“Software countermeasures provide additional flexibility to configure safety measures depending on the specific design selected by customer. For example, a safety library is a useful and valuable safety component that packages all recommended software safety measurements and significantly increases customer use.”

Functional safety is a top-down driven approach, Microchip’s Arnold added. For software, there are many components that include Functional Safety Diagnostic Code, ASIL-B compliant MCALs, safe versions of AUTOSAR, safe scheduler or RTOS, and certified and compliant development tools, such as compiler, code analysis, etc., he said.

Renesas, for example, provides a range of software enablement tools, such as MCALs and CST software libraries with ASIL quality for the RH850 MCUs and ASIL quality software, such as CPU runtime test, computer vision software and security software in a SDK for R-CAR SoCs.

Additionally, STMicro’s latest MCU technical safety concepts target the highest ASIL-D levels with the Stellar MCUs providing major safety innovations, such as hardware support for embedded virtualization and increased system availability.

Some chipmakers like NXP also have applied the standard to their power management ICs (PMICs), matching the same level of integrity as the MCU, such as ASIL-D. The majority of its automotive products are developed to be ISO 26262 compliant for either ASIL-B or ASIL-D compliance. “We don’t force our customers to use our power management ICs but, of course, it’s strongly recommended because they are designed as a single concept and that helps them to get to market faster,” Blazy-Winning said.

Renesas also offers a broad portfolio of ISO 26262-compliant products for analog and power devices. For example, Renesas’s R-Car S4 SoC is a communication gateway device in which ISO 26262 functional safety assessment is nearing completion and supports ASIL B and ASIL D. The company also provides PMICs, which enable customers to develop vehicle computers for future E/E architectures.

Similarly, many chipmakers work with third-party partners to build a complete ecosystem for safety. As a result, there is a lot of collaboration across the software ecosystem including OS and compiler vendors to offer complete system solutions for functional safety.

The article originally published in EE Times A Turning Point for AVs special report.