Télécharger la présentation
La présentation est en train de télécharger. S'il vous plaît, attendez
1
Frédéric Boniol ONERA, Toulouse
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
et objectifs de vérification
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
Généralisation …. Dynamique imposée par le système à piloter Système pilotant électronique informatique Système à piloter (ex : une chaîne de production, une réaction chimique…) Autres systèmes données mesures événements commandes
6
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 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… L’ascenseur ne se déplace pas les portes ouvertes => Système à états discrets
7
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 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 l’absence d’erreurs 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
Zoom sur les systèmes de contrôle commande critique …
Exemple : les commandes de vol …
9
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 Servocommande Câble mécanique Commande classique « servomoteur » (A300 / A310) SM Servomoteur Pilote automatique Liaison électrique
10
Exemple : les commandes de vol (CdV)…
Liaison électrique Cde de vol 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 Liaison électrique Cde de vol Pilote automatique Liaison électrique Commande électriques « lois normales » (A320, A330, A340, A380 … )
12
Exemple : les commandes de vol (CdV)…
Ce qu’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)…
Ce qu’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)…
Ce qu’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)…
Ce qu’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)…
Pilote automatique Liaison électrique Cde de vol 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 … Catastrophique Mineure Hazardous 10-9 = 10-5 = 10-7 =
18
Exemple : les commandes de vol (CdV)…
Pilote automatique Liaison électrique Cde de vol 10-9 = 10-5 = 10-7 = Catastrophique Mineure Hazardous 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 !!
19
Analyse dysfonctionnelle
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) 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
20
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 Estimation des probabilités des événements redoutés Listes de pannes + probabilités Modes de défaillance des composants actifs
21
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 Fa Aa Ca aobs in {ok, ko, err} acmd in {ok, ko, err} Schéma abstrait gouva in {ok, ko, err} F A C obs : [-10;+10] cmd : [-10;+10] Schéma fonctionnel concret gouv : [-10;+10] abstraction
22
Analyse dysfonctionnelle ?
Puis… Étude des comportements de panne sur le modèle abstrait Fa Aa Ca aobs = err acmd = err dysfonctionnel 2 gouva = err Fa Aa Ca aobs = ok acmd = ok nominal gouva = ok Fa Aa Ca aobs = ok acmd = err dysfonctionnel 1 gouva = err Fa Aa Ca aobs = ok acmd = ok dysfonctionnel 3 gouva = err
23
Analyse dysfonctionnelle ?
Fa Aa Ca aobs = err acmd = err dysfonctionnel 2 gouva = err Fa Aa Ca aobs = ok acmd = ok nominal panne C gouva = ok panne F Fa Aa Ca aobs = ok acmd = err dysfonctionnel 1 gouva = err panne A Fa Aa Ca aobs = ok acmd = ok dysfonctionnel 3 gouva = err
24
Analyse dysfonctionnelle ?
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) panne C panne A panne F obsa = ok cmda = ok gouva = ok obsa = err cmda = err gouva = err panne C 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 R1 A1 R2 A2 R3 A3 alt1 alt2 alt3 R4 V1 F1 C1 z1 o1 R5 V2 F2 C2 z2 o2 ordre1 ordre2 Evénement redouté : perte non détectée de ordre1 et ordre2 Exigence : proba < 10-7
26
AltaRica pour l’analyse des dysfonctionnements
perteRi Ai : OKi perteAi KOi OKi KOi in OKi : alti = ok; in KOi : alti = ko; in ERRi : alti = err; perteNDRi perteNDAi ERRi ERRi Synch : (perteRi, perteAi), (perteNDRi, perteNDAi) pour i=1,3 Proba : perteRi = 10-3 perteNDRi = 10-4 R1 A1 R2 A2 R3 A3 alt1 alt2 alt3 R4 V1 F1 C1 z1 o1 R5 V2 F2 C2 z2 o2 ordre1 ordre2
27
AltaRica pour l’analyse des dysfonctionnements
Vi : perteVi 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) R1 A1 R2 A2 R3 A3 alt1 alt2 alt3 R4 V1 F1 C1 z1 o1 R5 V2 F2 C2 z2 o2 ordre1 ordre2
28
AltaRica pour l’analyse des dysfonctionnements
Fi : perteFi 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) R1 A1 R2 A2 R3 A3 alt1 alt2 alt3 R4 V1 F1 C1 z1 o1 R5 V2 F2 C2 z2 o2 ordre1 ordre2
29
AltaRica pour l’analyse des dysfonctionnements
Ci : perteCi 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) R1 A1 R2 A2 R3 A3 alt1 alt2 alt3 R4 V1 F1 C1 z1 o1 R5 V2 F2 C2 z2 o2 ordre1 ordre2
30
AltaRica pour l’analyse des dysfonctionnements
Configurations à 2 pannes menant à l’événement redouté : perteNDR1 + perteNDR2 perteNDR1 + perteNDR3 perteNDR2 + perteNDR3 perteNDR4 + perteNDR5 … Proba ≈ R1 A1 R2 A2 R3 A3 alt1 alt2 alt3 R4 V1 F1 C1 z1 o1 R5 V2 F2 C2 z2 o2 ordre1 ordre2 Evénement redouté : perte non détectée de ordre1 et ordre2 Exigence : proba < 10-7
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, => Exigence non respectée !!! R1 A1 R2 A2 R3 A3 alt1 alt2 alt3 R4 V1 F1 C1 z1 o1 R5 V2 F2 C2 z2 o2 ordre1 ordre2 Evénement redouté : perte non détectée de ordre1 et ordre2 Exigence : proba < 10-7
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
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… L’ascenseur ne se déplace par les porte ouverte => Système à états discrets
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)…
Latence capteur Fréquence de la boucle Pilote automatique Liaison électrique Cde de vol Latence calculateur + réseau Temps de réponse actionneur Présence dans le système de : - retards - gigues temps Angle de lacet
39
Exemple : les commandes de vol (CdV)…
Latence capteur Fréquence de la boucle Pilote automatique Liaison électrique Cde de vol Latence calculateur + réseau Temps de réponse actionneur Présence dans le système de : - retards - gigues temps Angle de lacet 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 Worst case freshness (WCF) ? Présence dans le système de : - retards - gigues F1, F2 Worst case traversal time (WCTT) ? Besoin : calcul de bornes supérieures de ces retards gigues 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 ( 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) Nombreux outils Limite
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
WCTT : Méthode (en bref)
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 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) F1, F2 F3, F4 F5, F6 y(t) X(t) β(t)
45
Calcul du WCTT (2/4) Idées (simples) du Network Calculus (suite)
=> Calcul du délai F1, F2 F3, F4 F5, F6 y(t) X(t) β(t)
46
Calcul du WCTT (3/4) Idées (simples) du Network Calculus (suite)
=> Dimensionnement du switch F1, F2 F3, F4 F5, F6 y(t) X(t) β(t)
47
Outils (chez Airbus) : ConfGen (outil maison)
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 d’opération Pas de prise en compte de niveaux de priorité F1, F2 F3, F4 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)…
Ce qu’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
51
La question de la vérif. fonctionnelle : au niveau modèle
Le cycle Airbus…
52
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 l’hypothè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 d’expérience (1/2) : Pas adapté aux modèle SCADE contenant des réels ou des entiers Adapté aux modèles booléens
53
La question de la vérif. fonctionnelle : au niveau modèle
Retour d’expérience (2/2) : Encore inefficace pour montrer qu’un système SCADE ne contient pas d’erreur Efficace pour trouver les erreurs (Difficulté d’interpréter les contre-exemple) Utilisation du model checking en moyen de débugg itératif, en non pas en certification
54
La question de la vérif. Fonctionnelle : au niveau du code
Le cycle Airbus…
55
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) d’appliquer des méthodes de « preuve » ou de « vérification » Retour d’expé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
La question de la vérif. fonctionnelle : au niveau du code
Retour d’expérience (2/3) 2. Méthode par interprétation abstraite Preuve d’absence 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
La question de la vérif. fonctionnelle : au niveau du code
Retour d’expé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 l’assembleur Automatique Outils : FLUCTUAT (CEA) Bilan Bonne couverture du niveau C Couverture du niveau modèle encore à améliorer
58
5. Les problèmes non résolus, et les défis à relever
59
Synthèse : ce qui est bien / mal fait …
Vérif. fonctionnelle des modèles Vérif. du logiciel Pour les systèmes actuels… Vérif. temps-réel Vérif. sûreté de fonctionnement Vérif. sécurité des données
60
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
Les défis à relever… (2/2)
Evolution vers des nouveaux patterns d’architectures 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
6. Annexe : Evolution vers la DO-178C : Ce que ça changera, en quoi les méthodes formelles seront reconnues… (Virginie Wiels)
63
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
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
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 l’ED-12B / DO-178B. Failure condition DAL (development assurance level) CAT (10-9) A HAZ (10-7) B MAJ (10-5) C MIN D No safety effect E
66
DO-178B System aspects relating to software development
Introduction System aspects relating to software development Software life cycle Software planning process Software development processes Software verification process Software configuration management process Software quality assurance process Certification liaison process Overview of aircraft and engine certification Software life cycle data 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
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
DO-178/ED-12 – Verification Process
System Requirements High-Level Software Architecture Source Code Executable Object Code Low-Level Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Complete & Correct Compliance Traceability Architecture Compatibility Consistency Partition Integrity Compliance Robustness Compatible With Target
69
Verification process Activités : revues, analyses, test
Analyses : repeatable evidence of correctness Reviews : qualitative assessment of correctness Test
70
DO-178C Formal Methods Supplement
Permettre l’utilisation des Méthodes formelles à la place de méthodes conventionnelles Fournir un guide pour l’utilisation 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
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
What is a Formal Method ? Descriptive notations and analytical methods used to construct, develop and reason about mathematical models of system behavior Formal Method Formal Analysis Formal model A formal method is a formal analysis carried out on a formal model.
73
What is a Formal Model ? 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 A formal model is a model defined using a formal notation Formal Method Formal model Formal Analysis A formal notation is a notation having a precise, unambiguous, mathematically defined syntax and semantics.
74
What is a Formal Analysis ?
The use of mathematical reasoning to guarantee that properties are always satisfied by a formal model. Formal Method Formal model Formal Analysis
75
Formal model of the requirements
Being Sound A method is formal if it has a sound mathematical basis, typically realized by a formal notation: X Not Sound Formal model of the requirements Formal Analysis OK A sound method never assert that a property is true when it is not.
76
Conservative representation
When a formal model is created from an informal item to do a formal analysis Then review or analysis should be used to demonstrate that the formal statement is a conservative representation of the informal requirement Formal Analysis Results Requirements Formal model of the requirements We need to be sure that whatever is proved about the formal model also applies to what is modeled.
77
DO-178/ED-12 – Verification Process
System Requirements High-Level Software Architecture Source Code Executable Object Code Low-Level Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Complete & Correct Compliance Traceability Architecture Compatibility Consistency Partition Integrity Compliance Robustness Compatible With Target
78
FM Supplement : Formal verification
Formal Analysis might replace : Review and analysis objectives.
79
FM Supplement : Formal verification instead of reviews
System Requirements Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Compliance Traceability When HLR are formaly expressed Formal analysis can be used Formal HLR HLR Compliance Robustness Architecture Compatibility Compliance Traceability Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Consistency Partition Integrity Software Architecture Low-Level Requirements Compliance Robustness Compliance Traceability Verifiability Conformance Accuracy & Consistency Source Code Executable Object Code Complete & Correct Compatible With Target
80
FM Supplement : Formal verification instead of reviews
System Requirements Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Compliance Traceability When HLR and LLR are formaly expressed Formal analysis can be used Formal HLR HLR Compliance Robustness Architecture Compatibility Compliance Traceability Compliance Traceability Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Consistency Partition Integrity Software Architecture Formal LLR Low-Level Requirements Compliance Robustness Compliance Traceability Verifiability Conformance Accuracy & Consistency Source Code Executable Object Code Complete & Correct Compatible With Target
81
FM Supplement : Formal verification
Formal Analysis might replace : Review and analysis objectives Conformance tests versus HLR & LLR Robustness tests
82
FM Supplement : Formal verification for EOC
System Requirements Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Compliance Traceability When LLR are formaly expressed with a conservative representation between code and EOC, then Formal analysis can be used to replace some tests HLR Compliance Robustness Architecture Compatibility Compliance Traceability Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Consistency Partition Integrity Software Architecture Formal LLR Low-Level Requirements Compliance Robustness Compliance Traceability Compliance Traceability X Verifiability Conformance Accuracy & Consistency Source Code Conservative representation Executable Object Code Complete & Correct Compatible With Target
83
Coverage Each requirement is completely covered
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
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
FM Supplement : Formal verification for EOC
System Requirements Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Compliance Traceability HLR Compliance Robustness Architecture Compatibility Compliance Traceability Accuracy & Consistency HW Compatibility Verifiability Conformance Algorithm Accuracy Consistency Partition Integrity Software Architecture Low-Level Requirements Compliance Robustness Compliance Traceability Verifiability Conformance Accuracy & Consistency Source Code Properties might be proved directly on EOC : WCET, Stack usage, … Executable Object Code Complete & Correct Compatible With Target Compatible With Target
86
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.
Présentations similaires
© 2024 SlidePlayer.fr Inc.
All rights reserved.