EverCheck EverTest EverView Workflow Training Guide Pricing Download Free Trial ✉ support@everbits.com
ISO 26262 · Part 6 · Clauses 7–10

The Safe MBD Workflow —
The ISO 26262 Way

Your model com­piles. Can you ship it?

We fol­low Part 6 from ar­chi­tec­tural de­sign to in­te­gra­tion. You get a clear work­flow, the right work prod­ucts, and ev­i­dence that stands up in an audit.

⬇ Get Free Trial

All Fea­tures · No Credit Card

The ISO 26262 V-model with EverCheck, EverTest and EverView mapped to each stage ARCHITECTURE UNIT DESIGN CLAUSE 7 Architectural Design EverCheck CLAUSE 8 Unit Design & Implementation EverCheck CLAUSE 9 Unit Verification EverTest CLAUSE 10 Integration & Verification EverTest REVIEWS Independence I1 EverView Specification & Design (left arm) Verification & Integration (right arm) Verification reviews (I1)

THE ISO 26262-6 V-MODEL

MATLAB & Simulink Partner
What MBD Was Sup­posed to De­liver

Three Promises MBD Breaks —
Without a Plan #

Model-based de­sign prom­ises one source of truth, faster it­er­a­tion and higher qual­ity — but with­out a dis­ci­plined work­flow it qui­etly breaks all three, leav­ing the model and gen­er­ated code to dis­agree, bugs to sur­face late at in­te­gra­tion, and unchecked guide­lines to hide de­fects.

01

"One Source of Truth"

The model and the gen­er­ated code can dis­agree. With­out back-to-back test­ing, you have two sources, not one.

02

"Faster Iteration"

Catch­ing bugs at in­te­gra­tion takes ten times longer than catch­ing them at the model. Slow tests at the model mean slow ship­ping.

03

"Higher Quality"

A model with no en­forced guide­lines and no cov­er­age tar­gets is just a dif­fer­ent way of writ­ing buggy code.

The Foun­da­tion

No Tool Replaces
a Trained Engineer. #

Com­bin­ing Simulink, State­flow and ISO 26262 well is a skill — and our free self-paced video cour­ses give en­gi­neers a shared vo­cab­u­lary for safe model-based de­vel­op­ment, from MATLAB fun­da­men­tals to a qual­i­fi­able ver­i­fi­ca­tion work­flow.

Free Training on Model-Based Design →

Free · No reg­is­tra­tion · Open to ev­ery­one

The Map

One V. Three Tools.
Every Stage Covered. #

Read the stan­dard left to right. Every clause is a stage. Every stage has a tool.

The ISO 26262 V-model with EverCheck, EverTest and EverView mapped to each stage ARCHITECTURE UNIT DESIGN CLAUSE 7 Architectural Design EverCheck CLAUSE 8 Unit Design & Implementation EverCheck CLAUSE 9 Unit Verification EverTest CLAUSE 10 Integration & Verification EverTest REVIEWS Independence I1 EverView Specification & Design (left arm) Verification & Integration (right arm) Verification reviews (I1)

Fig­ure 1The ISO 26262-6 V-model, with EverCheck, EverTest and EverView mapped onto each clause.

Walk­ing the V

Four Stages, Four Clauses,
One Continuous Workflow #

Each stage has clear in­puts, clear out­puts, and the right tools for the job.

7CL.
Stage 1 · Ar­chi­tec­tural De­sign · Left arm

The model becomes the specification.

Clause 7 wants an ar­chi­tec­ture that is ver­i­fi­able, con­fig­urable and testable. In an MBD project, that ar­chi­tec­ture is a Simulink and State­flow model.

EverCheck makes sure it's a model a re­viewer can trust. Every sig­nal has a name, a type, a range, a unit. The hard­ware-soft­ware in­ter­face is fully de­fined.

Every re­quire­ment ID is an­no­tated in a for­mat the tool can check au­to­mat­i­cally. No trace­abil­ity spread­sheets, no re­view-by-eye.

HSI Checks Trace­abil­ity
Worked exampleThe cruise con­troller starts as a two-page spec­i­fi­ca­tion in plain words: in­ter­face table, three re­quire­ments with IDs, writ­ten so that a test case can be de­rived from each one. See the spec­i­fi­ca­tion → The car model around it is planned as four units, each with its own spec­i­fi­ca­tion. See the plan →

8CL.
Stage 2 · Unit De­sign & Im­ple­men­ta­tion · Left arm

Where guidelines turn models into code.

Clause 8 lists ten de­sign prin­ci­ples for soft­ware units. Most of them are about model hy­giene: one entry/exit, no dy­namic ob­jects, no im­plicit type con­ver­sions.

EverCheck en­forces them. MAAB and MISRA SLSF rule sets out of the box, project-spe­cific ex­ten­sions on top. The Run & Fix fea­ture cor­rects the vi­o­la­tions that have a known fix and flags the rest be­fore the de­vel­oper com­piles.

The re­sult: a well-de­fined sub­set of Simulink and State­flow that sim­pli­fies every later step — code gen­er­a­tion, struc­tural cov­er­age, for­mal in­spec­tion.

Run & Fix MAAB / MISRA
Worked example54 checks on the cruise con­troller be­fore the first test: in­ter­face, ap­proved blocks, ini­tial­iza­tion, re­quire­ment IDs, model con­fig­u­ra­tion. The re­port is one HTML file. See the static anal­y­sis → The same 54 checks run on every plant unit. RES: 54 / 54 → BRK: 54 / 54 → LON: 54 / 54 →

9CL.
Stage 3 · Unit Ver­i­fi­ca­tion · Right arm

100% coverage for requirements & structure.

Clause 9 sets one bar: every re­quire­ment ex­er­cised, every branch cov­ered. EverTest is built around that bar.

Test cases are or­ga­nized by re­quire­ment ID. The HTML ver­i­fi­ca­tion re­port com­bines test re­sults, trace­abil­ity, state­ment, branch and MCDC cov­er­age. The same test runs un­changed across MIL, SIL and PIL — the al­go­rithm proven in sim­u­la­tion is proven again on the tar­get.

EverTest also brings Test-Driven De­vel­op­ment into reach. En­gi­neers write the fail­ing test, build the fea­ture, watch it pass. The Clause 9 ev­i­dence be­comes a side-ef­fect of the de­sign loop.

Req-Based MIL/SIL/PIL
The Test-Driven Development inner loop with EverCheck and EverTest INPUT Requirement Requirement ID 1 · RED Failing test 2 · BUILD Model feature 3 · GREEN Test passes 4 · CHECK EverCheck fix TDD LOOP EverTest + EverCheck OUTPUT Verified unit + test cases

Fig­ure 2The TDD inner loop — tests first, model sec­ond.

Worked exampleTwelve test cases for three re­quire­ments, trace­abil­ity ma­trix, de­ci­sion cov­er­age 8 / 8 — and the run where the test suite caught a de­fect the green re­ports had missed. See the re­sults → One test case per re­quire­ment and the first de­ci­sion to cover in the plant model: RES cov­er­age →

10CL.
Stage 4 · In­te­gra­tion & Ver­i­fi­ca­tion · Right arm

Does the whole behave like the parts?

Clause 10 asks the harder ques­tion: do the ver­i­fied units be­have cor­rectly when wired to­gether, on the tar­get, against the ar­chi­tec­tural de­sign?

EverTest treats sub­sys­tems as atomic. It gen­er­ates har­nesses, warns when bound­aries are miss­ing, and sup­ports fault in­jec­tion to ex­er­cise the ar­chi­tec­tural safety mech­a­nisms.

For the back-to-back test, the same EverTest cases run on model, SIL and PIL. Nu­mer­i­cal equiv­a­lence be­comes a re­port, not a man­ual ex­er­cise.

Fault In­jec­tion Back-to-Back
Worked exampleThe in­te­gra­tion test of the cruise con­troller needs a car model. ISO 26262-8 asks for a spec­i­fied ver­i­fi­ca­tion en­vi­ron­ment and for con­fi­dence in every tool that feeds the test, so each plant unit is ver­i­fied like the prod­uct be­fore the loop is closed. Why a test tool is ver­i­fied → Unit 2: driv­ing re­sis­tances → Unit 3: brakes → Unit 4: lon­gi­tu­di­nal mo­tion →

I1ASIL D
Stage 5 · Ver­i­fi­ca­tion Re­views · Across the V

Review the model in a browser. Anywhere.

EverView turns any Simulink or State­flow model into a sin­gle self-con­tained HTML file. One click in ver­sion con­trol, one sec­ond to open.

No li­cense. No setup. Any­one with ac­cess opens the file in a browser.

Re­view­ers nav­i­gate, in­spect func­tion­al­ity, search for text pat­terns and add com­ments. Each set of com­ments saves to its own file; EverView merges them back. The au­thor keeps au­thor­ship. The re­viewer keeps in­de­pen­dence. The audit trail keeps both.

One HTML An­no­ta­tions
The independent review flow with EverView AUTHOR LANE Build & Check EverCheck Run & Fix Run Tests EverTest TDD Generate EverView single .html file Commit version control Request review HANDOVER REVIEWER LANE Open EverView browser, no license Inspect Model in EverView Annotate Model in EverView Send to Author no model edits Independence preserved ✓

Fig­ure 3The ver­i­fi­ca­tion re­view work­flow.

Worked exampleOpen the mod­els of the case stud­ies as the re­view­ers see them: one HTML file each, re­quire­ment tags on the blocks, no MATLAB. CCC.html → WEB_PWL.html → WEB_RES.html →

A con­tin­u­ous work­flow — from the first model to the last re­view. One toolchain. One audit trail.
Worked ex­am­ples

The workflow on real units, every report public #

Three case stud­ies walk the V with small, com­plete units: the cruise con­troller as the prod­uct, and the first two units of the car model it will be tested against. Each one pro­duces the same five work prod­ucts: spec­i­fi­ca­tion, EverView model view, EverCheck static anal­y­sis, EverTest re­sults with trace­abil­ity, and struc­tural cov­er­age. All re­ports are linked as the tools wrote them. They open in a browser, no MATLAB needed.

Case study 1 · Product

Cruise Control, Start to Finish

A dis­crete PI cruise con­troller taken through the whole work­flow — in­clud­ing the run where the test suite caught a de­fect the green re­ports had missed.

  • 3 re­quire­ments, 12 test cases
  • 54 / 54 static checks
  • 8 / 8 de­ci­sion cov­er­age
  • 5 re­ports, linked unedited
Read the case study →CCC_VER.htmlCCC_COV.html
Case study 2 · Test tool

The Engine, as a Test Tool

The pow­er­train of the car model: a plant unit built as the test en­vi­ron­ment for the con­troller and ver­i­fied like a soft­ware unit, as ISO 26262-8 asks for test tools.

  • 5 re­quire­ments, 5 driv­ing tests
  • 54 / 54 static checks
  • 3 / 3 de­sign ranges reached
  • 1 day study and ver­i­fi­ca­tion
Read the case study →VER_PWL.htmlSMA_PWL.html
Case study 3 · Test tool

What Slows a Car Down

The driv­ing re­sis­tances: air drag, rolling re­sis­tance and slope. One test case per re­quire­ment, the first de­ci­sion to cover, and the top speed of two units checked on paper.

  • 5 re­quire­ments, 5 test cases
  • 54 / 54 static checks
  • 2 / 2 de­ci­sion cov­er­age
  • ~10 s full run
Read the case study →VER_RES.htmlCOV_RES.html
Case study 4 · Test tool

Stopping the Car

The brakes: pedal share, a first-order lag and the brake light. A unit with a state, the delay spec­i­fied as five num­bers a re­viewer can check by hand, con­di­tion cov­er­age with­out a de­ci­sion.

  • 5 re­quire­ments, 5 test cases
  • 54 / 54 static checks
  • 2 / 2 con­di­tion cov­er­age
  • ~10 s full run
Read the case study →VER_BRK.htmlCOV_BRK.html
Case study 5 · Test tool

Making the Car Move

The lon­gi­tu­di­nal mo­tion: forces into speed and dis­tance, lim­ited by the grip of the road. Two states, three lim­its, and a drive of ten kilo­me­tres that reaches every limit of the in­ter­face.

  • 6 re­quire­ments, 6 test cases
  • 54 / 54 static checks
  • 6 / 6 de­ci­sion cov­er­age
  • ~15 s full run
Read the case study →VER_LON.htmlCOV_LON.html

The car model is com­plete. Next in the se­ries: the closed loop with the cruise con­troller.

Tool Qual­i­fi­ca­tion

Qualified Tools — Because the Audit Will Ask. #

A clean work­flow is not enough on its own. ISO 26262-8 Clause 11 re­quires you to demon­strate that the tools you used to pro­duce the safety case are them­selves trust­wor­thy.

All three tools are qual­i­fi­able. EverCheck and EverTest are qual­i­fi­able at TCL 3: each ships with a Safety Man­ual, a Qual­i­fi­ca­tion Kit and a val­i­da­tion test suite that you run in your own en­vi­ron­ment. EverView is qual­i­fied by re­view: its out­put is the model it­self, as one HTML file, and the re­viewer ver­i­fies what they see. No kit needed.

A tool you build your­self gets the same ques­tion. A plant model that feeds a closed-loop test is such a tool; the case stud­ies show how it earns its con­fi­dence: spec­i­fi­ca­tion, static checks, tests against ex­pected val­ues, and re­ports that record every ver­sion. Two tools, two ar­gu­ments →

ISO 26262 Safety Man­ual Qual­i­fi­ca­tion Kit
How tool qual­i­fi­ca­tion works →
Trusted Since 2012

Building MBD Verification Tools Since 2012 #

Over a decade of hands-on ex­pe­ri­ence in ISO 26262 model-based de­vel­op­ment.

14+ years Build­ing MBD ver­i­fi­ca­tion tools
ASIL D High­est in­tegrity level fully sup­ported
TCL 3 Qual­i­fi­ca­tion kits for EverCheck & EverTest
2 Tools EverCheck & EverTest, one toolchain
FAQ

Frequently Asked Questions #

An­swers based on the ISO 26262 work­flow — from why MBD needs one to which ASIL it's built for.

With­out a work­flow, MBD breaks the very prom­ises it makes. The model and the gen­er­ated code can dis­agree with­out back-to-back test­ing. Bugs caught at in­te­gra­tion cost ten times more than at the model. A model with no en­forced guide­lines and no cov­er­age tar­gets is just a dif­fer­ent way of writ­ing buggy code. A clear ver­i­fi­ca­tion work­flow turns MBD's prom­ise into au­ditable ev­i­dence.
EverCheck is a qual­i­fi­able static model anal­y­sis tool (TCL 3 kit in­cluded). It en­forces mod­el­ing guide­lines (MAAB, MISRA SLSF), re­quire­ments an­no­ta­tion for­mats, full HSI def­i­ni­tion, and sup­ports Run & Fix cor­rec­tion of com­mon vi­o­la­tions di­rectly in Simulink and State­flow.
EverTest is a qual­i­fi­able dy­namic ver­i­fi­ca­tion tool (TCL 3 kit in­cluded). It sup­ports re­quire­ments-based test­ing, Test-Driven De­vel­op­ment, MCDC and branch cov­er­age, and runs the same test cases across Model-In-the-Loop, Soft­ware-In-the-Loop and Pro­ces­sor-In-the-Loop en­vi­ron­ments for back-to-back ver­i­fi­ca­tion.
EverView ex­ports a Simulink or State­flow model to a sin­gle self-con­tained HTML file. Any­one with ver­sion-con­trol ac­cess can open it in a browser in sec­onds — no MATLAB li­cense, no in­stall, no setup. Re­view­ers nav­i­gate, in­spect func­tion­al­ity, search for text pat­terns and add com­ments. Each set of com­ments saves to its own file; EverView merges them back, pre­serv­ing I1 in­de­pen­dence by con­struc­tion. EverView is qual­i­fi­able like the other two tools: it is qual­i­fied by re­view, be­cause its out­put is the model it­self and the re­viewer ver­i­fies what they see.
Yes, three. The cruise con­troller case study shows the prod­uct side: spec­i­fi­ca­tion, static anal­y­sis, twelve re­quire­ments-based tests, cov­er­age and re­view, every re­port linked. The pow­er­train and driv­ing-re­sis­tance case stud­ies show the test-tool side: plant units ver­i­fied the same way be­fore the loop is closed. All re­ports open in a browser. Cruise Control, Start to Finish →
The work­flow is built for ASIL D but cov­ers the meth­ods rec­om­mended for ASIL A through ASIL D. Tool sup­port cov­er­age and struc­tural cov­er­age tar­gets scale with the ASIL.
Ques­tions?

Talk to the people who build the tools

Not sure which tool fits your project, or how qual­i­fi­ca­tion works for your ASIL level? Write to us — you'll reach an en­gi­neer, not a sales desk.

The whole work­flow — EverCheck + EverTest, qual­i­fi­ca­tion kits in­cluded — from 3,000 € / year per en­gi­neer, or 10,000 € / year for a team of five. See pric­ing →

⬇ Download Free Trial

Or write to us at sup­port@ever­bits.com