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