se206: modélisation, génération de code et vérification · 2017-04-25 · new york, john wiley...
TRANSCRIPT
Page 1 - SE206: Introduction
SE206: Modélisation, génération de code et vérification
Introduction générale
Ulrich Kühne, Etienne Borde{ulrich.kuhne,etienne.borde}@telecom-paristech.fr
Page 2 - SE206: Introduction
Objectifs de l’UE
• Comprendre les objectifs et techniques d’analyse d’architecture des systèmes temps-réel embarqués.
• Découvrir les standards de spécification et modélisation les plus connus dans ce domaine (SVA, UPPAAL, AADL).
• Manipuler des outils d’analyse et de génération de code qui exploitent ces langages.
Page 3 - SE206: Introduction
Objectifs de l’introduction
• Définir la notion de modèles
• Motiver l’utilisation de modèles pour la conception des systèmes temps-réel embarqués
• Expliquer l’importance du temps dans ces systèmes
• Introduire les objectifs d’analyse s’appuyant sur les modèles
Page 4 - SE206: Introduction
Plan de l’introduction
1. Généralités sur la modélisation: abstraction, langage, modèles/méta-modèles, architecture
2. Modélisation et génie logiciel: processus de développement, rôle des modèles
3. Modélisation pour les systèmes embarqués: exemple du pendule inversé
4. Analyse de modèles: structurelle, temps-réel, model-checking
Page 5 - SE206: Introduction
Généralités sur la modélisation
Page 6 - SE206: Introduction
Modèle = abstraction
• Un modèle est une abstraction de la réalité, abstraction à partir de laquelle il devient possible de raisonner
Calculer des dimensions caractéristiques (consommation énergétique, temps de réponse, température, etc.).
Vérifier la conformité des dimensions caractéristiques vis-à-vis d’exigences (poids d’un avion, nombre de passager, besoin en carburant par km…).
Fournir des points de vus différent en fonction des rôles, préoccupations et/ou expertises de chacun (constructeur ou utilisateur d’un train, d’un avion, d’une voiture).
• C’est une définition plutôt vague, et c’est le but: pour modéliser, il faut de la rigueur (objectif = calcul, vérification) et de l’ouverture d’esprit (moyen = abstraction, point de vu)...
• Prenons quelques exemples pour rendre tout cela plus concret…
Page 7 - SE206: Introduction
Définition de base
Modeling, in the broadest sense, is the cost-effective use of something in place of something else for some cognitive purpose. It allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose. A model represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger and irreversibility of reality.
“The Nature of Modeling“ Jeff Rothenberg in Artificial Intelligence, Simulation, and Modeling, L.E. William, K.A. Loparo, N.R. Nelson, eds.
New York, John Wiley and Sons, Inc., 1989, pp. 75-92
Page 8 - SE206: Introduction
Modèles de la France…
Réseau des autoroutes Réseau des voies ferrées
Page 9 - SE206: Introduction
Modèles de la France…
Spécialités culinaires Vignobles
Page 10 - SE206: Introduction
Modèles de la France…
ReliefsPlages
Page 11 - SE206: Introduction
Plus sérieusement… Cartes météo
Carte des rafales de vents,avec direction et vitesse
Carte de l’enneigement, avecRisques d’avalanches
Page 12 - SE206: Introduction
Cartes météo
Carte des niveaux de vigilance,vent/neige/avalanches
Nombre moyen de coup de foudre, par km2, par an, entre 2000 et 2009
Page 13 - SE206: Introduction
Carte météo = abstraction
• Un modèle est une abstraction de la réalité Calculer des dimensions caractéristiques
o Niveau de risque d’inondation/incendie/avalancheo Température max/min/moyenneo Vitesse des rafales de vent
Vérifier la conformité des dimensions caractéristiques vis-à-vis d’exigenceso Un marin var vérifier la présence de vent, sa direction et sa vitesse…o Un alpiniste vérifiera la présence de neige, la présence de vent, la température…
Fournir des points de vus différents en fonction des rôles, préoccupations et/ou expertises de chacun.o Carte des températures, des vents, des précipitations, etc…
Page 14 - SE206: Introduction
Modèle = syntaxe + sémantique
• Un modèle a aussi pour objectif de donner une représentation facile à comprendre, interpréter, retenir…
• Il faut pour cela: Une représentation textuelle et/ou graphique. Une sémantique associée, plus ou moins abstraite.
• Sur les exemples précédents, les couleurs servent souvent de représentation graphique (syntaxique) alors que la légende explique la sémantique associée.
• La sémantique associée est plus ou moins abstraite…• Les modèles sont souvent des moyens de « prédiction »…
Page 15 - SE206: Introduction
Modélisation et génie logiciel
Page 16 - SE206: Introduction
Les modèles en informatique
• Un programme écrit en C est-il un modèle? … cost-effective use of something in place of something else for some cognitive
purpose.o Le langage C a bien été conçu pour réduire le cout de développement/portage d’un
système d’exploitationo C’est un langage de « haut niveau », objectif cognitif.
It allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose. A model represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of realityo Il est plus facile d’écrire du code en C qu’en assembleur, l’objectif est le même:
automatiser l’exécution d’un algorithme sur un ordinateuro On s’abstrait du fonctionnement de la machine (jeu d’instruction du processeur,
structure de la mémoire, registres, etc…).
• Est-ce suffisant? … Analyse/Vérification?
Page 17 - SE206: Introduction
Implémentation et processus de conception
• Un processus de développement décrit: « La séquence des activités d’ingénierie exécutées pour transformer les besoins et les exigences exprimés par le client en un produit. »
• L’implémentation, code source C par exemple, n’est qu’une activité du processus, parmi:
Analyse des besoins utilisateurs La spécification des exigences logicielles La conception (architecture et composants) L’implémentation La validation L’intégration Le déploiement et la maintenance
Page 18 - SE206: Introduction
Processus de développement classique: le processus en cycles en V
Analyse desbesoins
Spécification des exigences logicielles
Conception de l’architecture logicielle
Conception des composants
Implémentation
Déploiment et maintenance
Tests d’acceptation
Intégration du système
Intégration des sous-systèmes
Tests unitaires
validation
Vérification système
Vérification sous-systèmes
Verif. modules
Abs
trac
tion
Page 19 - SE206: Introduction
Processus en cycles en V: avantages et inconvénients
• Avantages Facile à comprendre. Préconisé par de nombreux standards, en particulier dans le domaine de
l’aéronautique et du spatial. Beaucoup d’outils support. Phase de validation/vérification associée à chaque phase de
conception/implémentation (permet de définir au plus tôt les moyens de validation).
• Inconvénients Suppose que l’on puisse précisément connaître les besoins (exigences), ou au
moins la plupart, dès le début. Plus on avance dans le processus de développement, plus les changements
sont difficiles (coûtent cher): on doit tout faire bien à chaque étape. Les problèmes sont découverts tard dans le processus de développement,
puisque la validation n’intervient qu’à la fin.
Page 20 - SE206: Introduction
Pour résoudre ces problèmes
• Possibilité 1: suivre un processus incrémental, avec des itérations courtes
• Possibilité 2: s’appuyer sur des modèles lors de la conception pour « valider » au plus tôt
Remarque: ces deux possibilités sont souvent compatibles.
Page 21 - SE206: Introduction
Pour résoudre ces problèmes
• Possibilité 1: suivre un processus incrémental, avec des itérations courtes
Analyse Spécification Conception Implémentation Validation Livraison
Analyse Spécification Conception Implémentation Validation Livraison
Analyse Spécification Conception Implémentation Validation Livraison
Analyse Spécification Conception Implémentation Validation Livraison
Incrément
Page 22 - SE206: Introduction
Processus incrémental et itératif
• Avantages Flexibilité: possibilités de livrer une première version rapidement,
et de s’adapter aux modifications d’exigences Réduction des risques d’échec, de dérive:
o Favorise les études de faisabilité au plus tôto Découverte de problèmes au plus tôt
• Inconvénients Pas toujours possible: les standards du domaine de l’avionique
préconisent un processus de développement en V classique Les incréments sont difficile à définir:
o En termes de périmètre fonctionnel (quelles fonctions par incrément?)o En nombre (combien d’incréments?)
• Pour aller plus loin: processus en spirale, méthodes agiles…
Page 23 - SE206: Introduction
Rôle des modèles pour les systèmes embarqués
• Possibilité 2: s’appuyer sur des modèles lors de la conception pour « valider » au plus tôt
• Faciliter les phases de conception en s’appuyant sur une représentation abstraite (modèle):
Support à la communication entre ingénieurs Support à la documentation des solutions choisi Support à la validation au plus tôt des exigences, par
raisonnement sur le modèle (calcul de propriétés caractéristiques) Support à la configuration de la plate-forme (OS+routage) Support à la génération de code source (C, Ada, Java…)
Page 24 - SE206: Introduction
Modèles et architectures
• En informatique, les modèles permettent de représenter une architecture informatique: l’organisation et les relations existantes entre les éléments (logiciels, matériels, et/ou sous-systèmes) d’un système informatique.
• Rappel, un modèle utilise un langage : syntaxe + sémantique
• On parle de langage de description d’architecture
Page 25 - SE206: Introduction
Exemple d’architecture avionique
Comment, et pourquoi modéliser une telle architecture?
Page 26 - SE206: Introduction
Modélisation pour les systèmes embarqués
Page 27 - SE206: Introduction
Particularités des systèmes embarqués
• Les systèmes embarqués contrôlent/pilotent des systèmes physiques en interaction avec:
Le monde extérieur (souvent appelé environnement du système) via des capteurs et des actionneurs.
Des êtres humains auxquels ils rendent service (transports, robotique, télécommunications, énergie, etc.).
• Ils sont donc soumis à des contraintes: De temps (temps de réaction à des évènement, gigue sur le calcul
de données) De fiabilité (capacité à détecter/isoler/recouvrir des fautes) D’empreinte mémoire (dimensionnement de la pile? Du tas?...) …
Page 28 - SE206: Introduction
Exemple du segway: temps et loi de contrôle
• Informations extraites du site « segway challenge »: http://people.kth.se/~crro/segway_challenge/index.html Pendule inversé, modélisé en physique par la deuxième loi de
Newton appliquée en dynamique de rotation
En suivant le raisonnement fournis sur le site du projet on obtient l’équation suivante, où θ(t) représente le mouvement angulaire du pendule, dans le temps:
T(t) est une force angulaire exercée à la base du pendule, et b est un facteur d’amortissement.
Page 29 - SE206: Introduction
Exemple du segway: architecture de contrôle
• Après formulation d’hypothèse et résolution des équations différentielles, le contrôleur produit une force T(t) comme suit (voir la page web pour plus d’explications):
Kp et kd pourront être déterminés en testant la dynamique du système. Pour plus d’informations sur les contrôleurs PID (notamment leur réglage): • https://en.wikipedia.org/wiki/PID_controller• L’architecture de contrôle est très simple et classique:
Dans le cas du « segway challenge »:o I = 0o u(t) = T(t)o r(t) est la consigne à respecter o (r(t) = 0 par exemple, pendule stationnaire)o y(t) = θ(t)
GyroscopeGyroscope ComputerComputer EngineEngine
Plant/process
Plant/process
θ(t) T(t)
Page 30 - SE206: Introduction
La question du temps dans le contrôle
• Fréquence d’échantillonnage: la boucle de contrôle va être exécutée à une certaine fréquence, par exemple 50Hz c’est à dire toutes les 20 ms.
• Que se passe-t-il si le temps de calcul est plus long, par exemple 40 ms? Quel impact sur la dynamique du système? Quel risque pour l’utilisateur?
• Définition: un système temps réel est un système dont les données son correctes si (i) les valeurs calculées sont correctes ET (ii) si les données sont disponibles à la bonne date.
Real-time ≠ fast computing
Page 31 - SE206: Introduction
Modélisation et temps
• Le but de la modélisation d’une architecture de système temps-réel embarqué va donc être de vérifier que les données sont toujours disponibles à la bonne date.
• Dans un système réel (avionique, ferroviaire, automobile, spatial …) le nombre de tâches, processeurs, bus est important.
Il faudra donc un modèle d’exécution, de communication, qui prenne en compte la notion de temps d’exécution, de fréquence d’activation, etc…
Il faudra aussi faire attention au ressources d’exécution partagéeso Le processeur, partagé par des tâches: l’ordonnancement jouera un rôle
important dans ce type de modèleo Les variables, avec les mécanisme de protection type verrouso Les bus de communication
Page 32 - SE206: Introduction
Modèles d’architecture et analyse
Page 33 - SE206: Introduction
Types d’analyse d’une architecture
• Au delà de l’analyse temporelle, un modèle d’architecture peut être utilisé à des fins d’analyse:
Structurelle: est-ce que l’architecture respecte des contraintes logiques qui définissent sa validité vis-à-vis d’un point de vu ou d’un objectif d’analyse:o Par exemple, pour une analyse de temps de réponse, le modèle définit un
temps exécution pour chaque tâche? Calcul de propriétés non-fonctionnelles, telles que le temps de
réponse mais aussi la fiabilité, la consommation énergétique, l’empreinte mémoire …
Le model-checking, visant à détecter au plus tôt des fautes de conception via des mécanismes de vérification exhaustive du comportement modélisé.
Page 34 - SE206: Introduction
Organisation de l’UE
1. TH cours 2: Spécification et vérification du matériel2. TH cours 3 et 4: Automates temporisés3. TH cours 5 et 6: AADL4. TH cours 7 : Génération de code
Alternance de THs de cours et de THs de TD/TP
Page 35 - SE206: Introduction
Analyse desexigences
Spécification des exigences logicielles
Conception de l’architecture logicielle
Conception des composants
Implémentation
Déploiment et maintenance
Tests d’acceptation
Intégration du système
Intégration des sous-systèmes
Tests unitaires
validation
Vérification système
Vérification sous-systèmes
Verif. modules
Abs
trac
tion3 - AADL3 - AADL
2 - UPPAAL2 - UPPAAL
4 – Génera-tion de code
4 – Génera-tion de code
Positionnement des parties du cours sur le processus en cycles en V
1 – Vérifica-tion du
matériel
1 – Vérifica-tion du
matériel