ISO 26262 driving away from mobile SoCs

Connected cars may be starting to resemble overgrown phones in many ways, but there are critical differences now leading processor teams in a different direction away from the ubiquitous mobile SoC architecture – in turn causing designers to reevaluate interconnect strategies.

The modern car has evolved into a microcontroller jungle, with 100 or more devices found in high-end automobiles today. Many of these MCUs have been placed at points of control, next to actuators or sensors they oversee, and interconnected throughout the vehicle for remote control and status. This has made subsystem design and integration far easier, but has complicated the overall reliability picture of the system with many more parts and data paths subject to failure.

image via Daimler, appearing in “This Car Runs on Code“, IEEE Spectrum

Many of these MCU-powered subsystems in a car are less-than-critical. Failures in some areas may create inconvenience or discomfort compared to optimum conditions for the driver or passengers, but do not compromise the functional safety or primary operational capability of the vehicle. Some failures result in degraded operation, requiring more urgent service. For the most part, the automotive industry has gone to great lengths to prioritize safety and catastrophic failures, and has hardened electronics in critical systems to rather high reliability levels.

As the processing capability and software content of a car continues to increase, maintaining that level of critical reliability is getting more challenging. The temptation is to coalesce more functions into a centralized processor, and hardening it further. This may be a much more feasible approach than hardening 100 individual MCUs over a distributed interconnect, but exposes some issues immediately that the average mobile SoC is ill prepared to deal with.

Mobile SoCs designed to excel at tasks within a smart phone are architected for performance and power consumption, but generally not reliability from a system standpoint – and it goes way beyond simply dealing with harsh environmental conditions. Cores common in mobile SoCs are not designed to be redundant, or able to provide hardware lock-step or voting schemes. Memory lacks error correction code (ECC) able to fix single bit and detect double bit errors, as do many data paths to and from peripheral interfaces using conventional interconnect (MIPI has some optional ECC capability). Software can only do so much for reliability when the underlying hardware architecture doesn’t support even the basics of data integrity.

This is pretty much the same experience the avionics and industrial control industries went through with microprocessors and digital control systems in safety critical applications, and the automotive industry is responding in a similar way – with standards such as ISO 26262, AUTOSAR, and MISRA C. With much of the focus rightly on software, the question reverts to how to get more reliable hardware.

Fortunately, the fabless transformation makes designing SoCs for mid- to high-volume applications easier than ever. The first step is a different breed of processor core. Eric Esteve introduced us to the Synopsys ARC EM SEP (Safety Enhancement Package) core, and the ARM Cortex-R core also brings features targeting ISO 26262. For example, TI is leveraging the Cortex-R in their Hercules safety-critical MCU family.

Once the core is rigged for safety, the second step is redefining chip-level interconnect beyond a shared bus structure. As Kurt Shuler of Arteris puts it: “For automotive applications, we are being asked to replicate interconnect for resiliency without just doubling circuitry.” This is where network-on-chip technology really excels, with ability to map initiators and targets at low latency without an inflexible crossbar structure that becomes unscalable for larger designs. NoCs can also handle end-to-end ECC capability, crucial for data integrity across a system, and are able to help adjust traffic for QoS criteria.

With the SoC design itself more flexible and reliable, the third step is improving system-wide interconnect. When connections were fairly slow, LIN and CAN served well, but for faster control data rates several solutions have emerged with varying success so far: notable entrants include CAN FD (an 8x data rate expansion), FlexRay (on life support by some accounts, but still out there), MOST (high end multimedia), and one-pair Ethernet (relatively new to the game). Bluetooth, Wi-Fi, and LTE are also in the mix, along with ISM-band wireless for key fobs.

Cars are likely to need a gateway, one capable of ensuring message delivery, integrity, and security, to handle all the devices inside plus the connection to the outside world – with reliability designed in. To make matters worse, not only are the interconnect protocols different, but the geographic preferences vary, making a single system interconnect winner even more unlikely, and higher-end protocols are likely to evolve for a while.

All that points to the case for designing with NoCs in automotive SoCs, not only to simplify chip-level interconnect and incorporation of new peripherals quickly, but to provide error correction, flow control, message prioritization and other features needed for this highly connected safety-critical scenario.

More Articles by Don Dingee…..

lang: en_US