As the automotive industry embraces a new technological shift, advanced functional safety features will be absolutely critical for many aspects of the vehicle. By Tom Conway
- The big picture: core computing components
- Safety: invisible but critical
- ASIL D for the highest level of risk
- ASIL B for lower levels of risk
- Software compatibility
- No ‘one size fits all’ solution
From the rapid conversion to electrical drivetrains to new driver assistance features, the automotive industry is currently going through one of the biggest technological transformations in its history. As computing innovation accelerates, so does the industry’s rigorous commitment to system-wide vehicle safety. Often safety is discussed in the context of high-profile, high-touch technology that is needed for driverless vehicles but what is sometimes overlooked is the role and importance of the smaller computing elements spread throughout the modern vehicle today.
Functional safety is an essential component for any application deployed within current and future vehicles. The capability detects, diagnoses and mitigates the occurrence of any fault across a wide variety of automotive applications, preventing harm to people and the environment. However, achieving optimum functional safety within the complex computing constraints of low power and low cost in today’s modern vehicles while adopting the new E/E architecture remains an ongoing challenge. This is why the automotive industry requires a wide range of computing technologies that meet different power, cost, area, software and functional safety demands, alongside adherence to robust external safety standards.
The big picture: core computing components
As OEMs invest in new vehicle EE architectures, there are three core computing components that require varying levels of performance and power. The high-performance central compute for ADAS enables greater driver autonomy and vehicle infotainment functions. Multiple zonal controllers serve as hubs for power distribution and data connection, as well as supporting various real-time automotive functions. And, finally, there are many low-power microcontrollers (MCUs) integrated into Electronic Control Units (ECUs) to support single-function automotive applications, including sensors, actuation and hardware control.
Safety: invisible but critical
Chip shortages in the automotive sector have uncovered how reliant drivers have become on the safety features in and around their vehicle. While invisible to the driver, what powers so many of these applications are MCUs and they are increasingly important to the safety of the driver and passengers. To put the importance of MCUs into perspective, a modern vehicle today could be considered Level 2/3 in ADAS functionality and typically requires a minimum of six cameras, five radars, and ten ultrasonic sensors. Level 3/4 doubles those figures, and it’s only up from there for Levels 4 and beyond.
Achieving optimum functional safety within the complex computing constraints of low power and low cost in today’s modern vehicles while adopting the new E/E architecture remains an ongoing challenge
Even low-power, single-function automotive applications require advanced functional safety capabilities. For example, ultrasonic parking sensors, tyre pressure sensors, rain sensors and LED controllers are all single-function applications in the vehicle that will be best served by low-power MCUs, but they still require high levels of safety due to the critical measurements and actuation that are taking place. This means that any MCU must now adopt functional safety features.
The inclusion of functional safety features in low-power MCUs also accelerates the time-to-market for engineering during the deployment of safety-critical applications. Engineering time and effort can be further reduced by ensuring any functional safety features are designed to meet safety goals before being assessed by external safety certifications, such as ASIL B and ASIL D, for comprehensive supporting safety documentation. This robust and rigorous approach minimises the risk of systematic faults occurring.
The overarching goal is to have safe computing capabilities available throughout the whole vehicle. This availability will then enable the flexible development and deployment of functional safety features across different system-on-chips (SoCs) and different functions across the vehicle.
ASIL D for the highest level of risk
ASIL D represents the highest level of potential risk and requires the most stringent approach to managing faults. For example, braking systems, battery management systems, on-board charging in electric vehicles (EVs) and airbag systems are classed as ASIL D, as faults in these systems can have grave consequences. However, higher levels of risk mean higher levels of computing performance which can impact area and cost. All these ASIL D applications require dual-core lockstep (DCLS), a feature where two identical processors run the same application in lockstep with a known time delay between them. This helps to detect any faults as part of the goal to achieve the ASIL D hardware metrics at the processor level.
Arm’s Cortex-M portfolio brings safety capabilities across all performance points of MCUs, with the newly updated Cortex-M85, Cortex-M55 and Cortex-M23 offering a range of functional safety features that can be used across the vehicle
ASIL B for lower levels of risk
ASIL B systems have a lower level of risk but still need to have mechanisms in place to ensure that various faults are dealt with. For example, applications like body control, lighting and engine control functions, if faulty, increase the probability of a hazard occurring. ASIL B level also requires the detection of 90% of single point faults and that detection of transient faults are addressed. However, the challenge with transient faults is that they can be hard to detect.
DCLS is one approach automotive Tier 1s and system integrators can take to achieve ASIL B, but duplicating the cores will also duplicate power and area which can be problematic for applications where cost and area are the most important considerations. This is where cost-effective transient fault protection could be more appropriate.
Software compatibility
Many software applications run on the vehicle control safety-critical functions like the transmission, anti-lock braking systems (ABS), adaptive cruise control (ACC), radar, and LiDAR. As a result, embedded software is required to meet higher reliability and safety, while still delivering performance and a reasonable memory footprint.
Software development teams have a significant challenge delivering high-quality, safe, and secure software. This is alongside ever-increasing pressures for shorter time-to-market and development times. As a result, it is crucial to have a robust software development and validation strategy that is supported by the right development tools. This ensures that the safety development activities are carried out efficiently and meet the product and delivery commitments.
No ‘one size fits all’ solution
As the automotive industry embraces a new technological shift in vehicles, advanced functional safety features will be absolutely critical for many aspects of the modern vehicle, from tiny low-power, single-function automotive applications all the way up to large multifunction controllers. Focusing on the needs of each application on a case-by-case basis, such as the required use cases, computing power, ASIL safety levels, or levels of software integration, will be the best way to identify the most appropriate technology solutions. A ‘one size fits all’ computing solution is not possible for the variety of different applications in the vehicle, which is why having access to a broad and scalable portfolio of computing technologies will help to achieve optimum functional safety.
About the author: Tom Conway is Senior Automotive Product Director at Arm
Keyword: Functional safety driving the automotive computing evolution