Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Software test for safety-critical auto systems

Posted: 24 Apr 2013     Print Version  Bookmark and Share

Keywords:ISO 26262  Automotive Safety Integrity Levels  Fault injection 

Virtual prototypes give development teams more than just software models for simulating the hardware; they are environments that allow them to debug and analyse hardware/software interactions. They also offer full visibility of the internal and external registers and signals, provide full control over program execution, and are completely non-intrusive.

Engineers can use virtual prototypes to freeze the full system execution at any point in time (even with multi-core hardware) and read and modify internal values. They can also use advanced analysis features to correlate software (at the application level) with hardware events, measure code coverage, apply fault injection, and use scripts to automate the simulations.

Virtual prototypes integrate seamlessly into existing software tool chains and connect to external third-party tools for hardware-in-the-loop and rest-of-bus complete simulations.

Teams can easily deploy and scale simulation models. Virtual prototypes are easy to share, archive and deploy across a worldwide organisation.

Fault injection using virtual prototyping technology
Virtual prototypes enable users to access all the internal hardware elements of a design – memory content, registers, signals – as well as specific, fault-tolerant mechanisms, like error correction codes (ECC) on memories, assuming, of course, that those features have been modelled. Users can create virtual prototype models without much effort by mirroring the functionality of the block at a more abstract level.

Virtual prototypes can model both transient and permanent faults. Users can inject faults through mechanisms on the simulation framework, without having to modify the embedded software models. They can also visualise and trace all hardware and software events that have been modelled on the systems. Visualisation tools present both hardware and software execution and events on the same windows using the same timeline, which allows users to correlate them and see the cause-and-effect of a fault.

 • Basic fault-injection environmentA 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 analyser, 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.

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 ISO26262.

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.

To download the PDF version of this article, click here.

 First Page Previous Page 1 • 2

Comment on "Software test for safety-critical au..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top