Electronic Design
Use A Model-Based Design Test Process For Your Smart Devices

Use A Model-Based Design Test Process For Your Smart Devices

Increasingly, we’re surrounded by intelligent devices. Your computer, smart phones, and the new Apple iPad are obvious examples. But your car, washing machine, and electrical power grid are also becoming smarter. The software embedded in these devices is driving their intelligence. In fact, it’s becoming more and more difficult to find electronic devices in our lives that are not defined in large part by some type of embedded software.

Who ever would have imagined we would need dozens of electronic control units (ECUs) in our cars to make a trip to the grocery store? Then again, the creature comforts of such a vehicle can certainly turn the chore of running an errand into a blogable experience. Nonetheless, as software-based devices become more ubiquitous and increasingly complex, embedded engineers are facing significant challenges in streamlining the design and test processes of such devices and achieving traceability of defects from the field back into the design.

Today’s embedded development process typically consists of various forms of design simulation, validation, verification, and system test. During these phases, a hard transition between design and test tools occurs. This often results in a complete rewrite of test code, test cases, and simulation and I/O interfaces to the models.

In addition, traditional design tools are becoming more cumbersome, making it hard to stitch together multiple models for pure simulation test with the growing complexity of the models and use-cases to be examined. Each of these issues presents real business challenges to organizations with respect to margins, personnel needs, documentation, and time-to-market.


A growing trend in the development of embedded control devices is the move to reusing design and test tools, models, and simulation data beyond their previous silos in the development process. Many design and test engineers are actively reusing models throughout the development process. However, these engineers can achieve more significant efficiency and quality gains by reusing tests across the design flow as well (see the figure).

Out of this need has grown a new category of software called real-time test software, which enables engineers to reuse testing tasks such as stimulus profiles, test sequences, analysis routines, and requirements tracing across the entire embedded design flow. The term “real-time” denotes this software’s capability to model the rest of the embedded system to test the firmware of the device under test (DUT) under real-world conditions.

By using the same test software components across all phases of the design flow, you get improved continuity from the initial product definition all the way through final system test. This is particularly important in trying to diagnose field failures. I have seen many situations where these failures are difficult to diagnose due to differences in testing procedures in characterization and production.

For example, when developing embedded control software, the stimulus profiles, analysis routines, and other components used in the model-in-the-loop (MIL) design tasks will be reused to create the hardware-in-the-loop (HIL) and field tests for prototype controllers. Once this stage is complete, the evolved software test components will be the starting point for the development of the HIL, subsystem, and systems integration test systems.

Ultimately, the production test plans used by manufacturing will be of the same DNA as the original components created during the design phase. Similarly, test benches and analyzers used by computer-aided engineering (CAE) tools in the design of ASICs will be applied to instrumentation-based test systems. In the end, development teams will produce and examine results the same way.

This will allow these teams to make decisions and adjustments more quickly and with greater effectiveness, reducing risk to schedules and budgets. Not only does this approach provide a high degree of flexibility and adaptability when teams are required to respond to any issues discovered during testing, it’s also helpful when they face the addition of further test cases resulting from mid-cycle project requirement changes and in tracing failures back to requirements in each phase of the design flow.

It is important to note that while real-time test software is enabling a new level of embedded design and test efficiency, it is not the only thing you should consider when addressing your embedded design and test needs. In addition to hiring domain experts, you should also develop and follow style guides and sophisticated processes to ensure the accuracy of your development needs and the ability to synthesize real-world implementations of your designs.

Companies that begin to view their embedded development process differently, in a way that sees test components as a common DNA throughout the entire development process, will have a competitive edge. Testing tasks executed after design completion will become the offspring of the procedures used during the creation of the product.

While they inherently have different goals, the subsequent test components will share a common ancestry. They will be clones of the previous steps in some cases and an evolution in others. This relationship will expand beyond today’s common origin of project requirements to the actual reuse of test components and processes. This will result in significant cost, time, and personnel savings while delivering the improved quality that end users have come to expect from the latest software-based devices.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.