🛡️ Deterministic C – Safety-Critical Avionics (DO-178C / MISRA)

1.1 Définition : “Deterministic C” (Safety-Critical)

Le déterminisme en 3 axes

Axe	Objectif	Ce qu’on maîtrise	Exemples
Fonctionnel	Mêmes entrées ⇒ mêmes sorties	États, modes, transitions	FSM explicite, invariants, “safe defaults”
Temporel	Temps borné / prévisible	Chemins d’exécution, boucles	Loops bornées, WCET, budget CPU
Mémoire	Ressources bornées / pas de surprises	Stack, statique, buffers	Pas de malloc, buffers dimensionnés, pas de fragmentation

Diagramme (concept) : boucle de contrôle temps réel

flowchart LR
  A[Read sensors] --> B[Validate / sanitize]
  B --> C[Compute control law]
  C --> D[Clamp & rate limit]
  D --> E[Output actuators]
  E --> F[Diagnostics / logging]
  F --> A
  note1([All steps are bounded in time & memory]):::note
classDef note fill=#0b1220,stroke=#334155,color=#cbd5e1;

Note : ce diagramme est “Mermaid-style”. Sur IDEO-Lab, tu peux soit l’afficher tel quel (code), soit intégrer un renderer Mermaid si tu en utilises déjà.

Pourquoi le C reste un standard de fait en avionique

Mapping machine : relation directe avec l’exécution (stack, registres, mémoire).
Toolchains robustes : compilateurs, linkers, debuggers, trace tools, coverage tools.
Auditabilité : le code est “explainable” au niveau machine (essentiel pour WCET / V&V).
Maîtrise des features : en imposant un profil strict (MISRA/CERT + règles internes), on neutralise les zones dangereuses.

Exemple minimaliste (style safety-critical)

#include 
#include 

#define ALT_MAX_FT (60000U)

static uint16_t g_altitude_ft = 0U;

bool set_altitude_ft(uint16_t new_alt_ft)
{
    if (new_alt_ft <= ALT_MAX_FT)
    {
        g_altitude_ft = new_alt_ft;
        return true;
    }
    return false; /* input out of range */
}

Anti-patterns “non déterministes” (à éviter)

Allocation dynamique dans la boucle temps réel : fragmentation, latence imprévisible.
Boucles non bornées : `while(x) {...}` sans borne claire ⇒ WCET indémontrable.
UB (Undefined Behavior) : overflow signé, shifts hors bornes, aliasing agressif, non init.
Concurrence implicite : accès partagés sans modèle clair (ISR/tasks).

Règle d’or : si tu ne peux pas expliquer “pire-cas temps + pire-cas mémoire + pire-cas état”, le design est incomplet pour du safety-critical.

1.2 Règles de codage : MISRA-C / CERT C / “No UB”

Restrictions typiques (profil “Deterministic C”)

Zone	Interdit / limité	Pourquoi	Alternative sûre
Mémoire	`malloc/free`, realloc	latence + fragmentation	buffers statiques, pools bornés (si autorisés)
Flow	récursion, `goto` (souvent), boucles non bornées	WCET incertain	FSM, boucles bornées
Types	casts implicites, conversions silencieuses	bugs “invisibles”	casts explicites, types `stdint.h`
UB	overflow signé, shift hors borne, non init	comportement non défini	fonctions “safe”, checks, saturation
Concurrence	accès partagés non protégés	race conditions	sections critiques, double-buffer, message passing

Exemple : boucle bornée + clamp + saturation

#include 
#include 

static int32_t clamp_i32(int32_t x, int32_t lo, int32_t hi)
{
    if (x < lo) { return lo; }
    if (x > hi) { return hi; }
    return x;
}

/* Bounded loop: always <= N iterations */
bool moving_average_i16(const int16_t *samples, uint16_t n, int16_t *out_avg)
{
    uint16_t i = 0U;
    int32_t acc = 0;

    if ((samples == (void*)0) || (out_avg == (void*)0) || (n == 0U) || (n > 64U))
    {
        return false;
    }

    for (i = 0U; i < n; i++)
    {
        acc += (int32_t)samples[i];
    }

    acc = acc / (int32_t)n;
    acc = clamp_i32(acc, -32768, 32767);
    *out_avg = (int16_t)acc;
    return true;
}

Points “review” sur cet exemple

Bornes : n ≤ 64 → timing borné (WCET plus simple).
Accumulateur : type élargi int32_t pour éviter overflow.
Checks : pointeurs & paramètres validés (defensive design).
Clamp : saturation explicite → évite UB, résultats stables.
Style : simple, lisible, testable, audit-friendly.

Conseil : dans du safety-critical, chaque conversion mérite une intention explicite (type élargi, clamp, cast final).

1.3 RTOS / Scheduling / Partitioning (concepts avioniques)

Le “C déterministe” vit presque toujours dans un environnement temps réel : tâches périodiques, contraintes de latence, priorités, interruptions, et parfois partitionnement (ex: concepts ARINC 653).

Diagramme : tâches périodiques (concept)

sequenceDiagram
  participant Timer as RTOS Timer
  participant Task1 as Task@10ms
  participant Task2 as Task@50ms
  participant ISR as Sensor ISR

  Timer->>Task1: Wake up (10ms)
  Task1->>Task1: Read/Validate/Compute/Output
  ISR-->>Task1: New sample (interrupt)
  Timer->>Task2: Wake up (50ms)
  Task2->>Task2: Health monitoring / logging / built-in tests

Table : risques “non déterministes” typiques

Risque	Effet	Mitigation
Priority inversion	latence imprévisible	protocoles (mutex prio-inherit), design sans lock sur boucle critique
ISR trop lourde	jitter + WCET explosif	ISR minimale + buffer + traitement en task
Partage de données	races / incohérences	double-buffer, messages, sections critiques bornées

2.1 WCET – Worst-Case Execution Time (le vrai “determinism gate”)

Ce qui rend le WCET prouvable

Chemins bornés : éviter la combinatoire (états/modes explicites).
Boucles bornées : pas de dépendance à des entrées non bornées.
IO maîtrisées : appels système/driver bornés, pas de retries infinis.
Structure stable : code simple, branches limitées, tables pré-calculées.

Exemple : boucle strictement bornée

#define N_MAX (32U)

/* Always executes at most N_MAX iterations */
int16_t dot_i16(const int16_t *a, const int16_t *b, uint16_t n)
{
    uint16_t i = 0U;
    int32_t acc = 0;

    if ((a == 0) || (b == 0) || (n == 0U) || (n > N_MAX)) { return 0; }

    for (i = 0U; i < n; i++)
    {
        acc += (int32_t)a[i] * (int32_t)b[i];
    }

    /* clamp to int16 range */
    if (acc > 32767) { acc = 32767; }
    if (acc < -32768) { acc = -32768; }
    return (int16_t)acc;
}

Ce qui casse le WCET (à bannir en boucle critique)

Pattern	Pourquoi
`while(!done) ...`	Nombre d’itérations dépend d’entrées/états, pire-cas indémontrable
allocations / frees	latence et fragmentation imprévisibles
algos non bornés	ex: tri “variable”, recherche non bornée, parsing non borné
logs “lourds”	IO variable, buffers, contention

Astuce avionique : séparer strictement la boucle de contrôle (hard real-time) et les tâches de maintenance (health monitoring / logs / BIT) avec budgets et priorités dédiés.

2.2 V&V – Tests, MC/DC, couverture, traçabilité

Table : V&V “safety-critical” (lecture pratique)

Niveau	Objectif	Artefacts	Exemples
Unit	prouver la logique locale	tests + rapports	clamp, filtrage, conversions, checks
Integration	interfaces + timings	stubs/mocks	driver capteur → normalisation → loi de commande
System	comportement global	scénarios	modes, dégradations, alarmes, transitions
Robustness	entrées “hostiles”	campagnes	valeurs extrêmes, capteur incohérent, intermittence

Exemple “testable” (pseudo-framework)

/* Given: clamp_i32(x, lo, hi) */

TEST(clamp_i32, clamps_low)
{
    ASSERT_EQ(-10, clamp_i32(-999, -10, 10));
}

TEST(clamp_i32, clamps_high)
{
    ASSERT_EQ(10, clamp_i32(999, -10, 10));
}

TEST(clamp_i32, passes_through)
{
    ASSERT_EQ(3, clamp_i32(3, -10, 10));
}

MC/DC : l’idée (sans entrer dans la jungle)

MC/DC vise à démontrer que chaque condition d’une décision logique peut influencer indépendamment le résultat. Ce n’est pas “plus de tests”, c’est des tests structurés pour lever les ambiguïtés.

/* Decision: if (A && (B || C)) */

Case  A  B  C  Result
1     0  0  0  0
2     1  0  0  0
3     1  1  0  1
4     1  0  1  1

Goal: show each of A, B, C can independently change outcome.

Traceability : le “vrai livrable”

flowchart TB
  R[System Requirements] --> SR[Software Requirements]
  SR --> AD[Architecture / Design]
  AD --> SC[Source Code]
  SR --> UT[Unit Tests]
  SR --> IT[Integration Tests]
  SR --> ST[System Tests]
  SC --> COV[Coverage Reports]
  UT --> REP[Test Reports]
  IT --> REP
  ST --> REP
  COV --> PKG[Certification Data Package]
  REP --> PKG

Une fonctionnalité “non traçable” = un risque : on ne peut pas prouver qu’elle a été spécifiée, testée, ni couverte.

2.3 Tooling : analyse statique, builds reproductibles, qualification (selon usage)

Pipeline “deterministic C” (concept CI)

1) Build (warnings treated as errors)
2) Static analysis (MISRA/CERT rules + deviations justified)
3) Unit tests (host) + reports
4) Integration tests (target or HIL) + reports
5) Structural coverage (statement/branch/MC/DC as required)
6) Packaging: traceability matrices + evidence bundle

Table : catégories d’outils et rôle

Catégorie	Objectif	Sortie attendue
Static analysis	détecter UB, violations de règles, code mort	rapports + dérogations justifiées
Compiler / linker	build maîtrisé, flags stables	binaires reproductibles
Coverage	preuve structurelle	rapports coverage par unité / module
Trace	timing/latence/jitter	mesures, logs bornés, profiling temps réel

Point d’attention : la “qualification d’outil” dépend de l’usage (outil qui peut masquer un défaut vs outil de confort). Dans un cadre avionique, on documente précisément l’outillage et ses limites.

3.1 Domaines d’application avionique (où le C déterministe est typique)

Modules typiques (lecture “safety-critical”)

Domaine	Pourquoi déterminisme ?	Exemples de contraintes
Flight Control	commande d’actionneurs, stabilité	latence max, modes, dégradations
Autopilot / Navigation	guidage, lois, modes	gestion d’états, transitions sûres
Engine control (FADEC)	moteur = safety-critical	calculs bornés, robustesse capteurs
Braking / steering	contrôle au sol / sécurité	détection défauts, fallback
Monitoring	surveillance & BIT	séparer hard RT vs maintenance

Pattern “capteur → normalisation → loi → clamp → diagnostic”

flowchart LR
  S[Sensor raw] --> V[Validate & plausibility]
  V --> N[Normalize / filter]
  N --> L[Control law]
  L --> C[Clamp / rate limit]
  C --> A[Actuator command]
  V --> D[Fault flags]
  N --> D
  L --> D

3.2 Références “avions” : A320 / 737 MAX (MCAS) – lecture engineering

Important : cette section vise à illustrer des principes de conception safety-critical (capteurs, modes, dégradations, diagnostics), pas à “refaire l’enquête”. On reste sur une lecture architecture & engineering patterns.

A320 (famille) – ce qu’on illustre côté software

Gestion de modes : “state machines” explicites, transitions contrôlées.
Lois de commande : séparation des boucles, saturation, rate limiting.
Diagnostics : plausibility checks, flags défaut, dégradation contrôlée.

Le point important ici : en avionique, un système est évalué sur sa capacité à se dégrader proprement quand l’environnement n’est plus nominal.

737 MAX / MCAS – ce que ça illustre (au niveau conception)

Dépendance capteurs : comment valider la plausibilité, gérer les incohérences et éviter l’amplification d’une mesure erronée.
Modes & autorités : “qui commande quoi”, quelles limites, quelles conditions d’activation/désactivation.
Degraded modes : que fait le logiciel quand une entrée critique devient douteuse ? (fallback / safe mode / inhibit).

Dans une perspective “deterministic C”, on cherche : états explicites, entrées validées, bornes strictes, et preuves V&V sur les transitions et les conditions limites.

Lessons “Deterministic” (transposables)

Problème à maîtriser	Pattern deterministic	Preuve attendue
Entrées capteurs “folles”	sanitization + plausibility + clamp	tests robustesse + coverage
Transition de modes	FSM explicite + invariants	tests de transitions + MC/DC (si requis)
Autorité de commande	rate limit + bounds + inhibit	analyses + campagnes de tests

3.3 Architecture : patterns sûrs (FSM, watchdog, safe defaults, diagnostics)

Pattern : machine à états (FSM) “mode-driven”

typedef enum
{
    MODE_OFF = 0,
    MODE_STANDBY,
    MODE_ACTIVE,
    MODE_DEGRADED,
    MODE_FAULT
} mode_t;

typedef struct
{
    mode_t mode;
    uint16_t fault_flags;
} ctx_t;

/* explicit transitions only */
static mode_t next_mode(mode_t cur, bool input_ok, bool health_ok)
{
    switch (cur)
    {
        case MODE_OFF:      return MODE_STANDBY;
        case MODE_STANDBY:  return input_ok ? MODE_ACTIVE : MODE_DEGRADED;
        case MODE_ACTIVE:   return health_ok ? MODE_ACTIVE : MODE_DEGRADED;
        case MODE_DEGRADED: return health_ok ? MODE_ACTIVE : MODE_FAULT;
        default:            return MODE_FAULT;
    }
}

Checklist design (vraiment avionique)

Chaque mode a des invariants (ce qui doit toujours être vrai).
Transitions explicites : pas de “magie” cachée dans 3 fonctions.
Safe defaults : en cas de doute → sortie bornée et neutre.
Diagnostics : flags, compteurs, détection d’intermittence.
Watchdog : timeouts, supervision de boucle.

Règle d’or : la sûreté se joue souvent plus dans la conception d’états et de dégradations que dans les formules.

4.1 Checklist “C déterministe” (revue de code & conception)

Checklist (copiable)

[Deterministic C Checklist]

A) Determinism
- [ ] All loops are bounded (explicit N_MAX, time budget)
- [ ] No dynamic allocation in real-time path
- [ ] No recursion, no hidden unbounded retries
- [ ] Worst-case state/mode transitions documented

B) Undefined Behavior / Types
- [ ] No signed overflow assumptions
- [ ] Shifts are guarded (0 <= shift < width)
- [ ] All variables initialized
- [ ] Explicit casts; no implicit narrowing conversions
- [ ] Use stdint.h fixed-width types everywhere

C) Interfaces / Defensive Design
- [ ] Input ranges validated (plausibility + sanity)
- [ ] Outputs clamped/rate-limited (safe defaults)
- [ ] Error handling returns explicit status codes
- [ ] Side effects are minimized and documented

D) Concurrency / Interrupts
- [ ] Shared data has a clear ownership model
- [ ] ISR is minimal; no heavy work; bounded time
- [ ] Critical sections are short and bounded
- [ ] No data races (double-buffer/message passing where possible)

E) Verification
- [ ] Unit tests cover normal + edge + invalid inputs
- [ ] Structural coverage measured (statement/branch/MC/DC as required)
- [ ] Static analysis clean; deviations justified
- [ ] Traceability exists Req -> Code -> Test -> Report

4.2 Références & ressources (standards, guidelines, concepts)

Liens “entry points” (à adapter selon tes préférences / ton référentiel IDEO-Lab).

À intégrer dans ta page IDEO-Lab : DO-178C (process), DO-330 (tool qualification), DO-331 (model-based), plus les “guidelines” C (MISRA/CERT).

4.3 Mini-projet : module “Safe Sensor Normalize” (exemple complet)

Spécification (style requirement)

ID	Requirement	Notes “deterministic”
SSR-001	Le module valide l’entrée capteur dans une plage plausible.	Entrées invalides ⇒ status explicite
SSR-002	Le module normalise en Q15 (fixed-point) et applique un clamp.	pas de float obligatoire
SSR-003	Le traitement est borné : O(1), pas de boucles non bornées.	WCET simple
SSR-004	Le module expose des diagnostics (flags + compteur).	observabilité

Implémentation (exemple)

#include 
#include 

typedef struct
{
    uint16_t invalid_count;
    uint16_t flags;
} diag_t;

#define DIAG_INVALID_RANGE (1U << 0)

/* Normalize raw (e.g., 0..4095) into Q15 [-1..+1] */
bool sensor_normalize_q15(uint16_t raw,
                          uint16_t raw_min,
                          uint16_t raw_max,
                          int16_t *out_q15,
                          diag_t *diag)
{
    int32_t num, den, q15;

    if ((out_q15 == 0) || (diag == 0) || (raw_min >= raw_max))
    {
        return false;
    }

    /* plausibility check */
    if ((raw < raw_min) || (raw > raw_max))
    {
        diag->invalid_count++;
        diag->flags |= DIAG_INVALID_RANGE;
        *out_q15 = 0; /* safe default */
        return false;
    }

    /* map [raw_min..raw_max] -> [-32768..32767] */
    num = ((int32_t)raw - (int32_t)raw_min);
    den = ((int32_t)raw_max - (int32_t)raw_min);

    /* scale to [0..65535], then shift to [-32768..32767] */
    q15 = (num * 65535) / den;
    q15 = q15 - 32768;

    if (q15 > 32767) { q15 = 32767; }
    if (q15 < -32768) { q15 = -32768; }

    *out_q15 = (int16_t)q15;
    return true;
}

Pourquoi c’est “deterministic” : pas d’allocation, pas de boucle non bornée, types explicites, checks d’entrée, sortie bornée.

Tests recommandés (edge cases)

Range invalid : raw_min >= raw_max.
Below min / above max : status false + safe default + flags + compteur.
Nominal : raw = min, mid, max (valeurs attendues).
Overflow : vérifie qu’aucun calcul intermédiaire ne dépasse int32 (selon tes bornes).

TEST(sensor_normalize_q15, below_min_sets_safe_default)
{
    int16_t out = 123;
    diag_t d = {0};

    ASSERT_FALSE(sensor_normalize_q15(10, 100, 200, &out, &d));
    ASSERT_EQ(0, out);
    ASSERT_TRUE((d.flags & DIAG_INVALID_RANGE) != 0);
    ASSERT_EQ(1, d.invalid_count);
}

⚙️ Quickstart : écrire du C “deterministic-ready” (en 10 règles)

1) Always fixed-width types: uint16_t, int32_t, ...
2) No dynamic allocation in real-time path
3) No recursion; no unbounded loops
4) Validate all inputs + plausibility checks
5) Bound outputs (clamp + rate limit) + safe defaults
6) Avoid UB: signed overflow, invalid shifts, uninit vars
7) Keep functions small, single-responsibility, testable
8) Make state machines explicit (modes, transitions)
9) Separate control loop from monitoring/logging tasks
10) Evidence-driven: tests + coverage + static analysis + traceability

🛡️ Certification & preuves : DO-178C (vue “engineering”)

La certification n’est pas “un label du langage”. C’est un processus + un dossier de preuves. Le C déterministe facilite la production de preuves (timing, absence d’UB, tests structurés, traçabilité).

Ce que cherche un auditeur

Exigences claires & traçables
Design explicite (modes / états / interfaces)
V&V robuste : tests + couverture structurelle
Analyse statique + gestion des dérogations
Build reproductible + configuration maîtrisée

Diagramme : “evidence package”

flowchart LR
  Req[Requirements] --> Code[Deterministic C Implementation]
  Code --> SA[Static Analysis Reports]
  Code --> UT[Unit Tests + Reports]
  Code --> COV[Structural Coverage]
  Req --> TM[Traceability Matrix]
  SA --> PKG[Certification Evidence Package]
  UT --> PKG
  COV --> PKG
  TM --> PKG

🛡️ Deterministic C – Safety-Critical Avionics

Le “C avionique” n’est pas un langage différent…

Définition : Deterministic C

Règles de codage : MISRA / CERT

RTOS / Partitioning

WCET & Worst-Case

V&V : tests, MC/DC, coverage

Outils qualifiés & pipeline

Domaines avionique

A320 vs 737 MAX (MCAS)

Patterns sûrs

Checklist “C déterministe”

Références & ressources

Mini-projet : module “safe clamp”