Contenu du cours et Planning

Transcription

1 Langages synchrones M2 SAR/SESI/STL LS Jérôme Hugues (ex ENST) Emmanuelle Encrenaz-Tiphène V3.2, septembre 2013 Contenu du cours et Planning 3 Introduction aux langages synchrones Systèmes réactifs Différences autres paradigmes prog Hypothèses synchrones Modèle sous-jacent Deux langages synchrones Modèle «flot de données»: Lustre Modèle «impératif»: Esterel Compilation et analyses statiques Causalité, calcul d horloges Code séquentiel, Compilation en circuit Vérification de propriétés de sûreté Observation Equivalences, minimisation Réduction et abstraction Extensions Extensions de Lustre, liens avec les langages fonctionnels Répartition, GALS Autres langages Lien vers les TP: Cours: UPMC, amphi 25 16/09: 4h, Introduction, modèle sous-jacent 23/09: 4h, Lustre 30/09: 4h, TP Lustre 07/10: 4h, Esterel 14/10: 4h, Analyse statique 21/10: 4h, Vérification sûreté 28/10: 4h, TP Extensions Lustre 21/11: Examen Page 1

2 Quelques références utiles 4 Articles scientifiques (fournis avec le support de cours) The Synchronous Languages 12 Years Later. Albert Benveniste, Paul Caspi, Stephen A. Edwards, Nicolas Halbwachs, Paul Le Guernic, and Robert de Simone. Proceedings of the IEEE 91(1):64-83, January A Synchronous Language at Work: the Story of Lustre. Nicolas Halbwachs. Third ACM- IEEE International Conference on Formal Methods and Models for Codesign, MEMOCODE'2005, Verona, Italy, July Livres Synchronous programming of reactive systems. Nicolas Halbwachs, Kluwer Academic Pub (bibliothèques IR, IE) The constructive Semantics of Pure Esterel. Gerard Berry 1. Introduction aux langages synchrones M2 SAR/SESI/STL LS a) Ingénierie des systèmes critiques b) Problèmes liés à la construction de systèmes critiques c) Définition de l approche synchrone a) Système réactif synchrone b) Modèle sous forme d automate d) Différents langages et utilisation industrielle Page 2

3 a) Ingénierie des systèmes critiques M2 SAR/SESI/STL LS Syst. temps-réel, embarqués, critiques 7 Temps-réel Temps de chaque traitement connu ou borné dans un intervalle Temps réel dur : contraintes temporelles à respecter impérativement Embarqué Dispositif logiciel + matériel «portable» (automobile, avion, humain) Consommation, poids, surchauffe sont des contraintes importantes Critique Défaillance d une partie du système a des conséquences importantes (humaines, environnementales, sociétales, économiques, ) Trois domaines fortement liés: Temps-réel et embarqué: horloges, alarmes,.. Embarqué et critique: systèmes de pilotage, robots chirurgiens, etc. Objectifs de ce cours: étudier l approche synchrone Les modules ETER et FSET complètent le panorama des solutions existantes Page 3

4 Explosion des systèmes critiques 8 Loi de Moore: «la puissance de calcul augmente tous les 18 mois» Corollaire: plus de puissance CPU pour moins d encombrement Majorité des processeurs utilisés dans un contexte embarqué, éventuellement communicants PDAs, téléphones portables, téléviseurs, imprimantes, Voitures, portails, etc. Toujours plus de puissance et de fonctionnalités Interactions Avec l utilisateur: GUI, entrées/sorties Avec d autres sous-composants: chaîne de capteurs / actionneurs Comment concevoir de tels systèmes? Systèmes, Domaines et Contraintes Contraintes de conception d un système dépendent : 9 du domaine d applications (vocabulaire, techniques, normes) de types de contraintes à respecter : fiabilité, maintenabilité, sécurité, intégrité, testabilité Domaine d applications Applications Criticité Types de contraintes Respect des Contraintes Avionique Pilotage, frein, distribution électrique Safety-critical Fiabilité, déterminisme Certifications Spatial Contrôle de trajectoires, altitude, imagerie, transmission Mission-critical Fiabilité, intégrité, déterminisme Qualité de code Grand public Imagerie, informatique Business-critical Time to market Tests Médical Pace-maker, robots chirurgiens Life-critical Fiabilité, déterminisme Certifications Page 4

5 Particularités des systèmes critiques 10 Fontionnement permanent Durée de vie : mois / années / décennies Interactions fortes Avec l environnement : Capteurs, horloges, utilisateur, environnement physique, [variables discrètes ou continues] Avec d autres entités du système : Un élément d une chaîne: centrale inertielle d un lanceur Ariane V Contraintes de performances Temps d exécution, consommation, poids Robustesse / résilience aux erreurs Nécessaire gestion des entrées erronées Entrées-sorties erronées Erreurs dues à l environnement; bit-flip du aux radiations solaires Recours à des méthodes de conception spécifiquement adaptées Exemple: l automobile Clim Badge de péage Audio & vidéo Contrôle moteur Vitesses Embrayage Direction Suspension 11 Lumières ABS Surveillance Tableau de bord Détecteur de sommeil GPS Airbag Siège Anticollision Coordination globale, >30 CPU Page 5

6 Types de traitements 12 CC : contrôle continu, traitement du signal Résolution d'équations différentielles, filtrage numérique Spécifications et simulation en Matlab/Scilab, code manuel ou automatique FSM : automates finis, graphes de transition Contrôle discret, protocoles, sécurité, etc. Automates plats ou hiérarchiques, code manuel ou automatique Calc : calcul intensif Navigation, cryptage, etc. C, manuel + librairies Web : navigation, audio / vidéo Interaction graphique / audio / vidéo Réseaux flots de données, Java Exemple: l automobile (2) 13 FSM Web + Calc +FSM CC+FSM FSM CC+FSM CC+FSM CC+FSM+Calc CC+FSM CC+FSM Calc+FSM CC+FSM CC+FSM FSM CC+FSM+Calc CC CC CC+FSM Coordination globale??? Page 6

7 Environnements de développement 14 Circuits IPs : blocs réutilisables, programmés en HDL (Hardware Description Language) Ex: Verilog, VHDL, SystemC Connectés par bus et réseaux (eux même des IP) Standardisation et réutilisation => SoC, System on Chip Logiciels C/C++, Java, Ada, Système d exploitation, exécutif assure la coordination Standardisation et réutilisation => bibliothèques Modèles à base de composants et environnement de déploiement [Fractal, BIP] Logiciel/matériel Plate-forme de conception mixte logiciel/matériel : Modèles d architecture multiprocesseurs + noyau système + code applicatif UML-Marte / SysML, AADL, Dysident, plateforme SOCLIB (Lip6) b) Problèmes liés à la construction de systèmes critiques M2 SAR/SESI/STL LS Page 7

8 Contraintes de conception 16 Certification : délivrance d une assurance écrite (certificat) d un organisme extérieur indépendant qui audite le système de conception et vérifie qu il est conforme aux exigences spécifiées dans la norme Accréditation : reconnaissance formelle (par un organisme d accréditation) qu un organisme de certification est compétent Sécurité des systèmes d information Critères communs : standard international (ISO/CEI 15408) Niveaux d évaluation (Evaluation Assurance Level) : EAL1 : testé fonctionnellement EAL2 : testé structurellement EAL3 : testé et vérifié méthodiquement EAL4 : conçu, testé et vérifié méthodiquement EAL5 : concç de façon semi-formelle et testé EAL6 : conception vérifiée de façon semi-formelle et testée EAL7 : conception vérifiée de façon formelle et testée Contraintes de conception 17 Validation : opération destinée à démontrer, documents à l appui, qu une procédure, un procédé ou une activité conduit aux résultats escomptés. Elle comprend la qualification des systèmes et des équipements. Documentation des composants : interface/fonctionnement Traçabilité : des spécifications fonctionnelles à la mise en œuvre du système Restrictions : limitation des pratiques dangereuses (alloc dyanmique, proc récursives) Outils de développement et de vérifications sûrs Vérification : utilisation de méthodes formelles pour vérifier du code informatique et du code décrivant des circuits électroniques Test : essais du système dans un grand nombre de configurations couvrant au maximum les points et chemins de fonctionnement. Plans de tests : tests unitaires / tests d intégration Mesures de couverture des tests. Page 8

9 Complexité croissante des systèmes 18 Complexité croissante des applications Interfaces analogique/digital Algorithmique embarquée: signal, graphique, alarmes, Choix des architectures: µp, DSP, ASIC, FPGA, Performance augmente la complexité Contrôle de la puissance pour éviter parasites (tél. portables), Optimiser les ressources batteries vs services Complexité impacte la vérification Réutilisation bute sur l absence de *vraies* spécifications Difficulté de tester l interaction entre composants Problème #1: erreurs de conception 19 Therac 25, thérapie par irradiation, 6 accidents entre 1985 et 1987 «An Investigation of the Therac 25 Accidents», N. Leveson et al. Accès concurrent à des variables non protégées => irradiation trop forte Ariane V Réutilisation d une portion de code de Ariane IV sans vérification du respect d hypothèses de conception => overflow et destruction de la fusée Mars Polar Lander Vibrations lors de la phase de descente ont induit en erreur le dispositif détectant le contact avec le sol, entraînant l extinction des moteurs, d où une chute de la sonde. Bug du FPU du Pentium I Erreur dans l écriture de tables stockant des valeurs précalculées Contrôleurs de vitesse des voitures Page 9

10 À méditer.. 20 As soon as we started programming, we found to our surprise that it wasn t as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs. Maurice Wilkes, 1949, Pionnier de l informatique Réduire les erreurs de conception Améliorer les procédures de test Coût prohibitif, pouvant atteindre 60% du budget du projet 21 Améliorer les techniques de conception, adaptées au niveau de certification visé Spécification des besoins Identification d une architecture matérielle logicielle Spécification fonctionnelle des différentes entités + contraintes spcéifiques (non fonctionnelles) S assurer de la cohérence et complétude de la spécification : fiable et réutilisable Modèle de calcul simple, apte à l analyse Réduire la distance architecte/concepteur/utilisateur, matériel/logiciel Intégration matériel/logiciel dans un même environnement, avec des modèles formels communs ou compatibles Besoin d outils : Modèles de haut niveau, spécifications formelles Vérification automatique ou guidée de propriétés Bibliothèques, compilateurs certifiés Page 10

11 Positionnement des langages synchrones 22 Les langages synchrones permettent de décrire, simuler, vérifier des systèmes réactifs, et de compiler du code ou du matériel garantissant le même comportement que le système décrit, si l hypothèse synchrone est vérifiée c) Définition de l approche synchrone M2 SAR/SESI/STL LS Page 11

12 d) Différents langages et utilisation industrielle M2 SAR/SESI/STL LS Modèle d un composant réactif synchrone 39 Modèle sous-jacent d un système synchrone : une Machine de Mealy Déterministe M = < S, I, O, T, G, S 0 > S = ensemble fini d états (états de contrôle) I = ensemble fini des signaux d entrée O = ensemble fini des signaux de sortie T = fonction de transition : S 2 I S G = fonction de génération : S 2 I 2 O I T S G O S 0 = état initial Un événement d entrée (resp. de sortie) : un élément de 2 I (resp. 2 O ) Machine déterministe et complète : T et G sont des fonctions (et non pas des relations) totales Un état initial et une séquence d événements d entrée donnés définissent un unique état de contrôle et un unique événement de sortie. Page 12

13 Composition 44 La mise en parallèle de modules synchrones correspond à la composition synchrone des machines de Mealy équivalentes. M1 M2 = M3 est une machine de Mealy sous hypothèses : analyse de causalité rejet des programmes ne respectant pas ces hypothèses Description modulaire Réutilisabilité / remplacement Vérification formelle à partir du modèle en Machine de Mealy Modèle basé flot de données 45 Le traitement des donnée est constant au cours du temps, les données passent à travers un réseau d opérateurs à un rythme pré-établi Chemins de données, contrôle continu, traitement du signal Lustre/SCADE: langages fonctionnels d équation séquentielles Cf Simulink (Matlab), Ptolemy, Y t = sin(x t ) * cos(y t-1 ) X sin * Y Y = sin(x) * cos(pre(y)) cos pre boîtes = opérateurs flèches = flots de données Page 13

14 Modèle basé flot de contrôle 46 Le comportement change fréquemment (et en fonction des données), peu de données Protocoles, IHM, mode de fonctionnement, contrôle mémoire Esterel/SyncCharts: impératif + hiérarchie Cf. aussi StateCharts, StateFlow, abort sustain DMAReq when DMAOk; abort abort every ByteIn do emit ByteOut (?ByteIn) end every when DMAEnd when 10 MilliSecond do emit TimeOut end abort boîtes = états flèches = transitions noms = signaux hiérarchie = préemption Sémantique formelle 47 Flots de données Équation de flots + calcul d horloge (Lustre, Signal) Équilibrage d équations (Ptolemy) Intégration (Haskell) Flots de contrôle Systèmes de transitions Logique constructive Les systèmes font exactement ce qu ils disent Déterminisme acquis Permet vérification formelle Page 14

15 Langages synchrones et industrie 49 Créés dans les années 1980 Esterel: Ecole des Mines/INRIA, SyncCharts: U. de Nice Lustre: IMAG (Grenoble), Signal: INRIA Rennes Ptolemy (Berkeley), TCCP (Xerox), Lava (Chalmers), Utilisation industrielles dès les années 1990 Lustre/SCADE: nucléaire (Schneider), avionique (Airbus) Esterel; avionique (Dassault), telecom Signal/SILDEX; contrôle continu Développement se poursuit Avionique; Airbus, Dassault, Eurocopter, SNECMA, Thales, Automobile: GM, PSA, Outils pour l industrie 50 Importance des outils pour valider et utiliser l approche Éviter de fournir une théorie inutilisable par l ingénieur Outils de spécification: Modèles de référence (golden models), réutilisables Contrats formels entre parties, facilite l intégration Synthèse: suppression d écriture de code Vérification: explorer espace d états Concepteurs perçoivent les apports des méthodes formelles Même cheminement que UML, mais plus lent Car plus complexe, plus coûteux Page 15

16 Compilation 51 Flot de données => logiciel Expansion, tri topologique (SCADE, signal) Optimisation: allocation mémoire, localité des données Flot de contrôle => matériel Traduction en ensemble de portes logiques + optimisation (Esterel v7) Graphe de dépendances + codage (Columbia Esterel) Flot de contrôle => Esterel Simulation de circuits (Esterel v5/v7) Ordonnancement statique de flots de contrôle (Synopsys Esterel) Ordonnancement et agrégation de blocs (FT R&D, INRIA, Columbia) Recherche d ordonnancements *statiques* efficaces Vérification 52 Calculer sur les programmes Propriétés de sûreté: rien de «mauvais» ne peut arriver À définir et documenter dès la phase de spécification! Équivalence de programmes Repose sur le modèle formel Techniques: travaux de vérification Contrôler explosion combinatoire Recherche rapide de contre-exemple (rapide) Montrer qu il n y a pas de contre-exemple (coûteux) Progrès constants dans ces techniques cf. modules : vérification formelle de SAR, vérification des systèmes matériels de SESI Page 16

17 Flot de conception d un logiciel embarqué 53 Spécifications informelles Modèles Matlab / Simulink Simulation Animation SCADE data flow FSMs Vérification formelle SAT + numérique (Prover plug-in) Compilateur certifié DO 178B Code C / Ada embarqué Autorise l échange de spécifications formelles Le flot circuits Esterel v7 Spécifications papier 54 Esterel v7 (référence unique) simulation C System C FPGA proto. matériel : VHDL, Verilog logiciel: C, C++ Vérification formelle Génération de tests La sémantique est exactement la même pour le matériel et le logiciel Page 17

18 UART with OPB Interface (Xilinx) 55 Mélange libre de textes et dessins, sémantique claire Conclusion Systèmes embarqués: un domaine en explosion Besoins applicatifs nombreux: grand public, défense, médical, transport, Domaine techniques: automatique, informatique, circuits 56 Fortes contraintes de qualités Coût de bugs, des tests, de la validation, de la certification Besoin de techniques spécifiques de conception et vérification Prise en compte du parallélisme et déterminisme Définition du modèle synchrone Langage et outils spécifiques Sémantique mathématique complète Compilation vers logiciel et électronique Synthèse et vérification formelle Bases mathématiques Page 18

19 Conclusion (2) 57 Les langages synchrones et leurs outils fournissent une base solide pour la construction de systèmes critiques Lustre/SCADE: générateur de code certifié Utilisé quotidiennement dans de nombreuses applications MAIS, ce ne sont QUE des outils, pas LA solution à tous les problèmes Nécessité de raisonner sur le système dans sa globalité Noyau réactif vs code fonctionnel vs partie physique Attention: ce n est pas parce que l outil dit OK que tout est correct, des erreurs de spécifications à haut niveau peuvent subsister Incomplétude du langage naturel, hypothèses implicites Influence du code, de la physique, Extra slides 58 Composition de deux machines de Mealy connectées séquentiellement (sans boucle) Page 19

20 Composition synchrone 59 Definitions / notations Extraction d une composante dans une configuration Soient e i une configuration sur I (e i 2 I ) et k un élément de I On note proj(e i,k) la projection de e i sur sa composante k proj(e i,k) indique la valeur de la composante k dans la configuration e i L extension à une sous configuration est immédiate Composition de fonction multi-variable Soit f une fonction multi-variable de variables x, y, z, la composition d une fonction g de variable t selon la variable y s écrit : f[y \ g(t)] = f(x,g(t),z, ) L expression g(t) est substituée à y dans l expression de f Composition synchrone 60 Soient deux machines de Mealy à composer comme suit : M1 M2 M 1 = < S 1, I 1, O 1, T 1, G 1, S 01 > et M 2 = < S 2, I 2, O 2, T 2, G 2, S 02 > Connexions I 1 I 2 : les entrées communes à M 1 et M 2 O 1 I 2 : les sorties de M 1 également entrées de M 2 Page 20

21 Composition synchrone 61 M1 M2 = M = < S, I, O, T, G, S 0 > tq : S S 1 S 2 et S 0 = (S 01, S 02 ) I = I 1 I 2 \ (O 1 I 2 ) O = O 1 O 2 \ (O 1 I 2 ) T : S 2 I S soit T 1 (s 1,e i1 ) = s 1 et T 2 (s 2,e i2 )=s 2, alors T(s,e i )=s avec s=(s 1,s 2 ), s = (s 1,s 2 ) et e i définie telle que pour tout k I 1, proj(e i,k) = proj(e i1,k) pour tout k I 2 \ O 1, proj(e i,k) = proj(e i2,k) pour tout l I 2 O 1 proj(e i2,l) = proj(g 1 (s 1,e i1 ),l) G : S 2 I 2 O soit G 1 (s 1,e i1 ) = e o1 et G 2 (s 2,e i2 )=e o2, alors G(s,e i )=e o avec G définie telle que: pour tout o O 1 \ I 2, proj(g(s,e i ),o) = proj(g 1 (s 1,e i1 ),o) pour tout o O 2, proj(g(s,e i ),o) = proj(g 2 (s 2,e i2 [j\proj(g 1 (s 1,e i1 )],j) j I2 O1 ),o) Page 21