Vehicle Control Unit Logic in Stateflow: Modes, Faults and Interlocks

The problem

The vehicle control unit decides when the high-voltage system powers up, which drive mode is active, what the motor is allowed to do and how the vehicle reacts to faults. Much of this is state logic rather than continuous control, and errors in it cause dangerous behaviour such as closing contactors without pre-charge. Stateflow is the standard tool for modelling and testing such logic before code is written.

Objectives

• Specify VCU states, inputs, outputs and transitions from a written requirement list.
• Model power-up with pre-charge, drive modes and shutdown in Stateflow.
• Add fault detection, fault reaction and limp-home behaviour.
• Build a test harness that exercises each requirement.
• Measure decision coverage of the chart.

What you need

Key concepts

Pre-charge

Before the main contactor closes, the DC-link capacitor is charged through a resistor and a pre-charge contactor. Closing the main contactor straight onto an empty capacitor would cause a large inrush current.

Hierarchical and parallel states

A Stateflow chart can nest states and run parallel regions at once, so power management, drive mode and fault management can each be modelled cleanly.

Limp-home

A reduced-capability mode after a non-critical fault, such as limited torque and speed, so the driver can reach a safe place instead of being stranded.

Requirements-based testing

Each test checks one requirement, and every requirement has at least one test. Coverage measurement then shows which parts of the logic were never exercised.

Step-by-step guide

1. 1

   Write the requirements

   Write 20–30 numbered requirements in a spreadsheet. Examples: the main contactor shall close only when DC-link voltage exceeds 95 per cent of battery voltage within 2 s of pre-charge start; drive mode shall only be entered when the brake is pressed and the gear selector moves from Park; a battery over-temperature warning shall limit torque to 50 per cent; an insulation fault shall open contactors. Include inputs, outputs and timing.

   Checkpoint: A numbered requirement list with a measurable condition in each.

2. 2

   Define the interface

   List chart inputs (key position, brake, gear selector, pedal position, DC-link voltage, battery voltage, fault flags from BMS and motor controller, vehicle speed) and outputs (pre-charge contactor, main contactor, torque limit, drive mode, warning lamps). Create Simulink buses and a data dictionary or workspace definitions with types and ranges. Give each signal a unit, a data type and a valid range. Add a sample time for the chart, for example 10 ms, which is typical for vehicle supervisory logic.

   Checkpoint: An interface table and bus objects that the chart and harness both use.

3. 3

   Model the power states

   Create a state hierarchy: Off, PreCharge, HVReady, Shutdown. In PreCharge, close the pre-charge contactor, wait until DC-link voltage exceeds 95 per cent of battery voltage, then close the main contactor and open the pre-charge contactor. Use after(2,sec) to trap a pre-charge timeout and go to a fault state. Model the pre-charge circuit as a resistor in series with the DC-link capacitor so the voltage rise is realistic. Check that a disconnected pre-charge resistor in a test causes a timeout fault.

   Checkpoint: Animated simulation shows Off to PreCharge to HVReady with contactor outputs in the correct order.

4. 4

   Model drive modes

   In a parallel region active in HVReady, create Park, Neutral, Drive and Reverse states, with Eco and Sport sub-states inside Drive setting different torque maps. Guard transitions with brake and low vehicle speed conditions as in the requirements. Add a simple pre-charge circuit model (resistor and capacitor) and a vehicle speed signal so the logic sees realistic inputs. Use enumerated data types for gear and mode so the logic is readable and the logged signals are easy to plot.

   Checkpoint: Gear changes are only accepted under the specified brake and speed conditions.

5. 5

   Add the fault manager

   Add a third parallel region with states Normal, Warning, LimpHome and Shutdown. Classify faults by severity in a truth table: warnings reduce torque, limp-home caps speed and torque, critical faults open contactors. Add debouncing with temporal logic so a single noisy sample does not trigger a fault. Make fault states latch until a key cycle. Keep the fault severity table in one place so it can be reviewed easily against the requirements.

   Checkpoint: Injecting each fault type produces the specified reaction, and a short glitch shorter than the debounce time is ignored.

6. 6

   Build the test harness

   Create a harness model with Signal Editor scenarios or Test Sequence blocks for each requirement: normal start-up, pre-charge timeout, gear change rejected while moving, each fault class and key-off shutdown. Add assessments, either Test Assessment blocks or MATLAB checks on logged outputs, that compare outputs with expected values and timings. Keep the harness separate from the design model so the design is not changed for testing. Give each test the number of the requirement it checks so traceability is clear in the results.

   Checkpoint: Each requirement has at least one scenario with a pass or fail assessment.

7. 7

   Run tests and fix defects

   Run all tests with Test Manager or a sim() script. Record failures, find the cause in the chart and fix it. Common defects include missing guards, transitions that fire in the wrong order and faults that do not latch. Rerun the full set after each fix to catch regressions. Record each defect with its symptom, cause and fix in a simple log. This shows the value of the test harness and is useful material for the report and viva.

   Checkpoint: All tests pass, with a log of defects found and fixed.

8. 8

   Measure coverage

   Enable decision coverage with Simulink Coverage, or log transition firings manually, and run the full test set. Identify transitions and conditions never exercised. Either add tests for them or remove unreachable logic. Aim for full decision coverage of the chart. Explain each uncovered item in the report. Some may be defensive transitions that cannot be reached in normal use; state why they are kept, or remove them. Rerun the full test set after any change and confirm that coverage did not fall.

   Checkpoint: A coverage report with every decision covered or each gap justified.

9. 9

   Report

   Present the requirement list, the chart with its parallel regions, the test matrix linking each requirement to tests, defects found and the coverage result. Discuss how this would map to embedded code and to functional safety processes. State that this is a model of supervisory logic, not a certified safety design. Include a short section on what would change for a real vehicle, such as more fault types, communication timeouts and diagnostics.

   Checkpoint: A report with a requirement-to-test traceability table and coverage summary.

Testing & validation

• Every requirement linked to at least one passing test.
• Contactor sequencing never closes the main contactor before pre-charge completes in any test.
• Fault reactions and debouncing as specified.
• Decision coverage reported for the chart.

Expected results

A Stateflow VCU model with power, drive-mode and fault-management regions, verified by a requirement-based test harness with full traceability and coverage results.

Take it further

• Generate C code with Embedded Coder and run software-in-the-loop tests.
• Add regenerative braking blending logic.
• Use Requirements Toolbox to link requirements directly to chart elements.
• Prove key safety properties with Simulink Design Verifier.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.