Analyses de sûreté de fonctionnement multi-systèmes

1. Présenté par Romain Bernard Doctorant LaBRI / ONERA / Airbus Analyses de sûreté de fonctionnement multi-systèmes

2. Plan • Introduction et objectifs de la thèse • Contexte • Raffinement AltaRica • Raffinement appliqué à la sûreté de fonctionnement • Conclusion

3. Plan • Introduction et objectifs de la thèse • Contexte • Raffinement AltaRica • Raffinement appliqué à la sûreté de fonctionnement • Conclusion

4. Conception de systèmes embarqués et SdF • La sécurité dans l’aéronautique est une priorité: certification • Besoin d’analyses de sûreté de fonctionnement des systèmes (SdF) pour garantir un niveau de sécurité requis • Evolution des systèmes embarqués liée aux contraintes de poids: • systèmes multi-fonctions, intégration en hausse • complexité d’analyse croissante Besoin d’outils d’aide aux analyses • Les avionneurs s’intéressent aux méthodes formelles: modèles formels exploités à l’aide d’outils/services • Scade, Esterel, Simulink, etc… : conception • AltaRica: sûreté de fonctionnement

5. InterpretationSdF Utilisation des modèles dans le processus SdF Documentsde conception • Description du système • Schéma d’architecture Résultats de l’analyse SdF Générationautomatisée • Coupes minimales exhaustives Résultat informel lié à l’expertise de l’ingénieur SdF Résultats de l’analyse SdF AbstractionSdF du Système • Diagramme de dépendance • Arbre de défaillances Formalisationactuelle Formalisationproposée Modèle formel

6. Objectifs industriels • Les premières expérimentations de connexion de modèles ont montré: • Difficultésde création du modèle: • Gestion des interfaces entre modèles • Difficultésd’exploitation du modèle: • Lenteur des analyses, difficulté d’utilisation des résultats • Une méthodologie d’analyse multi-systèmes est nécessaire • L’utilisation de modèles a introduit dans l’industrie le souhait d’une modélisation complète de l’avion: • Un modèle présentant tous les systèmes embarqués

7. Approche proposée • Conception industrielle de systèmes: processus incrémental • Conception de modèles formels par raffinement progressif A M A • Objectif: théorème de compositonnalité pour du raffinement • coupler des modèles de niveaux de détail différents bisimulation bisimulation A’ M’ A’ • Raffinement: cohérence entre différents modèles d’un même systèmes • détaillé pour analyses mono-système • abstrait pour analyses multi-systèmes • Cadre AltaRica: théorème de compositionnalité [Point2000]

8. Plan • Introduction et objectifs de la thèse • Contexte • Sûreté de fonctionnement • AltaRica et MecV • Raffinement AltaRica • Raffinement appliqué à la sûreté de fonctionnement • Conclusion

9. Contexte détaillé: sûreté de fonctionnement • Principe: Coupes minimales Fonctions Situations redoutées Loss of yaw ctl HAZ G.Fail & B.fail & P3.loss … Ctl yaw • Objectif: • Vérifier que chaque système répond au critères réglementaires imposés pour la certification

10. Processus actuel de SdF Vue avion Analysesfonctionnelles→ fonctions → situations redoutées Vue multi-systèmes Vue système Analyses de la sûreté de fonctionnement → coupes minimales→ probabilité d’occurrence (par heure de vol) Vue équipement

11. Plan • Introduction et objectifs de la thèse • Contexte • Sûreté de fonctionnement • AltaRica et MecV • Raffinement AltaRica • Raffinement appliqué à la sûreté de fonctionnement • Conclusion

12. Contexte détaillé: AltaRica • Projet AltaRica: • Collaboration chercheurs (LaBRI) et industriels (Dassault…) • Création d’un langage formel pour la sûreté de fonctionnement • Langages AltaRica: • Langage originel: contraintes • Langage « industriel »: flot de données • Outils • Simulation • Model checking • Génération de coupes/séquences

13. AltaRica: présentation • Un composant AltaRica est appelé nœud Hypothèses/spécification Description textuelle d’un noeud AltaRica state Status : {ok, err, lost}; init Status := ok; event error, loss; extern law <loss> = exp (1 e -4) law <error> = exp (1 e -7); flow Output : {ok, err, lost} : out; assert Output = Status; trans Status = ok |- error -> Status := err; Status != lost |- loss -> Status := lost; • Soit un calculateur « Cpu1 »: nodeCpu1 edon • deux modes de défaillances erroné et perdu • →Trois états possibles: ok (initial), err et lost • une sortie correcte, erronée ou perdue • →Trois valeurs possibles: ok, err et lost • deux défaillances: erreur et perte Loss Error Status = err Status = lost Status = ok Représentation graphique du noeud AltaRica • le signal en sortie correspond à l’état du calculateur Loss

14. AltaRica: sémantique Loss Error Loss Status = err Output = err Status = lost Output = lost Status = ok Output = ok • La sémantique d’un nœud AltaRica est un système de transition interfacé: • Configurations: variables d’état et de flux • Transitions

15. AltaRica: hiérarchie • Un nœud AltaRica peut contenir des instances d’autres nœuds. Description textuelle Représentation graphique nodeRudderCtl sub P1,P2,P3:Cpu1; … assert G.in = P1.Output; … sync <P1.loss,P2.loss,P3.loss>; edon

16. AltaRica: modèle pour la SdF Observateur Cpu Modèle ServoCtl • AltaRica est adapté aux modèle dits « de propagation de défaillance »: • Actions nominales (reconfigurations, détections d’erreur…) • Défaillances

17. MecV ReachA(s) += nodeA!init(s) | <u><e>(ReachA(u) & nodeA!t(u,e,s)); • Model checker développé au LaBRI (A.Vincent), • Capable de: • Traiter directement du code AltaRica • Manipuler plusieurs nœuds à la fois • Effectuer des calculs de points fixes (plus grand ou plus petit) • pour un ensemble d’états donné, recherche du sous-ensemble d’états satisfaisant les conditions spécifiées • Outil de calcul nécessitant l’écriture des formules souhaitées dans un langage propre (inspiré du µ-calcul)

18. Plan • Introduction et objectifs de la thèse • Contexte • Raffinement AltaRica • Raffinement appliqué à la sûreté de fonctionnement • Conclusion

19. Objectifs liés aux besoins industriels A M A raffinement raffinement A’ M’ A’ • Besoins industriels: • Compositionnalité (pour analyses multi-systèmes) • Préservation des résultats d’analyse (coupes/séquences) • La compositionnalité sous-entend que tout raffinement d’un système peut être utilisé dans un modèle multi-systèmes: • variables de flux du modèle abstrait à conserver

20. Candidats au raffinement nodeCpu0 … event loss; trans Status != lost |- loss -> Status := lost; … edon nodeCpu0’ … event loss1, loss2; trans Status != lost |- loss1, loss2 -> Status := lost; … edon Status = ok Output = ok Status = ok Output = ok Loss Loss1 Loss2 Status = lost Output = lost Status = err Output = err Status = lost Output = lost Status = err Output = err • Substitution d’événement

21. Candidats au raffinement nodeCpu1 … event error, loss; trans Status = ok |- error -> Status := err; Status != lost |- loss -> Status := lost; … edon nodeCpu2 … event error, loss; trans Status = ok |- error -> Status := err; Status= ok |- loss -> Status := lost; … edon Loss Loss Error Error Status = ok Output = ok Status = ok Output = ok Status = lost Output = lost Status = lost Output = lost Status = err Output = err Status = err Output = err Loss Renforcement de la garde d’une transition

22. Candidats au raffinement nodeCpu2 … flow Output:{ok,err,lost}:out; … edon nodeCpu3 sub Com,Mon:Cpu2 … flow Output:{ok,err,lost}:out; … edon Com Mon Ajout de hiérarchie

23. Candidats au raffinement nodeCpu0 … event loss; trans Status != lost |- loss -> Status := lost; … edon nodeCpu1 … event error, loss; trans Status = ok |- error -> Status := err; Status != lost |- loss -> Status := lost; … edon Loss Loss Error Status = err Output = err Status = ok Output = ok Status = ok Output = ok Status = lost Output = lost Status = lost Output = lost Status = err Output = err Loss Loss Non retenu car peut introduire de nouveaux états accessibles • Ajout d’événement/transition

24. Raffinement AltaRica • La relation de bisimulation forte interfacée [Point2000] est trop contraignante en pratique. • Nous avons souhaité étudier de nouvelles relations: • moins fines: relations de type simulation • applicables aux enrichissements choisis • principe de compositionnalité • Étudier les restrictions sur le langage nécessaires pour pouvoir établir le théorème de compositionnalité • Chaque relation étudiée est spécifiée en MecV: • Simulation interfacée paramétrée • Simulation quasi-branchante interfacée paramétrée

25. La relation de simulation • Classiquement, un objet A simule un objet B si: • toute séquence d’événements depuis l’état initial de B peut être effectuée depuis l’état initial A, les états atteints étant comparables • MecV nécessite de spécifier les relations permettant de comparer: • les états respectifs (RelF) • les événements considérés comme similaires (RelEvt)

26. La relation de simulation relF s’ t’ s relEvt e’ e sim t sim(s,s’) -= RelF(s,s’) & ([e’][t’](transA’(s’,e',t’) => <e><t >(transA(s,e,t) & RelEvt(e,e’) & sim(t,t’)))); • Simulation interfacée paramétrée: • Tout état s’ du nœud détaillé est en relation avec un état s du nœud abstrait. • Pour toute transition (s’,e’,t’) du nœud détaillé et tout état s en relation avec s’, il existe une transition (s,e,t) du nœud abstrait telle que sont respectivement en relation: • les flux, • les événements, • les états cibles.

27. Renforcement de garde Cpu2 Cpu1 loss error loss error loss Status = ok Status = lost Status = err Status = lost Status = ok Status = err Cpu1 simule Cpu2 Cpu2 ne simule pas Cpu1 Soit un calculateur de type Cpu1. Pour restreindre le comportement, défaillances seulement considérées depuis l’état initial. La relation sur les flux est l’égalité. La relation sur les événements est l’identité.

28. Substitution de défaillance Cpu0’ Cpu0 loss1 loss2 loss Status = ok Status = err Status = lost Status = err Status = lost Status = ok Cpu0 simule Cpu0’ Cpu0’ simule Cpu0 Soit un calculateur de type Cpu0. Pour analyses SdF, nécessité de différencier loss1 et loss2 (même effet mais probabilités d’occurrence différentes). La relation sur les flux est l’égalité. La relation sur les événements est: {loss}≡{loss1,loss2}.

29. Compositionnalité A M’ A’ M A simule A’ a b a a b Hiérarchie: « b plus prioritaire que a » M ne simule pas M’ • Restrictions du langage • Priorités • Diffusion dans les vecteurs de synchronisation • Théorème de compositionnalité • Soient M et M’ deux nœuds hiérarchiques sans priorité ni diffusion. Alors M simule M’ si tout sous-nœud Ni de M simule un sous-nœud N’i de M’.

30. Calcul de séquences G.fail & B.fail & P3.loss … {loss} ≡ {loss1, loss2} G.fail & B.fail & P3.loss1 G.fail & B.fail & P3.loss2 … Le théorème permet en plus de calculer des séquences détaillées à partir des séquences abstraites

31. Simulation quasi-branchante * * * e’ e’ e e qb-sim qb-sim qb-sim qb-sim qb-sim qb-sim Si aucun événement non observable dans le nœud abstrait • Besoins: • Relation de simulation • Distinction: événements observables et non observables  • Travaux existants: Van Glabbeek, Van Benthem • Simulation quasi-branchante interfacée

32. Simulation quasi-branchante Bus 1Bus 2 Bus Bus 1Bus 2 Bus 1Bus 2 Bus 1Bus 2 Bus Loss of Bus 2 Loss of Bus 1 Loss Loss of Bus 1 Loss of Bus 2 • Illustration: • Théorème de compositionnalité • Soient M et M’ deux nœuds hiérarchiques sans priorité ni diffusion. Alors M qb-simule M’ si tout sous-nœud Ni de M qb-simule un sous-nœud N’i de M’.

33. Bilan • Définition de deux relations de simulation • Théorèmes de compositionnalité • Implémentation en MecV de ces relations

34. Plan • Introduction et objectifs de la thèse • Contexte • Raffinement AltaRica • Raffinement appliqué à la sûreté de fonctionnement • Conclusion

35. Opérations préparatoires Correction Loss Error Transition à masquer masquage État « transitoire » Loss Error Status = lost Status = ok Status = lost Status = ok Status = ok Status = err Status = ok • Le raffinement ne peut être vérifié que si le modèle détaillé n’introduit pas de nouvel état accessible (vis-à-vis de RelF) • En SdF, les séquences ne contiennent que des défaillances: • Nécessité de masquer les événements nominaux

36. Raffinement pour la sûreté de fonctionnement • Formules MecV de vérification du raffinement implémentées pour être génériques: • Seuls quelques éléments communs à toutes les relations sont à initialiser par l’utilisateur. • Liberté d’utilisation restreinte à la définition des relations RelF et RelEvt • MecV permet deux approches: • vérification : relations spécifiées par l’utilisateur • exploration : relations calculées

37. Approches vérification/exploration • Approche vérification: Travail coûteux pour spécifier tous les événements en relation Si la relation est vérifiée par MecV alors le raffinement est prouvé sans travail supplémentaire • Approche exploration Pas de spécification initiale: RelEvt(e,e’) = true Si relation non vérifiée par MecV alors pas de raffinement Si relation vérifiée alors nécessité de vérifier les couples d’événements calculés par MecV

38. Méthodologie de vérification du raffinement • Masquage des événements/transitions nominales • Test des états accessibles • Vérification qualitative • Existe-t-il une relation? • Analyse quantitative: • Génération des séquences détaillées et quantification

39. La compositionnalité pour la SdF raffinement raffinement

40. Bilan • Méthodologie appliquée sur deux cas d’étude: • Calculateur raffiné jusqu’à contenir une architecture contrôle/commande • Système de génération électrique • Expérimentations de vérification globale du raffinement: • Vérification possible sur modèles les plus abstraits mais rapidement impossible sur des modèles plus détaillés • Confirme le besoin d’appliquer un raffinement progressif et de tirer partie de la compositionnalité

41. Plan • Introduction et objectifs de la thèse • Contexte • Raffinement AltaRica • Raffinement appliqué à la sûreté de fonctionnement • Conclusion

42. Conclusion: travaux académiques • Apports: deux relations étudiées • simulation paramétrée interfacée • Compositionnalité préservée et théorème établi • Algorithmes de calcul des séquences écrit • Relation adaptée au raffinement sans ajout de hiérarchie • simulation quasi-branchante paramétrée interfacée • Compositionnalité préservée et théorème établi • Relation adaptée au raffinement par ajout de hiérarchie • Perspectives à court terme: • Étudier la préservation des séquences pour la relation de simulation quasi-branchante • Algorithme de calcul des séquences détaillées à partir des séquences abstraites pour la simulation quasi-branchante

43. Conclusion: travaux industriels • Apports industriels: • Méthodologie détaillée de raffinement • Spécification générique des relations en MecV • utilisation facilitée • manipulations nécessaires réduites • Enseignement: le raffinement est difficilement vérifiable a posteriori • Industrialisation: • Développer une IHM pour: • saisir les relations RelF et RelEvt • appels aux différentes relations dans MecV • Identifier de nouveaux besoins (principe de conception) de nouvelles relations à étudier

44. Publications / Communications • Dependable Control of Discrete Systems (DCDS’07) • Experiments in model-based safety analysis: flight controls • International System Safety Conference (ISSC’08) • Failure propagation modeling: multi-system safety analysis • Lambda-Mu (LM16) • Raffinement AltaRica pour l’étude de systèmes à différents niveaux de détail

45. © AIRBUS FRANCE S.A.S. Tous droits réservés. Document confidentiel. Ce document et son contenu sont la propriété d’AIRBUS FRANCE S.A.S. Aucun droit de propriété intellectuelle n’est accordé par la communication du présent document ou son contenu. Ce document ne doit pas être reproduit ou communiqué à un tiers sans l’autorisation expresse et écrite d’AIRBUS FRANCE S.A.S. Ce document et son contenu ne doivent pas être utilisés à d’autres fins que celles qui sont autorisées. Les déclarations faites dans ce document ne constituent pas une offre commerciale. Elles sont basées sur les postulats indiqués et sont exprimées de bonne foi. Si les motifs de ces déclarations n’étaient pas démontrés, AIRBUS FRANCE S.A.S serait prêt à en expliquer les fondements. AIRBUS, son logo, A300, A310, A318, A319, A320, A321, A330, A340, A350, A380 et A400M sont des marques déposées.