Functional safety has become both increasingly important and prevalent across a variety of markets, and this is clearly demonstrated within the automotive and industrial sectors.
Functional safety within the automotive industry was initially reserved for a number of critical functions implemented in a small number of Electronic Control Units (ECUs) within a vehicle. However, over the last few years this has changed significantly as the number of automotive applications with safety requirements have grown. This is perhaps best illustrated with the number of safety features made available in vehicles with level 2 autonomous functions such as traffic jam assistance and driver monitoring. As more driver assistance innovations and applications are integrated into the vehicle, the necessity for even wider adoption of functional safety is one of the most fundamental requirements on the journey to full autonomy.
The industrial sector’s evolving transformation towards smart manufacturing has seen the rise of automation and the growing adoption of collaborative robots (co-bots) working alongside humans on the production line. As human and machines continue to work in such close proximity, control systems must constantly monitor the integrity of the robot and react appropriately under error conditions. This in turn has driven the necessity for higher levels of functional safety.
To learn more about functional safety in the industrial sector read our Arm blueprint blog here.
Implementing safety requirements in a structured and consistent way has been made possible by using internationally agreed standards, such as ISO 26262 for the automotive industry and IEC 61508 for industrial manufacturing. These standards have been put in place to develop a common language across the industry as well as provide a reference for what is considered best practice. To satisfy an application’s safety requirements, the creation of safety mechanisms and rigorous development processes are needed.
One of the most recognized ways to mitigate random hardware faults to achieve the highest level of safety integrity, is through the use of redundant hardware. For a CPU, this could be through the creation of a processor with dual core lock-step implementation. This approach typically consumes a considerable amount of area and power which may not be merited for applications with lower safety integrity levels such as ASIL B or SIL 2. A combination of safety mechanisms, such as Error Correcting Codes (ECC), Built In Self Tests (BIST) and other safety mechanisms can be used to help achieve such targets. There are various forms of BISTs, including memory BIST, logic BIST and software BIST (Software Test Libraries).
Logic BIST can be complex to implement with pseudorandom generated test patterns loaded into scan chains to test the logic which when run, can introduce high peak power demands on the system. The CPU must be taken offline to run the LBIST tests and restarted. This poses a challenge to tight requirements of fault detection during runtime. The performance level can also be negatively affected as there is time required for the processor to be reset and restarted on completion of the tests. In the case of memory BIST, the built-in testing is used for detecting predominantly stuck-at-faults within the memory and pattern testing is applied at full memory speeds. Memory BIST can be used with other safety mechanisms as this does not test the functional logic of the CPU.
A Software Test Library (STL) lends itself to be a natural choice when used with memory protection. An STL does not require any form of hardware redundancy therefore using less silicon area and power. STLs are typically less complex to deploy as they are a simple library of software functions called by the software stack without the requirement to reset the processor. Perhaps most importantly, STLs can be deployed on devices which are already available in silicon, unlike online LBIST which needs to be planned at design time. STLs power usage is equivalent to that of an application running on the CPU and there is no additional power impact like in the case of LBIST.
STLs are a library of software functions which provide diagnostic capabilities. STLs test the hardware for the presence of permanent faults within the processor functional logic, such as stuck at one and stuck at zero faults. STLs can achieve ‘medium’ percentage detection rates of faults within automotive applications that is, up to ASIL B for the Single Point Fault Metric and up to SIL 2 industrial applications for the Safe Failure Fraction. In ASIL D automotive applications where the CPU utilizes dual core lock-step, STLs can be used at start-up to check the health of the CPU before the safety applications are run and can be used to run periodically to detect faults. STL source code is generally optimized so that it utilizes a minimal memory footprint. Tests are generally written in assembly to improve deterministic execution and fault coverage when compared to compiling a high-level language like C.
Arm Cortex-R5 STL and Arm Cortex-M33 STL have recently been added to the STL product portfolio. The newly released STLs can be integrated onto a new or existing SoC using either Cortex-R5 or Cortex-M33, both of which are aimed towards automotive and industrial applications.
To address a new market or applications with an existing chip, there may be a need to increase hardware metrics such as Single Point Fault Metric (SPFM) from the existing level as part of the functional safety requirements and STLs could be used to be help with this. When targeting an established chip at applications up to ASIL B or SIL 2, an STL is a natural choice to consider. It can be deployed without the need for additional hardware changes to the device. In addition, the STL allows users to define the individual tests to be executed and so limits the test time and memory resources used.
When implementing an STL, it is valuable to consider where the Software Test Library fits in the overall safety concept of the CPU, how it can be integrated and how the analysis of diagnostic coverage can be performed. Arm enables licensees to do this through the documentation it provides with its STLs, adding confidence to help meet the targeted safety goals. Each STL has its own specific documentation such as a user guide, IP Failure Modes Effects and Diagnostic Analysis (FMEDA) and a Safety Manual.
Each device has a functional safety concept which includes the safety measures and safety mechanisms implemented within the processor. When looking to deploy an STL, it is important to define the areas of the safety concept which will be addressed by the test library. STLs not only detect faults in the functional logic of the CPU identifying stuck at one and stuck at zero faults. The Arm STL FMEDA report provides the licensee detailed information about the areas within the specific CPU that can be covered by the library. This can be used as guidance on how to apply hardware coverage for the processor to help fulfill the safety concept.
STLs can be simply integrated into the software stack with a standard API and can be run periodically with the flexibility to define how testing is performed. The flexibility enables the licensee to either execute the complete STL with a single call or the testing can be divided into multiple discrete blocks. This either enables the depth of testing to be selected by targeting specific tests or it enables fitting the execution of tests across available time windows. This minimizes the STL’s effect on the main application’s workload and helps meet the desired Fault Tolerant Test Interval (FTTI). The operation and integration of the STL are described in the Arm STL user guide.
The diagnostic analysis can be done in several parts, it can either be based on analysis to identify relevant areas where diagnostic coverage is needed and alternatively can be based on coverage measurement of the faults. The detectable faults of the processor can be measured through a fault injection simulation, the results of this can be used in a FMEDA to document their contribution to the overall detection of faults for the design and identify the residual fault fraction. Each STL is provided with its own processor FMEDA analysis performed by Arm which has been populated with the results of the measured STL fault simulation coverage. The analysis is based on a specific implemented configuration of the processor which can be used as guidance for populating results for the actual device netlist and configuration. To assist with this analysis, Arm also provides fault injection scripts simplifying the execution of fault simulation on the design’s netlist.
The analysis of the product and its specific safety goals may allow areas of the design to be considered as not safety relevant. This can be used to adjust the results of the measured analysis, restricting this to only the appropriate areas of the design. In doing so, it is possible to achieve a higher percentage SPFM coverage for the device. If any gaps remain between the final coverage goal and the analysis performed, there may be added coverage provided through system level checks and safety application-related software.
A safety assessment of the product is typically performed and although this addresses more than just the STL and processor, this will normally form a critical part of the assessment, and can be assisted by the information provided by Arm with the STL. The STL documentation can be used to provide evidence of the library’s systematic development. It also contributes to demonstrate its correct integration and the processor’s analysis to achieve the product’s safety goals.
While the focus has been on the deployment of STLs for existing designs, the same principles also apply to a ground up development of a new device. In the case of a new device, there is the additional opportunity for the inclusion for further hardware measures to boost coverage.
Automotive and Industrial applications examples
For existing SoC designs requiring the ability to enable functional safety, Software Test Libraries provide an ideal asset. STLs offer key components to enable the safe execution of systems throughout a range of applications, particularly in the automotive and industrial segments. STLs offer a flexible and efficient solution to help address the critical functional safety requirements which are only set to increase as we move to a more automated future.
Arm STLs are currently available across a range of CPUs including Cortex-A, Cortex-R and, Cortex-M products. If you have any questions about Software Test Libraries or functional safety for Arm-based devices, click here to talk to an Arm expert.
Discover more information about Arm Software Test Libraries visit our Arm.com webpage.
Discover More