Moving towards achieving Autonomous Vehicle’s functional safety in year 2019 and beyond, electronic systems are becoming more common and sophisticated. Because of this, safety and verification are a critical part of every automotive chip design as well as the IP integrated into the silicon. Compliance with ISO 26262, which describes automotive functional safety requirements and levels, has become mandatory for products in this domain. System and chip designers must comply with the standard allowing their end products to be certified.
The electronics content of cars is increasingly rapidly. Ten years ago, perhaps 20% of the value of a car was made up of electronics. Today it is more like 35%, and in ten years’ time electronics could represent half of a car’s value – as well as enabling 90% of its innovative features. You only have to look at a Tesla, with its innovative electric powertrain, evolving autonomous driving capabilities and iPad-like controls to see where we’re heading.
More electronics means more Systems-on-Chip (SoCs) to design and verify, and greater competition to supply this rapidly growing market. New product development teams can design and verify SoCs, however serving the automotive market introduces constraints that IC vendors attempting to migrate from, for example, the mobile-phone sector may not be familiar with. To compete, new entrants will either have to learn very quickly, or get some help from a trusted IP vendor.
Functional safety is critical for SoCs that are the technology backbone for Autonomous Vehicles, Advanced Driver Assistance Systems (ADAS), infotainment equipment, and other in-car systems. However, meeting the various safety standards can be time-consuming and labor-intensive, involving voluminous amounts of data that changes as the standards evolve.
One key challenge in developing Autonomous Vehicles is incorporating functional safety for those SoCs in the safety-critical path. The industries have worked long and hard to understand safety and reduce risk, in part through the development of the Automotive Safety Integrity Levels (ASIL) defined in the ISO 26262 standard. These combine the probability of exposure to a hazard, the extent to which it is controllable by a driver, and the severity of a failure to control such a hazard, into four categories, A thru D. Of these, ASIL D represents the integrity level necessary in the most safety-critical circumstances.
Functional safety is the concept that a system will remain dependable and function as intended even in the face of an unplanned or unexpected occurrence. If a system is functionally safe, then it is assumed that the system is able to avoid unacceptable risk of physical injury or damage.
For SOCs, there are two foundational requirements of a functionally safe system:
As SoCs move into smaller process nodes they become more susceptible to errors. For example, phenomena including radiation sources, magnetic fields, and internal wear can all be disruptive to an advanced-node SoC. To assure that an SoC is functionally safe, a designer would typically need to establish a functional verification environment where errors (faults) could be injected into the system. Redundant logic would vote on the correct data to eliminate errors and maintain continuous operation. Checkers would monitor the erroneous data within specified time periods and apply error corrections.
Following certain methodologies can make it more efficient for designers to ensure an Autonomous Vehicle will behave as anticipated, even if something unplanned or unexpected occurs. A set of design and verification technologies that automate fault tolerant, fault injection and result analysis for intellectual property (IP), SoC, and system designs can reduce ISO 26262 compliance efforts by up to 50 percent.
Managing Autonomous Vehicle’s safety is a holistic process – everything has to work together correctly for the system to offer the expected levels of safety protection. This means that foundational components such as embedded processors must meet the requirements of the specified ASIL. To meet ASIL D this includes a system level requirement of fewer than 1% single points of failure. In practice this means that a processor going in to an ASIL D certifiable chip must implement Cyclic Redundancy Check (CRC) or Error Checking and Correction (ECC) on caches and closely coupled memories, include a watchdog timer, and operate in lockstep with a redundant core. In a lockstep implementation, two cores run the same code and include a mechanism for comparing the outputs of the two cores and flagging any discrepancies. Extensive safety documentation is also required to demonstrate that risks have been clearly identified and assessed: these documents then could become a key part of the ISO 26262 certification process.
Additionally, the self-checking safety monitor can be introduced to ensure lockstep operation, and can delay the activity of one of the redundant cores relative to the other while still comparing results in the correct program counter order, to avoid potential issues related to glitches that affect both cores at once (e.g. a signal transient).. There’s also hardware stack protection to check for overflow and underflow of reserved stack space – to prevent data corruption and program crashes – and a watchdog timer to help recover from deadlocks and enable countermeasures against tampering.
Furthermore, a functional safety solution based on multi-purpose built-in self-test and repair infrastructure for SoCs can be developed. This solution allows building a hierarchical network and managing it in multiple in-field test and repair modes.
As the opportunity represented by the development of Autonomous Vehicles grows, and the rate at which it innovates accelerates, competition to provide the key SoCs can only intensify. Although well-designed, carefully verified hardware is critical to achieving ISO 26262 certification, what will really set competitors apart in the automotive market will be how quickly they can meet evolving market requirements and bring a differentiated solution to the market.
Moving towards achieving Autonomous Vehicle’s functional safety in year 2019 and beyond, ensuring that an automotive SoC is functionally safe also gives drivers and passengers confidence in their vehicles. Integrating safety verification into the functional verification flow can be an effective way to speed up the process and manage the effort of complying with standards such as ISO 26262. Using functional verification and fault simulation technologies can also minimize your safety verification effort. With these methodologies and technologies, companies can spend more time creating safe and unique automotive designs.
Computer Science & Engineering, Engineering - Chemical, Engineering - Electrical, Engineering - General, Engineering - Industrial & Manufacturing, Engineering - Mechanical, Ergonomics & Human Factors, Information Technology, Materials Science, Mathematics, Nanoscience & Technology, Occupational Health & Safety, Public Administration & Public Policy, Statistics
Redundancy provides multiple processing paths that limit the risk that any one error will disrupt the system
Checkers monitor the systems and trigger error response and recovery features when needed