GL97 - 4 Décembre 1997

Génération de code à partir de spécifications de systèmes

communicants

S. Löffler J-P. Cottin A. Serhrouchni

UniversitätStuttgart

O. Cherkaoui

Plan The Steam Boiler Control Specification Problem Tâches du programme de contrôle Courte présentation de Promela/SPIN Spécification en Promela Processus de développement Simulation,Validation et Implémentation Le compilateur Non-Déterminisme durant l’exécution / Ordonnancement Résultats - Implémentations distribuées Conclusions et prospectives

Spécification du problème de la chaudière à vapeur Présenté à Dagstuhl lors de

“Methods for Semantics and Specification” en juin 95

Problème réaliste, très informel Aucun Détail (Format des

messages, Comportement physique exact)

Nécessité de valider le Programme de Contrôle et pas seulement le Protocole.

Niveaude vapeur

Contrôleur de pompe Valve

M2N2

N1M1

Chaudière

Pompe

Programme de Contrôle

Tâches du programme de Contrôle

Maintenir le niveau d’eau entre N1 et N2 Le système serait endommagé si le niveau d’eau est en dessous /

au dessus de M1 / M2 pendant plus de 5 sec.

Mode Initialisation: attends les unités physiques pour être prêt. Mode Normal: l’eau est entre les niveaux N1 et N2 Mode Dégradé: lors d’une anomalie d’un capteur Mode de sauvetage: tentative de maintenir le système malgré les

anomalies des capteurs. Estimations des niveaux. Mode d’arrêt d’urgence: arrêt de toutes les opérations du

système suite à un des multiples problèmes prévus.

Cycle de fonctionnement

5 Modes de fonctionnement: Initialisation, Normal, Secours, Dégradé et Arrêt.

ID

S

AN

Détection de pannes prévisibles Pompe

Non respect d ’un ordre d’ouverture ou de fermeture Changement spontanée d’état

Contrôleur de pompe Non indication d ’un ordre de changement d’état Indication incohérente de changement d’état

Unité de mesure du niveau ou de la vapeur Valeur indiquée hors limite Valeur incompatible avec la dynamique du système

Transmission Réception d’un message inattendu Non réception d ’un message indispensable

Dynamique du systèmev: quantité de vapeur q: quantité d’eau 12

)(U

t

tvU

0

Quantitéde vapeur

temps

W U1

-U2

tt

dxxvdxXPqtq00

)()()0()( CsttUtvdtUt

tv

22 )()(

)(.)( aon 2 tvUtv )(.)( et 1 tvUtv

)),(),(()()()()),(),(()()(

tvtvdxxPtqtqtvtvdxxPtq bas

t

t

haut

t

t

Promela/SPIN Développé par Gerard Holzmann chez AT&T (« The Design and

Validation of Computer Protocols »). Domaine PublicDomaine Public. Promela = Protocol Meta Language. Langage de spécification basé

sur les machines à états communicantes. SPIN = Simple Promela Interpreter. Outil de simulation et de

validation de spécifications écrites en Promela. L’analyseur permet plusieurs types de vérifications: Deadlocks,

Assertions, Livelocks, code mort, règles de logique temporelle,... Un outil graphique (Xspin) permet de visualiser les machines à états,

les MSC… SPIN produit une machine à états finis en C équivalente à celle décrite

en Promela.

Eléments de syntaxe de Promela

Processus Modélisent une machine à états finis Un processus (proctype) est défini par une partie entête

(nom, paramètres) et un bloc d’instructions Canaux

Emission/Réception des messages entre processus Canal = File d’attente bornée FIFO

Variables Globales: Communication via « Shared Memory » Locales: Internes à une machine à états finis.

Définition d’un canal Messages: Ensemble de paramètres Paramètres: int,short,byte,bit,bool,chan,mtype Exemple de déclaration

Promela/SPIN: les expressions

Expressions = Constituées de termes et d’opérateurs opérateurs arithmétiques opérateurs de comparaison opérateurs logiques opérateurs de niveau bit émission et réception de messages groupe et index len,run opérateurs particuliers

Exécutabilité - Non déterminisme Une opération (condition, affectation, envoi de message) est franchiefranchie sous réserve

de son exécutabilité. Les propositions peuvent être exécutables ou bloquées. 2 opérateurs non déterministes

Sélection (cf. CSP) SPIN choisira une suite d’instructions dont la 1ère est exécutable. if

:: suite_d_instructions_1:: suite_d_instructions_2...

:: suite_d_instructions_n fi

Répétition do :: suite_d_instructions_1 ::….od

Le langage Processus:

Déclaration des proctype Instantiation: « run » Processus initial:  « init »

Variables locales Exécutabilité Non Déterminisme:

« if..fi », « do..od »

chan cnl=[1] of {byte};proctype ProcA(int a, chan k){ byte b; if :: (a<2) ; b=1 :: (a<3) ; b=2 :: (a<4) ; b=0 fi; k ! b }proctype ProcB (chan g){ byte v; g?v; printf( "Value:%d\n",v)}

init{ run (ProcA(1,cnl)); run (ProcB(cnl)) }

a<2a<3

a<4

b=1 b=2 b=0

Structure: un “proctype” for: Programme de contrôle Chacune des 4 pompes et leurs contrôleurs Chaudière + Valve + Dispositif de mesure “Unités Physiques” - proctype particulier qui sera une

interface avec le Programme de contrôle.

Définition des message en “#define” Programme de contrôle: Spécification séquentiel

des modes d’opération. Synchronisation / Contrainte temps réel:

5 sec. Cycle d’opération pour le programme de contrôle.

Spécification en Promela

Programme de contrôle

“Unités physiques”

Processus de Développement Approche: Ecrire une

spécification dans un langage formel la valider à l’aide d’un outil.

Simuler/Valider jusqu’à ce que ça fonctionne.

Ensuite, implémentation le modèle validé dans un langage de programmation.

Spécificationinformelledes besoins

SpécificationFormelle

Simulation Validation

Implémentation

?

Simulation, Validation et Implémentation

Jusqu’à présent: SPIN pouvant simuler et valider une spécification Promela

Nous désirons obtenir une Implémentation valide

Utilisation de la même abstraction (matrice de changement d’état) pour la validation et l’implémentation.

SpécificationPromelaPromela

Simulation

Abstraction

Validation

Implémentation

New!

Réutilisation de la machine à états

Cette réutilisation est facilitée par le fait que SPIN produit des fichiers C séparés.

On aura plusieurs proctype dans le même process Unix Nécessité d’un ordonnanceur pour l ’implémentation.

pan.b pan.c

pan.h pan.t

pan.mMouvements arr. Mouvements avant

Matrice de transitions

Machine à états

Non-Déterminisme durant l’exécution

Lorsqu’une machine à états offre plusieurs possibilités, laquelle choisir?

Différentes stratégies valides sont possibles.

Choix aléatoire = Implémentation se comporterait comme la simulation.

Quel proctype choisir ? Lorsque tous les proctype sont

bloqués, l ’exécution s’arrête.

Proctype A

Proctype B

Implémentation obtenue Un Process Unix gère tous

les proctype. La communication avec

l ’utilisateur se fait uniquement via l’écran (printf ...)

init

pompes

chaudière

unités_physiques

Programme_de_contrôle

ProcessUnix

CodeAdditionnel

Implémentation Distribuée Deux spécifications Promela, l’une pour le programme de contrôle, l’autre pour les unités physiques.

Définition de canaux externes (asynchrones)

Communication par Sockets

init

pumps

boiler

physical_units

controlprogram

init

CanauxExternes

UnixProcess 1

UnixProcess 2

Conclusions et prospectives Promela convient tout à fait à la description d’un problème

technique tel que celui de la chaudière à vapeur Possibilités de bien structurer le problème Nous n’avons pas couvert tout le problème mais on arrive déjà à

un modèle trop compliqué pour la validation exhaustive. Le compilateur et les transmissions de messages ne sont pas

validées L’implémentation se comporte plus ou moins comme la simulation Champ d’application principale: prototypage rapide Etude d’une autre démarche: SDL comme langage source et C++

ou Java comme langage cible