La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Frédéric Boniol12-14 juin 2011 – R2I2011 Vérification formelle des systèmes et des architectures embarqués critiques (avioniques (Airbus)) Frédéric Boniol.

Présentations similaires


Présentation au sujet: "Frédéric Boniol12-14 juin 2011 – R2I2011 Vérification formelle des systèmes et des architectures embarqués critiques (avioniques (Airbus)) Frédéric Boniol."— Transcription de la présentation:

1 Frédéric Boniol12-14 juin 2011 – R2I2011 Vérification formelle des systèmes et des architectures embarqués critiques (avioniques (Airbus)) Frédéric Boniol ONERA, Toulouse

2 Frédéric Boniol12-14 juin 2011 – R2I2011 Plan 1.Contexte, et exemple Systèmes embarqués Quels besoins de vérification ? 2.Vérification formelle de propriétés de « sûreté de fonctionnement » 3.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é) 4.Vérification formelle de propriétés « fonctionnelles » –Sur des modèles –Sur le code 5.Les problèmes non résolus, et les défis à relever 6.Annexe : Evolution vers la DO-178C, ce que ça va changer dans la pratique

3 Frédéric Boniol12-14 juin 2011 – R2I Contexte, exemple, et objectifs de vérification

4 Frédéric Boniol12-14 juin 2011 – R2I2011 Le contexte : les systèmes embarqués critiques Quelques exemples classiques (et significatifs)

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

6 Frédéric Boniol12-14 juin 2011 – R2I2011 Le contexte : les systèmes embarqués critiques 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 dun 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 dun aéronef, contrôle dune réaction nucléaire… Lascenseur ne se déplace pas les portes ouvertes => Système à états discrets

7 Frédéric Boniol12-14 juin 2011 – R2I2011 Le contexte : les systèmes embarqués critiques 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 dun 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 dun aéronef, contrôle dune réaction nucléaire… Démonstration de labsence derreurs dans la spécification et dans le logiciel Démonstration de la tolérance aux défaillances Démonstration de la correction temporelle du système

8 Frédéric Boniol12-14 juin 2011 – R2I2011 Zoom sur les systèmes de contrôle commande critique … Exemple : les commandes de vol …

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

10 Frédéric Boniol12-14 juin 2011 – R2I2011 Exemple : les commandes de vol (CdV)… Commande électriques « lois normales » (A320, A330, A340, A380 … ) Pilote automatique Liaison électrique Cde de vol

11 Frédéric Boniol12-14 juin 2011 – R2I2011 Exemple : les commandes de vol (CdV)… - Système « pilotant » = « Cde de vol » - Système « à piloter » = lavion = vital (transport de personne) => exigences de sûreté de fonctionnement pour les CdV => exigences dabsence derreur comportementale => exigences dabsence derreur à lexécution = dynamique (mouvement physique suivant des équations différentielles) => exigences de temps-réel pour les CdV Commande électriques « lois normales » (A320, A330, A340, A380 … ) Pilote automatique Liaison électrique Cde de vol

12 Frédéric Boniol12-14 juin 2011 – R2I2011 Exemple : les commandes de vol (CdV)… Ce quil faut vérifier : 1. la sûreté de fonctionnement Vérifier que - compte tenu de larchitecture 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. Vérifier que - compte tenu de larchitecture 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 Frédéric Boniol12-14 juin 2011 – R2I2011 Exemple : les commandes de vol (CdV)… Ce quil faut vérifier : 2. la correction fonctionnelle Modèles SCADE + codage automatique + codage manuel C 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…) - … 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…) - … Vérifier que le code C ne contient pas derreurs : - division par zéro - débordement de range - … Vérifier que le code C ne contient pas derreurs : - division par zéro - débordement de range - …

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

15 Frédéric Boniol12-14 juin 2011 – R2I2011 Exemple : les commandes de vol (CdV)… Ce quil faudrait aussi vérifier : la sécurité des données…. ?

16 Frédéric Boniol12-14 juin 2011 – R2I Vérification de propriétés de sûreté de fonctionnement (Pierre Bieber)

17 Frédéric Boniol12-14 juin 2011 – R2I2011 Exemple : les commandes de vol (CdV)… –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 lavion Le roulis hollandais Les oscillations de la structure … Les exigences de sûreté de fonctionnement dépendent de la fonction du système : Catastrophique Mineure Hazardous Catastrophique = = = = Pilote automatique Liaison électrique Cde de vol

18 Frédéric Boniol12-14 juin 2011 – R2I2011 Exemple : les commandes de vol (CdV)… 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 Catastrophique = = = = Pilote automatique Liaison électrique Cde de vol

19 Frédéric Boniol12-14 juin 2011 – R2I2011 Analyse dysfonctionnelle Analyses « dysfonctionnelles » : démarche générale À partir de larchitecture 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) Listes des événements redoutés Listes de pannes + probabilités Modes de défaillance des composants actifs Estimation des probabilités des événements redoutés

20 Frédéric Boniol12-14 juin 2011 – R2I2011 Analyse dysfonctionnelle ? 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 Listes des événements redoutés Listes de pannes + probabilités Modes de défaillance des composants actifs Estimation des probabilités des événements redoutés

21 Frédéric Boniol12-14 juin 2011 – R2I2011 Analyse dysfonctionnelle ? 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 FaFa AaAa CaCa a obs in {ok, ko, err} a cmd in {ok, ko, err} Schéma abstrait gouv a in {ok, ko, err} F A C obs : [-10;+10] cmd : [-10;+10] Schéma fonctionnel concret gouv : [-10;+10] abstraction

22 Frédéric Boniol12-14 juin 2011 – R2I2011 Analyse dysfonctionnelle ? Puis… –Étude des comportements de panne sur le modèle abstrait FaFa AaAa CaCa a obs = err a cmd = err dysfonctionnel 2 gouv a = err FaFa AaAa CaCa a obs = ok a cmd = err dysfonctionnel 1 gouv a = err FaFa AaAa CaCa a obs = ok a cmd = ok nominal FaFa AaAa CaCa a obs = ok a cmd = ok dysfonctionnel 3 gouv a = err gouv a = ok

23 Frédéric Boniol12-14 juin 2011 – R2I2011 Analyse dysfonctionnelle ? FaFa AaAa CaCa a obs = ok a cmd = ok nominal FaFa AaAa CaCa a obs = ok a cmd = ok dysfonctionnel 3 gouv a = err panne C panne F panne A gouv a = ok FaFa AaAa CaCa a obs = ok a cmd = err dysfonctionnel 1 gouv a = err FaFa AaAa CaCa a obs = err a cmd = err dysfonctionnel 2 gouv a = err

24 Frédéric Boniol12-14 juin 2011 – R2I2011 Analyse dysfonctionnelle ? Un graphe fini de modes de défaillances Génération darbres de défaillances Calcul de la probabilité davoir la gouverne en état « err » P(gouv=err) ~ P(panne C) + P(panne A) + P(panne F) panne C panne A panne F obs a = ok cmd a = ok gouv a = ok obs a = err cmd a = err gouv a = err obs a = ok cmd a = ok gouv a = err obs a = ok cmd a = err gouv a = err panne C panne F panne C

25 Frédéric Boniol12-14 juin 2011 – R2I2011 AltaRica pour lanalyse des dysfonctionnements Approche formalisée par la langage AltaRica (LaBRI) –Langage à base dautomates de contraintes –Sémantique formelle : automate asynchrone + vecteurs de synchronisation R1 A1 R2 A2 R3 A3 alt1 alt2 alt3 R4 V1 F1 C1 z1o1 R5 V2 F2 C2 z2o2 ordre1 ordre2 Evénement redouté : perte non détectée de ordre1 et ordre2 Exigence : proba < 10 -7

26 Frédéric Boniol12-14 juin 2011 – R2I2011 AltaRica pour lanalyse des dysfonctionnements R1 A1 R2 A2 R3 A3 alt1 alt2 alt3 R4 V1 F1 C1 z1o1 R5 V2 F2 C2 z2o2 ordre1 ordre2 Ri : OKi KOi ERRi perteRi perteNDRi Ai : OKi KOi ERRi in OKi : alti = ok; in KOi : alti = ko; in ERRi : alti = err; perteAi perteNDAi Synch : (perteRi, perteAi), (perteNDRi, perteNDAi) pour i=1,3 Proba : -perteRi = perteNDRi = Proba : -perteRi = perteNDRi = 10 -4

27 Frédéric Boniol12-14 juin 2011 – R2I2011 AltaRica pour lanalyse des dysfonctionnements R1 A1 R2 A2 R3 A3 alt1 alt2 alt3 R4 V1 F1 C1 z1o1 R5 V2 F2 C2 z2o2 ordre1 ordre2 Vi : OKi KOi ERRi in OKi : zi= vote(alt1,alt2,alt3); in KOi : zi= ko; in ERRi : zi= err; perteVi perteNDVi Synch : (perteR4, perteV1), (perteNDR4, perteNDV1) Synch : (perteR5, perteV2), (perteNDR5, perteNDV2)

28 Frédéric Boniol12-14 juin 2011 – R2I2011 AltaRica pour lanalyse des dysfonctionnements R1 A1 R2 A2 R3 A3 alt1 alt2 alt3 R4 V1 F1 C1 z1o1 R5 V2 F2 C2 z2o2 ordre1 ordre2 Fi : OKi KOi ERRi perteFi perteNDFi Synch : (perteR4, perteF1), (perteNDR4, perteNDF1) Synch : (perteR5, perteF2), (perteNDR4, perteNDF2) in OKi : oi= zi; in KOi : oi= ko; in ERRi : oi= err;

29 Frédéric Boniol12-14 juin 2011 – R2I2011 AltaRica pour lanalyse des dysfonctionnements R1 A1 R2 A2 R3 A3 alt1 alt2 alt3 R4 V1 F1 C1 z1o1 R5 V2 F2 C2 z2o2 ordre1 ordre2 Ci : OKi KOi ERRi perteCi perteNDCi Synch : (perteR4, perteC1), (perteNDR4, perteNDC1) Synch : (perteR5, perteC2), (perteNDR4, perteNDC2) in OKi : ordrei = if (o1==o2) then oi else ko; in KOi : oi= ko; in ERRi : oi= err;

30 Frédéric Boniol12-14 juin 2011 – R2I2011 AltaRica pour lanalyse des dysfonctionnements R1 A1 R2 A2 R3 A3 alt1 alt2 alt3 R4 V1 F1 C1 z1o1 R5 V2 F2 C2 z2o2 ordre1 ordre2 Configurations à 2 pannes menant à lévénement redouté : -perteNDR1 + perteNDR2 -perteNDR1 + perteNDR3 -perteNDR2 + perteNDR3 -perteNDR4 + perteNDR5 - … Evénement redouté : perte non détectée de ordre1 et ordre2 Exigence : proba < Proba

31 Frédéric Boniol12-14 juin 2011 – R2I2011 AltaRica pour lanalyse des dysfonctionnements R1 A1 R2 A2 R3 A3 alt1 alt2 alt3 R4 V1 F1 C1 z1o1 R5 V2 F2 C2 z2o2 ordre1 ordre2 Configurations à 2 pannes menant à lévénement redouté : -perteNDR1 + perteNDR2 -perteNDR1 + perteNDR3 -perteNDR2 + perteNDR3 -perteNDR4 + perteNDR5 -perteNDR1 + perteR2, … => Proba 6, => Exigence non respectée !!! Evénement redouté : perte non détectée de ordre1 et ordre2 Exigence : proba < 10 -7

32 Frédéric Boniol12-14 juin 2011 – R2I2011 AltaRica pour lanalyse des dysfonctionnements Approche formalisée par la langage AltaRica –Possibilité de vérifier des propriétés daccessibilité (ou de non accessibilité) dun é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 lensemble des systèmes (y compris les systèmes non informatiques).

33 Frédéric Boniol12-14 juin 2011 – R2I Vérification de propriétés « temps-réel »

34 Frédéric Boniol12-14 juin 2011 – R2I2011 La question du temps réel 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 dun 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 dun aéronef, contrôle dune réaction nucléaire… Lascenseur ne se déplace par les porte ouverte => Système à états discrets

35 Frédéric Boniol12-14 juin 2011 – R2I2011 Exemple : les commandes de vol (CdV)… Lexemple dans lexemple : le contrôle du roulis en lacet Angle de lacet temps

36 Frédéric Boniol12-14 juin 2011 – R2I2011 Exemple : les commandes de vol (CdV)… Lexemple dans lexemple : le contrôle du roulis en lacet Angle de lacet temps Une commande correcte « dans les temps »

37 Frédéric Boniol12-14 juin 2011 – R2I2011 Exemple : les commandes de vol (CdV)… Lexemple dans lexemple : 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 Frédéric Boniol12-14 juin 2011 – R2I2011 Exemple : les commandes de vol (CdV)… Présence dans le système de : - retards - gigues Pilote automatique Liaison électrique Cde de vol Fréquence de la boucle Latence capteur Temps de réponse actionneur Latence calculateur + réseau temps Angle de lacet

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

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

41 Frédéric Boniol12-14 juin 2011 – R2I2011 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 doptimisation –Logiciels simples (sans pointeurs, sans dynamicité…) –Architectures logicielles simples (tâches périodiques, priorités fixes, pas de création dobjets…) 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 Frédéric Boniol12-14 juin 2011 – R2I2011 Calcul du WCET (1/1) WCET : Méthode (en bref) –Au niveau du code binaire –Modélisation de lexécution du programme sous la forme dun 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 dexécution comme une expression de lILP –Recherche du maximum de cette expression Outils (chez Airbus) : aiT –Développé par Absint (www.absint.com)www.absint.com –DO-178B niveau A Limite : –ne marche pas pour les processeurs modernes (multi-core)

43 Frédéric Boniol12-14 juin 2011 – R2I2011 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 sapplique que pour les systèmes de tâches périodiques à priorité fixe –Ne sapplique que pour les architectures mono-processeurs Alternative : model checking…

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

45 Frédéric Boniol12-14 juin 2011 – R2I2011 Calcul du WCTT (2/4) Idées (simples) du Network Calculus (suite) => Calcul du délai F1, F2 F3, F4 F5, F6 X(t) y(t) β(t)

46 Frédéric Boniol12-14 juin 2011 – R2I2011 Calcul du WCTT (3/4) Idées (simples) du Network Calculus (suite) => Dimensionnement du switch F1, F2 F3, F4 F5, F6 X(t) y(t) β(t)

47 Frédéric Boniol12-14 juin 2011 – R2I2011 Calcul du WCTT (4/4) 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 dopération –Pas de prise en compte de niveaux de priorité F1, F2 F3, F4 F5, F6

48 Frédéric Boniol12-14 juin 2011 – R2I Vérification fonctionnelle - Au niveau des modèles - Au niveau du code (Virginie Wiels)

49 Frédéric Boniol12-14 juin 2011 – R2I2011 Exemple : les commandes de vol (CdV)… Ce quil faut vérifier : 2. la correction fonctionnelle Modèles SCADE + codage automatique + codage manuel C Vérifier que le code C ne contient pas derreurs - division par zéro - débordement de range - … Vérifier que le code C ne contient pas derreurs - division par zéro - débordement de range - … 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…) - … 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…) - …

50 Frédéric Boniol12-14 juin 2011 – R2I2011 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 lespace des états Espoir dapplication 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 dallocation dynamique de mémoire, pas de code dynamique… Espoir dapplication des techniques de vérification de logiciel

51 Frédéric Boniol12-14 juin 2011 – R2I2011 La question de la vérif. fonctionnelle : au niveau modèle Le cycle Airbus…

52 Frédéric Boniol12-14 juin 2011 – R2I2011 La question de la vérif. fonctionnelle : au niveau modèle Vérification de modèles SCADE : par model checking –Exigences : propriétés de « safety » = jamais une mauvaise chose –Exemple : « sous lhypothèse que les deux manches ne tombent pas en panne, il y a toujours un manche considéré actif pendant toute période de 100ms » Retour dexpérience (1/2) : –Pas adapté aux modèle SCADE contenant des réels ou des entiers –Adapté aux modèles booléens

53 Frédéric Boniol12-14 juin 2011 – R2I2011 La question de la vérif. fonctionnelle : au niveau modèle Retour dexpérience (2/2) : –Encore inefficace pour montrer quun système SCADE ne contient pas derreur –Efficace pour trouver les erreurs –(Difficulté dinterpréter les contre-exemple) Utilisation du model checking en moyen de débugg itératif, en non pas en certification

54 Frédéric Boniol12-14 juin 2011 – R2I2011 La question de la vérif. Fonctionnelle : au niveau du code Le cycle Airbus…

55 Frédéric Boniol12-14 juin 2011 – R2I2011 La question de la vérif. fonctionnelle : au niveau du code Au niveau du logiciel codé manuellement (en C) –Rappel : le logiciel est simple Possibilité (espoir) dappliquer des méthodes de « preuve » ou de « vérification » Retour dexpérience (1/3) 1. Méthode de preuve de type Logique de Hoare (méthode déductive, weakest precondition) –Vérification de la conformité du code aux exigences de bas niveau, en remplacement du test unitaire Pas de division par zéro, pas de racine carré négative… –interactif –Outils : CAVEAT, FRAM-C (CEA) –Qualifié DO-178B niveau A pour A380

56 Frédéric Boniol12-14 juin 2011 – R2I2011 La question de la vérif. fonctionnelle : au niveau du code Retour dexpérience (2/3) 2. Méthode par interprétation abstraite –Preuve dabsence de RTE telles que division par zéro, numerical overflow, out of bounds access to an array. –Automatique –Outils : ASTREE (Ecole Normale Supérieure, et commercialisé par Absint)

57 Frédéric Boniol12-14 juin 2011 – R2I2011 La question de la vérif. fonctionnelle : au niveau du code Retour dexpérience (3/3) 3. Méthode par interprétation abstraite –Calcul des erreurs numériques (arrondi) introduites par les opérateurs numériques –Sur le C ou lassembleur –Automatique –Outils : FLUCTUAT (CEA) Bilan –Bonne couverture du niveau C –Couverture du niveau modèle encore à améliorer

58 Frédéric Boniol12-14 juin 2011 – R2I Les problèmes non résolus, et les défis à relever

59 Frédéric Boniol12-14 juin 2011 – R2I2011 Synthèse : ce qui est bien / mal fait … Vérif. temps-réel Vérif. fonctionnelle des modèles Vérif. du logiciel Vérif. sûreté de fonctionnement Vérif. sécurité des données Pour les systèmes actuels…

60 Frédéric Boniol12-14 juin 2011 – R2I2011 Les défis à relever… (1/2) Corrélation entre les différents modèles de vérification ? –Comment garantir que le modèle AltaRica de sûreté de fonctionnement est une abstraction correcte du système (et de ses logiciels) ? Intégration des architectures multi-core –Impact sur les méthodes de vérification temps-réel ? Evolution vers des fonctions plus événementielles –Complexification des trafics réseaux –Complexification des ordonnancements calculateurs

61 Frédéric Boniol12-14 juin 2011 – R2I2011 Les défis à relever… (2/2) Evolution vers des nouveaux patterns darchitectures –Orientées services –Reconfigurables Passage à léchelle du model-checking Prise en compte de la dimension sécurité –Nouvelles architectures de sécurité pour les systèmes embarqués ?

62 Frédéric Boniol12-14 juin 2011 – R2I Annexe : Evolution vers la DO-178C : Ce que ça changera, en quoi les méthodes formelles seront reconnues… (Virginie Wiels)

63 Frédéric Boniol12-14 juin 2011 – R2I2011 Certification et méthodes formelles Méthodes formelles utilisées pour les systèmes critiques –Généralement contraints par des standards de certification Transports –Ferroviaire, Aéronautique, Espace, Automobile Méthodes formelles recommandées par certains standards –Par exemple, ferroviaire

64 Frédéric Boniol12-14 juin 2011 – R2I2011 DO-178 DO-178B –Standard de certification pour le logiciel aéronautique,1992 –Définit des objectifs pour chaque étape du processus de développement DO-178C –Mise à jour du DO-178 entamée en 2005, fin prévue 2010 –Core document + 4 suppléments techniques Tools Object Oriented technologies Model Based Design Formal Methods

65 Frédéric Boniol12-14 juin 2011 – R2I2011 DO-178B Liens ARP 4754 / DO-178B Le niveau de développement du logiciel est déterminé en fonction du niveau de certification du système dans lequel il intervient, de la gravité des dysfonctionnements potentiels de ce système. Le développement du logiciel doit ensuite respecter les objectifs définis pour ce niveau dans lED- 12B / DO-178B. Failure condition DAL (development assurance level) CAT (10 -9 )A HAZ (10 -7 )B MAJ (10 -5 )C MIND No safety effectE

66 Frédéric Boniol12-14 juin 2011 – R2I2011 DO-178B 1. Introduction 2. System aspects relating to software development 3. Software life cycle 4. Software planning process 5. Software development processes 6. Software verification process 7. Software configuration management process 8. Software quality assurance process 9. Certification liaison process 10. Overview of aircraft and engine certification 11. Software life cycle data 12. Additional considerations Annex A: Process objectives and outputs by software level Annex B: Acronyms and glossary of terms SOFTWARE CONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICAION RTCA DOCUMENT NO. RTCA/DO-178B December 1, 1992 Prepared by: SC-167 Requirements and Technical Concepts for Aviation

67 Frédéric Boniol12-14 juin 2011 – R2I2011 Software development processes Software requirements process –Develop high-level requirements (HLR) from outputs of the system process Software design process –Develop low-level requirements (LLR) and software architecture from high-level requirements Software coding process –Implement source code from the software architecture and the low-level requirements Integration process –Load executable object code into the target hardware for hardware/software integration

68 Frédéric Boniol12-14 juin 2011 – R2I2011 System Requirements High-Level Requirements Software Architecture Source Code Executable Object Code Low-Level Requirements Compliance Robustness Compatible With Target Compliance Robustness Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Verifiability Conformance Accuracy & Consistency Complete & Correct Compliance Traceability Architecture Compatibility Compliance Traceability Compliance Traceability Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Consistency HW Compatibility Verifiability Conformance Partition Integrity DO-178/ED-12 – Verification Process

69 Frédéric Boniol12-14 juin 2011 – R2I2011 Verification process Activités : revues, analyses, test Analyses : repeatable evidence of correctness Reviews : qualitative assessment of correctness Test

70 Frédéric Boniol12-14 juin 2011 – R2I2011 DO-178C Formal Methods Supplement Permettre lutilisation des Méthodes formelles à la place de méthodes conventionnelles –Fournir un guide pour lutilisation des méthodes formelles Modifier des objectifs existants Définir de nouveaux objectifs Décrire les activités nécessaires Décrire les arguments pour satisfaire les objectifs –Fournir des informations sur les méthodes formelles –Identifier et présenter leurs caractéristiques

71 Frédéric Boniol12-14 juin 2011 – R2I2011 Table des matières Introduction System aspects related to software development Software life cycle Software planning process Software development process Software verification process Software configuration management process Software quality assurance process Certification liaison process Overview of aircraft and engine certification Software life cycle data

72 Frédéric Boniol12-14 juin 2011 – R2I2011 Formal Method Descriptive notations and analytical methods used to construct, develop and reason about mathematical models of system behavior Formal model Formal Analysis A formal method is a formal analysis carried out on a formal model. What is a Formal Method ?

73 Frédéric Boniol12-14 juin 2011 – R2I2011 A model is an abstract representation of a given set of aspects of a system that is used for analysis, simulation, code generation, or any combination thereof Formal Method Formal model Formal Analysis A formal notation is a notation having a precise, unambiguous, mathematically defined syntax and semantics. A formal model is a model defined using a formal notation What is a Formal Model ?

74 Frédéric Boniol12-14 juin 2011 – R2I2011 Formal Method What is a Formal Analysis ? The use of mathematical reasoning to guarantee that properties are always satisfied by a formal model. Formal model Formal Analysis

75 Frédéric Boniol12-14 juin 2011 – R2I2011 A method is formal if it has a sound mathematical basis, typically realized by a formal notation: A sound method never assert that a property is true when it is not. Formal model of the requirements Formal Analysis OK X Not Sound Being Sound

76 Frédéric Boniol12-14 juin 2011 – R2I2011 When a formal model is created from an informal item to do a formal analysis Requirements Formal model of the requirements Formal Analysis Results We need to be sure that whatever is proved about the formal model also applies to what is modeled. Then review or analysis should be used to demonstrate that the formal statement is a conservative representation of the informal requirement Conservative representation

77 Frédéric Boniol12-14 juin 2011 – R2I2011 System Requirements High-Level Requirements Software Architecture Source Code Executable Object Code Low-Level Requirements Compliance Robustness Compatible With Target Compliance Robustness Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Verifiability Conformance Accuracy & Consistency Complete & Correct Compliance Traceability Architecture Compatibility Compliance Traceability Compliance Traceability Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Consistency HW Compatibility Verifiability Conformance Partition Integrity DO-178/ED-12 – Verification Process

78 Frédéric Boniol12-14 juin 2011 – R2I2011 FM Supplement : Formal verification Formal Analysis might replace : –Review and analysis objectives.

79 Frédéric Boniol12-14 juin 2011 – R2I2011 HLR Formal HLR Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Verifiability Conformance Accuracy & Consistency Complete & Correct Compliance Traceability Architecture Compatibility Compliance Traceability System Requirements Software Architecture Source Code Executable Object Code Low-Level Requirements Compliance Traceability Compliance Robustness Compatible With Target Compliance Robustness Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Consistency HW Compatibility Verifiability Conformance Partition Integrity When HLR are formaly expressed Formal analysis can be used FM Supplement : Formal verification instead of reviews

80 Frédéric Boniol12-14 juin 2011 – R2I2011 HLR Formal HLR Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Verifiability Conformance Accuracy & Consistency Complete & Correct Compliance Traceability Architecture Compatibility Compliance Traceability System Requirements Software Architecture Source Code Executable Object Code Low-Level Requirements Compliance Traceability Compliance Robustness Compatible With Target Compliance Robustness Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Consistency HW Compatibility Verifiability Conformance Partition Integrity When HLR and LLR are formaly expressed Formal analysis can be used Formal LLR Compliance Traceability FM Supplement : Formal verification instead of reviews

81 Frédéric Boniol12-14 juin 2011 – R2I2011 FM Supplement : Formal verification Formal Analysis might replace : –Review and analysis objectives –Conformance tests versus HLR & LLR –Robustness tests

82 Frédéric Boniol12-14 juin 2011 – R2I2011 HLR Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Verifiability Conformance Accuracy & Consistency Complete & Correct Compliance Traceability Architecture Compatibility Compliance Traceability System Requirements Software Architecture Source Code Executable Object Code Low-Level Requirements Compliance Traceability Compliance Robustness Compatible With Target Compliance Robustness Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Consistency HW Compatibility Verifiability Conformance Partition Integrity When LLR are formaly expressed with a conservative representation between code and EOC, then Formal analysis can be used to replace some tests Formal LLR Compliance Traceability Conservative representation X FM Supplement : Formal verification for EOC

83 Frédéric Boniol12-14 juin 2011 – R2I2011 Coverage Test –Functional coverage: test cases for each requirement –Structural coverage of the code by the test cases Formal methods: the structural coverage objectives are replaced by –Each requirement is completely covered –The set of requirements is complete with respect to the function –There is no non expected dependencies between output and input data –There is no dead code

84 Frédéric Boniol12-14 juin 2011 – R2I2011 FM Supplement : Formal verification Formal Analysis might replace : –Review and analysis objectives –Conformance tests versus HLR & LLR –Robustness tests Formal Analysis might help for verification of compatibility with the hardware.

85 Frédéric Boniol12-14 juin 2011 – R2I2011 HLR Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Verifiability Conformance Accuracy & Consistency Complete & Correct Compliance Traceability Architecture Compatibility Compliance Traceability System Requirements Software Architecture Source Code Executable Object Code Low-Level Requirements Compliance Traceability Compliance Robustness Compatible With Target Compliance Robustness Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Consistency HW Compatibility Verifiability Conformance Partition Integrity Properties might be proved directly on EOC : WCET, Stack usage, … Compatible With Target FM Supplement : Formal verification for EOC

86 Frédéric Boniol12-14 juin 2011 – R2I2011 FM Supplement : Formal verification Formal Analysis might replace : –Review and analysis objectives –Conformance tests versus HLR & LLR –Robustness tests Formal Analysis might help for verification of compatibility with the hardware Formal Analysis cannot replace HW/SW integration tests Therefore testing will always be required.


Télécharger ppt "Frédéric Boniol12-14 juin 2011 – R2I2011 Vérification formelle des systèmes et des architectures embarqués critiques (avioniques (Airbus)) Frédéric Boniol."

Présentations similaires


Annonces Google