Off-highway vehicle manufacturers must create quality ECU software while maintaining strict time-to-market requirement deadlines. To create software more efficiently, model-based design has become a standard practice for developing embedded control algorithms. Simulation models offer a layer of abstraction that enable developers to create complex mathematical algorithms that represent real-world system components through the use of preconstructed component libraries. There are many modeling tools available, and the best tool may change depending on application requirements. To create an offline, or model-in-the-loop (MIL), test of the entire control system, a common integration platform should be used to connect models created using multiple simulation tools. MIL tests validate control algorithms against a plant model before the algorithms are deployed to an ECU.
HIL testing reduces physical testing time and broadens embedded software test coverage by simulating the world around an ECU using a real-time test system. It can cover a much wider range of environmental conditions than would otherwise be possible or practical, and tests can often be performed with a fraction of the cost of physical tests. During HIL testing, real-world conditions are simulated through the use of models and test scripts that are deployed to the HIL test system. Test engineers are able to perform testing earlier in development and easily repeat tests for a variety of conditions to produce higher quality ECUs in less time than would otherwise be possible. For example, combines can be tested for a variety of harvest conditions regardless of whether there are actual crops available. In addition to testing multiple individual ECUs, HIL test systems can scale to test entire networks of ECUs simultaneously to validate an entire embedded system.
While model-based design and HIL testing enable engineers to create and test embedded software more efficiently than ever before, these practices alone will not be enough to keep up with the explosive growth of embedded software as the complexity of off-highway vehicles continues to evolve.
Different phases of embedded software validation exist independently, with no connection to any other tests. For example, an MIL test will include a user interface, stimulus profiles, data analysis algorithms, and test result reports. These same test components will often be completely redeveloped when the embedded software needs to be tested in a real-time environment for HIL testing. The re-creation of test components results in process inefficiencies, and these inefficiencies provide opportunities for process optimization.
Re-creating test components often includes implementing a new method of data analysis. This creates an inconsistency in the way that engineers look at test results. Data must be converted to compare results from different types of tests. This additional process adds inefficiency, and it introduces the potential for conversion errors, which puts embedded software quality at risk.
Test component reuse will help developers meet the challenges of growing embedded software. The foundation of this practice has been seen in the way that models are used. There is a great deal of development effort and investment into developing simulation models, and because of this investment, it is a widely accepted practice to reuse simulation models throughout embedded software development whenever possible to maximize efficiency.
While models are the most prominent example of test component reuse, this principle can be extended and applied to other components of embedded software test systems. Test profiles, user interfaces, and data processing and analysis are all components that have the potential to be created and reused throughout embedded software development.
By reusing test components, developers can standardize the way they stimulate, visualize, and analyze data, regardless of the development stage. Tests can be translated throughout development so there is no need to re-create tests when moving from MIL to HIL testing. The transition from MIL to HIL testing simply consists of replacing the control model with hardware I/O and the real ECU. All other components in the test system remain the same. For example, a load profile that represents a winding road will remain the same in both MIL and HIL testing. This load profile can be used to test the simulated control system during MIL testing and it can be reused to test the ECU during HIL testing. Should the desired load profile change, that change must only be created once, and that change will propagate from MIL testing to HIL testing.
An additional benefit of test consistency is that users can easily perform regression testing if ECU software changes late in the development cycle. When making changes to existing control algorithms, developers can perform regression testing without additional code conversion or test system modification.
Reuse of test components requires a real-time testing platform that can interact with a variety of simulation modeling environments and can easily integrate real-world I/O. National Instruments' VeriStand software is one such platform suited for these types of real-time testing applications. Nearly all test components can be re-used, so the transition from simulation-only MIL testing to hardware-based HIL testing can be done by simply changing the mapping of the signals from within an NI VeriStand configuration.
Nick Keel, Product Manager–NI VeriStand, National Instruments, wrote this article for SAE Off-Highway Engineering.