Model-in-the-Loop Testing of a VCU with Simulink Test

The problem

A VCU decides how much torque the motor should deliver based on pedal inputs, gear selection, faults and limits. Errors in this logic cause unintended acceleration or loss of drive. Testing the model before any code is generated, known as model-in-the-loop (MIL) testing, catches these errors early when they are cheapest to fix, and Simulink Test is the standard tool for organising such tests.

Objectives

• Model VCU torque arbitration with throttle, brake override, drive modes and derating.
• Write testable requirements for the VCU.
• Create test harnesses and Test Sequence blocks for each requirement.
• Add assessments that pass or fail automatically.
• Run the suite from the Test Manager and report results.

What you need

Key concepts

Model-in-the-loop

Testing the controller model in simulation, with inputs and expected behaviour defined by tests, before code is generated.

Test harness

A separate model that contains the component under test plus input sources and checks, so tests do not clutter the design model.

Test Sequence block

A table of steps, each setting inputs and moving to the next step when a condition or time is met, which makes multi-step scenarios easy to read.

Brake override

A safety rule that if throttle and brake are pressed together, brake wins and drive torque is cut, guarding against stuck-throttle scenarios.

Step-by-step guide

1. 1

   Write VCU requirements

   Write about ten numbered requirements with example values: torque request = throttle map × maximum torque in Drive; negative in Reverse limited to 30 per cent; zero in Park and Neutral; brake override cuts torque to zero within 100 ms if both pedals exceed 10 per cent; torque derated linearly from 100 per cent at 70 °C to 0 at 90 °C motor temperature; mode change from Park to Drive only with brake pressed and speed below 1 km/h.

   Checkpoint: A requirement table where each row is specific enough to write a pass/fail test.

2. 2

   Model the VCU

   Build the VCU as a subsystem at a 10 ms sample time. Use a Stateflow chart for gear modes, a 1-D Lookup Table for the throttle map, a separate brake-override block, a derating lookup on temperature and a final Saturation. Keep inputs and outputs as named bus signals so tests can set them clearly. Use a fixed-step discrete solver. Name every signal clearly, for example ThrottlePct and MotorTempC, so test steps and assessments read like the requirement text.

   Checkpoint: The model updates without errors and a quick manual simulation gives positive torque in Drive with throttle pressed.

3. 3

   Create a test harness

   Right-click the VCU subsystem and create a test harness using Simulink Test. Choose a Test Sequence block as the source so the harness opens with an editable step table. The harness keeps the design model clean and stays linked, so changes to the VCU are picked up automatically. Choose a harness that keeps the component under test as a model reference or subsystem, and set its sample time to match the VCU, so test timing behaves exactly as in the design model.

   Checkpoint: A harness that opens from the design model's harness badge and simulates without errors.

4. 4

   Write the first test sequence

   For the Park-to-Drive requirement, write steps: start in Park at zero speed; request Drive without brake (expect Park to remain); press brake and request Drive (expect Drive); release brake and press throttle (expect positive torque). Use transition conditions such as after(0.5, sec). Each step sets inputs only, so the sequence reads like a test procedure. Add a short description to each step stating its purpose, so a reviewer can read the sequence as a test procedure without opening the model.

   Checkpoint: The test sequence runs and the logged gear mode follows the expected pattern in the Simulation Data Inspector.

5. 5

   Add assessments

   Add a Test Assessment block, or use verify() statements in the sequence, for each expected behaviour, for example verify(gear == Drive) after the brake-pressed step, and a temporal assessment that torque reaches zero within 100 ms of brake override starting. Assessments turn a plot you would inspect by eye into a pass or fail that can be rerun automatically. Keep assessments separate from input steps where possible, so the same checks can be reused when the input scenario changes.

   Checkpoint: The test reports pass, and deliberately breaking the VCU, for example removing the brake condition, makes it fail.

6. 6

   Cover all requirements

   Create test cases for every requirement in the Test Manager, each linked to a harness and a test sequence scenario. Include boundary values: pedal at exactly 10 per cent, temperature at 70 and 90 °C, speed at 1 km/h. Include combined cases, such as brake override during derating. Group them into a test suite. Give each test case a name that starts with its requirement number, so reports and coverage of requirements can be read at a glance.

   Checkpoint: A test suite in the Test Manager with at least one test case per requirement.

7. 7

   Run the suite and fix failures

   Run the whole suite from the Test Manager. Investigate each failure from the result's logged signals. Decide whether the model or the test is wrong by going back to the requirement wording. Record each defect found, its cause and fix. Finding real defects is the point, not a sign of failure. Rerun the whole suite after every fix, not only the failing test, so a change that repairs one requirement does not silently break another one.

   Checkpoint: All tests pass after fixes, with a defect log of what was found.

8. 8

   Add baseline and equivalence tests

   Create a baseline test that stores outputs for a standard drive scenario, so future changes are compared with it and any difference is flagged. This protects against regressions when the VCU is changed. Make a deliberate small change to the throttle map and confirm the baseline test catches it. Store the baseline data with the test file under version control, and update it only through a documented review when an intended change alters the outputs.

   Checkpoint: The baseline test fails after the deliberate change and passes after it is reverted.

9. 9

   Generate the report

   Use the Test Manager's report generation to produce a PDF or HTML report with results, plots and assessments for every test case. Check that each requirement number appears in the test-case names or descriptions so a reviewer can trace them. Discuss which requirements were hardest to test and why. Include the MATLAB version and model version in the report header so results can be tied to the exact model that was tested.

   Checkpoint: A generated test report listing every test case with its result.

10. 10

    Write up

    Present the VCU requirements, model, harness design, test strategy (normal, boundary and combined cases), defects found and final results. State the limitations: MIL only, no plant model in the loop for closed-loop driving, and example values. Suggest how the same tests would be reused for SIL and PIL once code is generated. Include a summary table of test counts, pass rates and defects found per requirement, so the effort and its outcome are clear to the examiner.

    Checkpoint: A report with a requirement-to-test table and the generated test report attached.

Testing & validation

• At least one passing test case per requirement.
• Boundary-value tests at every threshold.
• Mutation check: a deliberate defect makes the relevant test fail.
• Baseline regression test catches an unintended change.

Expected results

A VCU model with a complete MIL test suite in Simulink Test, covering every requirement with automatic assessments, a defect log and a generated test report.

Take it further

• Link requirements and tests with Requirements Toolbox.
• Measure model coverage with Simulink Coverage and add tests for gaps.
• Add a vehicle plant model for closed-loop scenario tests.
• Rerun the suite as SIL after code generation.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.