The third unit of our car model: the brakes. Pedal position in, brake force and brake light out, with the short delay of a real hydraulic system. Specified in plain words and verified like a software unit: model review, static analysis, five tests, condition coverage. Every report linked as the tool wrote it.
See the work products ↓6 min read · all reports open in a browser, no MATLAB needed
Three tools · EverView · EverCheck · EverTest
The powertrain pushes the car, the driving resistances hold it back. The brakes are the driver’s side of the balance. Like the engine, they need a moment to deliver what the pedal asks for, so this unit has a state, and its tests look at sequences of steps instead of single values. Same workflow, same five work products, and this time a condition to cover but no decision.
| Step | Work product | Tool | ISO 26262 | Result |
|---|---|---|---|---|
| 1 | Unit Specification | Word | Part 8, Clause 9 — verification environment specified | 5 requirements |
| 2 | WEB_BRK.html — model view | EverView | Part 6, Clause 8 — design review input | 13 blocks, 5 requirement tags |
| 3 | SMA_BRK.html — static analysis | EverCheck | Part 6, Clause 8 — verification of unit design | 54 / 54 checks passed |
| 4 | VER_BRK.html — test results | EverTest | Part 8, Clause 9 — verification executed and evaluated | 5 / 5 passed, 5 / 5 requirements, 6 / 6 design ranges |
| 5 | COV_BRK.html — structural coverage | EverTest | Part 6, Clause 9 — coverage metrics | Condition 2 / 2, no decisions |
All reports are self-contained HTML files. They open offline, without MATLAB, and are the files that document the test environment in the safety case.
Next: The powertrain pushes, the resistances hold back, the brakes slow down. The last unit adds the three forces up and turns them into speed and distance, limited by the grip of the road.
Press the pedal, and three things happen. The pedal asks for a share of the strongest braking the car can do. The hydraulics need a moment to deliver it. And the brake light comes on at once, before any force is there. The unit models exactly these three things, nothing more.
| Effect | Where it comes from | How it behaves | Our car |
|---|---|---|---|
| Pedal share | The pedal position sets the pressure in the brake lines | Half pedal, half force: a straight line from 0 to the maximum | 15 000 N at full pedal: 10 m/s², about 1 g |
| Delay | Fluid has to move and pads have to press before the force is there | The force closes a fixed share of the remaining gap in every cycle; it never overshoots | 20 % per 20 ms cycle: 67 % after 0.1 s, 95 % after 0.28 s |
| Brake light | A switch at the pedal, not a pressure sensor | On in the same cycle the pedal moves, off in the same cycle it is released | Any pedal position above 0 % |
The car is the one from the previous pages: 1500 kg, and tyres that can transmit about the weight of the car as brake force on dry asphalt. Three numbers follow:
Figure 1 · Left: the brake force after a full-pedal step, computed from the specification. Right: what the delay costs in stopping distance.
Why a delay at all. Without it, the brake force would jump from 0 to 15 kN within one 20 ms cycle. Real brakes cannot do that, and a controller tested against such a brake would learn the wrong thing about the car. A first-order lag with a time constant of 0.1 s is the simplest model that gets the build-up right. It costs four blocks.
The plan. The car is built in steps, and each step is verified before the next one is added: the powertrain, the driving resistances, the brakes (this page), the longitudinal motion. Then the loop is closed with the cruise controller.
In the closed loop the brake pedal is how the driver takes over from the cruise controller. The brake light is the signal that tells the controller to let go. If the light came one cycle late, or the force built up too fast, the controller would be tested against a car that does not exist, and it would pass.
The delay is a state. A state can be initialized wrong, can drift, can overshoot. None of that shows up in a single-step check. The tests on this page look at sequences, and the specification says what the sequence must look like, number by number.
That is why ISO 26262-8 asks for a specified verification environment (Clause 9) and for confidence in every tool whose error could let a fault go undetected (Clause 11). The powertrain page explains the argument in full. The full run for this unit takes about ten seconds.
Two pages in the same layout as for the other units: the interface table and the requirements, written so that a reader without an engineering degree can follow them.
| Name | Type | Data type | Min | Max | Unit | Description |
|---|---|---|---|---|---|---|
cmdBrake | Input | single | 0 | 100 | % | Brake pedal position |
fBrake | Output | single | 0 | 15000 | N | Brake force at the wheels, positive slows the car |
brakeLight | Output | boolean | 0 | 1 | – | Brake light, on while the pedal is pressed |
F_BRAKE_MAX | Parameter | single | 15000 | 15000 | N | Brake force at full pedal |
BRK_TAU | Parameter | single | 0.1 | 0.1 | s | Time constant of the brake build-up |
TS | Parameter | single | 0.02 | 0.02 | s | Sample time |
F_BRAKE_MAX.BRK_TAU: it starts to move one cycle after the request changes, covers 67.2 % of a step within BRK_TAU, and never goes past the request.F_BRAKE_MAX.What matters: BRK-3 is written as numbers, not as a formula. In every cycle the force moves by TS / BRK_TAU, that is 20 %, of the distance to the request. After a full-pedal step that gives 3000, 5400, 7320, 8856 and 10 084.8 N: 67.2 % after five cycles, which is BRK_TAU. A reviewer can check these five numbers with a pocket calculator, and the test case does exactly that. The three parameters have Min equal to Max: one car, not a family of cars.
Thirteen blocks in two lines. The top line turns the pedal into a requested force and runs it through the lag: the difference to the current force, times the lag factor TS / BRK_TAU, added to the current force, stored in a unit delay. The unit delay is the state; its output is the brake force. The bottom line compares the pedal with zero for the light.
Figure 2 · The unit in EverView. Signal names, types and ranges on every line; one REQ tag per requirement on the block that implements it.
REQ: BRK-2 on the product that scales the pedal, BRK-3 on the sum that closes the gap, BRK-1 on the unit delay with its initial value 0, BRK-5 on the output, BRK-4 on the comparison. EverCheck and EverTest read the same tags.TS / BRK_TAU is a division of two constants in the model, not a magic number 0.2: change the sample time or the time constant, and the factor follows.cmdBrake > 0 is the only place where the unit asks a question. It drives the light directly: no switch, no decision, one condition for the coverage report.The same 54 checks as for the other units, run before any test effort is spent: interface complete and consistent, only approved block types, explicit initialization, unique requirement IDs, requirement traceability, model configuration, no warnings during model update. Result: 54 of 54 passed.
Figure 3 · EverCheck summary: 13 blocks, operator complexity 7, 54 / 54.
This unit remembers. Its output depends on what the pedal did before, so a test is a short story: press, hold, release, and look at every step in between. Five test cases, one per requirement, 815 time steps in total. Every expected value is one line of arithmetic from the specification.
| Test case | Situation | What we expect | REQ |
|---|---|---|---|
| TC1_Start | Full pedal from the first cycle, held for 0.78 s | 0 N in the first cycle, then 3000, 5400, 7320 N … up to 14 997.5 N | BRK-1 |
| TC2_PedalShare | 25, 50, 75, 100 and 0 % pedal, each held for 2 s | 3750, 7500, 11 250, 15 000, 0 N at the end of each hold | BRK-2 |
| TC3_Delay | Full pedal for seven cycles, then released | Force moves one cycle late: 3000, 5400, 7320, 8856, 10 084.8 N; after release it loses 20 % per cycle | BRK-3 |
| TC4_BrakeLight | Pedal 0.5 %, 100 %, 0 %, 1 %, 0 %, two cycles each | Light on, on, off, on, off in the same cycles; the force lags behind | BRK-4 |
| TC5_Range | No pedal for 2 s, full pedal for 2 s, released for 2 s | 0 N, 15 000 N reached and never passed, back to 0 N | BRK-5 |
? as reference. Each recorded value is compared with the hand-computed one; only then is it accepted. Largest difference: 0.002 N at 15 kN, the rounding of single precision. The allowed difference is 0.01 N.> pedal released becomes a marker line in the plot. The expected value sits in the same cell after //, where the reviewer needs it.This is the EverView export of the test harness itself, live in the frame: the brake unit between the EverTest source and sink, with the signal names and ranges of the interface. Double-click into BRK to walk the model, click a block for its properties. Exactly what a reviewer does, with no licence.
Open full screen in a new tab ↗
Open the live harnessFull screen in a new tab. Walk into the unit, click a block for its properties. Best on a tablet or desktop.Open live export ↗
LIVE EVERVIEW EXPORT · BRK_harness · NAVIGATE · SEARCH · PROPERTIES
One run executes the five cases in the harness and writes the verification report. Result: 5 of 5 passed, all five requirements covered, all six design ranges reached.
Figure 4 · Requirements traceability matrix: one test case per requirement, all passed.
Figure 5 · TC3_Delay in the report: the force starts one cycle after the pedal, climbs in shrinking steps, and fades the same way after the release.
Figure 6 · The test data of TC3: the hand-computed reference next to the recorded value, every step green.
The resistances had a switch. The brakes have none: the comparison cmdBrake > 0 feeds the light directly, so there is a condition to cover but no decision, and the cyclomatic complexity is 1. The coverage report shows both outcomes of the condition: true in 1106 steps, false in 746.
Figure 7 · COV_BRK: condition 2 / 2 on cmdBrake > 0; decision and MC/DC not applicable.
Figure 8 · TC4_BrakeLight: the test that was written for BRK-4 and also takes the condition both ways. Light above, pedal below, marker lines at every pedal change.
The argument is the same as for the powertrain and the resistances. EverCheck and EverTest bring their own TCL 3 qualification kit. The plant model is a tool we build ourselves, and its confidence comes from the work shown here: a specification, a model that passed the product’s static checks, tests against values computed in advance, coverage of every condition, and reports that record every version. With this page, three of the four plant units have that record.
Because without it the car would stop like a wall. The controller under test would see a brake that acts within 20 ms, and whatever it learned from that would be wrong on the road. A time constant of 0.1 s is a plain assumption for a hydraulic brake; it is written in the specification, and it costs four blocks.
Because that is how a car does it: the brake light switch sits at the pedal. The light is on while the force is still building up and off while it is still fading. For the cruise controller that is the right order: the signal to let go arrives before the car slows down.
A first-order lag closes 20 % of the remaining gap per cycle, so a gap always remains. After 2 s it is 0.002 N, within the tolerance of 0.01 N, and EverTest counts the limit as reached. The limit itself is never passed: that is what BRK-5 says, and TC5 checks it on every step.
The force moves towards the request by a share of the distance, and the request is at most F_BRAKE_MAX. It can never go past a value it only approaches. A limiter would hide a bug instead of preventing one; the tests prove that none is needed.
The last plant unit, Making the Car Move, adds up push, resistance and brake force and turns them into speed. With it the car is complete and the loop is closed with the cruise controller.
Download the trial, take one plant unit, and produce the five work products for it. Or bring one unit to a half-day working session — your model, your requirements, your reports at the end.
⬇ Download Free Trial Talk to us