📐 MATLAB – Engineering & Safety-Critical Workflows (Simulink, Codegen, MBD, V&V)

1.1 MATLAB : langage + environnement (ce que ça change en ingénierie)

Forces “ingénierie avionique”

Prototypage rapide : tester des lois/algos sur des données réelles.
Numérique : matrices, optimisation, identification, signal processing.
Écosystème : toolboxes (control, signal, optimization, aerospace, etc.).
Traçabilité possible via workflows MBD (Simulink + tests + rapports).

Exemple MATLAB (filtre + clamp)

function [y, diag] = safe_filter(x, state)
% Simple 1st order low-pass + clamp + diagnostic
% x: input sample, state: previous output
alpha = 0.1;
y = (1-alpha)*state + alpha*x;

diag = struct();
diag.saturated = false;

% clamp
if y > 1.0
    y = 1.0; diag.saturated = true;
elseif y < -1.0
    y = -1.0; diag.saturated = true;
end

Limites “embarqué & safety”

Non déterminisme potentiel (types dynamiques, allocations implicites) si on reste en prototype “desktop”.
Performance & timing : l’embarqué exige des boucles bornées, types fixes, budgets WCET.
Certification : le code final doit être prouvable (tests, coverage, traçabilité).

MATLAB est souvent le laboratoire. L’embarqué est souvent du C/Ada déterministe, parfois généré depuis un modèle, puis vérifié “back-to-back”.

1.2 Simulink & Model-Based Design (MBD) : du modèle à la simulation temporelle

Architecture conceptuelle d’un modèle avionique

flowchart LR
  Req[Requirements] --> M[Simulink Model]
  M --> P[Plant Model / Environment]
  M --> C[Controller / Laws]
  C --> O[Outputs / Actuators]
  P --> S[Sensors]
  S --> C
  C --> D[Diagnostics / Monitoring]
  D --> M

Points clés (safety-ready)

Concept	Pourquoi	Risque à éviter
Fixed-step	déterminisme temporel	variable-step non embarquable
Rates & scheduling	multi-tâches / périodes	jitter, transitions de rate mal gérées
Interfaces (buses)	API explicite	signaux implicites / connexions floues
State machines	modes, transitions	modes implicites / logique dispersée

Un modèle “certifiable” n’est pas un dessin : c’est une spécification exécutable avec discipline (naming, interfaces, data types, tests, traçabilité).

1.3 Commande & estimation : ce que MATLAB/Simulink fait très bien en avionique

Cas d’usage (GNC / FCS)

Design de correcteurs (PID, LQR, H∞) + marges / robustesse.
Observateurs (Kalman, complementary) + fusion capteurs.
Identification système (modèles à partir de données d’essai).
Simulation scénarios : turbulence, capteur bruité, panne, saturation.

Mini-exemple “discret” (concept)

% Discrete state-space: x(k+1)=A x(k)+B u(k), y(k)=C x(k)
A = [0.98 0; 0 0.95]; B = [0.02; 0.01]; C = [1 0];
x = [0;0];
for k=1:100
   u = 0.5;                 % command
   x = A*x + B*u;           % update
   y = C*x;                 % output
end

Ce qui devient “safety-critical”

Saturation & rate-limits (actuateurs).
Plausibility checks capteurs + dégradations.
Modes (active/degraded/fault) via machines à états.
Bornage : loops, temps, mémoire, types.

L’algorithme peut être “bon” sur le papier et dangereux sans garde-fous (bornes, plausibilité, modes, diagnostics).

2.1 Code Generation : passer du prototype au monde déterministe (embarqué)

Le “mur” prototype → embarqué

Aspect	Prototype MATLAB	Embedded deterministic
Types	dynamique / double par défaut	types fixes, éventuellement fixed-point
Timing	non contraint	périodes, WCET, fixed-step
Mémoire	allocations implicites possibles	buffers bornés, pas d’alloc dans la boucle
Safety	scripts “flexibles”	règles, restrictions, analyse statique, V&V

Diagramme : model → code → back-to-back

flowchart LR
  M[Simulink Model] --> CG[Code Generation]
  CG --> C[C / Embedded Code]
  M --> T1[Model Tests]
  C --> T2[Code Tests]
  T1 --> B2B[Back-to-back Comparison]
  T2 --> B2B
  B2B --> REP[Evidence Reports]

Back-to-back = prouver que le code (généré ou recodé) est équivalent au modèle sur un ensemble de scénarios/cas limites.

2.2 V&V : tests, SIL/PIL/HIL, couverture, traçabilité

SIL / PIL / HIL (lecture pratique)

Mode	But	Ce qu’on découvre
SIL	code tournant sur PC	écarts modèle/code, erreurs logiques, overflow
PIL	code sur target	timing, compilateur, ABI, précision numérique
HIL	target + plant temps réel	latences, interfaces, jitter, comportements limites

Requirements-based testing

Req-CTRL-001: Output must be saturated to [-1..+1]
Test-CTRL-001A: x=2.3 -> y=+1
Test-CTRL-001B: x=-9  -> y=-1
Test-CTRL-001C: x=0.2 -> y=0.2
Evidence: report + traceability matrix

La clé certification : prouver que chaque exigence est testée et que les résultats sont reproductibles.

Couverture (concept)

Couverture modèle : décisions, conditions, états/transitions (machines à états).
Couverture code : statement/branch (et parfois plus selon criticité/process).
Justifications : tout ce qui n’est pas couvert doit être justifié (code mort, unreachable, etc.).

La couverture n’est pas une “métrique vanity” : c’est une preuve structurelle au service de la sûreté.

2.3 Safety-critical : DO-178C / DO-331 (Model-Based Development)

Pour l’avionique, le sujet n’est pas “MATLAB certifié”, mais comment un workflow model-based produit des preuves acceptables. Cela implique : exigences, modèles, vérification, outillage, configuration, audits.

“Evidence package” (vue process)

flowchart TB
  R[System Requirements] --> SR[Software Requirements]
  SR --> M[Model (Simulink/Stateflow)]
  M --> TG[Test Generation / Scenarios]
  TG --> MR[Model Test Reports]
  M --> CG[Code Generation]
  CG --> C[Generated C Code]
  C --> CR[Code Test Reports]
  SR --> TM[Traceability Matrix]
  MR --> PKG[Certification Evidence Package]
  CR --> PKG
  TM --> PKG

Ce qui est “scruté” en audit

Zone	Question typique	Preuve attendue
Modèle	est-il déterministe, clair, et maîtrisé ?	guidelines, revues, restrictions, logs
Outillage	peut-il masquer un défaut ?	justification/qualification selon usage
Traçabilité	Req ↔ modèle ↔ tests ↔ résultats ?	matrices + rapports
Tests	cas limites et scénarios critiques couverts ?	campaign reports + coverage

Point clé : le model-based n’enlève pas la rigueur — il la déplace sur la discipline de modélisation + V&V + configuration.

3.1 Domaines avionique & références “avions” (A320 / 737) : usage typique de MATLAB

Cadre : MATLAB/Simulink est très utilisé en conception & validation (lois, modèles, tests) dans l’industrie aéro, tandis que l’embarqué final est généralement du C/Ada safety-critical (parfois généré depuis modèles).

Où MATLAB apparaît typiquement dans un programme avion

Phase	Usage MATLAB/Simulink	Livrables
Conception	design laws, estimation, identification	modèles, scripts, rapports
Simulation	plant + controller + scénarios	campagnes de sim, KPI
V&V	tests req-based, back-to-back	rapports, coverage, traçabilité
Industrialisation	codegen ou spécification vers C/Ada	code, tests target, evidence

Référence “737 MAX / MCAS” (lecture engineering, sans sensationalisme)

Les systèmes de commande et logiques de modes sont typiquement conçus/validés via modèles + scénarios.
Ce qui compte côté safety : validation des entrées, modes explicites, dégradations, limites d’autorité, tests robustesse.
MATLAB/Simulink sert à éprouver ces transitions et cas limites avant implémentation embarquée.

3.2 Architecture “model → code” : interfaces, rates, diagnostics, safe states

Pattern recommandé (safety-ready)

flowchart LR
  In[Sensors] --> Val[Validate & plausibility]
  Val --> Norm[Normalize / filter]
  Norm --> Ctrl[Control law]
  Ctrl --> Lim[Clamp / rate limit]
  Lim --> Out[Actuators]
  Val --> Diag[Fault flags]
  Norm --> Diag
  Ctrl --> Diag
  Diag --> Mode[Mode manager (FSM)]
  Mode --> Ctrl

Table : règles “design for verification”

Règle	Pourquoi	Comment
Interfaces explicites	traçabilité & test	buses, naming, dictionnaire de données
Modes centralisés	éviter logique dispersée	FSM / Stateflow, transitions revues
Bornes partout	sécurité + déterminisme	clamp/rate-limit, ranges, saturations
Logs bornés	timing stable	buffer circulaire, quotas, “monitoring task”

3.3 Checklist “MATLAB/Simulink safe-ready” (conception + V&V)

[MATLAB/Simulink Safety-Ready Checklist]

A) Determinism
- [ ] Fixed-step solver for embedded-intent models
- [ ] Explicit sample times; rate transitions handled
- [ ] No hidden dynamic memory patterns in real-time path

B) Data & Types
- [ ] Explicit data dictionary; no implicit signal typing
- [ ] Fixed-width types where needed; consider fixed-point strategy
- [ ] Saturation/clamp everywhere a boundary exists

C) Architecture
- [ ] Modes via explicit state machine (FSM)
- [ ] Separation: control loop vs monitoring/logging
- [ ] Diagnostics flags + counters (observable behavior)

D) Verification
- [ ] Requirements-based tests exist for each key requirement
- [ ] Edge cases covered: sensor out-of-range, spikes, intermittence
- [ ] Back-to-back tests between model and generated/hand code

E) Evidence
- [ ] Traceability matrix: Req -> Model element -> Test -> Report
- [ ] Coverage evidence (model and/or code as required)
- [ ] Configuration management: versioning, reproducible builds and reports

4.1 Mini-projet : filtre + clamp + diagnostic (prototype → embedded-style)

Prototype MATLAB simple

function [y, state, diag] = lp1_safe(x, state)
alpha = 0.2;
y = (1-alpha)*state + alpha*x;
diag = struct('sat', false);

if y > 1.0
   y = 1.0; diag.sat = true;
elseif y < -1.0
   y = -1.0; diag.sat = true;
end
state = y;

Embedded-style (intention : types fixes + bornes)

% Intent: fixed-point-ish style (concept)
% Use explicit scaling to int16 range [-32768..32767]
function [y_q15, state_q15, diag] = lp1_q15(x_q15, state_q15)
% x_q15: int32 representing Q15
alpha_q15 = int32(6553);  % ~0.2 in Q15 (0.2*32768)

y_q15 = ( (int32(32768)-alpha_q15) * state_q15 + alpha_q15 * x_q15 ) / int32(32768);

diag = struct('sat', false);

if y_q15 > int32(32767)
   y_q15 = int32(32767); diag.sat = true;
elseif y_q15 < int32(-32768)
   y_q15 = int32(-32768); diag.sat = true;
end

state_q15 = y_q15;

Ici on montre l’intention “embarqué” : éviter doubles implicites, rendre les bornes et saturations explicites.

Table de tests (cas limites)

Test	Entrée	Attendu	Diag
T1	x=0, state=0	y=0	sat=false
T2	x=+10, state=0	y=+1 (clamp)	sat=true
T3	x=-10, state=0	y=-1 (clamp)	sat=true
T4	x=0.1, state=0.1	y≈0.1	sat=false

En safety, tu ajoutes aussi : spikes, intermittence capteur, valeurs NaN/Inf (au niveau prototype), et comportement en modes dégradés.

4.2 Ressources & repères (toolboxes, workflows, safety)

Ici je te donne une structure “à remplir” avec TES liens internes IDEO-Lab et/ou docs officielles. (Tu peux garder la section en “entry points”.)

Toolboxes / briques utiles (typique aéronautique)

Brique	Usage
Control / Robust control	design de lois, marges, stabilité
System identification	modèles à partir de données d’essai
Signal processing	filtrage, spectral, détection
Simulink + State machines	modélisation exécutable, modes
Code generation	industrialisation vers C (et workflows V&V)
Test / coverage	campagnes, rapports, traçabilité

4.3 FAQ : “MATLAB tourne en vol ?” + réalités embarquées

Q1 — MATLAB est-il exécuté “tel quel” sur avion ?

Généralement non. L’usage principal est ingénierie : conception, simulation, validation. L’embarqué vise du code déterministe (souvent C/Ada), parfois généré depuis modèles puis vérifié.

Q2 — Alors pourquoi MATLAB est central ?

Accélère les itérations d’algorithmes.
Permet des campagnes de simulation massives.
Structure le V&V via MBD : tests + rapports + back-to-back.

Q3 — Le risque principal ?

Confondre prototype “desktop” (flexible) et design embarqué (borné, déterministe). La solution : discipline, restrictions, tests, traceability, evidence.

⚙️ Quickstart MATLAB/Simulink (orientation avionique & safety)

1) Prototype algorithm in MATLAB using real flight/test data
2) Move to Simulink for executable model + timing intent
3) Enforce determinism: fixed-step, explicit sample times, bounded logic
4) Model modes explicitly (state machine) + diagnostics flags
5) Define data dictionary: types, ranges, units, scaling
6) Add clamps/rate limits + plausibility checks everywhere
7) Create requirements-based tests + edge cases
8) Run back-to-back tests (model vs generated/hand code)
9) Validate on SIL then PIL then HIL for timing/IO behavior
10) Produce evidence: reports, coverage, traceability, config management

📐 MATLAB – Engineering & Safety-Critical Workflows

MATLAB : le “workbench” de l’avionique moderne.

MATLAB, c’est quoi (vraiment) ?

Simulink & Model-Based Design

Commande & estimation

Code Generation (Embedded)

V&V : tests, couverture, traçabilité

Safety-critical : DO-178C / DO-331

Domaines avionique & exemples “avions”

Architecture “model → code”

Checklist “MATLAB/Simulink safe-ready”

Mini-projet : filtre + clamp + diagnostic

Ressources & docs

“MATLAB en avion, ça tourne ?”