“Safety Documentation Package” Boosts Updated Functional Safety in ARM Systems
Leaving aside medical and industrial markets to focus on the automotive industry, there has been a significant increase in Advanced Driver Assistance Systems (ADAS) such as lane departure warnings and collision avoidance steering systems in vehicles, and there’s a growing trend towards connected vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) safety systems. These rely on the functional safety of electronic systems to avoid collision and harm to the driver and other road users and pedestrians.
When considering functional safety, i.e., how a system reacts when certain conditions are detected, the developer has to be “always thinking how things can wrong,” says Lauri Ora, Functional Safety Manager, ARM.
ISO 26262 Standard Review
The automotive industry is reviewing the ISO 26262 standard “Road Vehicles – Functional Safety.” This, along with Automotive Open System Architecture (AUTOSAR), ensures automotive systems, software and hardware can be developed and operated for functional safety. The ISO 26262 standard for automotive functional safety was introduced in 2011, and in November 2014 the industry began the work towards its second edition. This work includes aspects of the standard’s applicability to semiconductor designs, including IP topics.
ARM’s Ora has been leading the IP work, including co-ordinating concerns and documentation from different countries and organizations. The standard can have different meanings, Ora explains: “The [ISO 26262] standard can be taken and read in different ways,” he says, “and with different implementations. Extra guidance in the documentation will set the baseline for expectations and highlight concerns of the types of data to be made available [for IP designs]. It will help everyone,” he concludes.
Work has been on-going for more than two years to capture guidance for IP-based designs for functional safety. This work covers, for example, what information needs to be available for IP to be designed and verified, and what information is available for potential failure modes and to define the information to be made available for IP-based designs. The result of this collaboration is expected to be available within 12 months.
ARM® Cortex®-R5 processor
ARM released its Cortex-R5 in 2010, just before the ISO 26262 standard was introduced (Figure 1). The real-time processor has a set of fault detection and control and, now, a safety document set that semiconductor companies can use to support demonstration of compliance with functional safety standards, reducing time to market, component count, complexity and energy consumption.
“A system microcontroller, including an ARM Cortex-R5 processor, is a physical device,” says Ora. “It can influence behavior with EMI or with radiation, for example, and this needs to be detected so that the software does not run incorrectly.”
Detect and Correct
This is where the ARM Cortex-R5’s fault detection and fault control features are particularly beneficial in the safety arena (Figure 2). The processor and parts of the controller unit can react to certain types of faults that are detected and corrected by the Cortex-R5 and the hardware.
Features such as fault detection and control, as well as what Ora describes as lock-step-plus reduce checks in software. The hardware itself is used to detect and flag certain faults. This in turn means there is no software overhead associated with the error checking so that more code and complex algorithms can be run in software as the hardware is taking care of monitoring and checking for system faults.
By being free to focus on software development, developers can create more complex, advanced algorithms for safety features. “A regular processor—without a fault detection mechanism —would have to add test routines to the software to allow the processor to do this,” explains Ora.
The lock-step logic is not new to the Cortex-R5, yet is worthy of note as it affords a high rate of detection. Altogether the Cortex-R5 is, says Ora, “a compelling safety story.” (See Embedded Systems Engineering’s Chris Turner interview.
There are different configurations of Cortex-R5 and different memory files to suit the application. The lock-step detects and corrects errors in the memory which can be corrupted by external influences. Ora explains that while the lock-step would ordinarily increase silicon area, as it replicates a large amount of logic, the Cortex-R5 is engineered in such a way that it does not replicate memory but instead uses a copy. A discrepancy in the hardware is thus also spotted in the system, so the silicon area required by the memories is not increased.
A critical application, with no lock-step microcontroller, would use redundant and separate microcontrollers to manage safety at the PCB level, says Ora. “All the complexity is squeezed or compressed into a single microcontroller to simplify PCB and software design. As a result of this integration, the component count is reduced, improving reliability, as fewer parts are involved. Another benefit is that complexity and energy use decrease,” (refer back to Figure 1).
The ARMv7-R architecture, used in the Cortex-R5, defines the Memory Protection Unit (MPU). This can be configured to detect application software bugs, flagging up any instances when the application software tries to access an area that it should not. Architecture features include user and privileged software operating modes with an MPU and advanced error management as well as support for lock-step processor configuration for diagnostic coverage of random hardware faults.
Other features designed to meet the strict real-time operation required for safety-related applications are tightly coupled memories, close to each core (refer back to Figure 2), which make the core suitable for fast and deterministic interrupt response. There is also a low latency interrupt mode to optimize performance.
A Cortex-R5 documentation pack was released in January 2015. It is designed for silicon vendors integrating the Cortex-R5 into an SoC design and who need to certify their products for safety-critical automotive (and other) systems (Figure 3). It is targeted and only available to Cortex-R5 licensees, such as Texas Instruments and Spansion. It provides access to additional information required for demonstrating functional safety. It also includes, says Ora, a description of product features for functional safety support, such as error detection and error correction mechanisms. It describes, in detail, the reaction if a fault is detected. What’s more, it describes the type of development life cycle approach and what audits and assessment have been undertaken.
The detailed information, collated over the years, includes assumptions of use: how to use the Cortex-R5 in SoC designs and any constraints for the system designer, e.g., in using certain signals and when not to use some because of interference. “There are a number of possible design solutions,” points out Ora, “so we can’t tell an SoC or MCU designer not to do something, but only give recommendations.”
As well as ISO 26262, the documentation also supports IEC 61508, the industrial safety standard. The generic nature of the Cortex-R5 safety documentation means that it can also be applied to other markets, including medical, which is covered by a range of standards, points out Ora.
Software Development Tools
To address tool qualification for a variety of safety-related markets, the company has developed the ARM Compiler Qualification Kit, which contains information about the ARM C/C++ compiler that can be used for tool qualification. This qualification kit also includes a safety manual for the compiler, which describes the compilation flow and information about possible failure modes of the compiler tool chain and about constraints of use.
The compiler tool chain is certified by TÜV SÜD to fulfil the requirements for development tools classified T3 according to IEC 61508-3 relating to software requirements.
Roadmap for Safety
The growing connectivity of devices, particularly within the automotive market, plus the proliferation of ADAS automotive systems in today’s cars demands a cost-effective and time-efficient means to integrate functional safety in systems. The ecosystem and support of the ARM Cortex-R5 show that the industry is already moving in this direction.
ARM is actively working on a number of fronts for functional safety support, confirms Ora. The recently launched Cortex-M7 processor has a number of features for fault detection and control. For applications requiring high compute throughput, such as ADAS, ARM recently announced functional safety support plans for recent Cortex-A series applications processors, including Cortex-A53, Cortex-A57, and Cortex-A72.
This article was sponsored by ARM.