Vérification formelle des systèmes et des architectures embarqués critiques (avioniques (Airbus))

1. Vérification formelle des systèmes et des architectures embarqués critiques (avioniques (Airbus)) Frédéric Boniol ONERA, Toulouse

2. Plan • Contexte, et exemple • Systèmes embarqués • Quels besoins de vérification ? • Vérification formelle de propriétés de « sûreté de fonctionnement » • Vérification formelle de propriétés « temps-réel » • calculateur (respect d’échéance, pire temps de réponse) • réseau (pire temps de traversé) • Vérification formelle de propriétés « fonctionnelles » • Sur des modèles • Sur le code • Les problèmes non résolus, et les défis à relever • Annexe : Evolution vers la DO-178C, ce que ça va changer dans la pratique

3. Contexte, exemple, et objectifs de vérification

4. Le contexte : les systèmes embarqués critiques Quelques exemples classiques (et significatifs)

5. Le contexte : les systèmes embarqués critiques Dynamique imposée par le système à piloter Autres systèmes Autres systèmes Autres systèmes données Système pilotant électronique informatique Système à piloter (ex : une chaîne de production, une réaction chimique…) mesures événements commandes Généralisation ….

6. Le contexte : les systèmes embarqués critiques L’ascenseur ne se déplace pas les portes ouvertes => Système à états discrets Leurs principales caractéristiques … • Criticité : • Si le bon fonctionnement du système à piloter est « vital », alors le système pilotant doit être « sûr de fonctionnement » • Exemple : contrôle des portes d’un ascenseur… • Dynamique du « pilotant » assujettie à la dynamique du « piloté » • Si le système à piloter a sa propre dynamique (dans le temps), et si son bon fonctionnement est « vital », alors le système pilotant doit être « temps-réel ». • Exemples : contrôle moteur, contrôle de la trajectoire d’un aéronef, contrôle d’une réaction nucléaire…

7. Le contexte : les systèmes embarqués critiques Démonstration de l’absence d’erreurs dans la spécification et dans le logiciel Leurs principales caractéristiques … • Criticité : • Si le bon fonctionnement du système à piloter est « vital », alors le système pilotant doit être « sûr de fonctionnement » • Exemple : contrôle des portes d’un ascenseur… • Dynamique du « pilotant » assujettie à la dynamique du « piloté » • Si le système à piloter a sa propre dynamique (dans le temps), et si son bon fonctionnement est « vital », alors le système pilotant doit être « temps-réel ». • Exemples : contrôle moteur, contrôle de la trajectoire d’un aéronef, contrôle d’une réaction nucléaire… Démonstration de la tolérance aux défaillances Démonstration de la correction temporelle du système

8. Zoom sur les systèmes de contrôle commande critique … Exemple : les commandes de vol …

9. Exemple : les commandes de vol (CdV)… Cde de vol Liaison électrique Pilote automatique Servocommande Liaison électrique Câble mécanique Commande électriques « lois normales » (A320, A330, A340, A380 … ) SM Servomoteur Pilote automatique Evolution du système de contrôle du vol … en 25 ans Liaison électrique Commande classique « servomoteur » (A300 / A310)

10. Exemple : les commandes de vol (CdV)… Cde de vol Liaison électrique Pilote automatique Liaison électrique Commande électriques « lois normales » (A320, A330, A340, A380 … )

11. Exemple : les commandes de vol (CdV)… • Système « pilotant » = « Cde de vol » • Système « à piloter » = l’avion • = vital (transport de personne) • => exigences de sûreté de fonctionnement pour les CdV • => exigences d’absence d’erreur comportementale • => exigences d’absence d’erreur à l’exécution • = dynamique (mouvement physique suivant des équations différentielles) • => exigences de temps-réel pour les CdV Cde de vol Liaison électrique Pilote automatique Liaison électrique Commande électriques « lois normales » (A320, A330, A340, A380 … )

12. Exemple : les commandes de vol (CdV)… Cequ’il faut vérifier : 1. la sûreté de fonctionnement • Vérifier que • compte tenu de l’architecture du système, de ses logiques de redondance et de reconfiguration, des exigences allouées à chaque fonction, du comportement dysfonctionnel de chaque composant physique • alors chaque fonction répond aux objectifs de taux de défaillance.

13. Exemple : les commandes de vol (CdV)… Cequ’il faut vérifier : 2. la correction fonctionnelle • Vérifier que les modèles et le code C satisfont : • des exigences de contrôle (précision, robustesse des lois de commandes…) • des exigences de sûreté de fonctionnement (détection de pannes…) • … Modèles SCADE + codage automatique + codage manuel C • Vérifier que le code C ne contient pas d’erreurs : • division par zéro • débordement de range • …

14. Exemple : les commandes de vol (CdV)… Cequ’il faut vérifier : 3. le comportement temps-réel Calculer pour chaque communication le temps de traversée pire cas du réseau Système multi-tâche + ordonnancement temps réel Réseau de communication Calculer le temps d’exécution pire cas de chaque tâche (WCET) Calculer pour chaque chaine fonctionnelle, ses caractéristiques temps-réel (latences, fraicheur des données…) Vérifier que chaque tâche respecte ses exigences temps-réel (échéance, gigue…)

15. Exemple : les commandes de vol (CdV)… Cequ’il faudrait aussi vérifier : la sécurité des données…. ?

16. 2. Vérification de propriétés de sûreté de fonctionnement (Pierre Bieber)

17. Exemple : les commandes de vol (CdV)… Cde de vol Liaison électrique Pilote automatique Liaison électrique Catastrophique Mineure Hazardous Hazardous Hazardous Catastrophique 10-9 = 10-5 = 10-7 = 10-7 = 10-7 = 10-9 = Les exigences de sûreté de fonctionnement dépendent de la fonction du système : • Appliquer les ordres de pilotage aux gouvernes (calcul des angles de déflection et application des angles) • Contrôle du trim (réduction des efforts sur la gouverne de profondeur) • Offrir un pilotage indépendant de la configuration de vol • Offrir un virage à altitude constante • Contrôler les oscillations de l’avion • Le roulis hollandais • Les oscillations de la structure • …

18. Exemple : les commandes de vol (CdV)… Cde de vol Liaison électrique Pilote automatique Liaison électrique • Exigence de démonstration que • La probabilité que la fonction ne soit plus remplie consécutivement à une panne matérielle est inférieure au taux requis • Analyse dysfonctionnelle !! Catastrophique Mineure Hazardous Hazardous Hazardous Catastrophique 10-9 = 10-5 = 10-7 = 10-7 = 10-7 = 10-9 =

19. Analyse dysfonctionnelle Listes des événements redoutés Estimation des probabilités des événements redoutés Listes de pannes + probabilités Modes de défaillance des composants actifs Analyses « dysfonctionnelles » : démarche générale À partir de l’architecture du système… • Identification des « événements redoutés » • Identification des pannes possibles sur cette architecture, et de leur relation de dépendance • Identification des probabilités de ces pannes • Identification de leurs effets sur les composants actifs du système (capteurs, actionneurs, fonctions)

20. Analyse dysfonctionnelle ? Listes des événements redoutés Estimation des probabilités des événements redoutés Listes de pannes + probabilités Modes de défaillance des composants actifs Mais … !!! • Un très grand nombre (voire une infinité) de modes de défaillance possibles • Analyse impossible à un niveau « grain fin » • Abstraction nécessaire !! • Idée : abstraction des fonctions et des flux

21. Analyse dysfonctionnelle ? acmd in {ok, ko, err} cmd : [-10;+10] Aa A Fa F C Ca aobs in {ok, ko, err} obs : [-10;+10] Schéma abstrait Schéma fonctionnel concret Mais … !!! • Un très grand nombre (voire une infinité) de modes de défaillance possibles • Analyse impossible à un niveau « grain fin » • Abstraction nécessaire !! • Idée : abstraction des fonctions et des flux gouva in {ok, ko, err} gouv : [-10;+10] abstraction

22. Analyse dysfonctionnelle ? gouva = err acmd = err Aa Fa acmd = ok Ca aobs = err Aa Fa dysfonctionnel 2 acmd = ok Ca gouva = err aobs = ok gouva = err acmd = err Aa Fa Aa nominal Fa Ca aobs = ok Ca aobs = ok dysfonctionnel 3 dysfonctionnel 1 Puis… • Étude des comportements de panne sur le modèle abstrait gouva = ok

23. Analyse dysfonctionnelle ? gouva = err acmd = err Aa Fa acmd = ok Ca aobs = err Aa Fa dysfonctionnel 2 acmd = ok Ca gouva = err aobs = ok gouva = err acmd = err Aa Fa Aa nominal Fa Ca aobs = ok Ca aobs = ok dysfonctionnel 3 dysfonctionnel 1 panne C gouva = ok panne F panne A

24. Analyse dysfonctionnelle ? obsa = err cmda = err gouva = err panne C obsa = ok cmda = ok gouva = ok panne F panne C obsa = ok cmda = err gouva = err panne A panne C obsa = ok cmda = ok gouva = err panne F • Un graphe fini de modes de défaillances • Génération d’arbres de défaillances • Calcul de la probabilité d’avoir la gouverne en état « err » • P(gouv=err) ~ P(panne C) + P(panne A) + P(panne F)

25. AltaRica pour l’analyse des dysfonctionnements • Approche formalisée par la langage AltaRica (LaBRI) • Langage à base d’automates de contraintes • Sémantique formelle : automate asynchrone + vecteurs de synchronisation z1 o1 V1 F1 C1 A1 alt1 ordre1 • Evénement redouté : perte non détectée de ordre1 et ordre2 • Exigence : • proba < 10-7 R1 R4 A2 alt2 R2 z2 o2 V2 F2 C2 ordre2 R5 A3 alt3 R3

26. AltaRica pour l’analyse des dysfonctionnements perteAi Ai : Ri : perteRi OKi KOi OKi KOi in OKi : alti = ok; in KOi : alti = ko; in ERRi : alti = err; perteNDAi perteNDRi ERRi ERRi Synch : (perteRi, perteAi), (perteNDRi, perteNDAi) pour i=1,3 • Proba : • perteRi = 10-3 • perteNDRi = 10-4 z1 o1 V1 F1 C1 A1 alt1 ordre1 R1 R4 A2 alt2 R2 z2 o2 V2 F2 C2 ordre2 R5 A3 alt3 R3

27. AltaRica pour l’analyse des dysfonctionnements perteVi Vi : OKi KOi in OKi : zi= vote(alt1,alt2,alt3); in KOi : zi= ko; in ERRi : zi= err; perteNDVi ERRi Synch : (perteR4, perteV1), (perteNDR4, perteNDV1) Synch : (perteR5, perteV2), (perteNDR5, perteNDV2) z1 o1 V1 F1 C1 A1 alt1 ordre1 R1 R4 A2 alt2 R2 z2 o2 V2 F2 C2 ordre2 R5 A3 alt3 R3

28. AltaRica pour l’analyse des dysfonctionnements perteFi Fi : OKi KOi in OKi : oi= zi; in KOi : oi= ko; in ERRi : oi= err; perteNDFi ERRi Synch : (perteR4, perteF1), (perteNDR4, perteNDF1) Synch : (perteR5, perteF2), (perteNDR4, perteNDF2) z1 o1 V1 F1 C1 A1 alt1 ordre1 R1 R4 A2 alt2 R2 z2 o2 V2 F2 C2 ordre2 R5 A3 alt3 R3

29. AltaRica pour l’analyse des dysfonctionnements perteCi Ci : OKi KOi in OKi : ordrei = if (o1==o2) then oi else ko; in KOi : oi= ko; in ERRi : oi= err; perteNDCi ERRi Synch : (perteR4, perteC1), (perteNDR4, perteNDC1) Synch : (perteR5, perteC2), (perteNDR4, perteNDC2) z1 o1 V1 F1 C1 A1 alt1 ordre1 R1 R4 A2 alt2 R2 z2 o2 V2 F2 C2 ordre2 R5 A3 alt3 R3

30. AltaRica pour l’analyse des dysfonctionnements • Configurations à 2 pannes menant à l’événement redouté : • perteNDR1 + perteNDR2 • perteNDR1 + perteNDR3 • perteNDR2 + perteNDR3 • perteNDR4 + perteNDR5 • … Proba ≈ 4.10-8 z1 o1 V1 F1 C1 A1 alt1 ordre1 • Evénement redouté : perte non détectée de ordre1 et ordre2 • Exigence : • proba < 10-7 R1 R4 A2 alt2 R2 z2 o2 V2 F2 C2 ordre2 R5 A3 alt3 R3

31. AltaRica pour l’analyse des dysfonctionnements • Configurations à 2 pannes menant à l’événement redouté : • perteNDR1 + perteNDR2 • perteNDR1 + perteNDR3 • perteNDR2 + perteNDR3 • perteNDR4 + perteNDR5 • perteNDR1 + perteR2, … => Proba ≈ 6,4 . 10-7 • => Exigence non respectée !!! z1 o1 V1 F1 C1 A1 alt1 ordre1 • Evénement redouté : perte non détectée de ordre1 et ordre2 • Exigence : • proba < 10-7 R1 R4 A2 alt2 R2 z2 o2 V2 F2 C2 ordre2 R5 A3 alt3 R3

32. AltaRica pour l’analyse des dysfonctionnements • Approche formalisée par la langage AltaRica • Possibilité de vérifier des propriétés d’accessibilité (ou de non accessibilité) d’un événement redouté donné (par model checking) • Possibilité de générer automatiquement des arbres de défaillances, puis de calculer les coupes minimales et les probabilités des événements redoutés • Outil développé par Dassault-System (Cecilia-OCAS) • Utilisation opérationnelle par Airbus pour l’ensemble des systèmes (y compris les systèmes non informatiques).

33. 3. Vérification de propriétés « temps-réel »

34. La question du temps réel L’ascenseur ne se déplace par les porte ouverte => Système à états discrets Leurs principales caractéristiques (rappel) … • Criticité : • Si le bon fonctionnement du système à piloter est « vital », alors le système pilotant doit être « sûr de fonctionnement » • Exemples : contrôle des portes d’un ascenseur… • Dynamique du « pilotant » assujettie à la dynamique du « piloté » • Si le système à piloter a sa propre dynamique (dans le temps), et si son bon fonctionnement est « vital », alors le système pilotant doit être temps réel. • Exemples : contrôle moteur, contrôle de la trajectoire d’un aéronef, contrôle d’une réaction nucléaire…

35. Exemple : les commandes de vol (CdV)… L’exemple dans l’exemple : le contrôle du roulis en lacet Angle de lacet temps

36. Exemple : les commandes de vol (CdV)… L’exemple dans l’exemple : le contrôle du roulis en lacet Angle de lacet temps Une commande correcte « dans les temps »

37. Exemple : les commandes de vol (CdV)… L’exemple dans l’exemple : le contrôle du roulis en lacet Angle de lacet temps Une commande incorrecte temporellement (à contre temps) => Commande correcte fonctionnellement mais aux mauvais instants !

38. Exemple : les commandes de vol (CdV)… Fréquence de la boucle Latence capteur Cde de vol Liaison électrique Pilote automatique Liaison électrique Latence calculateur + réseau Temps de réponse actionneur Angle de lacet temps • Présence dans le système de : • - retards • - gigues

39. Exemple : les commandes de vol (CdV)… Fréquence de la boucle Latence capteur Cde de vol Liaison électrique Pilote automatique Liaison électrique Latence calculateur + réseau Temps de réponse actionneur Angle de lacet temps • Présence dans le système de : • - retards • - gigues • Besoin : calcul de bornes supérieures de ces • retards • gigues

40. La question du temps réel Worst case execution time (WCET) ? Worst case response time (WCRT) ? F3, F4 • Présence dans le système de : • - retards • - gigues F1, F2 • Besoin : calcul de bornes supérieures de ces • retards • gigues Worst case traversal time (WCTT) ? Worst case freshness (WCF) ? F5, F6 • Deux niveaux • calcuteurs • réseaux

41. La question du temps réel • En général, calculs infaisables  • Seule solution : tests et mesures => Devenus impossibles dans les architectures « modernes » (asynchrones) • Mais, bonne nouvelle : dans les systèmes critiques • Calculateurs simples sans mécanismes d’optimisation • Logiciels simples (sans pointeurs, sans dynamicité…) • Architectures logicielles simples (tâches périodiques, priorités fixes, pas de création d’objets…) • WCET et WCRT calculables  • Protocoles réseaux à base de contrats et sanction en cas de non respect des contrats • Trafics réseaux simples (périodiques, sans dynamicité…) => WCTT calculable 

42. Calcul du WCET (1/1) • WCET : Méthode (en bref) • Au niveau du code binaire • Modélisation de l’exécution du programme sous la forme d’un ILP • Prise en compte des politiques de gestion des ressources du processeur (cache, pipe-line) (pire cas calculé par interprétation abstraite) • Expression du temps d’exécution comme une expression de l’ILP • Recherche du maximum de cette expression • Outils (chez Airbus) : aiT • Développé par Absint (www.absint.com) • DO-178B niveau A  • Limite : • ne marche pas pour les processeurs modernes (multi-core) 

43. Calcul du WCRT (1/1) • WCRT : Méthode (en bref) • Dans le cas de tâches indépendantes à priorités fixes • Nombreux outils • (mais Excel suffit) • Limite • Ne s’applique que pour les systèmes de tâches périodiques à priorité fixe • Ne s’applique que pour les architectures mono-processeurs • Alternative : model checking…

44. Calcul du WCTT (1/4) y(t) X(t) F3, F4 • WCTT : Méthode (en bref) • Méthode du « Network Calculus » • Base mathématique = algèbre (min, +) • Idées (simples) du Network Calculus • À partir d’une « enveloppe » maximale du trafic entrant X(t) • A partir d’une caractérisation du service de chaque switch • minimale β(t) • maximale Β(t) • Calcul du trafic sortant • minimal y(t) • maximal Y(t) β(t) F1, F2 F5, F6

45. Calcul du WCTT (2/4) y(t) X(t) F3, F4 • Idées (simples) du Network Calculus (suite) => Calcul du délai β(t) F1, F2 F5, F6

46. Calcul du WCTT (3/4) y(t) X(t) F3, F4 • Idées (simples) du Network Calculus (suite) => Dimensionnement du switch β(t) F1, F2 F5, F6

47. Calcul du WCTT (4/4) F3, F4 • Outils (chez Airbus) : ConfGen (outil maison) • Utilisé pour la certification A380 • Limite : • Suppose que chaque flux respecte son contrat • Pas de nouveaux flux en cours d’opération • Pas de prise en compte de niveaux de priorité F1, F2 F5, F6

48. 4. Vérification fonctionnelle - Au niveau des modèles - Au niveau du code (Virginie Wiels)

49. Exemple : les commandes de vol (CdV)… Cequ’il faut vérifier : 2. la correction fonctionnelle • Vérifier que les modèles et le code C satisfont • des exigences de contrôle (précision, robustesse des lois de commandes…) • des exigences de sûreté de fonctionnement (détection de pannes…) • … Modèles SCADE + codage automatique + codage manuel C • Vérifier que le code C ne contient pas d’erreurs • division par zéro • débordement de range • …

50. La question de la vérification fonctionnelle • En général problème difficile • Mais, deux bonnes nouvelles (avionique – Airbus) 1.Model based design • Basé sur le langage synchrone SCADE : sémantique formelle et déterministe • Réduction de l’espace des états • Espoir d’application des techniques de model-checking • Génération de code « certifié » automatique • Vérifier les modèles suffit à la vérification du système 2. Les logiciels codés manuellement sont simples • Pas de pointeur, pas d’allocation dynamique de mémoire, pas de code dynamique… • Espoir d’application des techniques de vérification de logiciel