Virtual testing, based on system simulation and Model-Based Design, takes the traditional "test-at-the-end" system development process (represented in the V diagram) and makes it more iterative. Virtual testing shortens both the design cycle and the final physical testing phase.

The Problems: System Complexity and Late-Stage Error Detection
Complexity in embedded software development is driving the cost of test and verification to as much as 70% of overall development costs. Industrial automation, automotive, and aerospace engineers conduct exhaustive design and code reviews and build increasingly complex test systems to confirm that the software in embedded processors meets high-integrity standards and design requirements. And as verification consumes more time, engineers have fewer opportunities to innovate and create product differentiation through design optimization.

Many organizations are finding that most errors they uncover in test and integration were introduced at the beginning of the design process while interpreting system requirements. Engineers now face the challenge of checking for errors and "cleaning them out" closer to the beginning of the development process, when they are cheaper to fix.

Finally, as development teams grow and become geographically dispersed, they are seeking better ways to collaborate.

The Solution: Test Early
Embedded software errors can be cut substantially by doing more complete design verification at or near the beginning of the design process via systematic system simulation, or virtual testing. "Virtual" in this case denotes simulation, but with no hardware involved—just software and simulation engines. "Systematic" means building tests based on requirements and then executing those tests against the system design.

Two critical concepts that drive virtual testing process improvements:

• An executable system specification
• Requirements based tests

The executable system specification is a model that you can simulate, and includes your system design as well as environment models: models of the important elements of the physical world your embedded system interacts with. The system model needs to include subsystem domains such as controls, mechanical components, electrical components, and hydraulics. These models should be as detailed as needed to capture their system-level functional behavior.

Requirements-based tests are formulated from functional requirements that can be expressed as tests; essentially, "Given a particular input, here is the output I expect." At a minimum, you need to have a simulation input signal or sequence for each test, as well as output captured from the simulation, to compare with the expected output. You should also build a complete set of tests that fully exercise the requirements.

To understand how this works, consider the classic design process V diagram (Figure 1). With virtual testing, you would follow a second V early in the process, starting partway down the left leg and then up to the right. The design flow moves to a virtual test rather than down the left leg to the original apex (the point of implementation) and then up the right leg (the hardware side) to physical testing.


Figure 1: The V diagram, which illustrates the traditional embedded system development process. The right side represents physical test and verification, which occur late in the process when problems are more costly to fix.
(Click on image to enlarge)


Figure 1 illustrates a traditional design flow, in which engineering teams move from written requirements to design, manual coding and, finally, system integration and test. Ensuring requirements are valid at the start is a challenge, verifying the design against the requirements is difficult, and implementing the code is a manual, error-prone process.