Requirements-Based Design and Traceability for an EV Controller

The problem

In automotive projects, engineers must show that every requirement is implemented and tested, and that every piece of the design exists for a reason. Keeping this in spreadsheets drifts out of date as the model changes. Requirements Toolbox keeps requirements, design and tests linked inside the Simulink environment and shows which requirements are not yet implemented or verified.

Objectives

• Write structured requirements for a speed-limiter controller.
• Build the controller model in Simulink.
• Link requirements to model elements and to test cases.
• Use the traceability matrix and status views to find gaps.
• Handle a requirement change and track its impact.

What you need

Key concepts

Traceability

Links from each requirement to the design elements that implement it and the tests that verify it, in both directions, so you can answer 'why does this block exist?' and 'is this requirement tested?'.

Implementation status

A Requirements Toolbox view showing which requirements have links to design elements and which do not.

Verification status

Shows whether linked tests have run and passed, failed or are missing, updated when the test results are loaded.

Change impact

When a requirement changes, its links are flagged so the linked blocks and tests can be reviewed and updated.

Step-by-step guide

1. 1

   Choose and describe the function

   Pick an EV speed limiter: the driver sets a limit and the controller caps motor torque so speed does not exceed it, except when the driver presses the throttle fully (kick-down override). Write a one-page functional description with inputs (speed, throttle, set and cancel buttons, brake), outputs (torque limit, status) and example values such as a 10 km/h minimum limit and a 2 km/h tolerance.

   Checkpoint: A functional description that names every input, output and mode.

2. 2

   Author requirements

   Open the Requirements Editor and create a requirement set with about 12 requirements: activation conditions, speed-holding tolerance, kick-down override, cancel on brake, display status and fault behaviour. Give each a summary, a clear 'shall' statement and a rationale. Use a hierarchy: top-level function, then detailed requirements. Avoid vague words like 'fast' or 'smooth'. Ask a classmate to review the set for ambiguity and missing cases before modelling begins, and record the review comments and changes made.

   Checkpoint: A requirement set where each requirement is testable and has a rationale.

3. 3

   Build the controller model

   Model the controller at 10 ms: a Stateflow chart for Off, Standby, Active and Override modes, and a PI controller that reduces a torque limit as speed approaches the set limit, with anti-windup. Add a simple vehicle plant (mass, road load, motor torque) for closed-loop simulation. Keep the controller in its own subsystem. Keep each requirement's logic in an identifiable part of the model, such as a named subsystem or chart state, so links later point to clear elements.

   Checkpoint: In a closed-loop simulation with full throttle and a 40 km/h limit, speed settles at the limit within the specified tolerance.

4. 4

   Link requirements to design

   Select a block or chart state, then right-click the requirement in the editor and create an 'Implements' link, or drag the requirement onto the block. Link each detailed requirement to the blocks or states that implement it. Turn on requirement highlighting in the model to see linked and unlinked elements. Use consistent link types throughout, for example Implements for design and Verifies for tests, so the status views and matrix are reliable.

   Checkpoint: Model highlighting shows linked elements, and the editor shows a link for each implemented requirement.

5. 5

   Check implementation status

   In the Requirements Editor, enable the Implementation Status column. Requirements with no implementing links show as unimplemented. Find the gaps and either implement them, link existing elements or recognise that a requirement is not handled. Also look the other way: find model elements with no requirement and decide whether they are needed. Record each orphan element found and the decision taken, because this review often reveals behaviour that was added without a requirement.

   Checkpoint: Implementation status at 100 per cent, or each gap listed with its reason.

6. 6

   Write and link tests

   In Simulink Test, create a harness and test cases for each requirement: activation, holding speed on a downhill, kick-down, cancel on brake. Add assessments with verify statements. Link each test case to its requirement with a 'Verifies' link. Some requirements need more than one test case. Include boundary tests at each threshold, such as speed exactly at the limit plus tolerance, and name each test case after its requirement so the links are easy to check.

   Checkpoint: Every requirement has at least one linked test case.

7. 7

   Run tests and update verification status

   Run the test suite from the Test Manager, then enable the Verification Status column in the Requirements Editor and refresh it. Passing, failing and unrun tests show for each requirement. Fix failures and rerun. Show a verification status screenshot before and after fixes. If a requirement shows as unverified despite a passing test, check that the link type is Verifies and that the results file is loaded, since status depends on both being correct.

   Checkpoint: Verification status shows all requirements verified with passing tests.

8. 8

   Use the traceability matrix

   Generate a Traceability Matrix with requirements on one axis and model elements or tests on the other. Use it in a review: look for requirements linked to many unrelated blocks, which may be too broad, and tests that verify many requirements, which may be weak. Export it for the report. Use the matrix filters to show only unlinked items, which is the quickest way to find gaps in a larger requirement set.

   Checkpoint: An exported traceability matrix with any review findings noted.

9. 9

   Make a requirement change

   Change one requirement, for example tighten the speed tolerance from 2 to 1 km/h. Observe that links are flagged as changed. Review and update the linked blocks (controller gains) and tests (assessment limits), then clear the change flags. Rerun tests. This shows how traceability supports controlled change. Record the change with its reason, the elements reviewed and the tests rerun, as you would for a change request in an industrial project.

   Checkpoint: The changed requirement's links are flagged, then cleared after updates, with tests passing at the new tolerance.

10. 10

    Report

    Present the function, requirements, model, link strategy, implementation and verification status, the matrix, the change exercise and lessons learnt. Note that this follows the style of automotive processes but is not a certified process. State limitations such as a simple plant and example values. Attach the requirement set, model and test file so a reviewer can open the links and check the traceability themselves, rather than relying only on screenshots.

    Checkpoint: A report with status screenshots, the matrix and the change-impact record.

Testing & validation

• Implementation status shows every requirement linked to design elements.
• Verification status shows every requirement linked to passing tests.
• Model elements without requirements reviewed and justified or removed.
• Requirement change flagged, reviewed and closed with updated tests.

Expected results

A speed-limiter controller with a complete requirement set linked to design and tests in Requirements Toolbox, showing full implementation and verification status and a traced requirement change.

Take it further

• Import requirements from a Word or ReqIF document.
• Add Simulink Design Verifier property proofs linked to requirements.
• Extend to adaptive cruise control with a lead-vehicle model.
• Generate code and link it to requirements in the code report.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.