When designing a test harness you need to have in mind re-use of your test cases. Many of the tests that you create for use against a model, or for SIL testing, will be re-usable during HIL testing, but only if you plan ahead.
Your most important decisions are related to choosing the I/O interface to your SUT. Here is what you should keep in mind:
•Units - Try to select a set of native units. If you use SI units, convert all signals to SI units as soon as possible. The harness should transmit SI Units.
•Interface Connectors - Identify the available interfaces - When you look at how you will connect MxVDev to the SUT, identify the interfaces that are available. For example:
oSIL - We typically see a MicroController Abstraction Interface, and an Application Component Interface. (In the world of AUTOSAR these interfaces are very well defined.)
▪MicroController Abstraction Interface - Choosing this low level interface enables you to test (nearly) the complete controller functionality on the PC and give you tests that are highly portable to the HIL environment. For existing software, where the architecture is not clear, this is the easiest strategy.
▪Application Component Interface - This is good for testing feature by feature and often is chosen if the 'services layer' is not available for test. This approach is also good if some components are modeled and some are handcrafted in C.
oHIL - Often we are provided with a COM interface or an API to access some device drivers. We can also interface to HIL testers using files on disk.
•Partitioning - Logically partition your system for testing. Partition your system into Units, and test them independently (Unit Test). Test that the Units interact correctly (Integration Test). Test that the Units work together as a system. Using larger units usually results in better requirements, fewer interface connectors to consider, and test cases that are more comprehensible to Systems Engineers. However, ensure you can fully test each Unit from its interfaces.
•I/O - Identify Signals that are inputs and outputs to the chosen interface (Buttons, displays, bus messages, etc.). Note that you will be able to access many more Signals in the model and SIL environment but as a minimum you should include the signals that you can access during HIL testing. Start capturing information about your Signal choices in the project Signal Dictionary. Set up the Engineering Units and Scaling setting entries in the Signal Dictionary. Create a few sample test cases to examine your choice of Input and Output signals.
•Representation - Decide how you want to graphically represent the Signal in the MxVDev GUI. This is easy where the signal is an analog voltage, an On/Off value or a message. A little more thought is needed for some Signals. Consider the following three examples:
oSpecifying the input from a knob. Your choices may be to represent the input in the MxVDev GUI as:
▪An analog signal (showing angle of rotation), or
▪A pair of discrete signals (so that you can directly control the quadrature phase and duration).
oCapturing the output to a bit-mapped display. The output could be captured and compared as a bitmap, or we could perform some character recognition on the bitmap and display and compare recognized text in MxVDev.
oSpecifying the signal from a Remote Keyless Entry fob. If in the HIL environment you plan to use a real fob, then the MxVDev project may have four discrete Signals defined, one for each fob button. If in the HIL you plan to use RF transmission equipment, then you may define one message Signal in the MxVDev project.
Once you have an idea of how you want to represent and manipulate each of the input and output signals to/from the SUT, you can start creating the Test Harness.