Functional safety is a formal discipline that analyses a system to identify:
Safety Function Requirements - what safety functions are performed by the system
Safety Integrity Requirements - what degree of certainty is necessary that the safety function will be performed without a dangerous failure
The objective of Functional Safety is freedom from unacceptable risk of physical injury or of damage to the health of people either directly or indirectly (through damage to property or to the environment).
Complexity and electrification of automobiles increases steadily, which involves an enhancement of safety-requirements of applied E/E-components, controllers and their connection and interaction in between. As a fundamental safety-relevant standard, the E-Gas monitoring concept has been introduced in the '90s. Recently, a new version of this E-Gas monitoring concept has been published, which includes the application of multi-core processors.
Each architecture (Power, X86, ARM) is available in a number of configurations, enabling vendors to meet a range of computing and power requirements within their product lines. In addition, some products offer built-in accelerators that may or may not be of value for a given application.
In order to fulfill safety standards/regulations such as ISO 26262 there is the need to implement redundant calculations which can be compared to each other during run-time in order to increase reliability of the systems and finally deliver products which are state-of-the-art. Implementing redundancy concepts on one chip of course is subjected to Common Mode Failure (CMF), because of single hardware, however calculations have shown that many failures happening in software can be detected and handled by redundancy concepts in multi-core systems.
The Power and ARM Architectures are based on a Reduced Instruction Set Computer (RISC) design while the X86 processors are Complex Instruction Set Computers (CISC). This is really a simplification, since Power and ARM A-core processors use some complex operations, so hey can’t be considered a pure RISC design. In comparison, Power and ARM have a simpler instruction set than x86.
Automotive OEMs are requiring semiconductor suppliers to develop ADAS system-on-chips (SoCs) and modules in compliance to the ISO 26262 Functional Safety standard. Safety critical systems rely on SoCs to meet Automotive Safety and Integrity Levels (ASIL) specific to each application. Using certified IP also helps SoC designers reduce supply chain risk and accelerate the requirements specification, design, implementation, integration, verification, validation and configuration of their SoC-level functional safety.
The processor IP plays an import role in the ISO 26262 certification/compliance process. All three architectures (Power, X86, ARM) contain protected Intellectual Property (IP). For high-integrity use, knowledge of internal processor information is required to understand where resource contention exists that can affect deterministic operation. For Power and X86, this IP is considered to be a trade secret and access to IP is dependent on the supplier. ARM IP is also protected but can be purchased. Recent high-end ARM cores are approaching the performance of Power cores (e6500), particularly if the e6500 accelerators are disabled for high-integrity use.
CISC processors, such as X86, perform multiple operations with a single instruction. Compared to a RISC processor, additional hardware is included in each core to accomplish the complex instruction. As a result the compiled instructions are more compact, requiring less code memory for a given function. In general, the additional transistors required to support CISC will also require additional power. That said, Intel has invested heavily in reduced transistor feature size which mitigates some of the power consumption differences.
Pure RISC processors (Power, ARM) have a minimal set of instructions that operate in a single clock cycle. This simplicity reduces the number of transistors required to support the instruction set however more instructions are required to perform a given function, compared to a CISC design. As a result, code space memory size will be higher for a pure RISC application, compared to a similar CISC application. The RISC architectures lend themselves to safety-critical applications, because processor characterization of deterministic behavior is easier to accomplish with a simpler design. With fewer transistors, RISC processors tend to be more power-efficient than CISC processors. ARM-based products have been extensively used in battery or otherwise low-powered devices such as smartphones.
Multicore architectures seem to be an interesting option for safety-related applications. PC and server-class processor computing performance is achieved by integrating multiple processing cores into a single package. The multiple cores share some level of resources that affect determinism while generally providing higher performance. Functional safety certification/compliance has become more complicated as a result of MCP development because of reduced determinism and potential contention.
For Autonomous Vehicles, Product certification/compliance using MCPs, and safety certification/compliance requires showing evidence of meeting the functional safety requirements set forth by ISO 26262. Compared to SCPs, MCP integrators are more reliant on supplier-provided MCP information to understand internal resource contention (interference channels) and how the MCP arbitrates contention.
Multicore parametrization/programming/debugging is challenging. For computing-intensive applications such as Advanced Driver-Assistance Systems (ADAS), multiprocessor and multi-core processor systems are increasingly being used in embedded systems. CRC Press News titled “Multi-Core Processor Functional Safety Considerations for Autonomous Vehicles” shows how requirements for a multi-core system design can be implemented in compliance to ISO 26262 modeling concepts, i.e. safety standards. Accordingly, safety-relevant system-level requirements have to be broken down to the subordinate system components (e.g., controllers) as well as the hardware and software architecture. In safety-critical application domains, there are also requirements and limitations that must be taken into account during partitioning, mapping, and distribution processes. For the distribution of software components to the individual processing cores, various algorithms are mostly used, since a manual distribution under consideration of all constraints is error prone, time consuming, and ineffective. CRC Press News titled “Multi-Core Processor Functional Safety Considerations for Autonomous Vehicles” finally presents a way to determine and identify requirement types along with methods and tools that are supported by A Notional MCP Software Architecture for Autonomous Vehicles.