Design Article
Software testing for safety-critical automotive systems
By Victor Reyes, Synopsys
12/17/2012 7:30 PM EST
Basic fault-injection environment
A basic fault-injection environment includes the following elements:
Figure 2: Fault-injection environment
The fault injector and library are based on a simple fault-injection API to model fault- injection scenarios. The API has two basic commands: trigger and inject. The trigger command invokes an injector routine when a trigger event happens. Users can concatenate triggers to enable other triggers dynamically, depending on the system status. The inject command sets the specified element to a certain value. Supported elements are IO pins, registers, internal signals and memory locations. The value can be set just once (transient) or can be forced permanently. Users can add model-dependent commands for specific purposes (for instance, to flag an ECC error on a memory after a read/write access).
Fault-injection scenario: Data abort due to ECC error
This soft-error scenario uses fault-injection to corrupt data on the SRAM memory during normal software execution. ECC functionality on the SRAM model triggers the data abort exception. The process is:
• The MCU is running an AUTOSAR software application
• Triggered by the internal interrupt line, the processor core goes into a standard, interrupt-service routine
• The first, next-access to the SRAM memory will trigger an ECC error back
Engineers can describe this scenario using the scripting facilities in the framework and the fault-injection API using just three commands and fewer than 10 lines of code. When the core enters the software-exception routine, an error routine shuts down the OS. We can trace the fault injection and its effects using the built-in monitoring and analysis capabilities.
Summary
Fault injection, as recommended by the ISO 26262 standard, is the best method available to test the fault tolerance of hardware blocks and to ensure the effectiveness of diagnostic software.
Virtual prototypes provide a complete framework to create advanced fault-injection scenarios. They offer more visibility and fault-injection points than hardware-based fault injection, can model both permanent and soft errors, and, unlike software-based fault injection, virtual prototype frameworks are completely non-intrusive. Virtual prototypes run orders of magnitude faster than RTL/gate level simulators.
Fault-injection frameworks that use virtual prototypes enable users to put errors under version control and automate fault-injection regression testing every time the software changes. Virtual prototype simulations have the potential to be used as evidence for certification and compliancy with standards like
ISO 26262.
About the author
Victor Reyes is currently a Technical Marketing Manager in the System Level Solutions group at Synopsys. His responsibilities are in the area of Virtual Prototype technology and tools with special focus on Automotive. Victor Reyes received his MsC and PhD in Electronics and Telecommunication from University of Las Palmas, Spain, in 2002 and 2008 respectively. Before joining Synopsys, he held positions at CoWare, NXP Semiconductors and Philips Research.
A basic fault-injection environment includes the following elements:
- A target system – the virtual hardware model,
- A fault injector – injects faults from a library,
- The workload generator – creates stimuli according to the test scenarios
- A monitor-- feeds information back from the target system and the data collector and analyzer, and
- A controller – to orchestrate everything.
The fault injector and library are based on a simple fault-injection API to model fault- injection scenarios. The API has two basic commands: trigger and inject. The trigger command invokes an injector routine when a trigger event happens. Users can concatenate triggers to enable other triggers dynamically, depending on the system status. The inject command sets the specified element to a certain value. Supported elements are IO pins, registers, internal signals and memory locations. The value can be set just once (transient) or can be forced permanently. Users can add model-dependent commands for specific purposes (for instance, to flag an ECC error on a memory after a read/write access).
Fault-injection scenario: Data abort due to ECC error
This soft-error scenario uses fault-injection to corrupt data on the SRAM memory during normal software execution. ECC functionality on the SRAM model triggers the data abort exception. The process is:
• The MCU is running an AUTOSAR software application
• Triggered by the internal interrupt line, the processor core goes into a standard, interrupt-service routine
• The first, next-access to the SRAM memory will trigger an ECC error back
Engineers can describe this scenario using the scripting facilities in the framework and the fault-injection API using just three commands and fewer than 10 lines of code. When the core enters the software-exception routine, an error routine shuts down the OS. We can trace the fault injection and its effects using the built-in monitoring and analysis capabilities.
Summary
Fault injection, as recommended by the ISO 26262 standard, is the best method available to test the fault tolerance of hardware blocks and to ensure the effectiveness of diagnostic software.
Virtual prototypes provide a complete framework to create advanced fault-injection scenarios. They offer more visibility and fault-injection points than hardware-based fault injection, can model both permanent and soft errors, and, unlike software-based fault injection, virtual prototype frameworks are completely non-intrusive. Virtual prototypes run orders of magnitude faster than RTL/gate level simulators.
Fault-injection frameworks that use virtual prototypes enable users to put errors under version control and automate fault-injection regression testing every time the software changes. Virtual prototype simulations have the potential to be used as evidence for certification and compliancy with standards like
ISO 26262. About the author
Victor Reyes is currently a Technical Marketing Manager in the System Level Solutions group at Synopsys. His responsibilities are in the area of Virtual Prototype technology and tools with special focus on Automotive. Victor Reyes received his MsC and PhD in Electronics and Telecommunication from University of Las Palmas, Spain, in 2002 and 2008 respectively. Before joining Synopsys, he held positions at CoWare, NXP Semiconductors and Philips Research.
|
|
|
|
|
Navigate to related information