Embed Size (px)
Citation preview
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE
DIPLOME D’ETUDE APPROFONDIE de
PRODUCTION AUTOMATISEE Université de NANCY 1 ENS de CACHAN
- Mémoire de Recherche - Présenté à : L’École Normale Supérieure de Cachan Le : 01 Juillet 2003 Par : Vincent GOURCUFF Titre :
“ Vérification des systèmes multi-tâches temps réel ” Travail effectué au :
Laboratoire Universitaire de Recherche en Production Automatisée (L.U.R.P.A.) 61, avenue du Président Wilson 94235 CACHAN CEDEX
Directeur de laboratoire : Jean-Jacques LESAGE Directeur de recherche : Olivier DE SMET
2
Remerciements Je remercie tout d'abord M. Jean-Jacques LESAGE pour m'avoir accueilli dans le laboratoire; je remercie ensuite M. Jean-Marc FAURE pour m'avoir accueilli au sein de l'équipe ISA ; je remercie également M.Olivier DE SMET pour m'avoir encadré et m'avoir aidé à mener à bien les travaux. Enfin, je tiens à remercier Mme Houda BEL MOKADEM et Mme Béatrice BÉRARD pour leurs apports dans le cadre du projet VSMT.
3
A Contexte......................................................................................................................... 5
A.1 Intérêt et apport de la Vérification de Système Multi-tâches Temps-réel ................. 5 A.2 Projet VSMT dans le cadre du Plan Pluri-Formation (PPF)..................................... 5
B Les automates programmables industriels multi-tâches................................................... 6 B.1 Présentation............................................................................................................ 6
B.1.1 Les différentes tâches de l’API........................................................................ 6 B.1.2 Ordonnancement des tâches ............................................................................ 7 B.1.3 Comportement spécifique de quelques constructeurs....................................... 8
B.1.3.1 Les automates programmables industriel SIEMENS ................................... 8 B.1.3.2 Les automates programmables industriel SCHNEIDER .............................. 9
B.2 Comportements non décrit par les documentations ............................................... 11 B.2.1 Comportement à vérifier ............................................................................... 11
B.2.1.1 Comportement de la tâche maître .............................................................. 11 B.2.1.2 Comportement de la tâche rapide .............................................................. 12 B.2.1.3 Comportement des tâches évènementielles ................................................ 12 B.2.1.4 Comportement global du mode multitâche ................................................ 12
B.3 Tests expérimentaux ............................................................................................. 13 B.3.1 Résultats ....................................................................................................... 13 B.3.2 Conclusions .................................................................................................. 14
C Modélisation des langages de programmation de L’API ............................................... 15 C.1 Prise en compte des aspects temporisés des langages de programmation............... 15
C.1.1 Intérêt ........................................................................................................... 15 C.1.2 Etat de l’art ................................................................................................... 15
C.1.2.1 Les automates temporisés.......................................................................... 15 C.1.2.2 Modèle de Mader-Wupper ........................................................................ 16
C.2 Apport du multi-tâches au modèle de l’API .......................................................... 16 D Vérification de programmes API multi-tâches .............................................................. 17
D.1 Types de propriétés à vérifier................................................................................ 17 D.2 Modèle de l’API sous UPPAAL ........................................................................... 18
D.2.1 Présentation de l’outil UPPAAL ................................................................... 18 D.2.2 Modélisation de la tâche maître d’un API...................................................... 18 D.2.3 La tâche événementielle ................................................................................ 19 D.2.4 Les temporisations ........................................................................................ 20
D.2.4.1 Approches constructeurs ........................................................................... 20 D.2.4.2 Différentes modélisations.......................................................................... 21
D.2.4.2.1 Modèle asynchrone............................................................................. 21 D.2.4.2.2 Modèle à top d’horloge....................................................................... 22 D.2.4.2.3 Analyse comparée des différents modèle de temporisation ................. 23
D.3 Modélisation de la partie opérative ....................................................................... 24 D.3.1 Intérêts et limites........................................................................................... 24 D.3.2 Méthode de modélisation sous UPPAAL ...................................................... 25
D.3.2.1 Hypothèses de modélisation ...................................................................... 25 D.3.2.2 Discrétisation des systèmes continus ......................................................... 25 D.3.2.3 Synchronisation des différents automates .................................................. 26
D.4 Méthodes de vérification de propriété ................................................................... 27 D.4.1 Utilisation du model-checker ........................................................................ 27 D.4.2 Utilisation d’observateur............................................................................... 27
D.5 Vérification de propriétés pour la plate-forme MSS .............................................. 27
4
D.5.1 Présentation .................................................................................................. 27 D.5.2 Propriétés vérifiées et temps de calcul........................................................... 28 D.5.3 Limites du modèle ........................................................................................ 28
Conclusions ......................................................................................................................... 29 BIBLIOGRAPHIE............................................................................................................... 30
5
A Contexte
A.1 Intérêt et apport de la Vérification de Système Multi-tâches Temps-réel Notre expérience quotidienne nous force à étudier la sécurité des personnes et des biens.
En effet, notamment dans le cadre du contrôle des systèmes, la notion d’erreur de programmation, ou bug, est souvent présente, et leur vérification devient nécessaire. Les systèmes critiques (nucléaire, chimique, manufacturier,…) sont d’autant plus touchés car une défaillance du programme de contrôle peut entraîner de lourdes pertes humaines, environnementales, matérielles mais aussi l’arrêt de la production. Pour ces systèmes, la validation avant implantation est préférable pour réduire les risques, ce qui nécessite des techniques de vérification formelle, basés sur la formalisation des langages de programmation.
Notre recherche porte plus particulièrement sur le contrôle des systèmes critique par des Automates Programmable Industriel (API). Leur utilisation très courante dans l’industrie est le fait de leur performance de sécurité mais aussi de leur langage de programmation robuste défini dans la norme IEC 61131-3.
De nombreux travaux visant à la vérification des programmes d’API par la technique du model-checking ont été réalisés. Une grande contribution a été accomplie dans le cadre du projet VULCAIN, entrepris par deux laboratoires l’École Normale Supérieure de Cachan : le Laboratoire Spécification et Vérification (LSV) et le Laboratoire Universitaire de Recherche en Production Automatisée (LURPA) d’une part, et Alcatel Research & Innovation d’autre part. Ces travaux, [Ros03], [RDC+00], [CDP+00], [LL00], ont permis de définir une démarche complète permettant la vérification de programmes d’API écrits dans les langages standardisés définis par la norme IEC 61131-3. Ils se sont focalisés sur des programmes exécutés sur des API mono-tâche et sans prendre en compte explicitement les aspects temporisés présents dans ces langages. La pertinence des choix théoriques de cette démarche a été illustrée sur des exemples réels. Ce stage de DEA s’inscrit dans la continuité de ces travaux et vise à étendre ces travaux par la prise en compte des aspects multitâches des API.
La vérification des programmes implantés dans les API multi-tâches passe aussi par la modélisation de l’environnement extérieur. En effet, la prise en compte de la partie opérative permet de vérifier de nouvelles propriétés, dépendantes la sollicitation exercée sur l’API. Bien que sa mise en place soit encore une activité d’expertise, cette modélisation sera justifiée et limitée au comportement nominal du système.
Ce mémoire se décomposera en trois parties. Nous développerons au début le comportement des API multi-tâches. À partir de cette connaissance, nous construirons un modèle du langage API dans la partie suivante. Et dernièrement, nous utiliserons cette modélisation pour vérifier des propriétés propres aux multi-tâches sur l’outil UPPAAL, notamment sur un exemple concret, la plate-forme MSS, en modélisant sa partie opérative.
A.2 Projet VSMT dans le cadre du Plan Pluri-Formation (PPF)
Ce projet a reçu l’appui du Ministère de la Recherche sous la forme d’un Programme Pluri-Formations (2002-2005). Il est conduit en partenariat entre deux laboratoires de l’ENS de Cachan : Le Laboratoire Spécification et Vérification (UMR 8643) et le Laboratoire Universitaire de Recherche en Production Automatisée (LURPA).
6
B Les automates programmables industriels multi-tâches
B.1 Présentation
L’unité élémentaire d’exécution d’un automate programmable industriel (API) est la tâche. Une tâche représente un ensemble d’opération exécuté séquentiellement. Contrairement à l’informatique, une tâche d’un API réalise l’ensemble des opérations qui lui sont désignées puis s’arrête et ce dans un temps imparti, jusqu'à son prochain lancement. En effet, toutes les tâches d’un API disposent d’un chien de garde vérifiant que son temps d’exécution est limité.
B.1.1 Les différentes tâches de l’API Le mode d’exécution d’une tâche dans un API peut s’effectuer de différentes manières :
• Cyclique : la tâche est automatiquement relancée après sa fin. • Périodique : la tâche est lancée périodiquement sur la base d’une période prédéfinie. • Evénementielle : la tâche est lancée lors de l’occurrence d’un événement prédéfini.
L’ensemble des tâches est ensuite ordonné sur la base de priorités. Celles-ci sont affectées à
chaque tâche, mais nous pouvons regrouper par type de tâche :
Figure 1. Priorité des tâches API
• La tâche maître est unique. Elle est cyclique ou périodique et a une priorité basse. Elle contient le programme principal, généralement programmé dans l’un des langages de la norme IEC 61131-3 . Elle est lancée au lors du passage de l’API en mode « marche ». Elle évolue suivant le cycle présenté sur la figure 2. Elle est surveillée par un chien de garde et mise en défaut en cas de dépassement du temps d’exécution imparti.
Figure 2. Cycle de la tâche maître
• Les tâches rapides sont optionnelles et périodiques et sont plus prioritaires que la tâche maître. Elles contiennent des programmes nécessitant une période de lancement précise et prioritaire. Elles conviennent par exemple aux alarmes horaires ou aux calculs des consignes de régulation. Elles n’affectent qu’un nombre limité d’entrées et sorties qui leurs sont propres, mais peuvent modifier toutes les variables internes, notamment les images mémoires des sorties de la tâche maître. La priorité entre plusieurs tâches rapides est déterminée par l’utilisateur. Elles sont surveillées par un chien de garde et mises en défaut en cas de dépassement du
Lecture des entrées
Traitement
Emission de sortie
run run
Tâche système Tâche maître Tâches rapides Tâches événementielles
Priorité – +
7
temps d’exécution imparti ou de chevauchement de la même tâche rapide (temps d’exécution supérieur à la période).
• Les tâches événementielles sont optionnelles et démarrées sur l’occurrence d’un événement extérieur ou intérieur à l’API. Elles ont la plus forte priorité. Un événement peut être le changement d’état d’une entrée, d’une sortie, d’une variable mémoire ou d’un sémaphore (instruction d’une autre tâche). Elles n’affectent qu’un nombre limité d’entrées, sorties ou variables communes avec les tâches rapides ou la tâche maître. Elles sont surveillées par un chien de garde et mises en défaut en cas de dépassement du temps d’exécution imparti ou de chevauchement de la même tâche événementielle (temps d’exécution supérieur à l’intervalle entre deux événements).
• La tâche système a la plus basse priorité et est cyclique.
Elle ne contrôle aucune entrée ni sortie mais peut modifier des variables internes ou affecter des communications sur réseau. Elle contient des programmes constructeurs pour la gestion de l’automate ainsi que des programmes de supervision. Ce schéma est utilisé chez plusieurs constructeurs : SIEMENS, SCHNEIDER, ALLEN
BRADLEY.
B.1.2 Ordonnancement des tâches L’ordonnancement des tâches est réalisé en fonction des priorités et de la politique
d’ordonnancement. Celle-ci est du type statique et préemptif, comme décrit dans [Tri99], sur les API étudiés.
La priorité est statique car elle est attribuée par l’utilisateur pendant la programmation. Elle ne peut pas être changée pendant l’exécution. Un ordonnancement préemptif implique qu’une tâche peut être interrompue pour laisser une tâche de plus grande priorité s’effectuer. Lorsque la tâche de plus grande priorité est finie, la tâche de moindre priorité reprend son exécution.
A tout moment, une seule tâche peut être exécutée : la tâche active de plus grande priorité. Le figure 3 illustre le séquencement des tâches d’un traitement multitâche sur un API comportant une tâche maître cyclique, une tâche rapide de période 20ms et une tâche événementielle.
Figure 3. Exemple de séquencement de tâche sur un API (Schneider).
Nous pouvons remarquer que chaque tâche possède son propre cycle de lecture d’entrées
et d’écriture des sorties. Cependant le nombre d’entrées lues et de sorties affectées, par les tâches autre que « maître », est souvent limité pour des raisons de rapidité d’exécution.
Les tâches ne peuvent communiquer entre elles que par des zones mémoires allouées. En effet, les entrées et sorties allouées à chaque tâche leur sont propres, donc une entrée ou sortie ne peut être lue ou affectée que par une seule tâche.
8
Les zones de communication entre tâche sont des ressources partagées : elles ne peuvent être lues ou écrites que par une seule tache à la fois. Ces ressources peuvent être de différent type :
• Une variable interne de l’automate sous la forme d’une variable binaire ou d’un mot • Une entrée ou une sortie
B.1.3 Comportement spécifique de quelques constructeurs
B.1.3.1 Les automates programmables industriel SIEMENS Les tâches sont réparties par blocs d’organisation (OB). Chaque OB à une classe de priorité
prédéfinie (figure 4). L’ensemble des OB regroupe les tâches maîtres, rapides et événementielles.
Figure 4. Liste des blocs d’organisation et leurs priorités Le déroulement d’un cycle de l’automate programmable industriel Siemens est décrit sur la
figure 5.
Le système d'exploitation démarre la surveillance du temps de cycle
La CPU écrit ensuite les valeurs de la mémoire image des sorties dans les modules de sorties.
La CPU lit l'état des entrées dans les modules d'entrées et met à jour la mémoire image des entrées.
Puis, la CPU traite le programme utilisateur et exécute les opérations indiquées dans le programme. Les OB sont organisés entre eux en fonction de leurs priorités
A la fin d'un cycle, le système d'exploitation exécute les travaux en attente, par exemple le chargement et l'effacement de blocs ou la réception et l'émission de données globales.
La CPU revient alors au début du cycle et démarre à nouveau la surveillance du temps de cycle.
Figure 5. Déroulement d’un cycle dans les processeurs Siemens
9
La figure 6 expose un exemple de fonctionnement pour un cycle automate. Sur cet exemple, la tâche maître OB1 est périodique et finie son exécution avant le temps de cycle minimal. Ceci permet à la tâche de fond OB90 de s’exécuter pendant le temps restant.
Figure 6. Exemple de cycle automate sur un API de marque Siemens
B.1.3.2 Les automates programmables industriel SCHNEIDER Les tâches dans les API de marque SCHNEIDER sont séparées en trois groupes :
• La tâche Maître, MAST : Elle est toujours présente. Elle peut être cyclique ou périodique. Cette tâche qui est la moins prioritaire gère la majeure partie du programme application. La tâche MAST est organisée selon le modèle décrit dans le cas général: lecture des entrées, exécution du programme application et écriture des sorties (figure 7). La tâche est contrôlée par un chien de garde qui permet de détecter une durée anormale du programme application.
Figure 7. cycle de fonctionnement des API Schneider
Remarque : Dans le cas du TSX 57, le traitement interne (T.I.) est réalisé en parallèle avec les traitements des entrées et sorties.
10
• La tâche Rapide, FAST : Elle est optionnelle mais toujours périodique de 1 à 255 ms. Elle est prioritaire par rapport à la tâche MAST et donc de préférence courte par rapport à la tâche MAST. En plus du programme application, la tâche FAST exécute des fonctions système liées à la gestion des entrées/sorties qui lui sont associées. Elle est surveillée par un chien de garde et peut être inhibée par une simple variable. Elle ne s’affecte qu’a un nombre limité d’entrées et de sorties qui lui sont propres. La modularité des modules TOR étant de 8 voies successives (voies 0 à 7, voies 8 à 15,...), les entrées/sorties ne peuvent être affectées que par groupes de 8 voies à la tâche FAST.
• La tâche Evénementielle, EVTi : Ces traitements sont optionnels et servent aux applications nécessitant des temps de réponse courts pour agir sur les entrées/sorties. Elles sont appelées par le système lors de l'apparition d'un événement sur une carte d’entrées/sorties. Leur nombre est variable et dépend du modèle d’automate mais elles ont toutes la même priorité, supérieure à la tâche MAST et FAST. Le traitement de l’événement s’effectue suivant 4 étapes, décrites dans la figure 8.
Figure 8. Phases de traitement d’une tâche événementielle.
Le temps de réponse d’un événement, c’est-à-dire le temps entre l’apparition de l’événement et l’affectation d’une sortie est donné par le constructeur (figure 9).
Figure 9. Temps de réponse d’une tâche événementielle sur API Schneider
Acquisition implicite des entrées associées à la voie, origine de l’événement
Acquisition implicite des entrées utilisées dans la tâche EVTi
Traitement de l’événement
Mise à jour des sorties utilisées dans la tâche EVTi
L’apparition de l’événement associé déroute le programme application vers le traitement: • Toutes les entrées associées à la voie qui a provoqué l'événement sont acquises automatiquement. • Toutes les entrées utilisées par l'utilisateur dans la tâche EVTi sont acquises. • Le traitement doit être le plus court possible. • Toutes les sorties utilisées par l'utilisateur dans la tâche EVTi sont mises à jour. Les sorties associées à la voie qui a provoquée l'événement doivent être également utilisées, pour être mise à jour.
11
B.2 Comportements non décrit par les documentations Pour compléter les informations fournies par les constructeurs, différentes
expérimentations ont été réalisées afin de disposer de modèles de comportement détaillés pour permettre la vérification de programmes.
B.2.1 Comportement à vérifier Pour chacune des tâches, une série de tests doit être mis en place afin de vérifier certaines
propriétés. Remarque : Dans chacun des chronogrammes présentés dans cette partie, les abréviations
suivantes on étés utilisées : E Lecture des entrées associées à la tâche. T Traitement du programme associé à la tâche S Emission des sorties associées à la tâche. Com Communication à travers un réseau d’API
B.2.1.1 Comportement de la tâche maître o Influence des tâches prioritaires sur le temps de cycle de la tâche maître.
Dans le cas de l’utilisation d’une tâche maître périodique, le temps de réponse (TR) de l’automate est connu et borné, [Ben03] :
T entrée +T période + T sortie ≤ TR ≤ T entrée + 2.T période + T sortie Mais ce temps ne prend pas en compte l’influence des tâches plus prioritaires (tâche rapide
ou tâche événementielle). Il est donc nécessaire de connaître le comportement de la période de la tâche maître en fonction des autres tâches.
Dans l’exemple suivant, nous pouvons donc étudier la différence entre la période de la tâche maître avec et sans tâche rapide.
Rapide
Maître
Système
E T T T TS E T T T TS
Période de la tâche maître sans tâche rapide
Rapide
Maître
Système
E T S
E T T
ETS E T S
T T S
E TS ETS ETSETS
E T T
ETS ETS
T TS
E T S E T S ETS
Période de la tâche maître avec apparition de la tâche rapide
t
t
12
B.2.1.2 Comportement de la tâche rapide o Maintien de la périodicité de la tâche rapide en fonction de la charge du système.
La tâche rapide est souvent utilisée dans le cadre de calcul de consigne de régulation. Le respect de la période est donc une nécessité, et ceci indépendamment de la charge de la tâche maître ou du nombre de communication.
La variation de la période doit être étudiée en fonction des paramètres des autres tâches. En cas de variation importante, la priorité de la tâche rapide indiquée par les constructeurs est à remettre en question.
B.2.1.3 Comportement des tâches évènementielles o Temps de réaction d’une tâche évènementielle
Pour des questions de performance, le temps de réponse de la tâche événementielle doit être connu.
Ce temps reflétera aussi l’intérêt de cette tâche par rapport à une tâche maître, dans le cas de système nécessitant des réactions rapides de l’automate.
B.2.1.4 Comportement global du mode multitâche o Possibilité d’interruption de la lecture des entrées ou de l’écriture des sorties.
La lecture des entrées et l’émission des sorties sont deux sous-parties de la tâche maître. Cependant elles y tiennent une place non négligeable en temps de traitement (10% environ du temps de cycle) et en quantité de donnée de transfert. Le problème se pose en cas d’activation d’une tâche prioritaire (rapide ou événementielle) pendant cette phase de transfert de donnée.
Dans l’exemple suivant, il faut déterminer le comportement réel de l’API : Pendant la phase de lecture des entrées, la tâche évènementielle est-elle retardée en cas d’activation ou interrompt-elle la phase en cours ?
Rapide
Maître
Système
ETS ETS ETS
E T S T E T ST
com
E T S T
Période stable
com
Evènementielle
Sortie Evènementielle
Temps de réponse
Entrée d’activation
ETS
Entrée activation
OU ?
Evènementielle
Maître
Sortie Evènementielle
Système
ETS
E T
ETS
E T E
Temps de réponse Temps de réponse
t
t
t t
13
Suivant le comportement de l’API, le retard de causalité de l’événementielle pourrait être fortement changé en cas de phase de lecture trop longue.
B.3 Tests expérimentaux Les tests expérimentaux ont été réalisés sur un API Micro 3722 de la marque Schneider
possédant : • Une carte d’entrée/sortie • Une carte de communication ASI • Une carte PCMCIA de communication Unitelway
Les tests sur les tâches évènementielles n’ont pu être effectué car la configuration de la carte d’entrée/sorties ne le permettait pas.
Pour réaliser les essais, la plate forme d’essais PRISME [DDL+01] a été utilisée. Nous pouvons remarquer que les tests ne se basent que sur les variations des sorties. Le fonctionnement réel interne ne peut pas être révélé, seul son effet sur les sorties peut être décelé. Pour cette raison les tests sont effectués de manière statistique en mesurant des écarts de temps entre les sorties.
B.3.1 Résultats Les résultats sont donnés en annexe VI et sont synthétisés ci dessous.
o Influence des tâches prioritaires sur le temps de cycle de la tâche maître. Les résultats d’écart de la période de la tâche maître en fonction de la tâche rapide sont
présentés figure 10. Dans ce test, la tâche maître est configurée pour une période de 50ms et son traitement dure environ 7ms.
Figure 10. résultat d’écart de la période de la tâche rapide en fonction de la charge Les résultats montrent que la période de la tâche maître est très dépendante des
paramètres des autres tâches, dans notre cas la tâche rapide. Par contre, la période moyenne de la tâche maître est conservée dans la mesure du possible : si la tâche maître finit trop tard, la période suivante est plus courte.
o Maintien de la périodicité de la tâche rapide en fonction de la charge du système.
La figure 11 présente les résultats d’écart de la période de la tâche rapide, configurée à 20ms, en fonction de la configuration de la tâche maître. Ces dispersions ont été calculées sur cinq cents périodes de la tâche rapide.
Temps de traitement de la tâche rapide
- 1ms 10ms 10ms 1ms 10ms
Période de la tâche rapide - 100ms 30ms 40ms 20ms 20ms
Période réelle de mini. la tâche maître maxi.
49.1ms, 51.1ms
48.8ms, 50.7ms
40.0ms, 60.3ms
49.4ms, 60.3ms
48.9ms, 51.5ms
58.7ms, 61.1ms
14
Figure 11. résultat d’écart de la période de la tâche rapide en fonction de la charge
Nous pouvons remarquer que la période n’est pas influencée par le temps de traitement de la tâche maître ni par sa période. Nous pouvons donc considérer que la tâche rapide est bien plus prioritaire et que la tâche maître est bien préemptive.
o Possibilité d’interruption de la lecture des entrées ou de l’écriture des sorties.
Les tests sur les cycles de lecture des entrées et d’émission de sortie sont effectués en déactivant la tâche maître, ce qui a pour effet d’arrêter le traitement mais de continuer la lecture des entrées et l’émission des sorties. En comparant les écarts de la période de la tâche rapide avec ou sans déactivation de la tâche maître nous pouvons repérer leur effet. La figure 12 présente un test avec une tâche rapide configuré à 10ms.
Figure 12. résultat d’écart de la période de la tâche rapide en fonction de la charge Malgré un léger écart, ce test ne permet pas de conclure de manière certaine si les
cycles de lecture et d’émission sont interruptifs.
B.3.2 Conclusions Le comportement global du traitement multi-tâches est conforme au fonctionnement
décrit par les constructeurs. Les tests de vérification de comportement sont cependant difficiles à effectuer à cause du manque de transparence dans le fonctionnement des API. En effet, aucune documentation ne permet de connaître le système d’exploitation temps réel implanté. Les tests n’ont donc pu qu’observer l’effet qu’à l’API sur le monde extérieur : ses sorties.
Ces connaissances sur le comportement du traitement multi-tâches des API vont permettre de construire des modèles plus proches de la réalité. Même si certains points n’ont pas pu être vérifiés, des hypothèses seront effectuées pendant la modélisation.
Temps de traitement de la tâche maître
18ms 18ms 6ms 6ms 9ms
Période de la tâche maître 100ms 20ms 100ms 20ms 10ms
Période réelle de mini. la tâche rapide maxi.
19.8ms, 20.7ms
19.8ms, 20.7ms
20.0ms, 20.5ms
20.0ms, 20.5ms
20.0ms, 20.4ms
Tâche maître Active Déactivée
Période de la tâche maître 100ms -
Période réelle de mini. la tâche rapide maxi.
0,0102 s 0,01035 s
0,0101 0,0104
15
C Modélisation des langages de programmation de L’API
C.1 Prise en compte des aspects temporisés des langages de programmation
C.1.1 Intérêt La norme IEC 61131-3 présente les différents aspects temporisés de la programmation
d’un API. Le temps apparaît principalement au niveau des temporisations et du temps d’exécution mais aussi de manière moins explicite au niveau du traitement multi-tâches. Les API sont souvent utilisés comme plates-formes matérielles d'exécution d'applications temps-réel, c'est-à-dire d'applications où des contraintes quantitatives sur les temps de réaction aux entrées doivent être satisfaites. Ces contraintes sont généralement exprimées de façon informelle dans leurs cahiers des charges. Les différents cas d’études rencontrés dans la littérature fournissent de nombreux exemples de telles propriétés :
• Dans [ZRK03], la vanne doit être ouverte cinq secondes avant que la pompe ne soit démarrée.
• Pour tout intervalle de trente secondes, le système décrit dans [Die00] ne doit pas avoir de fuite de gaz de plus de quatre secondes.
• [Huu99] vérifie que la production de vapeur ne s’arrête pas plus de 19 secondes sous risque que la solution devienne solide.
C.1.2 Etat de l’art
C.1.2.1 Les automates temporisés Nous étudions les systèmes temporisés, c’est à dire les systèmes dont le comportement est
fortement conditionné par le passage du temps. Pour appliquer des méthodes formelles de spécification et vérification de ces systèmes nous avons besoin d'un modèle mathématique de leur comportement.
Nous allons pour cela utiliser les automates temporisés, décrit par [Yov93] et utilisé par [MW99] pour donner une modélisation temporisée des automates programmables industriels prenant en compte les temporisations. [Yov93] considère qu'un système temporisé est composé en général par plusieurs processus communicants. Un système temporisé peut évoluer d'un état à un autre par l’exécution d'une action, qui est en général le résultat d'une communication, ou d’un écoulement continu du temps.
Le temps est modélisé par une variable globale fictive. Elle est fictive car elle n’est pas une vraie variable du système mais seulement une abstraction qui sert à exprimer les contraintes temporelles. Elle est globale au sens où elle est la même pour toutes les composantes du système. L’exécution d'un système temporisé est une séquence de pas, où chaque pas a deux étapes :
• La première est une étape de progression du temps. Dans cette étape le temps progresse d'une quantité finie ou infinie, mais de la même quantité pour toutes les composantes du système. Une hypothèse fondamentale du modèle est donc que le temps passe de manière synchrone pour tous les processus qui font partie du système.
• Dans la seconde étape, les composantes exécutent, individuellement ou en coopération, une séquence arbitrairement longue mais finie d'actions instantanées. Un nouveau pas commence lorsque la seconde étape termine.
Le fonctionnement décrit combine les coopérations synchrones et asynchrones en deux
étapes alternées : dans la première, toutes les composantes se synchronisent pour laisser passer le temps de la même quantité, dans la seconde, les composantes exécutent instantanément et de manière asynchrone une séquence d'actions.
16
Ce mode de fonctionnement permet de modéliser le comportement d'un système temporisé par un système de transitions étiquetées dont les étiquettes sont des actions ou des valeurs réelles positives qui représentent l'écoulement du temps.
C.1.2.2 Modèle de Mader-Wupper Il existe plusieurs manières de modéliser le comportement cyclique de l’automate
programmable et les contraintes temporisées telles que la durée du cycle, comme [ZRK03], [Ben03] ou [MW99]. Bien que la vérification de certaines propriétés de sûreté puisse se passer de toute prise en compte de la durée du cycle dans le modèle, d’autres propriétés temps-réel nécessitent la prise en compte de cette durée.
Nous retiendrons le modèle de Mader-Wupper (figure 13), présenté dans [MW99]. Dans ce modèle, le programme est considéré dans sa globalité : nous ne regardons pas le temps d’exécution d’une instruction élémentaire mais plutôt le temps du cycle automate. Ce temps est borné par deux constantes : ε1 et ε2. Chaque instruction peut ainsi s’exécuter n’importe quand dans le cycle, pourvu que l’instant de son exécution soit compris entre ε1 et ε2.
Figure 13. modèle de Mader-Wupper
Ce modèle sera utilisé sur chacune des tâches de l’API en implantant les concepts de lecture des entrées, traitement et émissions des sorties. Le nombre de place où le temps peut s’écouler sera aussi réduit afin de gagner en temps de calcul.
C.2 Apport du multi-tâches au modèle de l’API Après avoir étudié la structure des Automates Programmables Industriels multi-tâches,
nous pouvons maintenant implémenter cet aspect aux modèles décris dans les paragraphes précédents. Cet apport passera par la modélisation des différentes tâches utilisées dans ces API ainsi que la prise en compte de l’ordonnancement et du respect des priorités. L’aspect temporel sera lui aussi développé afin de mieux prendre en compte les contraintes temporelles liées au traitement multitâches.
Afin de délimiter les champs d’application de ces modèles, la définition des hypothèses de travail est nécessaire. Elles se reposeront sur les expérimentations effectuées sur les API multitâches dans le paragraphe B.2.
Les API multi-tâches considérés pour les modèles sont de type monoprocesseur et ne comportent que trois types de tâche : tâche maître, tâches rapides, tâches événementielles. De plus nous ne considérerons que les programmes décrits dans le langage LADDER, en raison de sa forte utilisation dans le monde industriel et de sa polyvalence. L’exécution de ce programme LADDER sera supposée répondre aux hypothèses suivantes :
• L’exécution d’une ligne LADDER est atomique Ceci permet de certifier que le temps de calcul d’une ligne est indivisible. C’est-à-dire que
l’exécution de la ligne n’est pas préemptive
17
• Chaque ligne du LADDER peut être représentée par une équation algébrique. Cette hypothèse permet de traduire le programme LADDER en une suite d’équations
exécutées séquentiellement. • Tout calcul d’effectue à temps nul, le temps ne peut s’écouler que entre deux calculs.
La figure 14 illustre la modélisation de l’activité d’un programme LADDER. Dans ce cas l’écart de temps ∆t représente de manière virtuelle le temps de calcul réel.
Figure 14. chronogramme d’exécution du modèle d’un programme LADDER Les cycles de lecture des entrées et d’émission des sorties sont eux aussi soumis aux hypothèses :
• Ils ne sont pas préemptifs. • Toutes les entrées associées à une tâche sont lues en un temps nul au début de la tâche. • Toutes les sorties de la tâche correspondante sont émises en un temps nul à la fin de la
tâche.
D Vérification de programmes API multi-tâches
D.1 Types de propriétés à vérifier L’aspect multi-tâches des API apporte plusieurs propriétés à vérifier, pourtant non
présentes dans le cas d’un API multi-tâches. Ces propriétés peuvent être du type : • Communication entre les tâches.
Par exemple, l’utilisation multiple d’une variable de communication dans une tâche maître peut conduire à sa modification, par une autre tâche, entre deux utilisations. Cela peut conduire à un défaut si ces deux utilisations sont contradictoires. Dans l’exemple présenté sur la figure 15, un traitement mono-tâche impliquerait que « b = c » alors que ce n’est pas toujours vrai dans un traitement multi-tâches.
Figure 15. exemple de programme LADDER
• Temps de réponse.
Contrairement au fonctionnement mono-tâche, le temps de réponse de l’API multi-tâches ne dépend pas seulement du nombre de d’éléments de programmation dans chaque tâche mais de l’interaction entre ces tâches. Ces interactions doivent donc être vérifiées.
Calculs instantanés
∆t ∆t ∆t
∆t ≥ 0
Programme LADDER
t
| a c | +–––||–––––( )––+ | a b | +–––||–––––( )––+ | |
18
alea
DM_avancer:=0topv?
DM_avancer:=1topv?
D.2 Modèle de l’API sous UPPAAL
D.2.1 Présentation de l’outil UPPAAL UPPAAL [LPW97] [BDL+01] [DBL+03] est un outil pour modéliser, simuler et vérifier
des systèmes temps réel, développé conjointement par le département Basic Research in Computer Science (BRICS) à l'université d'Aalborg au Danemark et au département des systèmes informatiques à l'université d'Uppsala en Suède. L'outil est approprié pour les systèmes qui peuvent être modélisés comme une collection de processus non déterministes avec une structure finie de commande et des horloges à valeurs réelles, communiquant par des messages ou des variables partagées. Les domaines d'application typiques sont les contrôleurs temps réel et les protocoles de transmission en particulier, ceux où les aspects de synchronisation sont critiques.
UPPAAL se compose de trois parties principales: un langage de description, un simulateur et un model-checker.
• Le langage de description est basé sur la gestion de transition gardée non déterministe composée de variables d'horloge à valeurs réelles et de types de données simples. Il intègre aussi des canaux de communication par message de type appel-réponse.
• Le simulateur est un outil de validation qui permet l'examen d’exécutions dynamiques possibles d'un système pendant les étapes préliminaires de conception (ou modélisation) ainsi que la visualisation de la trace des contre-exemples données par le model-checker.
• Le model-checker permet de vérifier des propriétés temporelles basées sur la logique temporelle CTL ou des propriétés de vivacité en explorant l'espace d’état symbolique d'un système, c.-à-d. analyse de l’atteignabilité en termes d'états symboliques représentés par des contraintes. Un exemple ou contre-exemple de la propriété peut aussi être donné et représenté grâce au simulateur.
D.2.2 Modélisation de la tâche maître d’un API Comme explicité dans le paragraphe C.2, les lignes LADDER sont traduites en équations
algébriques. Le cycle, périodique ou cyclique, de la tâche sera représenté comme le suggère [MW99] en intégrant les composants du cycle automate (figure 16).
Figure 16. exemple de Programme LADDER modélisé avec UPPAAL Dans la figure 16, nous retrouvons le cycle de la tâche maître :
• La lecture des entrées Elle est représentée par la synchronisation de toutes les entrées à l’aide d’un message de
type broadcast. Dans la figure 13, à l’émission du message topv!, toutes les entrées, représentées
ligne_1
ligne_2
lecture_entree
emission_sorties
topv!
DM_avancer:=!manu ? 0 : DM_avancer
cAvancer:=DM_avancer
Avancer:=cAvancer
alea
manu:=0topv?
manu:=1topv?
| manu DM_avancer| |----|/|-----------(R)----| | | | DM_avancer Avancer | |----| |-----------( )----| | | | |
19
par un automate indépendant indéterministe, sont forcées de choisir une valeur, 0 ou 1. En dehors de cette synchronisation les entrées ne peuvent pas évoluer.
• Le traitement Chaque ligne du programme est écrite ici. Les équations algébriques sont représentées
sous forme d’« update » de la transition. Les équations peuvent être calculées indépendamment, une par transition, ou être regroupée, plusieurs par transition. Dans ce cas la séquentialité du calcul est tout de même respectée.
• L’émission des sorties
Chaque sortie est mise à jour par rapport à sa copie représentant le registre interne de l’automate. Dans la figure 13, la sortie Avancer n’est mise à jour qu’à la fin du cycle, en recopiant sa variable interne correspondante, cAvancer.
Le temps de cycle aussi peut être introduit (figure 17) si nécessaire : si l’on veut vérifier des propriétés dépendant du temps ou si le temps est utilisé dans un autre automate. Nous utiliserons dans ce cas une horloge associée à cet automate. Des gardes et des invariants devront être rajoutés pour contraindre l’évolution du cycle.
Figure 17. Modèle UPPAAL avec prise en compte du temps de cycle La figure 17 nous montre un exemple de modèle prenant en compte le temps de cycle.
Dans ce cas le temps de cycle peut varier entre cinq et sept unités de temps. Nous pouvons remarquer que du fait de l’instantanéité des actions, le temps est positionné avant l’action : nous ne faisons que retarder l’effet de l’action.
D.2.3 La tâche événementielle La tâche interruptive sera modélisée par un simple automate s’activant sur un message de
la partie opérative, étudiée au paragraphe D.4. Ce message correspond à la condition d’activation de la tâche.
x représente le temps de cycle Invariant de la place : la place peut être active que si x<2. La durée de lecture des entrées est donc inférieure à 2 unités de temps. Garde temporelle : la transition ne peut être franchie que si x>5. La durée d’un cycle est donc supérieure à 5 unités de temps. A la fin du cycle, le temps de cycle est réinitialisé.
traitementx<3
lecture_entreex<2
emission_sortiesx<7
topv!
Avancer:=cAvancer,x:=0
x>5
DM_avancer:=!manu ? 0 : DM_avancer,cAvancer:=DM_avancer
20
Le modèle de la tâche événementielle s’obtient à partir du modèle de traitement
standard sur lequel est rajouté une condition de lancement : la recepetion du message d’activation La figure 18 présente un exemple de tâche événementielle se déclanchant sur l’activation du détecteur a.
Figure 18. Modèle UPPAAL d’une tâche interruptive en cas de partie opérative modélisé Le modèle retenu est celui d’une exécution à temps nul (pour refléter la priorité de la tâche
événementielle sur la tâche maître). Cette caractéristique est obtenue par l’utilisation d’une place de type « committed ».
D.2.4 Les temporisations
D.2.4.1 Approches constructeurs De façon à reproduire le plus fidèlement possible le comportement d’un API, des
expérimentations sur des API ont été menées. Parmi les comportements possibles nous avons retenu le plus fréquent dans lequel les temporisations fonctionnent de manière indépendante par rapport au programme LADDER et sont basées sur les tops d’une horloge interne. Dans ce cas, le programme LADDER ne fait que démarrer la temporisation, celle-ci évolue alors d’elle-même en comptant le nombre de top d’horloge dans la résolution où elle est définie (figure 19).
Figure 19. Fonctionnement réel d’une temporisation asynchrone au programme Le fonctionnement retenu pour la temporisation a pour caractéristique :
o Une incertitude sur la durée réelle de la temporisation qui peut varier d’une période d’horloge :
T temporisation voulue ≤ T temporisation réelle ≤ T temporisation voulue + T période d’horloge o La variable TON_OUT peut évoluer pendant la phase de traitement du programme API.
En cas d’utilisation multiple, sa valeur peut évoluer d’un calcul à l’autre. o Lors de l’utilisation de plusieurs temporisations simultanément, elles deviennent
synchronisées par le biais de l’horloge interne.
TON_IN
Horloge interne
Compteur : ET
TON_OUT t
Tâche interruptive déclenchée sur activation du detecteur_a
| b sortie_int||----| |------+----( )----|| | || c | ||----| |------+ || |
+-------+ | TON | TON_IN---|IN Q|---TON_OUT TIME---|PT ET|---TIME +-------+
PT
21
D.2.4.2 Différentes modélisations [MW99] proposa une modélisation de temporisation Time ON delay (TON) d’un point de
vue formel. L’automate représentant la TON possède trois places qui indiquent son état. Chaque changement d’état utilise des messages pour se synchroniser avec l’automate représentant le programme. Ces idées ont été reprises afin de proposer les deux modèles suivants.
D.2.4.2.1 Modèle asynchrone Ce modèle prend en compte les modifications récentes de UPPAAL relative aux messages
de type broadcast. Leurs utilisations permettent de gagner en simplicité de programmation et évitent les blocages. En effet, les envois de message, combinés à des invariants temporels, impliquent souvent des blocages, ou « deadlock ». La modélisation proposée se base sur le fonctionnement défini dans la norme IEC 61131-3. Comme présenté sur la figure 20, une temporisation est modélisée par un automate à trois états communicant avec le programme LADDER avec un message de type broadcast, TEMPO, commun à toutes les temporisations et des variables mémoires, ton_in et ton _out, entrée et sortie de la temporisation.
Figure 20. Modèle d’une temporisation Time ON delay (TON) avec un programme LADDER correspondant
Dans ce modèle, le message TEMPO sert à la prise en compte des variations de ton_in,
modifié dans le modèle LADDER. Pour cette raison, lors de chaque modification de la variable d’entrée d’une temporisation, un message de synchronisation doit être immédiatement émis.
Ce modèle peut être étendu aux deux autres types de temporisations, Time OFF delay (TOFF) et Time Pulse (TP). Ceux-ci sont présentés dans la figure 21.
Figure 21. Modèle de temporisation TOFF et TP
ligne_2
TONx<=10
ton_in:= og && !rc && !car
TEMPO!
Inactive declencheex_Ton <= 500
enclenchee
ton_in
TEMPO?
ton_out := 0,x_Ton:=0
!ton_in
TEMPO?x_Ton == 500 && ton_in
ton_out := 1
!ton_in
TEMPO?
ton_out := 0
enclenchee declencheex_Ton <= 500
Inactive
!ton_in
TEMPO?
ton_out := 0,x_Ton:=0
ton_in
TEMPO?x_Ton == 500 && !ton_in
ton_out := 0
ton_in
TEMPO?
ton_out := 1
idle enclencheex_Ton <= 500
ton_in
TEMPO?
ton_out := 1,x_Ton:=0
x_Ton==500
ton_out:=0
!ton_in
TEMPO?
TOFF TP
22
D.2.4.2.2 Modèle à top d’horloge Dans cette partie, nous allons nous intéresser à la modélisation du comportement réel
d’une temporisation dans un API, décrit dans le paragraphe D.2.4.1. Le modèle est basé sur l’utilisation d’un batteur, reproduisant la fonction top d’horloge de l’API. Comme pour les modèles précédents, l’enclenchement ou la déactivation de la TON, modélisée sur la figure 22, est réalisée avec un message du programme, top_ladder, lorsque sa variable d’entrée prend la valeur correspondante.
Figure 22. Modèle de time on delay utilisant le top horloge avec le programme correspondant
La différence apparaît au niveau du déclenchement. Le modèle compte le nombre de
message top dans la variable c_ton. Le message top est envoyé toutes les dix mille unités de temps par un automate temporisé, appelé « batteur ». La garde d’évolution pour déclencher la temporisation prend en compte la valeur du compteur. Dans le cas de la TON modélisé figure 21, le temps de temporisation Tp est donc :
Tp = 10000 x 3 = 30000 unités de temps Ce modèle permet de prendre en compte la variation de la valeur réelle de temporisation
exposée dans le paragraphe D.2.4.1. L’utilisation d’un batteur unique permet aussi de reproduire les problèmes de synchronisation entre plusieurs temporisations.
ligne_1x<=10
ligne_2
emission_sorties_lecture_entreex<=10
TONx<=10
cclose:=!(cg || car || open) && (ton_out || close),x:=0
copen:= !og && ((rc || (!cg && car)) || open)
open:=copen,close:=cclose
topv!
ton_in:= og && !rc && !carx>=10
top_ladder!
x_bat<=10000
x_bat==10000x_bat:=0top!
Batteur
TONProgramme
23
D.2.4.2.3 Analyse comparée des différents modèle de temporisation Afin de vérifier les comportements et les performances de chacun des modèles de
temporisation, nous allons effectuer des tests sur un programme de fermeture/ouverture de portail. Le programme principal est réalisé en LADDER, représentée en figure 23.
Figure 23. programme de commande LADDER du portail de parking
Les trois modèles obtenus par les trois méthodes explicitées dans le paragraphe D.2.4.2 sont présents dans l’annexe II. Les mesures de performance sont effectuées avec un test de vivacité : vérification de non-blocage du modèle quelle que soit l’évolution. Le temps de calcul indiqué en figure 24 correspond au temps d’utilisation d’un processeur ATLON 1800+ avec 512Mo de RAM, fonctionnant sous Windows XP.
Temps de calcul (s) Mémoire utilisée maximum (Mo) Modèle Mader-Wupper 6.118 9.940 Modèle asynchrone 5.898 8.460 Modèle à top d’horloge 16.994 31.560
Figure 24. performance des modèles de temporisation Les performances du modèle asynchrone sont donc très légèrement supérieures au modèle
de Mader-Wupper mais permet une programmation plus aisée et une diminution des variables utilisées.
Le modèle à top d’horloge est plus lourd mais permet de prendre en compte des comportements plus réalistes. Cette augmentation du temps de calcul est due à la méthode de vérification implantée dans UPPAAL, présentée dans paragraphe D.4.1. Le compteur de top d’horloge oblige la vérification à discrétiser le temps et à connaître précisément la valeur de ce compteur alors que dans les deux autres modèles, le temps écoulé dans la temporisation est juste borné au niveau de l’horloge. En effet, d’un point de vue des performances de model-checking de l’outil UPPAAL, une horloge est plus performante qu’un compteur car la vérification s’effectue grâce au principe de zone de valeur pour l’horloge [Ben03].
| RS_L1 | | +----+ | | RC | RS | Open | R1 +--+-----| |------+--------|S Q|--( )--+ | | CG Car | | | | | +--|/|---| |---+ | | | | OG | | | +-------| |----------------|R1 | | | +----+ | | | | TON_L2 RS_L2 | | +-----+ +----+ | | OG RC Car | TON | | RS | Close | R2 +--| |--|/|--|/|--|IN Q|--|S Q|--( )--+ | 3s-|PT | | | | | CG +-----+ | | | +--+---| |---+-------------|R1 | | | | Car | +----+ | | +---| |---+ | | | Open | | | +---| |---+ |
RC (Remote control)
Car
CG (Closed Gate)
Close
Open
24
D.3 Modélisation de la partie opérative Afin de ne pas seulement vérifier le programme de l’API mais aussi son intégration dans le
système à commander, nous avons étudié la modélisation de la partie opérative. Ceci implique une connaissance approfondie du système à contrôler, notamment le comportement de chaque élément et le temps de réaction. La modélisation de la partie opérative permet d’étendre les possibilités de la vérification de propriété mais souffre de difficultés de mise en œuvre. Pour cette raison, nous allons identifier les apports et les difficultés de cette modélisation, dans le paragraphe suivant, et proposer des solutions aux problèmes énoncés pour l’outil UPPAAL, dans le paragraphe D.3.2.
D.3.1 Intérêts et limites Le principal apport de la modélisation de la partie opérative est la simplification de la
vérification de propriété. Ce gain se décompose en deux parties : • Diminution du temps de calcul
La prise en compte du comportement de la partie opérative permet de limiter le domaine des états atteignables par le programme. En effet, tous les comportements aberrants sont ne sont pas pris en compte à moins de les inclure dans le modèle. De plus, l’utilisation d’un modèle plus ou moins permissif en terme de variation, temporelle et comportementale permet de se prémunir d’une explosion combinatoire de calcul.
• Simplification des équations de propriété L’état de la partie opérative à un moment donné est donné par l’état du modèle qui
la représente. Ces états peuvent donc être utilisés pour effectuer des vérifications de propriété : nous pouvons vérifier que le système commandé ne va jamais atteindre une configuration donnée, sans chercher quels états des sorties de l’API engendreraient cette configuration. De plus, si un contre exemple à cette vérification est trouvé, nous pouvons connaître l’état de l’API y conduisant.
L’utilisation d’un modèle de partie opérative permet ainsi d’atteindre la vérification de
nouvelles propriétés auparavant limitées par l’explosion combinatoire des calculs de vérification. Mais son apport permet aussi la prise en compte de nouveaux concepts de vérification :
• La séquence d’action Dans le cas d’une vérification d’exécution d’un enchaînement d’action, le modèle
de la partie opérative pourra aider à la vérification : la vérification s’effectuera sur son état après la séquence d’action.
• Les propriétés temporelles Certaines propriétés prennent en compte le temps de réaction global du système ou
s’intéressent au temps de réaction du système de commande. Dans ce cas, la modélisation du système contrôlé permet de vérifier des propriétés temporelles entre la partie commande et la partie opérative.
• Les réponses à une sollicitation particulière La vérification de propriété peut être conditionnée par l’état de la partie opérative.
Suivant la configuration de la partie opérative, la réponse du programme implanté dans l’API peut être différente. Nous pouvons donc grâce à la modélisation de la partie opérative, vérifier le comportement de l’API dans des conditions particulières, notamment à l’activation d’une tâche événementielle.
Cependant la modélisation de la partie opérative impose un lourd travail d’étude et
d’expertise du comportement du système. Nous nous efforcerons donc de proposer une méthode de représentation de la partie opérative.
25
D.3.2 Méthode de modélisation sous UPPAAL L’utilisation de l’outil UPPAAL impose certaines contraintes de fonctionnement et de
représentation du modèle de partie opérative. En effet, UPPAAL possède des horloges dont l’utilisation est limitée à leurs réinitialisations ou à des tests simples de valeur. Elles ne peuvent pas être arrêtées ou utilisées dans une équation complexe de test. En partant de ces constats, nous allons construire une modélisation basée sur les hypothèses imposées dans le paragraphe suivant.
D.3.2.1 Hypothèses de modélisation Les hypothèses suivantes ont pour but de délimiter la modélisation en s’appuyant au mieux
sur les capacités de l’outil UPPAAL. • Chaque composant de la partie opérative est modélisé par un automate qui représente
l’état de ce composant. • La partie opérative est modélisée par ses positions stables.
Nous appelons « positions stables » un état de fin de course, de possibilité de d’arrêt ou de passage devant un capteur.
• Chaque passage d’une position stable à une autre est défini par un temps de trajet. • Une fois le trajet débuté, il doit être continué jusqu’à sa fin : pas de modification de
mouvement pendant le trajet Cette hypothèse est du à la restriction d’utilisation des horloges sous UPPAAL.
• Les différents éléments de la partie opérative sont synchronisés par des envois de message.
Le paragraphe D.3.2.2 explicitera cette hypothèse. • La modélisation de ne prend en compte que le fonctionnement nominal du système.
D.3.2.2 Discrétisation des systèmes continus Certains composants de la partie opérative ne se comportent pas seulement en événement
discret, comme le fait un capteur par exemple, mais ont un fonctionnement continu, comme axe asservi, ou hybride, comme un vérin, discret en fin de course mais continu lors du déplacement. La modélisation proposée ici a pour but de discrétiser les comportements continus.
Comme énoncé en hypothèse, dans le paragraphe D.3.3.1, les systèmes continus sont modélisés par des positions stables sur un automate temporisé. La figure 25 présente un exemple de modélisation pour un vérin, son distributeur associé et les capteurs de fin de course
Figure 25. modèle UPPAAL d’un vérin Dans l’exemple présenté, le vérin est donc décomposé en deux états stables correspondant
aux deux fins de course, Verin_rentre, l’état initial, et Verin_sorti. Lorsque le distributeur est commandé pour faire sortir le vérin, l’automate évolue dans l’état sortie_en_cours et l’horloge x_verin est initialisé. L’automate va alors rester dans cet état pour une durée comprise entre 400 et 500 unités de temps représentée par l’invariant de l’état et la garde de la transition. Après cette durée, la variable verin_sorti, correspondant au capteur de fin de course, est mise à un, un message est émis et l’automate est dans l’état Verin_sorti. Le comportement est identique pour la
Verin_rentre Verin_sorti
rentrer sortir
verin_rentre Verin_sorti
sortie_ en_coursx_verin<=500
rentree_ en_coursx_verin<=500
sortir?x_verin:=0
verin_sorti:=1
x_verin>=400verin_sorti!
x_verin:=0rentrer?
verin_rentre:=1x_verin>=400
26
rentrée. Cet exemple présente le principe de discrétisation de mouvement continu : un mouvement transitoire est représenté par une place où une horloge s’écoule.
D.3.2.3 Synchronisation des différents automates Après avoir modélisé chacun des éléments de la partie opérative, nous allons étudier
comment modéliser leurs interactions. Les principales synchronisations s’effectueront par le biais de message, et les transferts de donnée par variables communes.
Entre les automates de la partie opérative les synchronisations permettront de prendre en compte des effets de causes et conséquences directes d’un ensemble sur l’autre. Par exemple, la figure 26 présente deux automates synchronisés qui répondent à la conséquence « lorsque le vérin est sorti, la pièce est déplacée »
Figure 26. exemple de synchronisation entre deux automates La définition du type de message, broadcast ou normal, dépend des contraintes de
synchronisation à imposer. Dans notre exemple, un message de type broadcast doit être utilisé si le vérin peut évoluer même si la pièce ne peut être déplacée ou si plusieurs pièces doivent être déplacées avec le même vérin. Dans les autres cas un message de type normal peut être utilisé. La synchronisation avec le programme de l’API est effectuée de manière unilatérale :
• Les sorties de l’API sont liées à des messages. Lorsqu’une sortie est active, le modèle de l’API émet un message correspondant pour forcer les automates de la partie opérative à évoluer en conséquence.
• Les entrées de l’API sont des variables communes modifiés par la partie opérative et lues par les tâches de L’API.
La communication entre les différents composants du modèle est donnée sur la figure 27.
Figure 27. Schéma global d’échanges de données entre les automates du modèle
verin_rentre Verin_sorti
sortie_ en_coursx_verin<=500
rentree_ en_coursx_verin<=500
sortir?x_verin:=0
verin_sorti:=1
x_verin>=400verin_sorti!
x_verin:=0rentrer?
verin_rentre:=1x_verin>=400
piece_ non_deplacee
piece_deplaceex_piece<=100
verin_sorti?x_piece:=0
piece_tombee!
Vérin Pièce
Variables d’entrée
Tâche maître
Tâche événementielle
Messages de sortie
Message d’activation
API Partie opérative
Variables communes
Messages de synchronisation
Composant1
Comp.2 Comp.3
TON
Messages de synchronisation
Messages de synchronisation
27
D.4 Méthodes de vérification de propriété
D.4.1 Utilisation du model-checker Le model-checker intégré à l’outil UPPAAL permet de vérifier des propriétés exprimées
en logique temporelle CTL [RL96]. Il fonctionne par exploration des états atteignables en fonction des zones de valeurs des horloges [Ben03].
D.4.2 Utilisation d’observateur La vérification de propriété temporelle peut se révéler difficile à mettre en œuvre dans le
cas où la durée est délimitée par deux événements sur des automates disjoints. Par exemple, le temps de réaction de l’API est compris entre l’activation du capteur et l’émission effective de la sortie correspondante.
Ce problème peut être résolu en utilisant un automate supplémentaire dont le but est de réagir aux événements concernés par la propriété temporelle et, par le biais d’une horloge qui lui est propre, de mesurer le temps entre ceux-ci. La propriété temporelle complexe devient donc une simple propriété de valeur d’une horloge. La figure 28 expose un exemple d’observateur.
Figure 28. Exemple de l’observateur de vérification de propriété temporelle
Dans cet exemple, nous allons mesurer le temps compris entre le message posdroite et
moteur_arrêt. Si nous voulons vérifier que la commande arrête le moteur en moins de dix unités de temps après l’arrivée en position droite, La propriété devient alors « A[] not(obs.arret and X>10) », c’est à dire « il n’y a jamais un cas où l’horloge X est supérieure à dix et que l’observateur est dans l’état arrêt ».
D.5 Vérification de propriétés pour la plate-forme MSS
D.5.1 Présentation
La plate-forme MSS a pour fonction de trier un stock de pignons de matières différentes et d’ajouter ou retirer un palier au pignon. Nous allons nous intéresser plus particulièrement au poste 2 qui permet d’identifier le matériau du pignon (acier, cuivre ou PVC noir) et de détecter la présence d’un palier à l’intérieur de celui-ci. L’annexe I présente le système complet ainsi que les modèles obtenus.
inactif
decompte_horloge
arret
posdroite ?X:=0
moteur_arret?
X:=0
28
D.5.2 Propriétés vérifiées et temps de calcul Les calculs de vérification (figure 29) de propriétés sont réalisés à l’aide du model-checker
intégré dans l’outil UPPAAL sur un ordinateur fonctionnant sous Windows XP avec un processeur AMD 1800+ et 1Go de RAM.
Propriété satisfaite
Temps de calcul
Mémoire utilisée (Mo)
Envoie sortie A[] !obs.arret or X<=5 oui 0:53 67992 variable modifiée A[] !obs.arret or X<=5 non 0:40 50166 Pas de partie opérative A[] !obs.arret or X<=5 - >13h >1Go
Figure 29. Résultats et performances du modèle du poste 2
D’après ces résultats, le temps entre l’arrivés au poste de test et l’arrêt du moteur est inférieur à 5ms, si la tâche événementielle émet sa propre sortie. Le programme est donc conforme aux attentes énoncées.
Si cette tâche n’émet pas de sortie mais ne modifie que des variables de communication avec la tâche maître, le temps de réponse devient supérieur à 5 ms. Le programme n’est alors pas conforme aux attentes. Une telle erreur de programmation peut donc être identifiée par cette méthode.
D’un point de vue des performances, nous observons que l’utilisation d’un modèle de partie opérative réduit considérablement le temps de calcul. Le modèle sans partie opérative a été effectué en rendant toutes les variables d’entrés de l’API non-déterministes. Dans ce cas, la vérification rencontre un problème d’explosion combinatoire et le résultat ne peut être trouvé.
D.5.3 Limites du modèle Les hypothèses de modélisation et l’utilisation d’un outil spécifique, UPPAAL, apportent
certaines limites à la vérification de propriétés. En terme de modèles de tâches API, le temps de cycle ne peut être réparti sur chacune des équations algébriques représentant le programme LADDER car le temps de calcul de vérification serait trop grand. Cette limite impose de répartir de manière « intelligente », et donc pas systématique, les places où le temps peut s’écouler.
D’un point de vue de la partie opérative, la seule prise en compte du fonctionnement nominal ne permet pas de connaître la réaction de la commande en cas de défaillance. De plus, certains mouvements ne sont pas possibles à cause de l’utilisation d’horloge de l’outil UPPAAL : une fois un déplacement continu commencé, il doit être fini jusqu'à la prochaine position stable.
29
Conclusions
Pour vérifier des programmes d’API, une formalisation de son comportement sous forme de modèle est nécessaire. Cependant les modèles présents dans la littérature ne s’intéressent pas à l’aspect temporel, multi-tâches et temps réel. Ce stage de DEA s’inscrivait dans cette optique de fournir des méthodes de vérification de propriété se basant sur des modèles. Nous avons choisi une modélisation par automates temporisés et synchronisés, présent dans l’outil de simulation et de model-checking UPPAAL.
Afin de concevoir des modèles au plus proche du comportement réel, une étude des documents constructeurs a été effectuée ainsi que certains tests de validation du comportement. Ces connaissances nous ont permis de formuler les hypothèses et les limites de notre modèle.
La prise en compte de l’aspect temporel et multi-tâches des langages de programmation d’API permet l’élargissement du champ des propriétés vérifiables. Notamment les propriétés temporelles et relatives à une sollicitation particulière, comme l’activation d’une tâche événementielle, sont vérifiables grâce à cette méthode. Cependant ceci s’accompagne de temps de calcul plus long dû aux variables temporelles.
Les développements futurs pourraient donc appliquer cette méthode sur un système de grande envergure afin de la valider que les problèmes d’explosion combinatoire ne seront pas atteints pour la vérification de propriétés. Dans le cas contraire, une optimisation du temps du calcul devra être envisagée.
30
BIBLIOGRAPHIE [BDL+01] G. Behrmann, A. David, K. G. Larsen, O. Möller, P. Pettersson, and W. Yi.
'Uppaal - Present and Future' .In Proceedings of the 40th IEEE Conference on Decision and Control (CDC'2001). Orlando, Florida, USA, December 4 to 7, 2001.
[Ben03] M. Ben Gaid, Modélisation et vérification des aspects temporisés des langages pour
automates programmables industriels. Mémoire de DEA. September 2003. 68 pages [CDP+00] G. Canet, B. Denis, A. Petit, O. Rossi, P. Schnoebelen, Un cadre pour la
vérification automatique de programmes IL, 1ère Conférence Internationale Francophone d'Automatique, IEEE-CNRS-GRAISyHM, CIFA'2000, Lille (France), pp. 693-698, Juil. 2000
[DBL+03] A. David, G. Behrmann, K. G. Larsen, and W. Yi. ‘A Tool Architecture for the
Next Generation of UPPAAL’ . Technical report Uppsala University 2003. [DDL+01] B. Denis, O. De Smet, J.-J. Lesage, J.-M. Roussel, Dispositif et procédé d’analyse
de performances et d’identification comportementale d’un système en tant qu’automate à événements discrets et finis, Brevet N° 01 110 933, Août 2001
[Die00] H. Dierks. PLC-Automata: A New Class of Implementable Real-Time Automata,
Theoretical Computer Science, 253(1):61-93, December 2000. [Huu99] R. Huuck. ‘Verifying timing aspects of VHS case study 1’. Technical Report, Christian-
Albrechts-Universität zu Kiel, 1999. Available at: http://www-verimag.imag.fr/VHS/year1/cs11j.ps
[LL00] S. Lamperiere-Couffin, J.-J. Lesage, Formal verification of the sequential part of PLC
programs, 5th Workshop on Discrete Event Systems, WODES'2000, Ghent (Belgium), pp. 247-254, Août 2000
[LPW97] K. G. Larsen, P. Pettersson and W. Yi. ' Uppaal in a Nutshell' .In Springer International
Journal of Software Tools for Technology Transfer 1(1+2), 1997. [Mad00] A. Mader. ‘A Classification of PLC Models and Applications’. 5th Int. Workshop on
Discrete Event Systems (WODES'2000) -- Discrete Event Systems, Analysis and Control, R. Boel and G. Stremersch (eds.) , published by Kluwer Academic Publishers, Massachusetts, held in Ghent, Belgium, Aug. , 2000, pp. 239-247.
[MW99] A. Mader, H.Wupper Timed automaton models for simple programmable logic
controllers. In Proceedings of Euromicro Conference on Real-Time Systems 1999, York, UK, june, 9-11 1999.
[RDC+00] O. Rossi, O. De Smet, S. Couffin, J.-J. Lesage, H. Papini, H. Guennec, Formal
verification: a tool to improve the safety of control systems, 4th IFAC Symposium on Fault Detection, Supervision and Safety for Technical Processes, SAFEPROCESS'2000, Budapest (Hungary), pp. 885-890, Juin 2000
31
[RL96] J.M. Roussel, J.J. Lesage, Définition d'un cadre formel Pour l'expression et la vérification de propriétés d'un modèle grafcet, Actes du congrès Modélisation des Systèmes Réactifs MSR'96 pp 229-237, Brest, 28-29 Mars 1996
[Ros03] O. Rossi, Validation formelle de programmes Ladder Diagram pour Automates
Programmables Industriels, Thèse de Doctorat en EEA, ENS de Cachan, 208 p., juin 2003 [TE99] Y. Trinquet, J.P. Elloy, Systèmes d’exploitation temps réel, principes, Technique de
l’ingénieur n° r8050, 1999 [Yov93] S. Yovine. Méthodes et outils pour la vérification symbolique de systèmes temporises.
Master thesis, Institut National Polytechnique de Grenoble, France, May 1993. [Wil99] H. X. Willems. 'Compact timed automata for PLC Programs. Technical Report,
University of Nijmegen. November 1999. [ZRK03] B. Zoubek, J.-M. Roussel, M. Kwiatkowska, Towards automatic verification of
ladder logic programs, Proceedings of IMACS-IEEE "CESA'03" : "Computational Engineering in Systems Applications", CD ROM paper S2-I-04-0169, 6 pages, Lille (France), 9-12 July 2003
