Too often test data is captured in a form that requires the use of a particular test product. You become more tied to that product with every test case that you write. In addition, you severely limit your ability to leverage test vectors throughout your product development life cycle, or from product to product. You need a level of abstraction between your test cases and the test tools, and you need a way to map your test vectors into the form accepted by each test tool. The MxSuite achieves this with a Virtual Wiring Harness (also referred to as a Test Harness or just the Harness).
The Harness, like a real wiring harness, provides connectivity, and again, like a real wiring harness, the Harness will have Connectors. The Harness Connectors connect at one end to MxVDev and at the other to the SUT.
The MxVDev Harness, unlike a regular harness, can transform signals before they arrive at their destination. From simple scaling changes or interpolation tables to complex image manipulation, or signal processing functions, it is easy to configure the Harness to deliver signals in the form that they are needed.
The Harness is used to stream test data between MxVDev, the Transforms, and the SUT. Also it enables interconnection between two or more SUTs for co-simulation.
•Deliver inputs to a particular SUT as they are generated from MxVDev
•Capture outputs from the SUT and deliver them back to MxVDev to be checked and displayed
•In the case of SIL testing, the Test Harness enables you to invoke function calls exposed by the SUT. It also enables you to capture information from 'callbacks' generated by the SUT.
•In the case of HIL testing, the Test Harness allows you to perform general test setup activities such as initializing test equipment.
The key benefit is that test cases can now be coupled very closely to requirements and have little to do with where the tests are executed. Consequently other benefits include:
•Portability - Tests, or at least parts of tests that are created for Unit Testing or Integration Testing can be reused in System Testing. The same tests can then be applied to:
oA Model (such as Simulink)
oA Software-In-The-Loop SUT for testing on a PC or on a target microcontroller
oAny Hardware-in-the-Loop (HIL) tester for a controller module
•Maintainability - Tests that are abstracted from the test environment (such as dSPACE or NI for HIL, or Matlab/Simulink for MIL) are easier to understand and change. They will only change when the requirement changes. A systems engineer can update test cases without knowledge of the test tools.
•Productivity - Because the tests are independent of the environment in which they will be executed, tests can be designed with knowledge only of the requirements of the system. In many cases MxVDev can be used to capture Use Cases and Requirements. One specification can be both the requirement and the test specification.
•Communication - Tests that are independent of the test environment. This means that anyone with knowledge of the system that we are testing can view all test cases in one common format.
•Multi SUT testing - Connect one or more SUTs to the harness allowing you to perform system level testing with several SUTs.
•Plant Model - Configure a Plant Model in the harness to work in conjunction with the SUT while it is being tested.
In simple cases, the Harness is created automatically, such as for Matlab/Simulink. In other cases, you create and configure your own Harnesses. In the case of Hardware-in-the-Loop testing there is a hardware component to the Harness.