Author: Dr. J\u00f6rg Koch, Renesas Electronics Europe Self-test software is a fundamental building block in the development of functional safety applications. In complex components such as a microcontroller's CPU, demonstrably meeting the required diagnostic coverage is challenging. This necessitates detailed knowledge of the underlying hardware. Validation of the required test coverage can be achieved through targeted fault simulation. This paper describes the development of self-test software for the CPU of the Renesas RX631\/63N microcontroller family. The development of the CPU self-test software presented here was carried out according to IEC 61508 and accompanied by a T\u00dcV Rheinland certification process.<\/strong><\/p>\n A number of requirements are placed on CPU self-test software. It should detect random CPU hardware errors during runtime with sufficient diagnostic coverage. In a safety-critical system, the necessary detection time is less than the "Process Safety Time" (PST). This PST is application-dependent and can be as short as a few milliseconds in time-critical systems. Furthermore, the self-test software should only occupy a limited portion of the available program memory and have the shortest possible interrupt masking time. A balance must be struck between these sometimes conflicting requirements when designing the self-test software. The development process must also comply with the requirements of IEC 61508 if the self-test software is to be used in safety-related applications with a corresponding SIL\/SC rating. Certification of the self-test software by an independent institute such as T\u00dcV Rheinland helps to meet these high quality standards.<\/p>\n The self-test software has a modular structure. The entire test consists of 40 test modules. Each test module can be called individually or in groups, depending on the maximum time window provided by the application for a sub-test. The entire test must be executable within the Process Safety Time.<\/p>\n The goal of the self-test software is to stimulate and detect random CPU hardware errors. Optimizing the diagnostic coverage is essential for both the stimulus and the detection process. To achieve a well-controlled stimulus, the test modules are programmed in assembly language. However, the user interface of each test module is implemented in C. The results of the various so-called "elementary" tests within a test module are combined into a signature value. After execution, each test module provides an actual signature value, which, if it deviates from the expected signature value, can be used to identify the test as faulty. The method of signature generation influences the efficiency of the detection process. The described CPU self-test software uses a 32-bit signature that combines the elementary test results using an exclusive-OR and bit rotation function. Each test module returns a "Pass" or "Fail" result and additionally stores the generated signature in a predefined memory area. These signatures can then be evaluated by, for example, an external "safety processor" without having to rely on the evaluation by the tested CPU itself.<\/p>\n It is important to note that CPU self-test software must always be accompanied by the use of a watchdog timer, as CPU errors can have fatal consequences for process control. Such errors are typically detected by a watchdog timer.<\/p>\n The basis for error simulation is the microcontroller's so-called "netlist," which represents all the logic in ASCII format. Using this netlist and appropriate software tools, the microcontroller's behavior when errors are introduced can be simulated.<\/p>\n The so-called "stuck-at" fault model was used, which is widely used and established and effectively models the various physical faults in a logic circuit. In this model, the value of an input or output of a logic gate in the netlist is stuck at "1" or "0", thus investigating the effects of a short circuit to the supply voltage or ground (Fig. 1, see Fig. 1).\u00a0PDF<\/a>The execution of the self-test software with an introduced error is then simulated, and the stimulation and detection of the error are monitored. The use of a watchdog timer is also taken into account. In total, approximately 200,000 possible stuck-at errors had to be simulated in the CPU, which can only be accomplished in a reasonable timeframe through massive parallel processing.<\/p>\n During fault simulation, submodules of the CPU, which implement various functions such as registers, arithmetic logic, or logical operations, could be examined separately. This facilitated targeted improvements to the self-test software in the relevant areas.<\/p>\n The self-test software was developed in several stages. It began with a basic version created by an experienced software team, whose development was based on the relevant user manuals for the hardware and the microcontroller's instruction set.<\/p>\n The diagnostic coverage of the basic version was determined using fault simulation. Based on the results for the various CPU submodules, the self-test software was optimized accordingly (Fig. 2, see [reference]).\u00a0PDF<\/a>). The additional requirements for runtime, memory space and interrupt masking time mentioned above also had to be taken into account.<\/p>\n Fig. 3 (see\u00a0PDF<\/a>The graph shows the percentage of detected "stuck-at" errors relative to the total number of CPU errors (blue line). To determine the CPU's diagnostic coverage, two further corrections must be made (red line).<\/p>\n Firstly, all errors that have no inherently dangerous consequences and therefore cannot be observed in the error simulation are subtracted from the total number of errors. These so-called no-effect errors are not considered when calculating the diagnostic coverage. Typical examples are errors in areas of the CPU's test logic, such as the scan-in input of a flip-flop. These errors can only be stimulated and detected when the corresponding test logic is activated. For the CPU used here, the number of these no-effect errors is approximately 12%.<\/p>\n Furthermore, unlike ISO 26262, IEC 61508 requires consideration of the so-called DC fault model for a diagnostic coverage of 90%. The DC fault model considers not only stuck-at faults but also other fault types such as stuck-open or bridge faults. The detection values obtained for stuck-at faults must be reduced accordingly by a correction factor, which can be derived, for example, from theoretical considerations.<\/p>\n Figure 3 shows (see\u00a0PDF<\/a>The effects of improving diagnostic coverage after corresponding optimization steps of the self-test software are clearly evident. The base version already has a fairly high detection rate of over 70%. After the aforementioned correction, this corresponds to a diagnostic coverage of approximately 79% for dangerous random hardware faults. Although a significant effort was invested in the development of the base version by an experienced software team, the diagnostic coverage is still considerably below the target value of 90%.<\/p>\n After optimization and the application of the corrections described above, the final version of the self-test software achieved a diagnostic coverage of 91%. This optimization more than halved the number of undetected critical errors in the CPU.<\/p>\n A closer look at the weaknesses of the basic version of the self-test software revealed a need for improvement, particularly in the arithmetic operations and the floating-point unit. For the arithmetic operations, the range of operand values had to be significantly expanded to achieve a sufficient detection value for the respective CPU submodule. The tests of the working registers were also greatly improved. This was achieved, for example, by expanding register-based addressing and register-based arithmetic operations. Significant improvements were also achieved in specific functions of the CPU under investigation (string functions, instruction pipeline, etc.) through error simulation and knowledge of the CPU's structure.<\/p>\n The self-test software was developed in accordance with the requirements defined in IEC 61508 for compliance with the SIL3\/SC3 safety level. Complete documentation of the various development steps plays a key role in this.<\/p>\n The fundamental planning at the start of measures to achieve safety-related objectives is documented in the Safety Plan. It defines, for example, all groups involved in the activity with their corresponding interfaces, the tools used with their respective qualifications, configuration management, software guidelines, and software lifecycle phases. Tailoring the requirements of Part 3 of IEC 61508 for software development is also part of the Safety Plan. Detailed planning documents regarding verification, validation, etc., supplement the Safety Plan.<\/p>\n The clear definition and documentation of requirements, e.g., regarding the function, development, and verification of the software, also play an important role in development according to IEC 61508. A requirements check must also be part of the verification process.<\/p>\n An IEC 61508-certified development environment, including a build chain, enables flexible software development for use in safety-related applications. If such a pre-certified development environment is not available, proof that the development environment is suitable for developing software in safety-related applications must be provided independently. Alternatively, the output for each application must be verified separately.<\/p>\n As mentioned above, IEC 61508 requires consideration of the DC fault model for a diagnostic coverage of 90%. The necessary correction means that a detection value greater than 90% must be achieved in the fault simulation based on the Stuck-At fault model.<\/p>\n When developing CPU self-test software, CPU fault simulation can significantly optimize the diagnostic coverage of the test. Based on our experience, we conclude that it would be very difficult to create self-test software with a diagnostic coverage of 90% without the support of fault simulation.<\/p>\n Download the article as a PDF<\/strong><\/a><\/p>\n Do you want to bring yourself up to date with the latest technology?<\/strong><\/p>\n Then find out more\u00a0here<\/strong>\u00a0<\/a>Regarding training courses\/seminars\/workshops and individual coaching sessions offered by MircoConsult on the topic\u00a0Quality, Safety & Security<\/strong>.<\/p>\n Valuable expertise on the topics of quality, safety & security is available.\u00a0here<\/strong>\u00a0<\/a>Available for you to download free of charge.<\/p>\n
\n<\/strong><\/p>\nContribution \u2013 Embedded Software Engineering Congress 2015<\/h3>\n
Fundamentals of CPU self-test software<\/h2>\n
Fault simulation<\/h2>\n
Optimization of the self-test software<\/h2>\n
Requirements of IEC 61508<\/h2>\n
Summary<\/h2>\n
\nOur training courses & coaching sessions<\/h2>\n
\nTraining & coaching on the other topics in our portfolio can be found here.\u00a0here<\/a>.<\/strong><\/p>\n
\nQuality, Safety & Security \u2013 Expertise<\/h2>\n