# Simulink and Model-Based Design: There Is No Such Thing as a DO-178C Certified Code Generator

MathWorks states in writing that its DO Qualification Kit does not prequalify tools. Automotive is different: TÜV SÜD certifies the same tools for ISO 26262 ASIL A to D.

Author: J.A. Watte
Published: July 15, 2026
Source: https://jwatte.com/blog/simulink-model-based-design/

---

There is no such thing as a DO-178C certified code generator. Not from MathWorks, not from anybody. MathWorks says so itself, on its own product page, as a question with a one-word answer: ["No. The DO Qualification Kit does not 'prequalify' tools."](https://www.mathworks.com/products/do-178.html) The same page adds that "tool qualification must be performed in the context of each specific project and operational environment," that "the tool user is ultimately responsible for qualification," and, bluntly, that "use of DO-178-qualified tools does not ensure the safety of the software or the system under consideration."

That is the fastest way to sort people who have shipped safety-critical software from people who have read about it. It is also the right place to start on Simulink, because the certification story is why industry writes the cheque, and it is the part almost everyone gets wrong.

## What Simulink actually is

MathWorks defines it plainly: ["Simulink is a block diagram environment used to design systems with multidomain models, simulate before moving to hardware, and deploy without writing code."](https://www.mathworks.com/products/simulink.html) It is not standalone. Per the [system requirements](https://www.mathworks.com/support/requirements/simulink.html), Simulink requires MATLAB, and in practice you write graphical blocks and textual MATLAB side by side.

Now the first trap. The product page advertises generation of "production-quality C, C++, CUDA, PLC, Verilog, and VHDL code," and the [Stateflow page](https://www.mathworks.com/products/stateflow.html) advertises "C, C++, VHDL, Verilog, and Structured Text for PLCs." Both are accurate quotations of marketing copy and both mislead if read as base-product capability. The Stateflow page gives the game away: every language in that list hyperlinks to a separate paid product. C and C++ to Embedded Coder, VHDL and Verilog to HDL Coder, Structured Text to Simulink PLC Coder. Neither Simulink nor Stateflow generates a line of code on its own.

Nor can anyone tell you cleanly when Simulink shipped. MathWorks' own history pages disagree: one refers to ["the release of Simulink in 1990"](https://www.mathworks.com/company/technical-articles/the-growth-of-matlab-and-the-mathworks-over-two-decades.html), while ["A Brief History of MATLAB"](https://www.mathworks.com/company/technical-articles/a-brief-history-of-matlab.html) lists it in a 1992 entry. A popular reconciliation involving a rename exists, which I could not confirm from any primary source. MathWorks' own accounts give both years, and that is where it stops.

## The workflow, not the product

Model-Based Design, per the [Simulink docs](https://www.mathworks.com/help/simulink/slref/simulink-concepts-model-development-processes.html), is a "development process that uses a system model as an executable specification throughout development," supporting "model and model component design, model simulation of dynamic behavior, code generation from the model, and continuous test and verification."

Notice what that does not say. It does not say the model is a picture of the design. It says the model *is* the specification and everything downstream is derived from it. The [marketing version](https://www.mathworks.com/solutions/model-based-design.html) promises you can "reduce your development time by 50% or more," published with no methodology at all. The [white paper's](https://www.mathworks.com/content/dam/mathworks/white-paper/why-adopt-model-based-design-white-paper.pdf) named customer numbers are weaker than they first look: Volvo Construction Equipment "anticipate a 30-50% reduction in prototype builds," a forecast rather than a measurement, and the Korea Institute of Machinery and Materials figure is one project's prototype cost of "$20,000 to $30,000," not a general rate. Vendor testimonials, all three.

## Build the canonical loop and watch it lie to you

Here is the model everyone builds first: a mass-spring-damper plant with m = 1 kg, b = 10 N s/m, k = 20 N/m, which in transfer-function form is P(s) = 1 / (s² + 10s + 20). Six blocks. A Step for the reference, a Sum with its List of signs set to `|+-` (that minus sign is the entire feedback loop), a [PID Controller](https://www.mathworks.com/help/simulink/slref/pidcontroller.html), a [Transfer Fcn](https://www.mathworks.com/help/simulink/slref/transferfcn.html) with numerator `[1]` and denominator `[1 10 20]`, a Scope, and a line from the output back to the Sum block's negative input.

Every number below is my own computation, verified with RK4 integration at a step of 1e-5 in numpy. Not quoted from MathWorks, not from any tutorial.

Open the loop and the plant's DC gain is 1/20, so a unit step settles at 0.05 and leaves 95 percent steady-state error, creeping there without overshoot because it is overdamped. That sluggish curve going nowhere near 1 is what the Scope shows before you add control. Close it and walk the controller up:

| Controller | Steady-state error | Overshoot | Rise time, 10 to 90% | 2% settling |
|---|---|---|---|---|
| P, Kp=300 | 6.25% | 40.07% | 0.072 s | 0.77 s |
| PD, Kp=300, Kd=10 | 6.25% | 12.03% | | 0.33 s |
| PI, Kp=30, Ki=70 | 0 | 1.26% | 0.408 s | |
| PID, Kp=350, Ki=300, Kd=50 | 0 | 5.44% | 0.279 s | 2.04 s |

The whole lesson is in those four rows. Only the integral term kills steady-state error, because the integrator is what drags closed-loop DC gain to exactly 1. The derivative term buys back the speed the integrator costs.

Note what this loop does not have. An [algebraic loop](https://www.mathworks.com/help/simulink/ug/algebraic-loops.html) "occurs when a signal loop in a model contains only blocks that have direct feedthrough," and the strictly proper plant has none, so it breaks the loop. Swap in a transfer function with equal numerator and denominator order and the same diagram acquires one, which Simulink must then solve numerically at every step, with impossible code generation among the documented consequences. Worse is the artificial algebraic loop, where merely making a subsystem atomic causes Simulink to detect one "even though the contents of the subsystem do not contain a direct feedthrough."

## The solver is not a formatting preference

This is what separates people who trust their Scope from people who should.

Same model, same gains, only the solver and step size change. The reference answer at 2 seconds is 1.020866. Explicit Euler, which Simulink calls ode1, has a stability limit of h < 0.03763 s given the fastest closed-loop pole at -53.14. What you actually get:

| Step size | ode1 result at t=2s |
|---|---|
| 0.036 | 1.02073 |
| 0.0376 | 0.89325 |
| 0.038 | 0.63173 |
| 0.04 | 53.19 |
| 0.05 | diverged |

Look at 0.0376. It does not crash. It does not warn. It returns a curve that looks like a perfectly plausible slightly-slow response and is 12 percent wrong. That is the failure mode that ships. Classical Runge-Kutta (ode4) moves the cliff to about 0.0524 s without removing it: 0.05 gives 1.02092, 0.0524 gives 1.15639, 0.055 gives 228.9.

Do not try to read a solver's order off its name, either. It works for [ode1 through ode8](https://www.mathworks.com/help/simulink/gui/solver.html) and breaks immediately after. ode113 is not 113th order, it is variable-order from first through thirteenth. ode15s is not 15th order, it is [first through fifth](https://www.mathworks.com/help/simulink/ug/compare-solvers.html). ode14x is not fourteenth-order anything, it is Newton's method plus extrapolation.

Stiffness is the deeper trap, and Simulink defines it precisely: a problem "is said to be stiff if the desired solution varies slowly, but there are closer solutions that vary rapidly." Implicit solvers handle stiff systems and cost more. Now watch a dialog box create stiffness from nothing. The PID block's default derivative is filtered, D·N·s/(s+N), and N is just a field you type in. On the same plant, N=10 gives a stiffness ratio of 8 but balloons overshoot to 35.78 percent, because over-filtering destroys the derivative action. N=100 gives ratio 54 and near-zero overshoot. N=1000 gives ratio 989. N=10000 gives ratio 10,397 and forces ode1 below 2.01e-4. One knob, 10 to 10000, makes the system roughly 1,300 times stiffer and demands a 300 times smaller step. That is exactly when you must leave ode45 for ode15s, and nothing on screen tells you.

Simulink will [choose for you](https://www.mathworks.com/help/simulink/ug/choose-a-solver.html), with a shortcut worth knowing: NumStatesForStiffnessChecking and StiffnessThreshold both default to 1000, and if the model has more continuous states than the first, Simulink treats it as stiff without computing stiffness at all. Only below that count does it measure.

And keep the abstraction straight while you are at it: signals "are mathematical, not physical, entities," and the lines "represent mathematical, not physical, relationships among blocks," [per the docs](https://www.mathworks.com/help/simulink/ug/signal-basics.html). A line is not a wire.

## The last mile is what you are buying

Everything above exists in cheaper tools. The reason aerospace and automotive pay is the staged verification chain and the paperwork at the end.

[Simulink Coder](https://www.mathworks.com/products/simulink-coder.html) "generates and executes C and C++ code from Simulink models, Stateflow charts, and MATLAB functions." [Embedded Coder](https://www.mathworks.com/products/embedded-coder.html) generates "readable, compact, and fast C and C++ code for embedded processors used in mass production," adding processor-specific optimizations, AUTOSAR and MISRA C support, bidirectional traceability, and "support for DO-178, IEC 61508, and ISO 26262 certification requirements." In one line: Simulink Coder is code that runs, Embedded Coder is code you ship.

Then the chain. A [SIL simulation](https://www.mathworks.com/help/ecoder/ug/about-sil-and-pil-simulations.html) "compiles and runs the generated code on your development computer," and MathWorks states the limit without flinching: it "does not test code compiled for target hardware because code is compiled for the development computer (different compiler and different processor architecture than the target)." PIL "cross-compiles source code on your development computer, and then downloads and runs the object code on a target processor or an equivalent instruction set simulator." Neither runs in real time. [HIL](https://www.mathworks.com/discovery/hardware-in-the-loop-hil.html) is where real time arrives, "connecting the real input and output (I/O) interfaces of the controller hardware to a virtual environment that simulates the physical system." [Simulink Test](https://www.mathworks.com/products/simulink-test.html) makes those one workflow rather than four.

And here is the mechanism behind every "it simulated fine but the hardware disagreed" story. MathWorks defines [numerical consistency](https://www.mathworks.com/help/rtw/ug/numerical-consistency-of-model-and-generated-code-simulation-results.html) as: "In fixed-point applications, the results agree in a bit-wise comparison. In floating-point applications, the results agree with an error tolerance that you specify." Floating-point generated code is not bit-accurate to your model by design. You pick a tolerance, and optimizations, custom code and code replacement library entries implementing different algorithms all move the answer. The [SIL and PIL limitations](https://www.mathworks.com/help/ecoder/ug/sil-and-pil-simulation-limitations.html) bite too: neither supports continuous sample times at the component boundary, and both ignore the Stop Simulation block and keep going.

## The certification asymmetry

Per [NASA's tool-qualification report](https://shemesh.larc.nasa.gov/fm/FMinCert/NASA-CR-2017-219371.pdf), qualification means identifying which DO-178C objectives a tool automates, specifying the functions you rely on, and demonstrating they work. That is all it buys: the right not to manually re-review the tool's output. The killer line is that "qualification of a code generator may only consider a subset of the legal input for the source language," and "the context of the tool's usage, and verification that the tool operates correctly within that context, is always required." Certification attaches to the aircraft, not the toolbox.

The second-most-common error is thinking Tool Qualification Level follows from software level. It follows from tool criterion crossed with software level. A Criterion 1 tool, whose output goes into the airborne software, on Level A software is TQL-1. A Criterion 2 verification tool on that same Level A software is only TQL-4, and Criterion 3 is TQL-5. TQL-1 is the most rigorous, TQL-5 the least.

So why buy the kit? NASA answers that too: "TQL-4 qualifications require insight into how the tool was built. If a tool was built by a third party, TQL-4 and above qualifications are not achievable without artifacts provided by the tool developer." You are buying MathWorks' internal development artifacts because you cannot produce them yourself.

Now the asymmetry, and conflating these two regimes is the single most common mistake in this space. Automotive is genuinely different. MathWorks states on its [ISO 26262 page](https://www.mathworks.com/solutions/automotive/standards/iso-26262.html): "MATLAB, Simulink, Stateflow, Embedded Coder, MATLAB and Simulink verification tools, and Polyspace code verification tools are certified by TÜV SÜD as qualified tools according to ISO 26262 for ASIL A-D." Third-party tool certificates genuinely exist here, and the [IEC Certification Kit](https://www.mathworks.com/products/iec-61508.html) ships them.

But do not swing too far. The certificate does not remove your classification work. Per MathWorks' own [SAE paper](https://www.mathworks.com/content/dam/mathworks/tag-team/Objects/s/68068-2011-01-1005-mathworks.pdf), "the intended usage of the tool (use cases) needs to be documented, analyzed, and evaluated." Tool Impact and Tool Error Detection combine into TCL1, TCL2 or TCL3; TCL1 needs no qualification, anything else needs one of four formal methods, and "when multiple use cases for a tool exist, there can be multiple TCLs." MISRA gets the same treatment: MathWorks writes that following its guidance "is not a guarantee that the system being developed will be safe," and that ["no assessment is made of the Embedded Coder tool chain."](https://www.mathworks.com/help/ecoder/ug/developing-a-misra-c2012-compliance-statement.html)

The coverage tooling exists for one reason. [Simulink Coverage](https://www.mathworks.com/products/simulink-coverage.html) measures modified condition/decision coverage, and the [NASA and FAA tutorial](https://ntrs.nasa.gov/api/citations/20010057789/downloads/20010057789.pdf) explains why MC/DC is the load-bearing feature: it is DO-178B Table A-7 objective 5, "applicable to level A software only." It exists because exhaustive testing does not scale, since "for a decision with n inputs, 2^n tests are required," while MC/DC gets independence evidence in roughly n+1. That tutorial addresses DO-178B; I did not verify the DO-178C text and will not claim it. It also carries the coverage-level version of the hardware-disagreed problem: "achieving MC/DC at the source code level does not guarantee MC/DC at the object code level, and vice versa."

## What it costs, and what it costs you

MathWorks' dated ["Euro, Standard Perpetual, March 2026" price list](https://es.mathworks.com/content/dam/mathworks/price-lists/euro-standard.pdf) is the only unambiguous primary anchor, excluding tax. Named-user perpetual: MATLAB 2,410 euros, Simulink 3,640, Stateflow 3,440, Embedded Coder 6,000, DO Qualification Kit 13,300. Adding them up is my own arithmetic, not a MathWorks bundle: a full DO-178 stack for one named user comes to 52,930 euros perpetual, or 211,725 on concurrent licences. Core only, MATLAB plus Simulink plus Stateflow plus Embedded Coder, is 15,490.

The non-cash costs are more interesting. Simulink saves models as [.slx by default](https://www.mathworks.com/help/simulink/ug/save-models.html), "a compressed package that conforms to the Open Packaging Conventions (OPC) interoperability standard" storing XML. That is a ZIP of XML, which is to say Git cannot line-merge it. Two engineers touching one model is a coordination problem, not a merge. MathWorks cites smaller files and incremental loading as the benefit; diffability was the price.

Stateflow runs deeper. MathWorks credits [David Harel by name](https://www.mathworks.com/discovery/state-machine.html) for hierarchy, parallelism and event broadcasting. But Yi, Wang, Zhan and Zhan of the Institute of Software, Chinese Academy of Sciences write in [an arXiv preprint](https://arxiv.org/pdf/2207.11965) that "Stateflow lacks an official formal semantics," and that it "is a highly complex language whose official semantics is only described informally in its Users Guide (the latest versions running over a thousand pages)." Their conclusion: "design using Stateflow alone is insufficient for guaranteeing correctness of safety-critical systems."

And the tool has bugs. Chowdhury, Mohian, Mehra, Johnson and Csallner published [SLforge at ICSE 2018](http://www.taylortjohnson.com/research/chowdhury2018icse.pdf): "During an approximately five months long testing time, we found and reported 12 bugs overall, MathWorks confirmed 10 of them, of which 8 were previously unknown." One was a specification ambiguity. Another had the same model simulate correctly in Normal mode and error in Accelerator mode. Whether those bugs were fixed is not something I can establish, and the count is not the point. The point is that the thing you are trusting to be your specification is itself unspecified software.

The escape hatch is [FMI](https://fmi-standard.org/), "a free standard that defines a container and an interface to exchange dynamic simulation models," supported by 280 or more tools. That MathWorks shipped Simulink FMU Builder as a [new product in R2026a](https://www.mathworks.com/products/new_products/latest_features.html) is a real concession to it.

None of this makes Model-Based Design wrong. It makes it a bargain with terms. You get one executable artefact carrying from specification to shipped C, staged verification that catches the compiler and the processor before the aircraft does, and a paper trail an authority will read. You pay with a file format your version control cannot reason about, a state-machine language with no formal semantics, a code generator nobody has certified and nobody can, and about 52,930 euros a seat before anyone writes a line of anything. Knowing which of those you are actually buying is the whole skill.

## Related reading

- [MATLAB: What It Actually Is, and Why Almost Every Article About Its Price Is Now Wrong](/blog/matlab-for-engineering-work/): the layer Simulink sits on, and the licensing picture underneath these numbers.
- [Jama Connect: The Trace Matrix Is Gone](/blog/jama-connect-requirements-management/): the requirements side of the traceability story, and what Requirements Toolbox reaches through ReqIF.
- [Antithesis and the Quiet Comeback of Deterministic Simulation Testing](/blog/blog-antithesis-deterministic-testing/): the other approach to trusting simulation, from a tool built to make every bug reproduce.
- [Going Frameworkless on Cloudflare, and Why You Still Reach for Vercel, Netlify, and Square](/blog/blog-cloudflare-frameworkless-vendor-lockin/): the same lock-in calculus in a cheaper domain, where the escape hatches are easier.
- [Shield AI: The Autonomy Company Building Toward an IPO, Not a Sale](/blog/shield-ai-hivemind-autonomy/): the industry where these certification regimes actually bite.

## Fact-check notes and sources

- **"No. The DO Qualification Kit does not 'prequalify' tools," qualification "must be performed in the context of each specific project," "the tool user is ultimately responsible," and qualified tools do "not ensure the safety of the software":** [MathWorks DO Qualification Kit](https://www.mathworks.com/products/do-178.html). The kit covers DO-178C, DO-278A, DO-254 and supplements including DO-330, DO-331 and DO-333, across Embedded Coder, Simulink Design Verifier, Simulink Test, Simulink Coverage, Simulink Check and Polyspace.
- **Simulink definition and the C/C++/CUDA/PLC/Verilog/VHDL marketing list:** [Simulink product page](https://www.mathworks.com/products/simulink.html). **Each language routes to a separate paid coder product:** [Stateflow product page](https://www.mathworks.com/products/stateflow.html). **Simulink requires MATLAB:** [system requirements](https://www.mathworks.com/support/requirements/simulink.html).
- **The 1990 vs 1992 contradiction:** [Growth of MATLAB](https://www.mathworks.com/company/technical-articles/the-growth-of-matlab-and-the-mathworks-over-two-decades.html) says 1990; [A Brief History of MATLAB](https://www.mathworks.com/company/technical-articles/a-brief-history-of-matlab.html) lists 1992. Both are MathWorks. No primary source reconciles them, so no single date is asserted here.
- **Model-Based Design as executable specification:** [Model Development Processes](https://www.mathworks.com/help/simulink/slref/simulink-concepts-model-development-processes.html). **The "50% or more" claim, published with no methodology:** [Model-Based Design solutions page](https://www.mathworks.com/solutions/model-based-design.html). **Volvo CE "anticipate a 30-50% reduction in prototype builds" (a forecast, attributed to Jae Yong Lee) and the Korea Institute of Machinery and Materials "$20,000 to $30,000" single-project prototype cost (attributed to Cheol Hoon Park):** [Why Adopt Model-Based Design white paper](https://www.mathworks.com/content/dam/mathworks/white-paper/why-adopt-model-based-design-white-paper.pdf). All vendor-published testimonials, not independent measurements.
- **Every PID, plant, solver-divergence and stiffness-ratio number here is my own computation** (numpy, RK4 and explicit Euler, reference at h=1e-6). They are not quoted from MathWorks or any tutorial. Block forms per the [PID Controller block reference](https://www.mathworks.com/help/simulink/slref/pidcontroller.html) and the [Transfer Fcn block reference](https://www.mathworks.com/help/simulink/slref/transferfcn.html). For the record: the full PID closed loop is T(s) = (50s² + 350s + 300) / (s³ + 60s² + 370s + 300), poles at -53.14, -5.90 and -0.957.
- **Algebraic loop and direct feedthrough definitions, the dogleg trust region algorithm, and the artificial algebraic loop:** [Algebraic Loops](https://www.mathworks.com/help/simulink/ug/algebraic-loops.html). Simulink chooses the algebraic loop solver automatically by default and may switch methods during simulation. Code generation is listed as impossible for models containing them, which is stated as documented rather than as an absolute law. **Virtual vs atomic subsystem behaviour change:** [What Is a Subsystem?](https://www.mathworks.com/help/simulink/ug/what-is-a-subsystem.html).
- **Solver tables and naming:** [Solver pane reference](https://www.mathworks.com/help/simulink/gui/solver.html). **ode15s is first through fifth order and ode113 first through thirteenth:** [Compare Solvers](https://www.mathworks.com/help/simulink/ug/compare-solvers.html), which also carries the stiffness definition. **Automatic solver selection, and both NumStatesForStiffnessChecking and StiffnessThreshold defaulting to 1000 with the state-count shortcut:** [Choose a Solver](https://www.mathworks.com/help/simulink/ug/choose-a-solver.html). **Fixed-step vs variable-step behaviour:** [Types of Solvers](https://www.mathworks.com/help/simulink/ug/types-of-solvers.html). **Also cut for length:** relative tolerance defaults to 1e-3, meaning each state must be accurate to within 0.1 percent, and the solver uses relative or absolute tolerance "whichever results in a larger tolerance," per [Relative tolerance](https://www.mathworks.com/help/simulink/gui/relativetolerance.html); variable-step solvers reject and retry a step when local error exceeds the acceptable error for any one state, per [Variable Step Solvers](https://www.mathworks.com/help/simulink/ug/variable-step-solvers-in-simulink-1.html).
- **Signals are mathematical, not physical:** [Signal Basics](https://www.mathworks.com/help/simulink/ug/signal-basics.html). **Not covered above for length, but relevant to the same "the tool is not doing what you think" theme:** zero-crossing detection brackets events only for signals of type double, roughly 47 blocks register crossings (1 for Relay and Switch, 5 for the Second-Order Integrator, the Integrator depending on configuration), and the docs show 1000 consecutive crossings inside an interval about 1.1 nanoseconds wide killing a run, per [Zero-Crossing Detection](https://www.mathworks.com/help/simulink/ug/zero-crossing-detection.html). The 1000 figure appears inside a quoted error message; the controlling setting is the "Number of consecutive zero crossings" solver option.
- **Simulink Coder vs Embedded Coder:** [Simulink Coder](https://www.mathworks.com/products/simulink-coder.html) and [Embedded Coder](https://www.mathworks.com/products/embedded-coder.html). The Simulink Coder page mentions Embedded Coder only in passing and never explains the difference.
- **SIL and PIL definitions, the SIL compiler and architecture limitation, and that neither runs in real time:** [SIL and PIL Simulations](https://www.mathworks.com/help/ecoder/ug/about-sil-and-pil-simulations.html). **The continuous-sample-time, Stop Simulation and error-status limitations:** [SIL and PIL Simulation Limitations](https://www.mathworks.com/help/ecoder/ug/sil-and-pil-simulation-limitations.html). **HIL definition and rationale:** [What Is Hardware-in-the-Loop?](https://www.mathworks.com/discovery/hardware-in-the-loop-hil.html). **One workflow across normal, accelerator, SIL, PIL and HIL:** [Simulink Test](https://www.mathworks.com/products/simulink-test.html). **Bit-wise for fixed-point, specified tolerance for floating-point:** [Numerical Consistency of Model and Generated Code](https://www.mathworks.com/help/rtw/ug/numerical-consistency-of-model-and-generated-code-simulation-results.html).
- **What qualification is and is not, the code-generator subset-of-legal-input caveat, the DO-178C Table 12-1 criterion-by-level TQL matrix (Level A: Crit 1 to TQL-1, Crit 2 to TQL-4, Crit 3 to TQL-5), cumulative DO-330 objectives (24 plus 14 = 38 at TQL-4), software-level objective counts (71/69/62/26, with Level E at zero), the third-party-artifacts rationale, and that certification attaches to the aircraft:** [NASA/CR-2017-219371](https://shemesh.larc.nasa.gov/fm/FMinCert/NASA-CR-2017-219371.pdf), reproducing DO-178C tables. **FAA AC 20-115D and EASA AMC 20-115D published 24 October 2017 and technically identical:** [EASA newsroom](https://www.easa.europa.eu/en/newsroom-and-events/news/harmonised-software-easa-amc-and-faa-ac-20-115d-have-been-published). The FAA document itself was not accessible, so nothing here is quoted from it.
- **TÜV SÜD certification of MATLAB, Simulink, Stateflow, Embedded Coder and Polyspace for ISO 26262 ASIL A-D:** [ISO 26262 support](https://www.mathworks.com/solutions/automotive/standards/iso-26262.html). **Kit scope and included TÜV SÜD certificates, spanning ISO 26262, IEC 61508, ISO 25119, EN 50128, EN 50657 and IEC 62304:** [IEC Certification Kit](https://www.mathworks.com/products/iec-61508.html). **TI/TD/TCL classification, TCL1 needing no qualification, four permitted methods, and multiple TCLs per tool:** [Sandmann, SAE 2011-01-1005](https://www.mathworks.com/content/dam/mathworks/tag-team/Objects/s/68068-2011-01-1005-mathworks.pdf). That paper cites ISO/FDIS 26262; the current edition is ISO 26262:2018 and clause numbers may differ. The specific TI-by-TD-to-TCL mapping is deliberately not stated because I could not verify it.
- **MISRA C:2012 compliance is the user's to state, and no assessment is made of the Embedded Coder tool chain:** [Developing a MISRA C:2012 Compliance Statement](https://www.mathworks.com/help/ecoder/ug/developing-a-misra-c2012-compliance-statement.html).
- **MC/DC as DO-178B Table A-7 objective 5, Level A only; the 2^n scaling argument; and the source-vs-object coverage gap:** [NASA/TM-2001-210876](https://ntrs.nasa.gov/api/citations/20010057789/downloads/20010057789.pdf) (Hayhurst, Veerhusen, Chilenski, Rierson, 2001). This tutorial addresses DO-178B; the DO-178C text was not verified. **Coverage metrics:** [Simulink Coverage](https://www.mathworks.com/products/simulink-coverage.html). **Formal-methods error classes, with the engine unnamed on the page:** [Simulink Design Verifier](https://www.mathworks.com/products/simulink-design-verifier.html). **Standards checked by Model Advisor, plus clone detection and complexity metrics:** [Simulink Check](https://www.mathworks.com/products/simulink-check.html). **DOORS, Word, Excel and ReqIF paths to Polarion and Jama:** [Requirements Toolbox](https://www.mathworks.com/products/requirements-toolbox.html).
- **All euro prices are named-user perpetual, excluding tax, from the dated March 2026 list:** [MathWorks Euro Standard Perpetual price list](https://es.mathworks.com/content/dam/mathworks/price-lists/euro-standard.pdf). **The 52,930, 211,725 and 15,490 euro totals are my own sums of that list, not MathWorks bundle prices.** MathWorks' USD figures differ across its pricing page and store because they are different licence models, so no USD figure appears here.
- **SLX as an OPC-conformant compressed XML package:** [Save Models](https://www.mathworks.com/help/simulink/ug/save-models.html). **Harel's hierarchy, parallelism and event broadcasting:** [What Is a State Machine?](https://www.mathworks.com/discovery/state-machine.html); MathWorks credits the concepts, and no claim is made here that Stateflow implements Harel statechart semantics. **Mealy and Moore enforcement:** [Stateflow Mealy and Moore docs](https://www.mathworks.com/help/stateflow/ug/overview-of-mealy-and-moore-machines.html). **No prescriptive Simulink-vs-Stateflow rule:** [MAB guidelines](https://www.mathworks.com/help/simulink/mdl_gd/maab/using-simulink-and-stateflow-in-modeling.html).
- **"Stateflow lacks an official formal semantics" and the thousand-page Users Guide:** Yi, Wang, Zhan and Zhan, [arXiv:2207.11965](https://arxiv.org/pdf/2207.11965), a preprint from the Institute of Software, Chinese Academy of Sciences; conference or journal publication was not confirmed.
- **12 bugs reported, 10 confirmed by MathWorks, 8 previously unknown, over about five months, with 2 of 12 false positives; the Normal-vs-Accelerator mode bug; and the absence of a complete formal specification:** Chowdhury, Mohian, Mehra, Johnson and Csallner, [SLforge, ICSE 2018](http://www.taylortjohnson.com/research/chowdhury2018icse.pdf). Whether those bugs were later fixed is not established. The same authors argue open-source models are a fair proxy for industrial ones because "a significant portion of these models are of size and complexity that are comparable to models used in industry"; the corpus is [SLNET, MSR 2022](https://arxiv.org/abs/2203.17112). No quantified evidence of bloat in proprietary industrial models exists publicly, so none is claimed here.
- **FMI as a free standard supported by 280 or more tools:** [FMI Standard](https://fmi-standard.org/). **Simulink FMU Builder, Simulink Copilot and Simulink Agentic Toolkit as R2026a products:** [R2026a Release Highlights](https://www.mathworks.com/products/new_products/latest_features.html). **Copilot's capabilities stop at explanation, guidance and predefined-task automation, with no release date given and no model-generation claim:** [Simulink Copilot](https://www.mathworks.com/products/simulink-copilot.html).

*This post is informational and reflects public documentation, published standards guidance, and my own numerical computations. It is not engineering, certification, safety, or purchasing advice. I have no affiliation with MathWorks, TÜV SÜD, NASA, EASA, the FAA, or any other organization named, and nothing here is endorsed by them. Product details, prices, and release contents are current as of mid-2026 and change.*


---

Canonical HTML: https://jwatte.com/blog/simulink-model-based-design/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/simulink-model-based-design.webp