Analyse temporelle des systèmes d'acquisition de données : une...

NO D’ORDRE 2008 ANNÉE 2008

THÈSE

A NALYSE TEMPORELLE DES SYS -TÈMES D ’ ACQUISITION DE DONNÉES :

UNE APPROCHE À BASE D ’ AUTO -MATES TEMPORISÉS COMMUNICANTS

ET D ’ OBSERVATEURS

Présentée devant :L’Institut National des Sciences Appliquées de LyonFaculté des Sciences de Tunis

Pour obtenir :Le grade de docteur

Spécialité :Informatique

Formation doctorale :Informatique

École doctorale :Informatique et Information pour la Société

Par :Belgacem BEN HEDIA

SOUTENUE PUBLIQUEMENT DEVANT LE JURY COMPOSÉ DE :

Frédéric BONIOL, Professeur, ENSEEIHT de Toulouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RapporteurNèjib BEN HADJ-ALOUANE, Professeur, ENSI Tunis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RapporteurPhilippe DHAUSSY, Enseignant-Chercheur, ENSIETA Brest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ExaminateurBelhassen ZOUARI, Professeur, Directeur de l’A.N.S.I Tunisie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ExaminateurJean Philippe BABAU, Professeur, UBO Brest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Co-directeur de thèseRiadh ROBBANA, Professeur, Ecole Polytechnique Tunis . . . . . . . . . . . . . . . . . . . . . . . . . . . Co-directeur de thèseFabrice JUMEL, Enseignant-Chercheur, ESCPE Lyon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Co-encadrant de thèse

CENTRE D’INNOVATIONS EN TÉLÉCOMMUNICATIONS ET INTÉGRATIONS DE SERVICES (CITI)LABORATOIRE D’INFORMATIQUE, DE PARALLÉLISME ET DE PRODUCTIQUE (LIP2)

Préambule

Remerciements

Une thèse, trois ans de travail et puis la rédaction de ce manuscrit. Il est certainqu’on n’y arrive pas tout seul, mais avec l’aide et le soutien des personnes qui nous ontentourés, sur le plan professionnel, mais aussi sur le plan personnel. Je ressers alors cesquelques paragraphes pour les remercier.

Je tiens tout d’abord à remercier Jean-Philippe Babau directeur de cette thèse, maisaussi de mon DEA (mastère) et de mon PFE. Ça fait cinq ans passés à ses côtés. Il asu m’orienter dans ce monde de recherche et faire preuve de patience et compréhen-sion dans les moments difficiles. Je le remercie pour ses conseils, et son soutien duranttoutes ses années. Il est pour beaucoup dans l’aboutissement de ce travail. J’ai beaucoupappris de lui.

Un très bon accueil dans son équipe, de très bonnes conditions de travail et de lacompréhension, c’est ce que m’a réservé Riadh Robbana le co-directeur de cette thèsepour chacun des séjours que j’ai effectué en Tunisie. Merci pour ses conseils et les dis-cussions constructives que j’ai eues avec lui.

Je tiens aussi à remercier Fabrice Jumel, co-encadrant de cette thèse pour ses re-marques, ses critiques constructives et ma première expérience d’enseignement à sescôtés. Il était toujours agréable de discuter des sciences avec lui.

Je tiens également à remercier chacun des membres du jury pour avoir acceptéde jouer ce rôle et en particulier, Frédéric Boniol et Néjib Ben Hadj Alouane pour lesconseils avisés qu’ils m’ont procurés en tant que rapporteur de cette thèse.

Enfin, il ne faut pas oublier les gens qui nous entourent pour leurs soutiens moralet matériel. L’équipe du CITI, ma femme Amna, mes parents et ma famille, mes amis(Mohsen, Abdellatif, Ali, Romuald, Claire, Lionel) et en particulier Julien, après quatreans de vie commune au bureau je peux lui dire un grand merci.

iv

Résumé

Dans le cadre des applications temps réel de contrôle de procédé, la thèse proposeune théorie et des outils formels pour caractériser temporellement le retard des don-nées acquises sur l’état du procédé, acquisition réalisée via un logiciel dédié appelépilote. Le contexte et le domaine d’étude de la thèse se base sur les éléments consti-tuant une chaîne d’acquisition de données dans un contexte de contrôle de procédé,les différentes caractéristiques temporelles et les approches pour les évaluer vis-à-visdes flots de données acheminés dans la chaîne d’acquisition. Ce travail s’appuie sur unensemble des bases théoriques requises pour cette caractérisation, particulièrement lesautomates temporisés communicants, les systèmes de transitions étiquetées et la vérifi-cation formelle de propriétés sur ces automates, et en particulier les observateurs. Nousproposons d’abord de formaliser les principes formels de l’évaluation des propriétéstemporelles des flots des données. L’approche se concentre sur le comportement desoccurrences d’un flot de données dans une chaîne d’acquisition et sur la mise en placede l’observation pour l’évaluation de leurs caractéristiques temporelles et spécialementle retard. Ensuite, nous donnons les clefs techniques de la modélisation de notre ap-proche en IF et nous proposons des exemples de modélisation de quelques élémentsde la chaîne d’acquisition, mais aussi la modélisation de l’observation pour l’évalua-tion des caractéristiques temporelles. Cette modélisation s’appuie sur deux approchesdifférentes de modélisation de la chaîne d’acquisition, un premier à un niveau de spé-cification et un autre à un niveau d’implémentation. Enfin, nous donnons les résultatsde l’approche proposée sur des exemples de chaînes d’acquisition, et nous présentonsplusieurs utilisations possibles des résultats obtenus (paramétrage ou tuning d’un pi-lote d’équipement, détermination du langage de retard pour une chaîne d’acquisition).Au final, l’étude de l’évaluation du retard montre l’influence des paramètres de confi-guration du pilote sur les retards des données traitées par l’application.

v

Notes

. 2

Table des matières

Préambule iii

Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

Table des matières . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Introduction 1

I État de l’art 5

1 Chaîne d’acquisition dans les systèmes de contrôle/commande 7

1.1 Domaine d’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2 Capteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 Les pilotes d’équipement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4 Chaîne d’acquisition des données des systèmes de contrôle de processusmodèles et caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.5 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2 Système temporisé communicant et méthodes classiques de vérification 25

2.1 Contexte de l’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2 Définition d’automates temporisés communicants . . . . . . . . . . . . . 282.3 Propriétés : classification et techniques de vérification . . . . . . . . . . . 35

2.4 Conclusion et discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

II Approche 47

3 Évaluation des propriétés temporelles d’un flot de donnée 49

3.1 Cycle de vie et propriétés d’une occurrence de flot de données . . . . . . 50

3.2 Variables d’observation d’occurrence . . . . . . . . . . . . . . . . . . . . . 59

3.3 Observateur d’occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

TABLE DESMATIÈRES vii

4 Modélisation 71

4.1 Outil et langage de modélisation IF . . . . . . . . . . . . . . . . . . . . . . 72

4.2 Modélisation formelle d’une chaîne d’acquisition . . . . . . . . . . . . . 73

4.3 Observateur d’évaluation de retard et extraction des résultats . . . . . . 85

4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

III Études de cas (expérimentation) 89

5 Évaluation et expérimentation 91

5.1 Expérimentations : exemples et valeurs de retard . . . . . . . . . . . . . . 92

5.2 Langage de retard et utilisation de l’approche pour la configuration despilotes d’équipement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Conclusions et perspectives 111

Bibliographie 115

Table des figures

1.1 Boucle fermée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Chaîne usuelle d’acquisition interne d’un capteur . . . . . . . . . . . . . 111.3 Architecture générique de capteur intelligent . . . . . . . . . . . . . . . . 131.4 Fonctionnalités internes d’un capteur intelligent . . . . . . . . . . . . . . 141.5 Le pilote d’équipement dans un système . . . . . . . . . . . . . . . . . . . 151.6 Chaîne d’acquisition des données . . . . . . . . . . . . . . . . . . . . . . . 18

2.1 Sémantique de l’urgence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.2 Deux automates temporisés et leur composition parallèle . . . . . . . . . 342.3 Architecture classique de la vérification . . . . . . . . . . . . . . . . . . . 432.4 Vérification “ à la volée ” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.1 Élément d’une chaîne d’acquisition . . . . . . . . . . . . . . . . . . . . . . 503.2 Communication du flot occ entre le producteur Comp1, le composant in-

termédiaire Comp2 et un composant consommateur Comp3 : mode re-quest/pull entre Comp2 et Comp3, et mode waiting/push entre Comp1 etComp2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.3 Cycle de vie d’une occurrence dans un élément de la chaîne d’acquisition 553.4 Cycle de vie d’une occurrence dans un élément de la chaîne d’acquisition

(suite) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.5 Cycle de vie d’une occurrence dans un élément de la chaîne d’acquisition

(suite et fin) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.6 Cycle de vie d’une occurrence dans une chaîne d’acquisition . . . . . . . 593.7 Observation d’une occurrence occi . . . . . . . . . . . . . . . . . . . . . . 663.8 Observateur de retard Obsretard . . . . . . . . . . . . . . . . . . . . . . . . 68

4.1 Chaîne d’acquisition des données . . . . . . . . . . . . . . . . . . . . . . . 744.2 Automate du capteur physique périodique (PC : période capteur) . . . . 754.3 Automate du capteur physique sporadique (PC : période capteur) . . . . 754.4 Automate du capteur physique avec un envoi en rafale périodique (PC :

période capteur) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.5 Automate de l’application de contrôle (PA : période de l’application) . . 764.6 Automate de l’interface de communication . . . . . . . . . . . . . . . . . 77

TABLE DES FIGURES ix

4.7 Automate de pilote d’équipement (Pmax et Pmin : période de pilote mini-male et maximale) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.8 Structure d’une chaîne d’acquisition réel . . . . . . . . . . . . . . . . . . . 794.9 Structure de modèle IF d’une chaîne d’acquisition réelle . . . . . . . . . . 814.10 Automate d’un processus IF avec une prise en compte d’une durée d’exé-

cution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.1 Retards minimaux et maximaux en fonction de la période du pilote . . . 935.2 Évolution du retard vis-à-vis de la période de scrutation du pilote pour

différentes périodes de l’application. . . . . . . . . . . . . . . . . . . . . . 965.3 Évolution du retard vis-à-vis de la période de scrutation du pilote pour

des durées d’exécution définies sous la forme d’intervalle. . . . . . . . . 975.4 Évolution du retard vis-à-vis de la période de scrutation du pilote et la

période de scrutation de l’application. . . . . . . . . . . . . . . . . . . . . 1035.5 Évolution du retard vis-à-vis de la période de scrutation du pilote et une

période de l’application de 20. . . . . . . . . . . . . . . . . . . . . . . . . . 1045.6 Évolution du retard vis-à-vis de la période de scrutation du pilote et une


période de l’application de 17. . . . . . . . . . . . . . . . . . . . . . . . . . 1055.8 Évolution du retard vis-à-vis de la période de scrutation du pilote et la

période de scrutation de l’application. . . . . . . . . . . . . . . . . . . . . 1065.9 Évolution du retard vis-à-vis de la période de scrutation du pilote et une



période de l’application de 17. . . . . . . . . . . . . . . . . . . . . . . . . . 1085.12 Automate des valeurs de retard possibles pour l’exemple 1. . . . . . . . . 1085.13 Automate des valeurs de retard possibles de l’exemple 2. . . . . . . . . . 1095.14 Automate des valeurs de retard possibles de l’exemple 3. . . . . . . . . . 109

Un problème sans solution est un problème mal posé

Albert Einstein

Introduction

LE XXe siècle fut marqué par la révolution des technologies de l’information et des

communications. L’informatique est passée, en l’espace de quelques décennies, dustatut de curiosité scientifique et de prototype militaire à celui d’outil incontournableet massivement répandu : désormais, tous les systèmes, des appareils domestiques auxsystèmes de navigation ou de contrôle de procédés industriels traitent et transmettentdes informations, en particulier des données mesurées sur l’état du procedé contrôlé etson environnement.

Systèmes de contrôle/commande

Les systèmes de contrôle de processus, c’est-à-dire les systèmes en charge du suiviet/ou du contrôle d’un processus physique auquel ils sont liés, sont présents dans desnombreux secteurs d’activités (système de contrôle de production, ferroviaire, avio-nique, spatiale ou encore domotique). Ces systèmes informatiques dont le compor-tement dépend de l’évolution du processus qu’ils contrôlent sont critiques : une dé-faillance du contrôle peut avoir des conséquences catastrophiques.

Systèmes temps réel

Les systèmes de contrôle de processus sont des systèmes réactifs qui contrôlent entemps réel leur environnement physique. Du fait de l’évolution dynamique du proces-sus, les systèmes de contrôle commandent le processus en fonction des “ informations” ou des données mesurées sur ce dernier et traduisant son évolution, dans un tempscontraint pour assurer un contrôle correct [Sta88].

Les spécificités temps réel des systèmes de contrôle de processus influent le pro-cessus de développement. En particulier, une évaluation des caractéristiques tempo-relles lors du développement est nécessaire pour assurer leur validation. Ainsi, si lescaractéristiques (les lois) temporelles des flots d’informations en provenance ou à des-tination de processus ne sont pas prises en compte lors de développement, la valida-tion du système est incorrecte vis-à-vis des propriétés temporelles qu’il doit satisfaire[WT95, MMJ05].

2

En effet, le système de contrôle évolue, non seulement en fonction des valeurs desinformations “ en entrée ”, mais aussi en fonction de leur qualité d’acquisition (préci-sion, retard,...).

Pilote d’équipement

Ce flot d’informations en “ entrée ” d’un système de contrôle de processus estconstruit par un ensemble de composants de mesure appelés “ capteurs ”, et à des-tination de l’application de contrôle. De plus, les systèmes de contrôle de processusintègrent un (ou plusieurs) composant logiciel appelé “ pilote d’équipement ” permettantde fournir une interface entre l’application et l’équipement (ici le ou les capteurs). Lepilote d’équipement est un composant logiciel qui affecte d’une manière importantela qualité des informations transmises à l’application de contrôle et donc la qualité dessystèmes. Le pilote de capteur ou pilote d’acquisition est un composant critique du sys-tème, il est à l’origine de plusieurs bugs et crashs des systèmes de contrôle de processus[MMM93].

Propriétés temporelles des pilotes d’équipement

La validation des propriétés temporelles des systèmes de contrôle de processus sebase sur une connaissance des caractéristiques temporelles des flots d’informations en“ entrée ” du système de contrôle. La caractérisation de flots d’information acheminésà partir des capteurs à l’application de contrôle se traduit par une évaluation des ca-ractéristiques temporelles de cette la chaîne d’acquisition. Vu le contexte temps réel dessystèmes de contrôle de processus cette validation se doit d’être exhaustive et formelle.

La validation des propriétés temporelles des pilotes des systèmes d’acquisition pourle contrôle de processus s’effectue alors en plusieurs étapes :

• Identifier les propriétés temporelles à vérifier pour le système d’aquisition vis-à-vis dusystème de contrôle.

• Modéliser le système et son pilote d’équipement.• Choisir un langage (et outils associés) pour la formalisation des modèles.• Analyser et vérifier des propriétés.• Paramétrer le pilote d’équipement et le système de contrôle en fonction des résultatstrouvé lors des étapes précédentes.

Ces étapes vont diriger notre proposition qui tâche de répondre à ces probléma-tiques.

Contributions 3

Contributions

Nous proposons une approche d’évaluation formelle des caractéristiques tempo-relles des chaines d’acquisitions de données dans les systèmes de contrôle de processus.Cette évaluation est basée sur les automates temporisés communicants et les observa-teurs des propriétés. Les résultats obtenus dans ce travail se focalisent sur les théma-tiques suivantes :

• L’instrumentation d’un observateur d’occurrence pour l’évaluation des proprié-tés temporelles.

• Évaluation et caractérisation fine des retards d’un pilote d’équipement.• Évaluation du retard, du langage du retard du pilote d’équipement en fonctiondes paramètres donnés d’une chaîne d’acquisition (paramètres des capteurs, pi-lote, et application du contrôle).

Pour obtenir ces résultats on a définit les :

1. principes d’un observateur d’occurrence de flot de données au sein d’un systèmecommunicant,

2. principes de modélisation d’un système d’acquisition de donnée.

Plan de la thèse

Cette thèse vise à proposer des outils et des méthodes pour l’évaluation de proprié-tés temporelles des pilotes d’acquisition pour les systèmes de contrôle de processus (es-sentiellement “ le retard ”). Après cette introduction générale de la thèse, le chapitre 1présente le contexte et le domaine d’étude de la thèse, après une introduction sur les élé-ments constituant une chaîne d’acquisition de données dans un contexte de contrôle deprocessus, nous présentons les différentes caractéristiques temporelles et les approchespour évaluer des flots des données acheminées dans la chaîne d’acquisition.

Le chapitre 2 définit l’ensemble des bases théoriques requises pour la suite de cetravail. Nous présentons particulièrement les automates temporisés communicants, lessystèmes de transitions étiquetées et la vérification formelle de propriétés sur ces auto-mates.

Une fois l’ensemble des bases théoriques déterminé, nous définissons dans le cha-pitre 3 une formalisation de l’évaluation des propriétés temporelles des flots des don-nées. L’approche présente le comportement des occurrences d’un flot de données dansune chaîne d’acquisition et la mise en place de l’observation pour l’évaluation de leurscaractéristiques temporelles et spécialement le retard.

Le chapitre 4 donne les clefs techniques de la modélisation de notre approche en IF[BGM02] et propose des exemples de modélisation de quelques éléments de la chaîned’acquisition mais aussi la modélisation de l’observation pour l’évaluation des caracté-

4

ristiques temporelles. Ce chapitre s’appuie sur deux approches différentes de modéli-sation de la chaîne d’acquisition, un premier à un niveau de spécification et un autre àun niveau d’implémentation.

Enfin, le dernier chapitre de la thèse donne les résultats de l’approche proposée surdes exemples de chaînes d’acquisition, et présentes plusieurs utilisations possibles desrésultats obtenus (paramétrage ou tuning d’un pilote d’équipement, détermination dulangage de retard pour une chaîne d’acquisition).

Première partie

État de l’art

On s’aperçoit qu’on est devenu un spécialiste quand les choses dont on parleavec plaisir ennuient les autres.

Gilbert Cesbron

1Chaîne d’acquisition dans les systèmes de

contrôle/commande

CE chapitre présente le contexte et le domaine d’étude de la thèse. Dans ce chapitre nous présentons leséléments d’une chaine d’acquisition de données dans un contexte de contrôle de processus ainsi que

les différentes caractéristiques temporelles et les approches pour évaluer des flots des données acheminésdans la chaîne d’acquisition.

Plan du chapitre

1.1 Domaine d’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1.1 Système de contrôle de processus . . . . . . . . . . . . . . . . . 81.1.2 Aspects temporels et développement des systèmes de

contrôle de processus . . . . . . . . . . . . . . . . . . . . . . . . 91.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Capteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.2 Capteurs intelligents . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3 Les pilotes d’équipement . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4 Chaîne d’acquisition des données des systèmes de contrôle de pro-cessus modèles et caractéristiques . . . . . . . . . . . . . . . . . . . . . 171.4.1 Modèle d’une chaîne d’acquisition des données . . . . . . . . 181.4.2 Caractéristiques d’une chaîne d’acquisition . . . . . . . . . . . 191.4.3 Évaluation des caractéristiques d’une chaîne d’acquisition . . 21

1.5 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8 1. Chaîne d’acquisition dans les systèmes de contrôle/commande

1.1 Domaine d’étude

L’étude menée dans cette thèse s’intéresse aux systèmes de contrôle de processus,c’est-à-dire des systèmes en charge du suivi et/ou du contrôle d’un processus physiqueauquel ils sont fortement liés. De ce fait, un système de contrôle du processus est unsystème informatique dont le comportement dépend de l’évolution du processus qu’ilcontrôle.

1.1.1 Système de contrôle de processus

Dans les systèmes de contrôle de processus on distingue deux entités principales :

L’environnement physique : il comporte le processus à contrôler et l’ensemble deson environnement, soit les phénomènes physiques n’appartenant pas au pro-cessus. L’environnement physique contient une entité appelée “ opérateur ” quiest une personne ou un système extérieur fournissant des directives que le sys-tème de contrôle doit réaliser sur le processus à contrôler. On parle généralementde consignes. Pour assurer le suivi de consignes, l’état du processus à contrôler etsont environnement peuvent être mesurés par un ensemble de capteurs et l’étatdu processus peut être modifié à l’aide d’actionneurs.

Le système de contrôle : c’est l’ensemble des applications de contrôle ainsi que leurssupports d’exécution matériels et logiciels (microcontrôleurs, exécutif temps réel,pilotes d’équipement...). Les applications de contrôle peuvent obtenir des infor-mations sur le processus via les capteurs et agir sur celui-ci par l’intermédiairedes actionneurs.

Les premiers systèmes de contrôle (production, automobile...) étaient basés exclusi-vement sur l’être humain (l’opérateur). Ce dernier est en charge d’agir sur le systèmeen fonction d’une sensation (observation) ou d’une perception de l’état de processuscontrôlé. Avec l’arrivée des systèmes automatisés, que ce soit dans l’industrie (les sys-tèmes de production) ou dans la vie courante (électroménager, automobile...), on assisteà une réduction de l’intervention de l’opérateur qui se réduit à donner des ordres oudes consignes de haut niveau.

L’automatisation du contrôle a alors pour but de sécuriser et d’optimiser les opé-rations de contrôle. Les stratégies actuelles consistent à réduire de plus en plus l’inter-vention de l’opérateur, le but étant d’améliorer la qualité tout en accroissant la sûretéde fonctionnement. Pour satisfaire ces exigences, le concepteur “ système ” intègre, àdifférents niveaux hiérarchiques de système, la boucle fermée (figure 1.1). Pour assurerle contrôle, un système de contrôle échange des informations avec son environnementphysique. L’échange se fait dans les deux sens. On distingue les informations dites “ enentrée ” qui sont consommées par le système de contrôle (lesMesure et les Consignes) etles informations dites “ en sortie ” qui sont produites par le système de contrôle. Par lasuite de l’étude, on s’intéresse aux informations “ en entrée ”.

1.1. Domaine d’étude 9

FIG. 1.1 – Boucle fermée

Une information “ en entrée ” est acquise par l’intermédiaire de capteurs pour pro-duire des mesures. Une mesure est une représentation numérique ou analogique degrandeurs physiques qui reflètent l’état de l’environnement physique. L’état de l’envi-ronnement physique peut être représenté par une ou plusieurs mesures. L’état de l’en-vironnement physique étant variable, une mesure numèrique est un flot de données,c’est-à-dire un ensemble infini d’occurrences consécutives, noté occi représentant unegrandeur physique mesurée occ de l’environnement physique ou i représente le nu-méro de la iéme l’occurrence de la mesure. Par la suite, on note par data(occi) la valeurde la donnée de l’occurrence occi. De même, @occi représente la date d’acquisition deocci, soit la date de la mesure.

Les flots d’informations naviguent dans le système de contrôle à partir des capteursjusqu’à l’application de contrôle. L’ensemble des entités traversées par ces flots d’infor-mations est appelé dans la suite chaîne d’acquisition des données.

1.1.2 Aspects temporels et développement des systèmes de contrôle de processus

Un système de contrôle de processus est un système réactif qui contrôle en tempsréel son environnement physique. Du fait de l’évolution dynamique du processus, lesystème de contrôle doit produire des “ sorties ” en fonction des “ entrées ” dans untemps contraint pour assurer un contrôle correct [Sta88].

Les spécificités temps réel des systèmes de contrôle de processus influent le proces-sus de développement. En particulier, une évaluation des caractéristiques temporelles


lors de développement est nécessaire pour assurer leur validation. Ainsi, les travaux[WT95, MMJ05, JUM03, Mar00, Lia01] font le constat que si les caractéristiques (leslois) temporelles des flots d’informations en provenance des capteurs ou à destinationdes actionneurs ne sont pas prises en compte lors du développement, la validation dusystème est incorrecte vis-à-vis de propriétés temporelles qu’il doit satisfaire.

En effet, le système de contrôle évolue, non seulement en fonction des valeurs desinformations “ en entrée ”, mais aussi en fonction de leur qualité d’acquisition (précision,retard,...). Pour les systèmes de contrôle [JUM03, MMJ05] mettent l’accent sur deuxpropriétés temporelles importantes pour les flots “ en entrées ” qui sont la loi d’arrivéeet la loi de retard.

1.1.3 Conclusion

La validation des propriétés temporelles des systèmes de contrôle de processus sebase sur une connaissance des caractéristiques de flots d’informations “ en entrée ” dusystème de contrôle. La caractérisation des flots d’information acheminés à partir descapteurs à l’application de contrôle se traduit par une évaluation des caractéristiquestemporelles de la chaîne d’acquisition.

Nous allons tout d’abord présenter les différentes entités formant une chaîne d’ac-quisition de données (capteur et pilote d’équipement). Nous étudions ensuite les carac-téristiques temporelles nécessaires à la validation de propriétés de temporelles sur lesystème de contrôle du processus. Nous pourrons alors étudier les approches et outilsformels pouvant être mis en œuvre pour permettre leur évaluation.

1.2 Capteurs

1.2.1 Définitions

Un capteur est un composant électronique qui fournit une image d’une grandeurphysique de l’environnement physique d’un système de contrôle de processus. Cetteimage permet d’appréhender l’environnement avec une certaine précision. La normeIEEE 1451 [14599] donne la définition suivante d’un capteur :

Définition 1.2.1. “ Component providing a useful output in response to a physical, chimical,or biological phenomenon. This component may already have some signal conditioning associa-

ted with it. Example : platinum resistance temperature detector, humidity sensor with voltage

output, light sensor with frequency output, pH probe, and piezoresistive bridge ”.

“ Composant fournissant une sortie utile en réponse à un phénomène physique, chimique

ou biologique. Ce composant peut intégrer une phase de conditionnement du signal. Exemples :

1.2. Capteurs 11

FIG. 1.2 – Chaîne usuelle d’acquisition interne d’un capteur

sonde de température, capteur d’humidité avec une sortie en tension, capteur de luminosité avec

une sortie fréquentielle, capteur pH, et des ponts piezorésistifs ”.

Avec les capteurs, on obtient une représentation numérique de l’état de proces-sus. Les grandeurs physiques ainsi mesurées permettent de guider la production, lamaintenance ou l’utilisation d’un système. Un capteur du point de vue de l’utilisateur[MMM93] doit englober les fonctions suivantes :

• Transduction : c’est un processus de transformation d’attribut physique (parexemple une énergie) en un autre attribut. La transduction est le principe de basede nombreux capteurs qui est est de transformer une grandeur physique en uneautre grandeur qui elle sera mesurable facilement (par exemple, une tension).

• Acquisition : c’est l’obtention d’un signal identifiable provenant d’un émetteur.• Conditionnement : c’est l’acte de mettre en forme le signal mesuré pour le tra-duire en une grandeur qui permet le traitement. Le conditionnement sert aussi àréduire le degré de distortion.

• Traitement : c’est le codage, la conversion ou la compression du signal pour sonstockage et sa transmission.

• Communication : c’est l’association établie entre des unités fonctionnelles pouracheminer des informations.

La figure 1.2 montre la chaîne usuelle d’acquisition interne d’un capteur. Après unephase d’acquisition et de conditionnement du signal (mise en forme du signal), la par-tie transmission permet de fournir au système de contrôle les données mesurées. Gé-néralement, un bus d’échange entre le capteur et le système de contrôle se charge descommunications. Il est de plus en plus courant d’utiliser des capteurs industriels ayantdes sorties bus I2C ou bus CAN (par expemple, dans l’automobile). Ainsi, les systèmesde contrôle de processus multi capteurs sont passés vers une technologie sur bus mul-tiplexé. Cette architecture multicapteurs offre une certaine souplesse aux concepteurs[SK98] :

• La redondance des capteurs est fortement facilitée dans une architecture sur bus.Ansi la défaillance d’un capteur (précision, sensibilité, panne ..) peut être com-pensée par la présence d’autres capteurs, de manière transparente pour l’appli-cation de contrôle.


• la répartition d’un même type de capteurs sur plusieurs zones géographiquesde l’environnement physique (processus ou le reste de l’environnement) permetd’avoir une image plus complète de l’environnement.

Les mesures qui sont fournies par les capteurs, des détecteurs, des analyseurs ouencore recueillies par les opérateurs, sont censées fournir une information objective etpermettent aux niveaux supérieurs du contrôle de prendre les décisions appropriées.

Ainsi, la fonction mesure (capteur) ne se résume plus seulement à la collecte et autransport d’information, mais intègre aussi la fonction gestion des informations (pro-duire, stocker, distribuer intelligemment, supprimer).

Puisque dans les cas les plus complexes (système de production, avionique, auto-mobile), l’information subit divers traitements avant qu’elle soit mise à la dispositiondes consommateurs, il semble logique que ces traitements soient réalisés au plus prèsdu producteur. Cette distribution de l’intelligence a donné naissance à la nouvelle gé-nération des capteurs. Ces capteurs, nommés capteurs intelligents, ont été introduitspar Ko et Fung en 1982 [KF82].

1.2.2 Capteurs intelligents

Pour l’utilisateur, le capteur “ idéal ” est un capteur qui :• doit être capable de reconnaître et de signaler son état (correct ou incorrect) ;• est interopérable, c’est-à-dire que les informations transmises sont interprétablespar le destinataire sans obliger l’utilisateur à écrire des programmes de traductionparticuliers ;

• est interchangeable : c’est à dire qu’un capteur de marque X peut être remplacépar un capteur demarque Y in situ, tout en respectant le cahier des charges initial ;

• préserve une compatibilité ascendante : c’est à dire qu’on peut remplacer un cap-teur de génération n par un capteur de génération n+ 1, celui-ci sera capable defournir les mêmes services que le capteur n.

On attend ainsi d’un capteur intelligent qu’il assure des fonctionnalités plus com-plexes telles que :

• valider la mesure, c’est-à-dire attribuer un niveau de crédibilité et de confiance àl’information fournie ;

• fournir une mesure opérationnelle, c’est-à-dire fournir une grandeur significativepour le système ;

• fournir une mesure datée permettant le contrôle à partir d’informations issues deplusieurs capteurs intelligents.

Si on attend du capteur intelligent d’être plus qu’un outil de mesure, soit une entitéintelligente, c’est parce qu’avec la complexité des systèmes, la quantité d’informationsémises par les divers composants aux niveaux supérieurs devient très grande et qu’unegestion sûre et optimisée des communications d’informations est devenue une néces-sité.

1.2. Capteurs 13

FIG. 1.3 – Architecture générique de capteur intelligent

Une architecture générique d’un capteur intelligent est présentée dans [MMM93](figure 1.3). Cette architecture générique regroupe les composants de base qui per-mettent d’assurer les fonctionnalités attendues d’un capteur intelligent (mesure, va-lidation, configuration, communication) (figure 1.4).

Fonctionnalité MESURE Pour un capteur intelligent, la fonctionnalité MESURE in-tègre les aspects métrologiques et de traitement de signal dans le but d’avoir unemesure opérationnelle qui est une mesure validée directement utilisable pas lesdifférents composants du système.

Fonctionnalité VALIDATION La fonction VALIDATION est la fonction qui permet devalider la mesure fonctionnelle en fonction desmesures technologiques qui carac-térisent le bon fonctionnement du capteur intelligent et ceci en terme de techno-logie (tension d’alimentation, température de l’électronique, intégrité de la chaîned’acquisition), mais aussi en terme de métrologie (la cohérence de la mesure parrapport à des modèles).

Fonctionnalité CONFIGURATION La fonctionnalité CONFIGURATION d’un cap-teur intelligent (peut être réalisée par le constructeur, l’installateur et/ou l’utili-sateur) consiste en une configuration technologique (intégrer le capteur dans sonenvironnement physique), une configuration fonctionnelle (rendre le capteur me-surant et communiquant) et une configuration opérationnelle (dédier le capteur


FIG. 1.4 – Fonctionnalités internes d’un capteur intelligent

a l’application). Les configurations fonctionnelles et opérationnelles peuvent êtremodifiées en cours de fonctionnement (dégradation, amélioration).

Fonctionnalité COMMUNICATION La fonctionnalité COMMUNICATION assurel’échange d’informations datées ou non entre le capteur intelligent et son environ-nement. Elle doit décoder et interpréter les ordres et messages qui parviennent aucapteur intelligent. Elle doit également mettre en forme (datation) et transmettreles informations du capteur intelligent vers l’environnement.

En conclusion, pour être utilisé de manière fiable, un capteur basique ou intelligent,doit être associé à un composant en charge des activités de mesure, configuration, vali-dation, communication. Ce composant s’appuie sur une partie matérielle en charge descomposants de type transduction et acquisition et sur une partie logicielle en charge destraitements et des communications avec l’application de contrôle. Cette partie logicielleest appelée pilote d’équipement.

1.3 Les pilotes d’équipement

Le pilote d’équipement est la partie logicielle qui fournit une interface entre l’ap-plication et l’équipement (ici le ou les capteurs). Ce logiciel est programmé au niveausystème et est souvent intégré dans les services du Système d’Exploitation (SE). Le pi-lote d’équipement est alors un composant critique du système, il est à l’origine de plu-sieurs bugs et crashs des SE. C’est aussi un composant logiciel qui affecte d’unemanièreimportante la qualité de conception des systèmes.

1.3. Les pilotes d’équipement 15

FIG. 1.5 – Le pilote d’équipement dans un système


La conception et la vérification d’un pilote d’équipement est très complexe, en rai-son de ses interactions et de l’influence de plusieurs éléments du système. Dans le cadredes systèmes embarqués et/ou temps réel, la conception et la vérification du piloteest encore plus critique et plus complexe du fait de la particularité de ces systèmes(contraintes de ressources, contraintes temporelles...).

Le développement des pilotes d’équipement présente une autre difficulté qui est laportabilité. Un pilote d’équipement dépend de plusieurs composants (les composantsmateriels tels que le processeur, le SE et les autres équipement). Ceci est un problèmemajeur du développement pour intégrer des capteurs dans diverses plateformes. Unesolution est alors d’intégrer le pilote dans le capteur, soit à developper des capteursintelligents (section 1.2.2). Les fonctionnalités attendues d’un capteur intelligent sontainsi les fonctionnalités attendues de son pilote. Ainsi le passage au capteur d’une nou-velle génération ne pose pas de problèmes de compatibilité avec le pilote existant oumême l’installation d’un nouveau pilote ne crée pas des risques ou d’incompatibilitéavec l’application existante.

Une autre stratégie est d’utiliser ou de proposer des standard dans la définitionsdes sources fournies par un pilote d’équipement. Ainsi une application est indépen-dante du pilote utilisé. Dans ce cadre, ces dernières années une attention particulière aété donnée à la spécification standardisée des pilotes d’équipement et ceci autant dansl’industrie que dans la recherche.

Devil [MRC+00] propose un langage de définition d’interface (IDL), ce langage per-met une abstraction des accès aux registres de l’équipement. À partir d’une spécifica-tion IDL, il génère une librairie des fonctions d’accès aux registres et permet une analysepartielle de ces fonctions. L’approche permet l’abstraction des détails de bas niveau, liésaux spécificités des architectures matérielles. Cette approche se limite à l’accès aux re-gistres et ne s’adresse pas aux autres composants logiciels des pilotes d’équipement.

Dans le contexte de codesign, O’Nils et Jantsch [A.01] proposent un langage appeléProGram pour la spécification des protocoles de communication matériel/logiciel. Lalimite de cette approche est qu’elle ne permet pas l’intégration de SE. D’autres ap-proches de codesign proposent de lier la communication matériel/logiciel à des rou-tines d’interruption, qui ne représentent seulement qu’une partie des fonctionnalitésdu pilote d’équipement.

D’autres approches, telle que I2O [SIG02] définissent une architecture standard desentrées/sorties intelligentes qui est indépendante de l’équipement, mais aussi du SE.Le problème de portabilité du pilote d’équipement est résolue par la spécification deprotocole de communication entre l’équipement et l’application. Cette approche est li-mitée aux systèmes à haute performance. Uniform Driven Interface (UDI) [UDI02] pro-pose un ensemble d’APIs (Application Programming Interfaces) entre le pilote d’équi-pement et la plateforme. Le pilote et la plateforme sont alors développés indépendam-ment.

1.4. Chaîne d’acquisition des données des systèmes de contrôle de processusmodèles et caractéristiques 17

D’autres travaux ont proposé de trouver une solution aux problèmes de spécifica-tion de pilotes d’équipement dans les cas des systèmes embarqués et/ou temps réel.[WMB03] se base sur les travaux de [UDI02], en proposant un “ framework ” basé surla modélisation formelle qui permet la vérification du pilote d’équipement.

[ML06] propose un approche de test pour les pilotes d’équipement pour systèmesembarqués. L’approche se base sur une génération de cas de test en se basant sur descas de test génériques des pilotes d’équipement tout en ajoutant des cas de test par-ticuliers liés au pilote d’équipement développé (contraintes de temps, caractéristiquesparticulières des routines d’interruption utilisées,...) et au système embarqué développé(contraintes de ressources, valeurs des arguments des fonctions appelés par le systèmepour communiquer avec le pilote d’équipement open(), ioctl()).

[MS00] propose un modèle de taches d’E/S qui permet une spécification des pilotesd’équipement dans le cas d’un système temps réel. À partir de ce modèle de tâches, uneanalyse d’ordonnancement des tâches du système et les tâches du pilote permettent lavérification (la garantie) de plusieurs propriétés temps réel. L’approche se base sur lesétapes suivantes :

• Évaluation des caractéristiques du capteur de l’application.• Identification des contraintes des ports d’entrée/sortie.• Calcul des bornes minimales et maximales de l’échantillonnage.• Trouver un compromis entres les bornes minimales et maximales.• Développer l’algorithme de lecture du capteur.• Analyser la performance du code du pilote.• Calcul du temps d’exécution du pilote afin de valider l’analyse expérimentale-ment.

• Sélectionner la période d’échantillonnage qui donne le meilleur compromis entreles bornes et son ordonnancement.

1.4 Chaîne d’acquisition des données des systèmes de contrôle deprocessus modèles et caractéristiques

On s’intéresse dans ce travail à l’étude des chaînes d’acquisition de données pourun système de contrôle de processus. Les chaînes d’acquisition de données ont pourobjectif l’acheminement d’informations (nous parlerons des données) entre différentséléments du système. La communication qui nous intéresse est de nature monodirec-tionnelle et se fait d’un ensemble de producteurs de données (les capteurs) vers unensemble de consommateurs (les applications de contrôle). Ainsi, même s’il peut exis-ter une communication bidirectionnelle au niveau du contrôle (en particulier pour laconfiguration ou pour initier des demandes de communication), la communication desdonnées suit un flux monodirectionnel des producteurs vers les consommateurs.


FIG. 1.6 – Chaîne d’acquisition des données

1.4.1 Modèle d’une chaîne d’acquisition des données

Au vue de l’état de l’art, une chaîne d’acquisition de données est composée dequatre éléments figure 1.6 :

Capteur : Il permet de convertir une information (température, vitesse) caractérisantl’environnement physique en une donnée numérique.

Interface de communication : Il assure l’interface entre un capteur et la partie logi-cielle du système. Il récupère les données produites par le capteur physique etles sauvegarde dans des registres accessibles par le pilote d’équipement.

Pilote d’équipement : C’est un logiciel dédié intégré au système d’exploitation et in-dépendant de l’application de contrôle. Il permet l’abstraction de la couche ma-térielle en offrant à l’application de contrôle l’accès aux données caractérisantl’équipement. Une fois configuré, ce composant logiciel est généralement acces-sible via des services standardisés (open, read, ioctl, close...).

L’application de contrôle (temps réel) : une application de contrôle utilise les donnéesdes pilotes d’équipement afin de produire des commandes dans un temps borné.

Dans notre approche, on distingue le pilote matériel (appelé ici interface de com-munication) et le pilote logiciel (appelé ici pilote d’équipement).

Dans une première modélisation pour la vérification des système de contrôle deprocessus on peut supposer que :

• les retards sont négligeables ou constants ;• les gigues sont négligeables ;• il n’y a pas d’erreur d’acheminement dans la chaîne d’acquisition de données.Mais les travaux [WT95, MMJ05, JUM03, Mar00, Lia01] font le constat que si les

caractéristiques temporelles des flots d’informations en provenance des capteurs ou àdestination des actionneurs ne sont pas prises en compte lors du développement, lavalidation des systèmes est incorrecte vis à vis des propriétés temporelles qu’il doivent


satisfaire. Ceci est dû au fait que l’application de contrôle est sensible aux caractéris-tiques et aux variations temporelles de la chaîne d’acquisition. [HC06] montre que lecontrôle dans les systèmes de contrôle de processus basé sur les évènements est trèssensible aux retards et aux gigues.

[MMJ05] donne les effets des variations temporelles aléatoires des périodes oudes délais d’acheminement d’information dans un système de contrôle. Ces effets im-pactent la performance, la robustesse et la stabilité des systèmes de contrôle de proces-sus.

1.4.2 Caractéristiques d’une chaîne d’acquisition

Les caractéristiques temporelles à considérer sont variées et diffèrent d’un systèmeà un autre, selon les besoins. Un problème majeur est alors d’identifier les caractéris-tiques qui affectent le système ou qui peuvent influencer le résultat de la vérificationde propriétés que le système de contrôle de processus doit satisfaire. Néanmoins, ontrouve dans la littérature [WT95] [BNC03] [Mar00] des caractéristiques communes. Cesdernières peuvent être classifiées dans l’une des catégories suivantes :

Les retards il y a essentiellement trois types de retard [WT95] : les retards de communi-cation ou d’acheminement entre le capteur et l’application de contrôle, les retardsde calcul ou de traitement dans l’application de contrôle ou le pilote d’équipe-ment et les retards de communication ou d’acheminement entre l’application decontrôle et les actionneurs. Ainsi, la définition la plus simple et la plus génériquedu retard est :

Définition 1.4.1. La différence entre deux dates concernant la même occurence dans unflot de données.

Selon les dates considérées, la définition de retard n’est donc pas toujours lamême. Par exemple, les temps de réponse ou les temps d’exécution des tâchespeuvent être considérés comme des retards.[Bat98, Red02]. De même, si le cap-teur et l’application communiquent via un réseau, [Ray89] considère les délaisd’acheminement de bout en bout comme étant les délais de communication entrele capteur et l’application. Il définit les retards ou délais comme étant :

Définition 1.4.2. Les délais d’acheminement des informations de bout en bout sont lesdélais entre la date à laquelle une information est présentée (sous une forme à définir,

physique ou numérique) dans l’environnement et la date à laquelle l’occurrence corres-

pondante est considérée par l’application de contrôle.

Classiquement dans les applications de contrôle commande, ce délai est vucomme un retard. Ainsi [JUM03, MMJ05] associent à cette caractéristique tempo-relle le nom de “ loi de retard ”.


Définition 1.4.3. La loi de retard exprime la loi sur les temps écoulés entre la date àlaquelle une information produite par les capteurs et la date à laquelle l’occurrence corres-

pondante est considérée par le système de contrôle.

Les périodes Les périodes sont des paramètres temporels caractérisant une fréquence.La période peut être sous la forme d’une période de contrôle. C’est la période a la-quelle les actions de contrôle sont exécutées. De même que le retard, la définitionde la période diffère suivant le contexte, les systèmes de contrôle et les besoins enterme de validation des propriétés.[CA07] définit une période de répétition des occurrences d’un évènement dans lecadre de MARTE [TETG07, OMG05a, OMG05b], comme étant

Définition 1.4.4. “ repetition period : duration between two successive occurrences ofthe event ”

“ période de répétition : c’est la durée entre deux occurrences successives d’un même

événement ”

[BNC03] définit la période d’une tâche comme étant :

Définition 1.4.5. “ the period of a task is the time between two consecutive earlist releases”

“ la période d’une tâche est le temps écoulé entre deux activations consécutives ”

Dans le contexte du contrôle de processus, [JUM03, MMJ05] mettent l’accent surla periodicité des mesures ou “ la loi d’arrivée ”, soit :

Définition 1.4.6. “ La loi d’arrivée est la loi exprimant le temps écoulé entre deux occur-rences successives d’une mesure ”

Les gigues La gigue reflète une variation incontrolée d’une grandeur temporelle et estdéfinit dans [Rad97] comme :

Définition 1.4.7. “ time-related, abrupt, spurious variations in the duration of any spe-cified related interval ”

“ une variation temporelle imprévue, brusque sur la durée d’un intervalle temporel ”

Il y a évidement plusieurs type de gigue [BNC03] selon l’information temporelleconsidérée. Par la suite, on s’intéresse aux gigues sur les retards et aux gigues surles périodes.

Les erreurs de transmission ou d’acheminement Les erreurs de transmission oud’acheminement ont comme effet la perte d’information, l’augmentation desretards, ou des erreurs sur le contrôle [WT95].

Ces caractéristiques sont liées et influent sur tous les éléments de la chaîne d’acqui-sition. Considérer ces caractéristiques lors de la validation du système de contrôle deprocessus nécessite de les considérer pour tous les éléments de la chaîne d’acquisition.


La défaillance d’un capteur classique en terme de précision, de sensibilité ou depanne totale peut engendrer la perte ou la défaillance des systèmes de contrôle de pro-cessus, ce qui peut avoir une conséquence catastrophique dans le cas des systèmes decontrôle de processus critiques. Du point de vue temporel un capteur est caractérisé parsa loi d’arrivée (appelée par la suite loi de production du capteur) et sa loi retard. Lerespect des paramètres temporels est alors un aspect important pour l’intégration sûred’un capteur dans un système automatisé de contrôle.

Dans le but d’avoir une vue plus précise du capteur et de détecter/traiter les dé-faillances (sur la mesure ou la communication) avant qu’elle n’influe sur le système decontrôle du processus, le capteur intelligent intègre une fonctionalité VALIDATION.

La fonctionalité VALIDATION est réalisée à travers plusieurs algorithmes de di-verses natures. Ils permettent généralement de :

• Traiter les données en enrichissant le niveau sémantique. Ceci peut être fait endégageant à partir des mesures l’information utile au système de contrôle de pro-cessus ou corriger les défauts d’acquisition.

• Prédire une donnée malgré l’absence de mesures réelles.• Contrôler le comportement et le fonctionnement interne du capteur afin d’évi-ter la propagation de défaillance au systèmes de contrôle de processus. Ainsi ilspeuvent par exemple agir sur le configuration de capteur afin de corriger les er-reurs ou la communication.

Si les erreurs ou l’absence de mesures sont traitées par l’architecture (redondance,prédiction, correction...), les aspect temporels requièrent la mise en place de techniquesspécifiques.

1.4.3 Évaluation des caractéristiques d’une chaîne d’acquisition

Des travaux intègrent, dans le modèle des systèmes de contrôle de processus, les ca-ractéristiques temporelles de la chaîne d’acquisition de données, sous la forme d’équa-tions [WT95], de constantes traduisant des pires cas [AW90] ou de modèles formels deces caractéristiques temporelles [DeA07]. Pour construire ces vues, plusieurs travauxs’intéressent à l’évaluation des caractéristiques temporelles de chaîne d’acquisition.

[ESF06] présente une méthode d’analyse de pire temps d’acheminement (pire re-tard) des réseaux a base d’architecture CAN/Ethernet multiplexé.

Le projet ADCN+ [BBDP07] prend en compte un réseau avionique global obtenupar interconnexion de différents sous réseaux hétérogènes (réseau AFDX, bus de ter-rain, bus avioniques classiques, réseaux de capteurs, bus de terrains, réseau monde ou-vert,...). Les exigences de certification d’applications embarquées temps réel critiques,impliquent toujours de pouvoir maîtriser les délais de transmission, en pires cas, surle réseau avionique global. Le rapport [BBE+07] présente succinctement plusieurs dé-


marches [CSF06] [CSEF06] qui ont déjà été menées dans le cadre du réseau AFDX ho-mogène, pour permettre une analyse des latences de communication.

L’évaluation de retards de bout en bout fait l’objet d’approfondissement et de gé-néralisation dans le cadre d’un réseau global obtenu par interconnexion de réseauxhétérogènes. Les approches utilisées dans le cadre du projet ACDN+ sont le calcul ré-seau probabiliste [RSF07b] [RSF07a], la simulation [SF07b] [SF07a] et le model-checkingà travers l’analyse temporelle des réseaux embarqués à l’aide des automates temporisés[ESF07].

Une étude approfondie des gigues dans les systèmes de contrôle de processus,[LCCB+06] donne une évaluation des gigues à travers des équations qu’il intègre dansses modèles de système de contrôle de processus.

1.4.3.1 Conclusion

L’étude des capteurs intelligents nous a permis de mieux comprendre les différentsaspects liés à une chaîne d’acquisition de données. Le pilote d’équipement (partie logi-cielle de cette chaîne) est un élément potentiellement complexe qui assure des fonctionsélémentaires de communication mais qui peut aussi gérer la configuration et la valida-tion en ligne de la chaîne. Valider le bon fonctionnement d’une chaîne d’acquisitionnécessite l’évaluation des caractéristiques du pilote à la fois sur des aspects fonction-nels ainsi que / et sur les aspects temporels.

Des approches basées sur l’analyse formelle permettent alors des estimations aupire cas des retards.

1.5 Synthèse

Une application de contrôle est sensible aux variations temporelles de la chaîned’acquisition. La connaissance quantitative des caractéristiques temporelles des élé-ments de la chaîne d’acquisition fournit des modèles, des équations, ou de pires caspermet une correction et une validation plus fine du système de contrôle.

Deux difficultés doivent être levées :• Identifier les caractéristiques qui influent sur les propriétés étudiées du systèmede contrôle.

• Identifier les modèles mathématiques des caractéristiques permettant de validerle système de contrôle tout en restant exploitable.

La majeure partie des travaux d’évaluation des caractéristiques des systèmes d’ac-quisition présentés précédemment fournit un résultat sous la forme d’une équation, demodèle de pire cas, d’un modèle sur la base d’une analyse stochastique ou par simu-lation. Deux approches seulement se basent sur les automates temporisés et le model-

1.5. Synthèse 23

checking [ESF07] [God04] pour donner une évaluation quantitative fine de ces carac-téristiques. L’approche de [God04] se base sur le model-checking et une approche pardichotomie pour l’évaluation de caractéristiques temporelles des réseaux embarquéscritiques et fiables pour l’automobile, ce qui donne des bornes approximatives maisplus précises qu’une analyse de pires cas [JUM03, MMJ05]. Notre approche consiste àévaluer les caractéristiques temporelles et particulièrement les délais d’acheminementde bout en bout à l’aide des méthodes formelles, donc d’une manière exhaustive etdonner une représentation quantitative exacte des ces caractéristiques.

Dans tous ces cas, une évaluation des caractéristiques des chaînes d’acquisition desdonnées est nécessaire. Cette évaluation doit permettre, dans la suite de processus dedéveloppement des systèmes de contrôle de processus, une représentation plus réalistede ces caractéristiques.

La science de la réalité ne se contente plus du comment phénoménologique ;elle cherche le pourquoi mathématique

Gaston Bachelard

2Système temporisé communicant etméthodes classiques de vérification

CE chapitre définit l’ensemble des bases théoriques requises pour la suite de ce travail. Dans ce chapitreon présente les automates temporisés communicants, les systèmes de transitions étiquetées et la

vérification formelle de propriétés sur ces automates.

Plan du chapitre

2.1 Contexte de l’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.1 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2 Définition d’automates temporisés communicants . . . . . . . . . . . . 282.2.1 Préliminaires : horloges et gardes temporelles . . . . . . . . . 282.2.2 Définition des automates temporisés . . . . . . . . . . . . . . . 292.2.3 Extension communicante des automates temporisés . . . . . . 302.2.4 Sémantique des automates temporisés communicants . . . . . 312.2.5 Composition des automates temporisés . . . . . . . . . . . . . 332.2.6 Conclusion et discussions . . . . . . . . . . . . . . . . . . . . . 33

2.3 Propriétés : classification et techniques de vérification . . . . . . . . . 352.3.1 Classification de propriétés . . . . . . . . . . . . . . . . . . . . 352.3.2 Logiques de spécification des propriétés . . . . . . . . . . . . . 362.3.3 Observateurs de propriétés . . . . . . . . . . . . . . . . . . . . 372.3.4 Propriétés : techniques de vérification . . . . . . . . . . . . . . 41

2.4 Conclusion et discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 43

26 2. Système temporisé communicant et méthodes classiques de vérification

2.1 Contexte de l’étude

2.1.1 Notations

Par la suite, on utilise les notations suivantes :• N est l’ensemble des entiers naturels.• Z est l’ensemble des entiers.• R est l’ensemble des réels, et R+ est l’ensemble des réels positifs ou nuls.• ∅ est l’ensemble vide.• Pour les ensembles : l’union est notée A ∪ B, l’intersection A ∩ B, la différenceensembliste A \ B, le produit cartésien A× B. L’inclusion des ensembles est notéeA ⊆ B et l’appartenance à un ensemble A pour un élément : x ∈ A.

• On note par 2A l’ensemble des parties de A et |A| le cardinal de l’ensemble A.• On appelle alphabet tout ensemble fini, les éléments d’un alphabet sont tradition-nellement appelés symboles, lettres ou encore caractères ou aussi étiquettes.

• Considérons maintenant un alphabet A. On appellemot sur A tout de suite d’élé-ments de A.

• Soit A un alphabet (ensemble fini), alors ǫ (ǫ /∈ A) est le mot de longueur 0(appelé aussi mot vide) , An est l’ensemble de mots sur A de longueur n, A∗ estl’ensemble de mots finis sur A et Aω est l’ensemble des mots infinis sur A.

• Soit A un alphabet (ensemble fini). On appelle langage formel sur A, ou plus sim-plement langage sur A, toute sous partie de l’ensemble A∗.

• La concaténation de deux langages L1 et L2 est l’ensemble des produits d’un motde L1 et d’un mot de L2, c’est-à-direL1L2 = uv |u ∈ L1, v ∈ L2

2.1.2 Motivation

La vérification de propriétés temporelles sur les systèmes peut se faire de plusieursmanières :

L’analyse d’ordonnancement : La validation des systèmes temps réel impose de vé-rifier si les tâches respectent les contraintes temps réel. Les techniques les plusconnues consistent en un calcul du pire temps de réponse basé sur une analysed’ordonancabilité [KRP+93]. Dans ce domaine, la technique la plus connue RMA(Rate Monotonic Analysis) est un ensemble d’outils mathématiques permettant auxdéveloppeurs de calculer une borne du pire temps de réponse.

Model-checking : Le Model-Checking litéralement “ vérification basée modèle ”[ACD90] [CGP00] désigne une famille de techniques formelles de vérificationautomatique des systèmes. Il s’agit de vérifier algorithmiquement si un modèledonné, le système lui-même ou une abstraction du système, satisfait une spécifi-cation, souvent formulée en termes de logique temporelle [EH82, Eme90] tel que

2.1. Contexte de l’étude 27

la logique linéaire “ Linear Temporal Logic (LTL) ” [Muk97] ou la logique arbores-sente “ Computational Tree Logic ” (CTL) [CES86], soit sous la forme d’un automateobservateur.

L’analyse RMA, comme les techniques d’analyse d’un pire temps de réponse, four-nissent souvent des bornes non réalistes des pires temps de réponse et ne considèrentque des architectures statiques. Pour répondre à ces problèmes, il a été proposé plus ré-cemment des approches basées sur la modélisation exhaustive de l’ensemble des com-portements temporels du système et la vérification des propriétés temporelles basée surle Model-checking.

Parmi les différentes techniques de vérification existantes, les méthodes formellesont pour objectif de fournir au concepteur un cadre afin de modéliser le système etensuite de démontrer qu’il est correct. L’idée est de faire une comparaison entre la des-cription du système, exprimée dans un formalisme approprié, avec une description deses spécifications, c’est-à-dire de l’ensemble de propriétés qu’il doit satisfaire.

La vérification formelle nécessite donc la réunion de quatre éléments [God91] :• Une description de systèmeM à vérifier.• Une description de l’ensemble des propriétés P .• Une relation de satisfaction noté |=, qui définit formellement la comparaison deMet P .M satisfait P est notéM |= P .

• Un algorithme, ou une méthodologie de décision, pour mettre en œuvre cettecomparaison.

Pour les systèmes concurrents, visés dans cette thèse, la description du système peutêtre représentée par un ensemble d’états représentant son comportement. Comparer lemodèleM et la spécification P passe alors par une énumération exhaustive de l’ensembledes états deM.

Cette idée est à l’origine des méthodes de vérification automatique, appelée mé-thode de vérification basée sur les modèles (ou model-based method). La vérification for-melle se base sur une description deM dans un formalisme possédant une sémantiqueopérationnelle formelle. Ainsi, l’interprétation (non ambiguë) du modèle permet deproduire un Système de Transitions Étiquetées (STE). Le STE modélise l’ensemble descomportements du système, soit l’ensemble de toutes ses exécutions possibles.

Selon le formalisme utilisé pour décrire les spécifications P , on distingue plusieursméthodes de vérification pour les spécifications logiques ou pour les spécifications compor-tementales :

Spécifications logiques : informellement, elles correspondent à l’expression d’un cer-tain nombre de propriétés à satisfaire par le système. Afin de décrire les proprié-tés, on s’appuie sur des formalismes mathématiques appelés logiques. Une spé-cification logique est un ensemble de formules d’une logique temporelle [Eme90,EH82, CES86] : linéaire LTL [Muk97], arborescente CTL [CES86] ou le µ-calul ar-


borescent [Koz83]. La vérification logique s’applique plus aux propriétés globalesdu systèmeM telles que l’absence de blocage ou l’exclusion mutuelle.

Spécifications comportementales : informellement, elles correspondent à la comparai-son du système et des spécifications exprimées via P . Formellement, c’est l’actede comparaison entre deux STEs correspondants àM et P au moyen d’une rela-tion d’équivalence R. cette relation d’équivalence dépend du type de propriété àvérifier. Parmi les relations d’équivalence les plus connue on peut citer la bissimu-lation forte [Mil80].

Il faut remarquer qu’en pratique,M et P sont décrits dans des formalismes de plushaut niveau et plus expressifs que les STEs. C’est leur sémantique opérationnelle quipermet d’obtenir des STEs équivalents. Parmi ces formalismes (langages), on trouve deslangages dits industriels tels que des techniques de description formelle (FDT) commeESTELLE [RJL85], LOTOS [DOTY95] ou SDL [IT00] et des langages dits académiques,basés sur l’algèbre des processus tel que CCS [Mil80], CSP [Hoa78] ou encore ceux baséssur les automates temporisés comme IF [Boz99] ou UPPAAL [BLL+95, DBLY03].

2.2 Définition d’automates temporisés communicants

Les méthodes de vérifications formelles nécessitent une spécification formelle dusystème M. Cette spécification est basée sur un langage formel dont la sémantiqueopérationelle est formellement définie, c’est-à-dire sans ambiguïté. La sémantique uti-lisée pour la vérification formelle est celle des systèmes de transitions étiquetées. Pourles systèmes visés par la thèse, les langages sont basés sur des formalismes tels que lesautomates à états finis [ACD90] et ses extensions temporisées [AD94] et communicants,le réseau de petri [Pet78] et leurs extensions [Pet80] ou l’algèbre de processus [Mil80].

Dans la suite du document, on s’intéresse aux langages à base d’automates tempo-risés communicants.

2.2.1 Préliminaires : horloges et gardes temporelles

En premier lieu, nous introduisons la notion d’horloge et de garde temporelle. Leshorloges sont utilisées pour limiter le comportement de systèmes, en introduisant descontraintes sur les intervalles temporels associés aux actions. Les contraintes s’appuientsur une initialisation ou une remise a zéro des horloges.

Définition 2.2.1. Une horloge est une variable à valeurs dans l’ensemble des réels positifs ounul,R+. Soit un ensemble fini d’horloges X . Alors, une valuation ν : X −→ R+ est un n-uplet

de réels, et pour toute horloge x ∈ X , ν(x) = v ∈ R+, dénote la valeur de l’horloge x dans ν.

2.2. Définition d’automates temporisés communicants 29

Pour la suite on considère que l’écoulement du temps se fait avec la même vitessepour toutes les horloges. Pour une valuation ν de l’horloge x à l’instant t0 et une duréetemporelle t ∈ R+ sans remise à zéro de l’horloge x entre t0 et (t0 + t), on note par(ν + t) la valuation ν′, soit à l’instant (t0+ t), ν′(x) = ν(x) + t pour toute horloge x ∈ X .x est une fonction affine du temps x = t+ k.

Nous introduisant maintenant la notion de garde sur les horloges :

Définition 2.2.2. une garde de X est une combinaison booléenne des contraintes de la formex ∽ c ou x ∈ X , c est une constante entière (c ∈ N), et ∽∈ <,6, les symboles < et 6

représente la relation d’ordre usuelle sur les réels. Soit Γ(X ) l’ensemble des gardes surX . Alors,on peut dire qu’une garde est l’union des conjonctions des contraintes de la forme a ≺ x, x ≺ bou ≺∈ <,6, a et b ∈ N.

On définit une remise à zéro ou Reset sur un ensemble d’horloges l’opération sui-vante : soit une valuation ν et Ω ⊆ X l’ensemble des horloges a remettre à zéro, alorsν[Ω := 0] dénote la nouvelle valuation après la remise à zéro définie comme suit :

(ν[Ω := 0])(x)de f=

0, si x ∈ Ω

ν(x), sinon(2.1)

Dans la suite on note ν[x := 0] par ν[x := 0].

2.2.2 Définition des automates temporisés

Les automates temporisés sont une extension des automates à états finis, proposéspar [ACD90] [AD94] pour permettre d’intégrer le temps dans les automates. Un auto-mate temporisé est un automate décrivant le comportement du système et un ensemblefini d’horloges permettant d’exprimer des contraintes temporelles sous forme de gardes.

Définition 2.2.3. Un automate temporisé est un n-uplet A = (L,X ,Σ, δ) où :• L est un ensemble fini de localités (ie. localité appelée aussi nœu d de contrôle), l0 ∈ Lreprésente par définition la localité initiale.

• X est un ensemble fini d’horloges.• Σ est un ensemble d’étiquettes.

• δ ⊆ L× Σ ×L× Γ(X )× 2X est un ensemble de transitions.

Une transition (l, d, l′,γd,Ωd) représente une action du système, étiquetée d. La tran-sition est exécutée seulement si les valeurs des horloges satisfont la contrainte tempo-relle γd. Les transitions exécutables sont exécutées séquentiellement et les horloges deΩd sont remises à zéro.


Plusieurs outils implémentent les automates temporisés. Ils permettent la descrip-tion d’un système à l’aide d’un formalisme de haut nivau : les réseaux d’automatesétendus (communicants, temporisés). Ces outils possèdent chacun leurs spécifités tem-porelles (temps discret ou temps dense), une sémantique de communication inter-automates (synchrone, asynchrone), la manière dont sont exécutées les transitions(par exemple, basée sur la notion d’urgence). Parmi ces outils, on peut citer UPPAAL[LPY97], Kronos [DOTY95], LUSTRE [CPHP87] ou IF [Boz99, BGM02]. Dans la suite onconsidère l’implémentation de [Boz99], et donc l’outil IF [BGM02].

2.2.3 Extension communicante des automates temporisés

Nous considérons les travaux de [Boz99], qui présente une extension pour la com-munication des automates temporisés. La communication inter-automates est asyn-chrone et se fait au travers de signaux gérés à l’aide de files d’attente (boîte aux lettresde type FIFO). Un signal de communication s, entre deux automates est représenté pardeux actions : !s pour l’action de l’écriture (l’envoi) du signal dans la file d’attente dureceveur et ?s pour la lecture (la réception) du signal à partir de la file d’attente dereceveur. La boîte au lettre est unique par receveur.

La sémantique opérationelle est exprimée vis-à-vis des automates temporisés. Àchaque automate temporisé communicant, on associe un automate temporisé simpledont les localités (les états de contrôle) sont des couples (localité respective de l’automatetemporisé simple, contexte sur les files d’attente). Les transitions sont dérivées des transi-tions de l’automate temporisé simple.

Dans le respect du principe de FIFO (premier arrivée, premier sortie), une transitionde communication asynchrone (action de lecture du signal de la file d’attente ?s) estexécutable si le signal existe exactement en tête de file. Si c’est ne pas le cas la transitionn’est pas franchissable.

Le modèle des automates temporisés communicant implémentés par [Boz99] dansle langage IF introduit deux concepts sur les transitions pour :

1. La notion d’urgence (figure : 2.1 ) est modélisée d’une manière explicite à l’aided’échéances associées aux transitions. Une transition peut être :• soit urgente (eager) : la transition est franchie dès que la garde est satisfaite ;• retardable (delayable) : la transition peut être franchie dès que la garde est satis-faite et est obligatoirement tirée avant que la garde ne soit plus satisfaite ;

• paresseuse (lazy) : la transition peut être franchie à partir de l’instant ou la gardeest satisfaite, mais elle ne peux plus être franchie une fois que la garde n’est plussatisfaite.

Par défaut, une transition est urgente. Ce modèle d’automates temporisés, appeléavec échéances, est défini dans [Bor98, BST98].


FIG. 2.1 – Sémantique de l’urgence

2. Enfin, la notion de priorités sur les transitions, qui est facultative, permet de don-ner une priorité à une transition sur une autre, dans le cas où les deux sont fran-chissables au même instant.

2.2.4 Sémantique des automates temporisés communicants

Nous donnons maintenant la sémantique opérationnelle des automates temporiséscommunicants. On considère un automate temporisé A = (L,X ,Σ, δ). Un état de Aconsiste en une localité et une valuation donnée à ses horloges avec des valeurs réelles,c’est-à-dire un état est un couple (l, ν) avec l ∈ L et ν ∈ [X −→ R+]. Soit SA l’ensembledes états deM, un état (l, ν) est appelé état entier si ν ∈ [X −→ N].

Nous associons à un automate temporisé communicant A un graphe d’état. Pourcela, on définit deux relations de transitions −→ et ⊲ entre les états de A. La transition−→ correspond à une transition due à la progression du temps dans une localité, et ⊲correspond à un déplacement entre deux localités utilisant une transition de δ.

Maintenant, soit une valuation ν et une garde g ∈ Γ(X ), on note par ν ⊢ g le fait quel’évaluation de g sous la valuation ν est vraie.

Finalement, on définit deux familles de relation entre états, t−→ et ⊲d avec t ∈ R+ etd ∈ δ. Pour tout t ∈ R+ et pour tout d ∈ δ, ces relations sont définies comme les pluspetites relations incluses dans SA × SA telles que :

• (l, ν)t−→ (l, [ν + t])


• Si une transition (l1, d, l2,γd,Ωd) et ν ⊢ γd Alors (l1, ν)⊲d (l2, ν[x := 0]x∈Ωd).

On définit une transition générale −→=⋃

t>0t−→ comme étant l’union des tran-

sitions temporelles et une transition générale ⊲ =⋃

d∈δ⊲d comme étant l’union destransitions non-temporelles. La relation →=−→ ∪⊲ reprèsente l’ensemble des transi-tions. Alors, le système de transition étiqueté d’états associés avec A est (SA, →).

Un automate temporisé est une représentation implicite d’un système de transitionétiqueté (STE).

Définition 2.2.4. La sémantique opérationnelle d’un automate temporisé communicant A =(L,X ,Σ, δ), est un système de transition étiqueté (SA, →), avec :

• SA est l’ensemble d’états, et s0 = (l0, ν0) l’état initial.• → représente l’ensemble des relations de transitions.

On définit maintenant la notion de séquence d’exécution d’un automate temporiséA.Une séquence d’exécution est définie comme étant une séquence finie de configurations.

Une configuration est un couple (s, τ) où s est un état de SA et τ ∈ R+ est la va-leur de temps. Intuitivement, une séquence d’exécution est un chemin fini dans le STEd’une exécution deA avec une horloge d’observation qui calcule le temps global écoulédepuis le début de l’exécution.

Formellement, nous étendons les relations de transition t−→ et ⊲d des états au confi-

gurations. On note ses extensions par t et d respectivement. Soit deux configura-tions (s, τ) et (s′, τ′), ses relations sont définies par :

• (s, τ) t (s′, τ′) ssi s t−→ s′ et τ′ = τ + t• (s, τ) d (s′, τ′) ssi s⊲d s′ et τ′ = τ

On note par l’union des tous les t et des d.

Définition 2.2.5. Une séquence d’exécution de A démarrant d’un état s est une séquence finie(s0, τ0) (s1, τ1) · · · (sn, τn) telle que s0 = s et τ0 = 0.

On note par CS(A, s) l’ensemble des séquences d’exécution deA démarrant à partirde s.

Définition 2.2.6. On définit une trace comme une séquence (l0, τ0) (l1, τ1) · · · (ln, τn)où les τi sont des réels positifs telle que τ0 = 0 et pour tous i > 0, τi 6 τi+1.

Soit une séquence d’exécution de A, σ = (l0, ν0, τ0) (l1, ν1, τ1) · · · (ln, νn, τn).La trace correspondante à σ est la séquence ρσ = (l0, τ0) (l1, τ1) · · · (ln, τn)


2.2.5 Composition des automates temporisés

D’un côté, la décomposition en plusieurs entités est un atout pour la modélisationdes systèmes complexes. D’un autre côté, la composition des automates temporisésclassiques n’est pas intuitive puisqu’elle introduit facilement des blocages temporels.Les automates temporisés à échéances, utilisés dans cette thèse, évitent par constructionce type de problème et définissent ainsi un opérateur de composition sans contraintessupplémentaires [Bor98].

La composition parallèle utilisée par la suite permet de composer deux ou plusieursautomates temporisés en tenant compte des interactions entres les automates à traversles signaux qui permettent de donner une sémantique à leurs synchronisations tout enmaintenant l’évolution de chaque automate indépendamment des autres.

Définition 2.2.7. Soit A1 = (L1,X1,Σ1, δ1) et A2 = (L2,X2,Σ2, δ2) deux automatestemporisés tel que X1∩X2 = ∅. Leur composition parallèle A1|[Σ

′]|A2, avec le respect desétiquettes de synchronisation (les signaux), Σ′ ⊆ Σ1 ∪ Σ2, est un automate temporiséA = (L,X ,Σ, δ), avec :

• L = L1 ×L2• X = X1 ∪ X2• Σ = Σ1 ∪ Σ2

• ((l1, l2), d, (l′1, l′2),γ,Ω) ∈ δ si :

1. (l1, d, l′1,γ,Ω) ∈ δ1), d ∈ Σ \ Σ′, et l′2 = l2 (seulement A1 évolue)⊕

2. (l2, d, l′2,γ,Ω) ∈ δ2), d ∈ Σ \ Σ′, et l′1 = l1 (seulement A2 évolue)⊕

3. (li, d, l′ i,γi,Ωi) ∈ δi), d ∈ Σ′,γ = γ1 ∧ γ2, et Ω = Ω1 ∪ Ω2, pour i = 1, 2 (A1et A2 évolue d’une manière synchrone)

Voir exemple figure 2.2

2.2.6 Conclusion et discussions

Le modèle des automates temporisés communicants à échéances présenté précé-demment est un modèle particulier des automates temporisés classiques. Ce modèleest implémenté dans l’outil IF (Intermediate Format) [BGM02]. IF consiste en un lan-gage intermédiaire permettant de spécifier un système temporisé communicant sous laforme d’un réseau d’automates temporisés. Cependant les automates temporisés IF ontquelques particularités :

• La progression de temps ne peut être définie tant que le franchissement des tran-sitions non temporelles n’est pas complètement décidé.


0

1 2

A

3

4

B

03

14 2

A || B

: états initial

1<x<4 : garde temporelle sur l’horloge x

x :=o : remise a zéro de l’horloge x

a,b,c : actions

1 < x < 4b

ax := 0

x < 2c

ax := 0

x < 3

b

ay := 0

cy >= 3

1 < x < 4 and y < 3

b

a

x := 0y := 0

x < 2 and y <= 3

c

a

x := 0y := 0

FIG. 2.2 – Deux automates temporisés et leur composition parallèle

2.3. Propriétés : classification et techniques de vérification 35

• Les automates IF sont des automates asynchrones et les phènoménes de la syn-chronisation n’apparaissent qu’au moment de la composition parallèle à traversles signaux de communication inter automates.

La sémantique opérationnelle d’IF est complètement définie en terme de systèmesde transitions étiquetées. L’ensemble du comportement, décrit en IF, peut être traduitsous la forme d’un STE. Il est à noter que les techniques de la vérification formelle depropriétés s’appliquent au niveau des STEs.

La section suivante présente une classification des propriétés temporelles des sys-tèmes temporisés, ainsi que les techniques et les outils de vérification de ces propriétés.

2.3 Propriétés : classification et techniques de vérification

La vérification d’une propriété P sur un système est le fait de vérifier que la des-cription d’un modèle de ce système satisfait cette propriété. Le modèle est ici décrit àl’aide d’automates temporisés. Les propriétés temporelles visées peuvent être décritessoit à l’aide d’une logique, soit à l’aide d’observateurs.

2.3.1 Classification de propriétés

Soit un système (un modèle de système)M et une propriété P ,M |= P représentela relation de satisfaction de la propriété P par le systèmeM. La définition formellede cette relation de satisfaction dépend de type de la propriété P . En s’inspirant de laclassification de [Rog06], nous proposons la description des propriétés suivantes :

Propriétés d’atteignabilitée (Reachability) : indique qu’un état de système peut êtreatteint (quelque chose de bon est toujours possible).M |= P est vrai si il existeau moins un état de CS(M, s0) ou P est vrai.Exemple 2.3.1. La porte de l’avion peut se verrouiller

Propriétés de sûreté (Safety) : exprime que sous certaines conditions, un évènementne peut jamais se produire (quelque chose de mauvais n’arrive jamais).M |= Pest vrai si pour tout état de CS(M, s0), P est faux. On peut distinguer troisprincipales formes d’expression d’une propriété de sûreté : formules de non-accessibilité, formules sans référence au passé et formules avec référence au passé.Il faut noter que la négation d’une propriété d’atteignabilité est une propriété desûreté.Exemple 2.3.2. En vol, la porte de l’avion ne se déverrouille jamais.

Propriétés de vivacité (Liveness) [AS85] : exprime que sous certaines conditions unévènement finira par avoir lieu.M |= P est vrai si pour tout état sP de CS(M, s0)ou P est vrai, alors pour tous chemin partant de sP il existe un état de CS(M, sP )


ou P est vrai. On distingue trois types de propriété de vivacité : la vivacité simple(un état du système sera finalement atteint, un état du système peut être toujoursatteint), la vivacité de progression (condition de vivacité vérifiée pour au moinsl’un des états terminaux) et la vivacité bornée (la condition de vivacité doit inter-venir avant un certain délai).Exemple 2.3.3. Quelles que soient les conditions, avant le décollage on peut toujoursverrouiller la porte.

Propriétés d’absence de blocage (No deadlock) : L’absence de deadlock est une pro-priété de sûreté particulière qui exprime que le système ne se trouvera jamaisdans une situation ou il ne peut plus progresser.Exemple 2.3.4. La porte ne peut pas rester tous le temps verrouillée.

Propriété d’équité (Fairness) : Une propriété d’équité exprime que, sous certainesconditions un événement arrivera (ou n’arrivera pas) infiniment souvent.Exemple 2.3.5. Aprés un atterissage, la porte ne reste pas toujours verrouillé.

Maintenant que nous avons décrit une classification des différents types de pro-priétés, nous allons voir comment celles-ci peuvent être décrites de manière formelle.La description se fait généralement à l’aide de logiques de spécification ou à l’aide d’ob-servateur.

2.3.2 Logiques de spécification des propriétés

Pour spécifier une propriété dans un formalisme de haut niveau, on utilise deslangages de logiques. Les spécifications logiques décrivent des propriétés “ système” à valider (ex : absence de blocage, l’exclusion mutuelle). Une spécification logiqueest un ensemble de formules d’une logique temporelle [Eme90, EH82] : linéaire LTL[Muk97, EH82], arborescente CTL [CES86, EH82] ou de µ-calcul arborescent [Koz83].

Pour exprimer les propriétés temps réel, des extensions aux logiques temporellesexistent, on peut noter MTL (Metric temporal logic) [Koy90] et [ACD90] introduit TimedCTL (TCTL) comme une extension de CTL permettant d’exprimer les propriétés tempo-relles d’une manière uniforme, où la sémantique temporelle se base sur le temps dense.On peut aussi utiliser une logique spécifique comme la logique temps réel [JM86].

Dans ce cadre, il existe plusieurs approches pour décider siM |= P est vrai. Ondistingue l’approche sémantique (qui revient a calculer l’ensemble d’états qui satisfaitsla formule) et l’approche fondée sur la théorie des automates (qui revient à construire l’au-tomate en composantM avec l’automate qui satisfait la formule P et vérifier si cettecomposition ne donne pas l’ensemble vide).

Les logiques modales sont des logiques très expressives. La complexité est alorsd’arriver à écrire correctement la propriété à vérifier. En particulier, si ces techniquespeuvent être utilisées pour des estimations des performances temporelles (analyse par


dichotomie [God04]), elles ne sont pas dédiées à l’évaluation d’une grandeur tempo-relle du système, par exemple le retard. Nous présentons donc dans la suite une autremanière de décrire les propriétés que sont les observateurs de propriétés.

2.3.3 Observateurs de propriétés

La notion d’observation consiste en la surveillance du comportement d’un systèmeà observer afin : de vérifier des propriétés, d’interdire des exécutions (des chemins),de donner un diagnostic et même de modifier le comportement du système. D’unemanière générale un observateurO est un automate (dans notre cas temporisé) qui sur-veille le comportement d’un modèle de systèmeM (automate temporisé) afin de véri-fier une propriété. Un observateur O possède généralement un nœud particulier échec,encode d’une manière implicite une propriété logique et observe les évènements, lesétats, ou les variables deM significatifs liés a la propriété. La validation de la propriétéconsiste en une composition parallèle synchrone entre l’automateM et l’automate O, siles états échec de la composition (M‖O) sont accessibles, la propriété n’est pas vérifiée.Si à l’inverse, les états échec ne sont pas accessibles alors la propriété est vérifiée.

L’utilisation des observateurs est simple, seules une composition parallèle et uneanalyse d’accessibilité sont nécessaires pour vérifier une propriété. Mais la restrictionmajeure des observateurs est qu’ils ne permettent que l’expression de propriétés desûreté et de vivacité bornée.

[Rog06] présente un état de l’art des observateurs. Les travaux autour des observa-teurs sont très différents. On peut distinguer deux types de travaux, les travaux liés auxautomates observateurs et les travaux liés aux notions fondamentales de l’observation.

2.3.3.1 Automates de Büchi

Soit Σ un alphabet fini, Σ∗ l’ensemble des chaînes finies de lettre de Σ et Σω l’en-semble des chaînes infinies de lettres de Σ. Une trace ω-régulière est de la forme t1.(t2)ω

avec t1, t2 ∈ Σ∗ et t1 6= ∅, t2 6= ∅.

Définition 2.3.1. Un automate de Büchi [GPVW95] [VW86] sur un alphabet Σ est un qua-

druplet A = (S ,S0, →,F), ou S est un ensemble fini d’états, S0 ⊆ S est l’ensemble desétats initiaux, →⊆ S × Σ × S est la relation de transition, et F ⊆ S est l’ensemble des étatsd’acceptation (ou états répétés).

Une exécution est réussie si elle contient une infinité d’états appartenant à F . Unechaîne infinie α est acceptée par A s’il existe une exécution réussie de A sur α. On noteL(A) l’ensemble des chaînes acceptées par A (L(A) est appelé aussi langage).

L ⊆ Σω est Büchi-reconnaissable s’il existe un automate A telque L = L(A).


La vérification des propriétés à l’aide de l’automate de de Büchi se fait à travers unalgorithme de model-checking de la logique LTL [Muk97]. Le principe repose sur lefait qu’il est possible de traduire toute formule logique ϕ de LTL en une expression ω-régulière Fϕ décrivant la forme que doit respecter une exécution si elle veut satisfaireϕ.

Pour vérifier une propriété φ décrit par une formule ϕ sur un systèmeM (M |= φ),un automateA¬ϕ est construit à partir de la formule ϕ reconnaissant les exécutions quine satisfont pas ϕ. Ensuite, il suffit de vérifier si le système issu de la synchronisation deM et deA¬ϕ notéM×A¬ϕ est vide ou non, s’il est vide cela implique queM satisfaitla propriété φ.

2.3.3.2 Automates de test

Les propriétés d’accessibilité sont simples à vérifier et des outils comme UPPAAL[DBLY03] ont mis en œuvre les algorithmes de vérification de ce type de propriétés.L’inconvenient majeur de ce type de propriétés, c’est leur expressivité. Afin de pal-lier ce problème, l’idée est d’exprimer ces propriétés sous la forme d’un observateur.[ABBL98, Bou02] ont axé leurs travaux sur la formalisation et l’expressivité des auto-mates de test, ces derniers permettant d’exprimer une propriété d’accessibilité à l’aided’un observateur.

Soit une propriété φ, on construit un observateur (automate de test) noté Tφ, et unautomate temporiséA. On définit par :

A vérifie φ(A |= φ) ⇐⇒ A‖Tφ ne permet pas d’atteindre un état rejetant (échec) de Tφ

(2.2)

Le logique Lµ,ν introduit par [LLW95] comme une extension temporisée de la lo-gique d’Hennessy Milner [HM85] qui est basé sur le µ-calcul, considérée comme l’unedes logiques les plus expressives.

Les travaux sur la formalisation et l’expressivité des automates de tests [ABBL98,Bou02] définissent le langage (logique) SBLL (Safety and Bounded Liveness Logic) basésur Lµ,ν. Ce langage possède les propriétés suivantes :

• il permet de caractériser complètement l’ensemble des propriétés dont la vérifi-cation peut se réduire à une analyse d’accessibilité ;

• pour chaque formule ϕ du SBLL, on peut construire d’une manière syntaxiqueun automate de test (observateur).

SBLL (Safety and Bounded Liveness Logic), comme son nom l’indique, ne permet d’ex-primer que des propriétés de sûreté et de vivacité bornée. Les automates de test sontdes automates temporisés, donc SBLL permet l’expression de propriétés temporisés.


2.3.3.3 Observateurs SDL

Les observateurs SDL fonctionnent sur le principe qu’à chaque action exécutée dansle système, l’observateur peut en exécuter plusieurs. L’observateur est composé avecle système lors de la simulation aléatoire ou exhaustive. Deux outils ont implémentél’observateur SDL avec deux syntaxes et deux constructions totalement différentes :

• le langage d’observation GOAL (Geode Observation Automata Language [Obe99]qui est implémenté dans l’outil ObjectGeode [Kap02] ;

• les observer processes sont des processus spécifiques qui implémentent les obser-vateurs SDL dans l’outil TauSdt[Tel98].

Les observateurs GOAL sont des automates SDL qui possèdent une constructiond’observation : match et des états succès/rejet qui peuvent être utilisés selon le besoin.Selon la simulation le résultat de la vérification d’une propriété écrite en GOAL est :OK, NOK, INCONCLUSIF pour une simulation aléatoire, ou propriété vérifiée ou nondans le cas d’une simulation exhaustive.

2.3.3.4 Les observateurs UML de projet OMEGA

Dans le cadre du projet OMEGA, [OGO06] propose de spécifier les propriétés à vé-rifier sous la forme d’observateurs en langage UML. La vérification des modèles UMLse fait par simulation et vérification. Les modèles sont traduits en IF [BGM02]. Les ob-servateurs des propriétés sont eux aussi traduits en IF et la vérification se fait de lamanière suivante :

• Dans le cas des propriétés de sûreté, les observateurs UML sont traduits en ob-servateur IF de type observateur classique (automate de test et analyse d’accessi-bilité d’états de reject).

• Dans le cas des propretés de vivacité, les observateurs UML sont traduits en ob-servateurs IF de type automates de Büchi.

Dans le profil OMEGA les observateurs sont des classes stéréotypées par observerajoutées au système. Chaque observateur a une machine à états. Certains de ces étatssont stéréotypés par sucess ou reject. Les observateurs peuvent observer les événementsd’opérations, de signaux, d’actions, d’états et les timers.

2.3.3.5 Observateurs Véda

Il est aussi possible d’observer un système en utilisant un observateur comme ceuxdu simulateur Véda [JMG88]. Un tel observateur est informé de la suite des actions ato-miques (transitions) effectuées par le système. Le langage de description des systèmeset des observateurs est Estelle [RJL85]. Véda simule des systèmes décrits avec Estelle,mais permet aussi de lire la description de propriétés fonctionnelles et de les vérifier(observation). Un observateur Véda est un programme décrivant la propriété à vérifier.Il a la possibilité de voir toutes les interactions du système et l’état des modules. Il peut


aussi stopper la simulation afin d’exécuter de traitement sur les données observées. Cesobservateurs peuvent être utilisés pour la mesure de performances temporelles. Il estpossible d’utiliser plusieurs observateurs en parallèle.

2.3.3.6 Observateurs pour systèmes autovalidés

[DJC94] propose un observateur pour les systèmes distribués. L’observateurconsiste en une copie (de point de vue comportement) du système à valider. C’est-à-dire que l’observateur est une implémentation différente du système. Ceci permet àl’observateur de constater le dysfonctionnement du système à travers des mécanismesd’observation (ou d’espionnage).

L’observateur est alors un sous-système formel, décrit pour vérifier un comporte-ment donné. La conception de l’observateur est indépendante de celle du système. Laspécification de l’observateur et du système en lui même doit intégrer des procéduresde vérification et inclure des mécanismes d’espionnage. [DJC94] utilise les réseaux dePétri pour décrire l’observateur et le système, il permet de spécifier les procédures devérification et intègre des mécanismes d’observation (d’espionnage). Par contre les ré-seaux de Pétri ne permettent que la vérification de la partie contrôle du système car ilsne permettent pas la manipulation des données.

2.3.3.7 Observateurs de machines synchrones

Les observateurs de machine synchrones sont utilisés par [HLR94] pour vérifier despropriétés de sûreté sur les systèmes réactifs et synchrones. La programmation syn-chrone est utilisée pour décrire ce type de systèmes, un programme synchrone réagitd’une manière instantanée et déterministe à l’évènement de l’environnement. Basé surl’algèbre de processus, les langages synchrones permettent la concurrence en garantis-sant le déterminisme et la communication synchrone interprocessus. L’approche syn-chrone à l’avantage que la composition parallèle est synchrone : une propriété est alorsdécrite à l’aide d’un observateur, un autre programme qui observe que le système etdécide s’il vérifie la propriété désirée ou non. L’observateur peut aussi exprimer despropriétés de l’environnement.

Définition 2.3.2. Unemachine I/O (Input/Output) est un n-upletM = (LM, l0M, IM,OM, δM)telle que :

• LM est un ensemble d’états de contrôle contenant l0M, l’état initiale.

• IM ⊂ Σ, l’ensemble de signaux d’entrées.

• OM ⊂ Σ tel que IM ∩OM = ∅ l’ensemble de signaux de sorties.

• δM = LM × I∗M ×O∗M ×LM, la relation de transition


Une propriété P est une ensemble de traces sur Σ. Une machine synchrone Msatisfait une propriété P si et seulement si chaque trace ρ de M appartient à P .Lorsque un observateur détecte une anomalie dans le système il émet un signal α /∈ Σ.L’observateur de la propriété de sûreté P , OP , est une machine synchrone OP =(LOP

, l0OP, IOP,OOP

, δOP) ou :

lρe−→ol′

ρ ∈ δOP, avec o =

∅, si (lρ, e) ∈ Pα, sinon

(2.3)

on peut écrire alors :M |= P ⇔ (M‖OP )

α9 (2.4)

ou OP est l’observateur généré à partir de P .

2.3.4 Propriétés : techniques de vérification

2.3.4.1 Model-checking

Pour la vérification, après l’étape de modélisation du système sous forme, parexemple, d’automates temporisés et de propriétés. L’étape suivante du Model-Checking consiste à exprimer le modèle considéré au moyen d’un STE. L’étape quisuit consiste à exprimer la négation de la formule de logique temporelle que nous sou-haitons tester. La négation de cette formule est donc elle-même transcrite sous formed’un STE, capable de reconnaître exactement l’ensemble des exécutions satisfaisant lanégation de la formule donnée. Par exemple, on pourra transcrire une formule LTL enun automate de Büchi non déterministe [Muk97]. La dernière étape consiste à réaliserle produit cartésien synchrone des deux STE obtenues précédemment. Si le langagereconnu par le produit est vide (pour une propriété d’accessibilité, mais plus généra-lement pour une propriété d’acceptation mettant en jeu la vivacité et l’équité), alors lesystème satisfait la formule de logique. Sinon, toute séquence appartenant au langagedu produit constitue un contre-exemple à la spécification.

Énumérer explicitement tous les états de l’automate peut être coûteux, c’est pour-quoi on procède généralement par des méthodes symboliques. Une approche, répan-due pour la vérification de propriétés exprimées dans la logique temporelle arbores-cente CTL, est fondée sur la représentation des états et des transitions du système pardes ensembles. De nombreuses méthodes de représentation d’ensembles d’états ont vule jour. La plus connue utilise les diagrammes de décision binaire (BDD) [Ake78]. Lefonctionnement d’un model-checker symbolique [McM93] consiste en l’obtention depoints fixes pour déterminer les états accessibles ainsi que ceux qui satisfont une ouplusieurs propriétés. Ces points fixes sont calculés à l’aide de deux transformateurs deprédicats associés au franchissement des transitions : le premier (Post) détermine, pourun ensemble d’états donnés, l’ensemble des états successeurs tandis que le second (Pre)est l’opération réciproque du premier.


2.3.4.2 Techniques de vérification

Les méthodes de vérification sont définies par :• une procédure de décision pour la relation de satisfaction |= pour les méthodesde vérification logique ;

• une procédure de décision pour une relation d’équivalence ou de préordreR.Les méthodes de vérification comportementales et logiques sont complémentaires.

Parmi un ensemble de propriétés à vérifier, certaines peuvent être facilement représen-tées comme une abstraction du comportement attendu du système, d’autre s’exprimentplus facilement à l’aide de logiques temporelles.

La vérification comportementale nécessite la mise en place de deux types d’outils :• un compilateur, dont le rôle est de traduire le système temporisé (l’ensemble d’au-tomates de système) en un système de transition étiquetée (STE) qui modélisel’ensemble de ses exécutions possibles.

• un vérificateur qui implémente un certain nombre de procédures de décisions as-sociées à des relations d’équivalences, et qui permet de comparer les deux sys-tèmes de transitions étiquetées (la description de système et la description de pro-priétés) généralement connu par le modèle de programme (système) et le modèlede spécification (propriétés). Il est aussi important que les vérificateurs donnentdes outils de diagnostic.

De même pour la vérification logique nécessite la mise en place de deux types d’ou-tils :

• un compilateur dont le rôle est de traduire le système temporisé (l’ensemble d’au-tomates temporisés de système) et dans certain cas la formule logique de la pro-priété en un système de transition étiquetée (STE) qui modélise l’ensemble deleurs exécutions possibles.

• un vérificateur qui peut varier d’un simple algorithme d’accessibilité dans le casou la formule de la propriété et traduite en STE à un algorithme demodel-chekingdans le cas ou la propriété est vérifiée en tant qu’une formule logique sur un STE.

D’une manière générale et dans les deux cas, ces deux outils s’organisent alors selonl’architecture “ classique ” de la figure 2.3 :

La vérification comportementale ou logique est assez complexe et gourmande enressources et le problèmemajeur liée à la vérification formelle est l’explosion du nombred’états. Pour remédier à ce problème, une première solution consiste à faire la vérifica-tion sur un système de transitions étiquetées réduit. La réduction dépend généralementdes propriétés à vérifier, cette réduction consiste en minimisation [ACH+92] du STE àtravers le calcul d’un quotion du STE (le plus petit STE équivalent) vis-à-vis à unerelation d’équivalence (par exemple la bissimulation [MOU92]) et modulo un critèred’abstraction (qui permet d’abstraire un ensemble de transitons de STE à une seuletransition équivalente). La deuxième solution consiste à effectuer la vérification au furet à mesure de la génération de STE, et donc à ne pas le mémoriser dans son intégralité.

2.4. Conclusion et discussion 43

FIG. 2.3 – Architecture classique de la vérification

Cette solution est généralement appelée la vérification “ à la volée ” (on the fly : figure2.4). Les premières applications de la vérification “ à la volée ” sont apparues dans lestravaux de [Hol85] pour le problème de l’analyse d’accessibilité, puis cette méthode aété étendue aux propriétés de sûreté spécifiées à l’aide de formule de logiques tempo-relles dans les travaux de[JJ90], et enfin pour des propriétés plus générales qui peuventse spécifier à l’aide des automates de Büchi [JJ92]

2.4 Conclusion et discussion

Pour caractériser les propriétés temporelles, les observateurs apparaissent plusadaptés. Ce sont des mécanismes assez puissants pour vérifier des propriétés de sû-reté ou de vivacité bornée. Or les propriétés visées (le retard) pour les systèmes visés(systèmes prédictibles au comportement borné) rentrent dans cette catégorie. La faci-lité d’exprimer une propriété sous la forme d’un observateur varie d’une approche àl’autre. L’existence ou non d’outils de vérification et d’analyse diffère aussi d’une ap-proche a l’autre.

Le tableau 2.1 compare les approches entre elles.

Nous retiendrons les avantages suivants :• La capacité des observateurs à analyser le comportement du modèle.• La facilité de mise en œuvre et de l’expressivité des observateurs pour décrirequelques propriétés.

• L’ensemble des outils de vérification qui implémente l’approche de vérification àbase d’observateurs.


FIG. 2.4 – Vérification “ à la volée ”

Les observateurs sont le plus adaptés pour la vérification des propriétés tempo-relles. Nous utilisons dans la suite l’approche de vérification à base d’observateurs pourl’évaluation des caractéristiques temporelles (en particulier le retard), mais il faut lesadapter pour l’instrumentation. Dans la suite, nous développons une théorie d’obser-vation des flots de données basés sur les observateurs dans le but de donner une loi desvaleurs des caractéristiques temporelles des pilotes d’équipements.

2.4.Conclusion

etdiscussion

45

Approche Expressivité OutilsMise en oeuvre del’observateur

Complexité de la véri-fication

Remarques

Automates de Büchi Logic LTL OUI Automatique Complexe Efficace

Automates de test µ-calcul NONConstruction à partirde SBLL

Analyse d’accessibi-lité

Très bon cadre théo-rique sans valeur pra-tique

Observateur SDL SDL OUI Aucune méthodologie Outils de diagnostic

Aucun étude sur l’ex-plosion ni sur la des-cription de l’environne-ment

Observateurs UML deprojet OMEGA

UML - Aucune méthodologie Complexe (2) -

Observateurs VédaAlgèbre deprocessus

OUI Automatique Simple (1)

Observateurs poursystèmes auto-validés

C’est ne pas de la validation formelle, mais des tests d’implantation ([DJC94] donneles base essentielle sur les observateurs : espionnage, contrôle, observation)

Observateurs de ma-chines synchrone

Ensemblede traces

- Complexe Moyen (2)

(1) Aucun gestion de l’explosion combinatoire n’est proposée ni technique ni méthodologique(2) Ces observateurs permettent aussi d’exprimer des hypothèses sur l’environnement : c’est une solution pourle problème de l’explosion combinatoire par une réduction du comportement de l’environnement

TAB. 2.1 – Tableau récapitulatif de diffèrents approches de vérification à base d’observateurs.

Deuxième partie

Approche

La science ne connaît qu’une loi : la contribution scientifique

Galilée

3Évaluation des propriétés temporelles d’un

flot de donnée

CE chapitre présente notre approche pour l’évaluation des caractéristiques temporelles des occurrencesd’un flot de données d’une chaîne d’acquisition. On commence par une formalisation du comporte-

ment du cycle de vie d’une occurrence de donnée dans une chaîne d’acquisition. Ensuite, nous présentonsnotre approche d’observation des occurrences pour l’évaluation du “ retard ”.

Plan du chapitre

3.1 Cycle de vie et propriétés d’une occurrence de flot de données . . . . 503.1.1 Chaîne d’acquisition de donnée . . . . . . . . . . . . . . . . . . 503.1.2 Communication entre éléments d’une chaîne d’acquisition . . 503.1.3 Comportement d’un élément de la chaîne d’acquisition . . . . 513.1.4 Cycle de vie d’une occurrence dans un élément Comp . . . . . 533.1.5 Composition des éléments d’une chaîne d’acquisition . . . . . 543.1.6 Cycle de vie d’une occurrence dans une chaîne d’acquisition . 58

3.2 Variables d’observation d’occurrence . . . . . . . . . . . . . . . . . . . 593.2.1 Retard d’une occurrence de donnée . . . . . . . . . . . . . . . 593.2.2 Variables d’observation . . . . . . . . . . . . . . . . . . . . . . 60

3.3 Observateur d’occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . 623.3.1 Caractéristiques et fonctionnement d’un observateur d’oc-

currence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.3.2 Observateur d’occurrences pour le calcul du retard . . . . . . . 66

3.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

50 3. Évaluation des propriétés temporelles d’un flot de donnée

E SComp

E, S =

occ, où occ est un flot de donnéecont, où cont est une information de contrôle

FIG. 3.1 – Élément d’une chaîne d’acquisition

3.1 Cycle de vie et propriétés d’une occurrence de flot de données

3.1.1 Chaîne d’acquisition de donnée

Une chaîne d’acquisition de données d’un système de contrôle de processus estcomposée d’un ensemble d’entités communicantes, notées Comp (cf. figure 3.1). Unélément Comp est un composant qui reçoit et émet des flots de données notés occ (occirépresente la iéme occurence du flot occ véhiculé) ainsi que des flots de contrôle notéscont.

Un élément Comp de la chaîne d’acquisition de données des systèmes de contrôlede processus peut être soit :

• Une source, c’est à dire un producteur des occurrences occi du flot de données occ :les capteurs physiques ou les capteurs intelligents (un seul Socc, pas de Eocc).

• Un puit, c’est à dire un consommateur des occurrences occi de flot de données : lesapplications de contrôle (un seul Eocc, pas de Socc).

• Un élément intermédiaire ou de traitement des occurrences occi de flot de données :pilotes d’équipement, interfaces de communication.

Il est à noter que chaque source determine la date de production de chaque occur-rence du flot qu’elle génère. Dans la chaîne d’acquisition, on considère qu’un même flotde donnée n’est généré que par une source unique. Cette source ne génère qu’un seulflot de données.

3.1.2 Communication entre éléments d’une chaîne d’acquisition

Chaque élément Comp peut communiquer avec les autres éléments de la chaîned’acquisition à travers des flots de données (notées occ) et des flots de contrôle (notéescont). Les occurrences notées occi, naviguent à travers les éléments de la chaîne d’ac-quisition de donnée. Chaque élément Comp peut recevoir (respectivement envoyer)une occurrence occi en provenance (respectivement à destination) d’un autre élémentde la chaîne d’acquisition de données. Les éléments producteurs ne font qu’envoyer desoccurrences alors que les éléments consommateurs ne font que recevoir des occurrences.Pour recevoir une occurrence un élément peut être soit :

• En attente ou “ waiting ” : l’élément attend toujours l’arrivée d’une occurrence.

3.1. Cycle de vie et propriétés d’une occurrence de flot de données 51

• En attente après une demande de lecture ou “ request ” : l’élément envoie unedemande de lecture d’une donnée suivant une loi (périodique, sporadique enrafale), puis, il se met en attente active d’une occurrence.

Pour envoyer une occurrence, un élément peut le faire selon deux modes :• Le mode attente active ou “ pull ” : l’élément attend l’arrivée d’une ou plusieursdemandes de lecture en provenance d’un ou plusieurs éléments et satisfait cesdemandes immédiatement ou après un certain temps, modélisant un temps detraitement.

• Le mode émission “ push ” : l’élément envoie à un autre élément une ou plu-sieurs occurrences en suivant une loi donnée. Parmis ces lois, on distingue l’en-voi simple (une émission d’une seule occurence), de l’envoi multiple (émission deplusieurs occurences). Dans ces dernières, on retrouve l’envoi périodique, spora-dique ou en rafale. Le nombre d’envoi peut être borné ou infini. Les envois sefont immédiatement à l’échéance de la loi d’envoi ou aprés un temps donné, mo-délisant un temps de traitement.

Pour des raisons de compatibilité dans les modes de communication entre les élé-ments, les modes “ request ” et “ pull ”, respectivement “ waiting ” et “ push ” sontcompatibles entre eux (cf. figure 3.2).

En dehors des occi, tout élément peut envoyer, respectivement recevoir, des occur-rences du flot de contrôle cont.

3.1.3 Comportement d’un élément de la chaîne d’acquisition

À la réception d’une occurrence occi, un élément Comp peut effectuer les trois ac-tions suivantes sur une occurrence occi :

• “ Transmit ” : renvoyer immédiatement ou après un délai l’occurrence à un autreélément Comp.

• “ Save ” : sauvegarder l’occurrence dans un registre ou une zone mémoire selonune politique d’écriture donnée (FIFO, LIFO...).

• “ Forget ” : ne pas considérer l’occurence (perte de l’inforamation)Les opérations Transmit et Save peuvent être menées conjointement. De même

l’émission d’une occurrence peut concerner plusieurs éléments Comp. Enfin, il est ànoter que la communication “ request-pull ” n’est possible que si l’élément Comp aprécédemment effectué une sauvegarde. Il en est de même pour un envoi multiple.

Le sauvegarde d’une occurrence occi se fait dans un registre ou dans une zone mé-moire de Comp. On dit qu’on a créé une copie de l’occurrence dans le système. Par hypo-thèse de l’étude, si on utilise le même registre ou la même zone mémoire, l’occurrencedéjà existante dans le registre ou dans cette zone mémoire est perdue. On parle dans cecas d’écrasement de l’ancienne occurrence. De ce fait, on ne considère pas ici les sauve-gardes avec historique (par ex : la donnée sauvegardée est la valeur moyenne des dixdernières occurrences). Le sauvegarde est modélisée comme une simple opération d’af-


FIG. 3.2 – Communication du flot occ entre le producteurComp1, le composant intermé-diaire Comp2 et un composant consommateur Comp3 : mode request/pull entre Comp2et Comp3, et mode waiting/push entre Comp1 et Comp2


fectation. Lors de la sauvegarde d’une occurrence occi, un élément Comp d’une chaîned’acquisition peut effectuer les actions suivantes :

Copie simple : crée une copie de l’occurrence occi dans le système, cette nouvelle co-pie de occi possède la même date de production que celle de l’occurrence occid’origine.

Copie avec écrasement : crée une copie et écrase une occurrence déjà existante dans lazone de sauvegarde de Comp. L’occurrence écrasée est une occurrence occj reçueà une date antérieure par Comp. On considère ici qu’une zone de stockage estliée à un flot de données : une occurence d’un flot peut écraser uniquement uneoccrence du même flot.

L’élément Comp peut recevoir ou émettre non seulement des occurrences mais aussides messages de contrôle. On peut énumérer ici plusieurs message de contrôle. Cesmessage permettent de lancer une ou plusieurs actions de contrôle ou générer des in-formations sur l’état d’un élément de la chaîne d’acquisition. Par la suite, on s’intéresseaux messages de contrôles liées aux occurrences.

Demande de lecture : une demande de lecture ?lecture(in f o) peut être reçue par unélément Comp en provenance d’un autre élément de la chaîne de d’acquisition.Cette demande de lecture peut contenir en paramètre des informations in f o per-mettant de spécifier la politique d’envoi de l’occurrence, les caractéristiques del’occurrence à envoyer ou des contraintes temporelles sur l’envoi de la donnée.

Message de configuration de périphérique : dans le cas ou l’élément Comp est un pé-riphérique ou un pilote d’équipement ces messages peuvent être de type DrvIns-tall, DevAdd, IOctl . . . . Ils correspondent à l’initialisation du composant d’un pointde vue logique (initialisations logicielles) ou physique (initialisation materielles).

Message d’information sur les états ou les actions : par exemple pas d’occurrencedisponible (registre ou zone mémoire vide), écrasement d’une ou plusieurs oc-currences, création d’une nouvelle copie d’une occurrence dans l’élément Comp,. . . .

3.1.4 Cycle de vie d’une occurrence dans un élément Comp

Les automates des figures 3.3, 3.4 et 3.5 présentent le cycle de vie d’une occurrenceocci dans un élément Comp telle que considérée dans cette thèse, c’est-à-dire le compor-tement obligatoire de Comp vis-à-vis d’une occurrence occi donnée. Plus précisement,le comportement d’un élément Comp autorisé doit simuler le comportement décrit parComp : soit une relation formelle de simulation entreComp et le comportement de Comp“ spécification ” vis-à-vis d’une occurence occi.

Le comportement réactif de Comp “ spécification ” est lié à la réception d’une entrée(occi ou cont). Comp “ spécification ” considère les occurences ou les contrôles l’une aprèsl’autre (mode FIFO de consommation des occurrences et des contrôles). La réaction


d’un élément Comp à la réception d’une occurence occi ou un contrôle cont se fait selonl’hypothèse “ run-to-completion ” : chaque entrée est traitée avant l’entrée suivante.

• L’élément Comp ne possède aucune occurrence occi et il reçoit occi : Comp peutrenvoyer occi immédiatement ou sauvegarder occi et donc créer une copie dansbu f f er, et donc écraser occk avec k 6= i (cf. figure 3.3(a)).

• L’élément Comp ne possède aucune occurence occi et reçoit une autre occurrenceoccj avec j 6= i, Comp peut renvoyer occj immédiatement ou sauvegarder occj etdonc créer une copie dans bu f f er, et donc écraser occk avec k 6= i (figure 3.3(b)).

• L’élément Comp ne possède aucune occurence occi et reçoit un message decontrôle cont, Comp peut envoyer le contenu de bu f f er qui contient occk k 6= i oune rien envoyer (figure 3.4(a)).

• L’élément Comp possède dèja une occurence occi et il reçoit une copie de occi,Comp peut renvoyer occi immédiatement ou sauvegarder occi et donc recopierdans bu f f er occi (cf. figure 3.4(b)).

• L’élément Comp possède dèja une occurence occi et reçoit un message de contrôlecont, Comp peut envoyer le contenu de bu f f er qui contient occi ou ne rien en-voyer (figure 3.5(a)).

• L’élément Comp possède dèja une occurence occi et reçoit une autre occurrenceoccj avec j 6= i, Comp peut renvoyer occj immédiatement ou sauvegarder occj etdonc créer une copie dans bu f f er et donc écraser occi (figure 3.5(b)).

3.1.5 Composition des éléments d’une chaîne d’acquisition

Une chaîne d’acquisition est composée de plusieurs éléments Comp. Ces élémentséchangent des informations de type flot de contrôle ou flot de données. La compositiondes éléments Comp pour construire une chaîne d’acquisition suit les règles suivantes :

1. Une chaîne d’acquisition possède au moins un élément Comp de type source (pro-ducteur).

2. Une chaîne d’acquisition possède au moins un élément Comp de type puîts(consommateur).

3. Une chaîne d’acquisition peut avoir un ou plusieurs éléments Comp de type in-termédiaire.

Un flot de données occ est produit par un élément source et il est acheminé par leséléments intermédiaires jusqu’aux éléments puits. Un flot de données s’écoule de la sourceaux puits. De ce fait, il ne peut pas revenir à un Comp intermédiaire qui’il a déja traité. Decette hypothèse, on déduit en particulier q’un Comp ne peut pas renvoyer un flot surlui même (pas de rebouclage).

L’acheminement des flots de contrôle et des flots de données entre les éléments dela chaîne d’acquisition est considéré comme sûr. C’est-à-dire durant la communicationentre les élements Comp, un flot (de contrôle cont ou de donnée occ) ne peut subiraucune modification de contenu, ni de perte, ni un delai de communication infini.


pas de occi dans Comp

occi dans Comp

occi recu

état état instable : aucune entrée n’estconsidérée dans cet état

?occi

!occi

f orget(occi)

∗

“bu f f er contient occ′′ksauvegarde(occi , bu f f er)

!copie(occi)

!ecrasement(occk )

“bu f f er vide′′

sauvegarde(occi , bu f f er)

!copie(occi)

(a) (k 6= i)

pas de occi dans Comp occj recu

occj memo

état état instable

?occj

!occj

τ

f orget(occj )

∗

“bu f f er contient occ′′ksauvegarde(occj , bu f f er)

!ecrasement(occk )!copie(occj)

“bu f f er vide′′

sauvegarde(occj , bu f f er)

!copie(occj)

(b) (j 6= i et k 6= i)

FIG. 3.3 – Cycle de vie d’une occurrence dans un élément de la chaîne d’acquisition


pas de occi dans Comp cont recu?cont

!occbu f f er

τ

∗

(a) (occbu f f er 6= occi)

occi dans Comp

occi recu


?occi

!occif orget(occi)

∗

sauvegarde(occi , bu f f er)

!copie(occi)

!ecrasement(occi )

(b) (buffer contient occi)

FIG. 3.4 – Cycle de vie d’une occurrence dans un élément de la chaîne d’acquisition(suite)


occi dans Comp cont recu?cont

!occi ∗

τ

(a) (buffer contien occi)

occi dans Comp

pas de occi dans Comp

occj recu

occj memo


?occj

!occj

τ

f orget(occj )

∗

sauvegarde(occj , bu f f er)!copie(occj)

!ecrasement(occi )

(b) (buffer contient occi)

FIG. 3.5 – Cycle de vie d’une occurrence dans un élément de la chaîne d’acquisition(suite et fin)


3.1.6 Cycle de vie d’une occurrence dans une chaîne d’acquisition

3.1.6.1 Notations

Pour écrire une formule en CTL “ Computational Tree Logic ” [CES86], on utilise lesnotations suivantes :

Q T P∀Pour tous chemins∃Il existe un chemin tel que

X successeur (next)

♦ un jour (fatalement)

toujours dans le futur (globally)

U until

proposition

¬♦ jamais

3.1.6.2 Cycle de vie d’une occurrence

À partir de sa date de production (considérée comme unique), une occurrence esttransmise jusqu’aux puits ou perdue, des copies peuvent être créés, puis écrasées ousupprimées.

À priori, un système est “ infini ” : une copie d’occurence peut rester dans le systèmeun temps infini. Par la suite, on cherchera a caractériser des systèmes “ finis ” : soit,

∀♦( f in de vie de occi) (3.1)

Une occurence occi existe tant que des Comp peuvent l’émettre ou en garder unecopie. L’état fin de vie de occi de l’automate de la figure 3.6, est donc caractérisé par lespropriétés suivantes :

∀♦( f in de vie de occi) ⇒ ∀¬♦(!occi) (3.2)

∀♦( f in de vie de occi) ⇒ ∀(NbrCopiesocci = 0) (3.3)

Du fait qu’il n’existe qu’une source d’émission lorsque il n’y a plus de copies, il nepeut plus y avoir d’émission. En effet, au vue du comportement du système, une copieest toujours résultante d’une émisssion. La formule 3.3 peut donc etre remplacée par laformule 3.4 :

∀♦( f in de vie occi) ⇒ (NbrCopiesocci = 0) (3.4)

3.2. Variables d’observation d’occurrence 59

pas de occi

occi existe

f in de vie de occi

!occiNbrCopiesocci := 1

NbrCopiesocci = 0

!occiNbrCopiesocci + +

?occiNbrCopiesocci −−

!copie(occi)NbrCopiesocci + +

!ecrasement(occi )NbrCopiesocci −−

FIG. 3.6 – Cycle de vie d’une occurrence dans une chaîne d’acquisition

De plus, on fait l’hypothèse de vivacite bornée sur les sytèmes étudiés, soit la for-mule 3.2 est contrainte par un temps maximum. En effet, l’objectif de l’étude est decaractériser des systèmes de contrôle de processus au comportement borné.

Globalement pour le système, l’état d’une occi est représenté par l’automate de lafigure 3.6

3.2 Variables d’observation d’occurrence

Les variables d’observation sont utilisées pour observer les occurrences dans unou plusieurs éléments Comp d’une chaîne d’acquisition. Ces variables d’observationvarient selon les ou la caractéristique d’une occurrence qu’on désire évaluer.

3.2.1 Retard d’une occurrence de donnée

Dans la suite de ce travail, on considère comme exemple de caractéristiques à éva-luer le retard d’une occurrence, que l’on définit comme étant :

Définition 3.2.1. “ Le retard d’une occurrence est la durée d’acheminement de cette occurrenceentre deux éléments de la chaîne d’acquisition ”.


Ou autrement dit :

“ Le retard d’une occi est la différence entre la date de consommation ou de réception de occipar un élément Compp et la date de la production ou de l’envoi de cette même occurrence occipar un autre élément Comps de la chaîne d’acquisition de données ”.

Dans la suite de ce document on considère que les éléments Comps et Compp sontrespectivement l’élément source ou producteur et l’élément puit ou consommateur de lachaîne d’acquisition.

Dans une chaîne d’acquisition de données, on considère qu’il existe plusieurs élé-ments sources et plusieurs éléments puits. Mais, on considère aussi qu’une occurrenceocci ne peut être produite que par un élément source unique. Par contre, elle peut êtreconsommée par plusieurs éléments puits. De même, un puits peut consommer plusieursfois la même occurence occi. Dans ce cas, on dit que les éléments puits consomment des“ copies ” de l’occurrence occi. Une occurrence occi possède ainsi une seule date decréation mais plusieurs dates de consommation donc plusieurs retards possibles.

Afin d’évaluer le retard des occurrences, il est nécessaire de connaître avec précisionla date de production par l’élément source producteur de l’occurrence et les dates deconsommation par les éléments puits consommateurs de toutes les copies de la mêmeoccurrence. Ces dates sont utilisées par la suite pour le calcul des retards possibles.

Pour l’évaluation de ces dates, il est nécessaire d’avoir au sein des éléments de lachaîne d’acquisition des outils de surveillance temporelle des occurrences. Ces outilsde surveillance des occurrences peuvent varier de simples variables ou l’on mémoriseles instants des dates de production et de consommation des occurrences, à un élémentd’observation indépendant permettant de suivre le cheminement des occurrences à tra-vers la chaîne d’acquisition. Dans le premier cas, on instrumente le système par des va-riables adéquates, et dans le deuxième cas, on introduit dans le système un observateurdes retards.

3.2.2 Variables d’observation

Nous considérons d’abord que le retard est évalué à l’aide de variables d’obser-vation. L’évaluation de ce retard se base sur une connaissance de la date de produc-tion initiale de l’occurrence et des dates de consommation de cette occi. Cette datede production est calculée vis-à-vis de l’horloge (chronomètre) globale notée Hglobalqui se déclenche avec la mise en fonctionnement de la chaîne d’acquisition du sys-tème de contrôle de processus. La date de production d’une occurrence occi noté@production(occi ) est alors la valeur de l’horloge globale à l’instant de sa productionpar un élément source. Soit la date d’émission de l’occurence par Source

@production(occi ) = valeur(Hglobale) à l’instant de production (émission) (3.5)

3.2. Variables d’observation d’occurrence 61

Les couples (@production(occi ), occi) doivent être enregistrés dans des variables Diafin de les utiliser ensuite pour calculer les retards, aumoment de la réception des copiesdes occurrences par les éléments puits.

À la réception d’une copie de l’occurrence occi donnée, un élément puits calcule ladate de réception (de consommation) notée @consommationj(occi) où j représente lenuméro de la copie de l’occurrence occi reçue à cette instant.

@consommationj(occi) = valeur(Hglobale) à l’instant de consommation (réception)(3.6)

À chaque couple (@production(occi), occi), est associé un ensemble de datesde consommation @consommation1(occi), @consommation2(occi), ..., @consommation-j(occi), ..., @consommationm(occi) oùm représente le nombre de copies créées et reçuesà partir de occi. La valeur de m varie d’une occurrence à l’autre selon le comportementdes éléments de la chaîne d’acquisition vis-à-vis des occurrences.

Pour une copie j donnée d’une occurrence occi le retard est défini par :

retardi,j = @consommationj(occi) −@production(occi ) (3.7)

Cette première méthode d’évaluation de retard utilise des variables pour surveillerles occurrences. Elle apparaît comme simple à mettre en œuvre : définition de quelquesvariables d’observation et mise en place d’actions d’observation. Mais, cette approcheprésente quelques inconvénients et pose des problèmes théoriques :

Gestion du temps de la simulation exhaustive : dans les outils de vérification for-melle, la notion d’horloge globale existe de manière implicite “ elle est créée lorsde l’exécution ou de la simulation de modèles ”. L’accès à la valeur de cette hor-loge est difficile voir impossible lors de la modélisation du système. La solutionconsiste alors à créer une horloge globale d’une manière explicite. Mais l’écoule-ment permanent de cette horloge rend la simulation ou l’exécution de modèle dela chaîne d’acquisition infinie, ce qui génère un problème d’explosion du nombred’états du système. Vue que l’exécution dumodèle est infinie (“ nombre d’états desystème infini ”), on est contraint d’arrêter l’exécution ou la simulation dumodeleà un instant choisi à l’avance. Cette instant correspond au moment ou on atteintl’exhaustivité vis-à-vis des valeurs de retard possibles. Il est très difficile, voireimpossible de calculer ou de détecter à priori cette instant vis-à-vis des valeursde retard inconnues à priori. Cet instant correspond au moment ou l’ensembledes états possibles du système est atteint (comportement cyclique vis-à-vis desretards). Une démarche a été développée pour fixer cet instant, démarche détailléedans le chapitre 4.

Observation : l’observation d’un système se fait en théorie d’unemanière synchrone etprioritaire par rapport à toutes autre action du système. Une action dans un élé-ment de la chaîne d’acquisition qui peut prendre du temps ne doit pas s’exécuter


avant une action d’observation. Il ne doit pas y avoir d’écoulement de temps entrel’instant où une occurrence est produite ou consommée et l’instant où la valeurde l’horloge globale est considérée “ récupérée ”. Ceci pose plus généralemenetle problème du placement adéquat des points d’observation [FON08]. Ceci étantdit, le formalisme utilisé pour modéliser le système et évaluer le retard permet derésoudre ce problème. On considère dans la suite que le temps d’une action est“ nul ” et que le temps n’est modélisé qu’au travers des gardes temporelles. Lestemps d’exécution ou les délais d’attente sont alors modélisés à l’aide des gardestemporelle. Les actions d’observation sont non préemptives et plus prioritairesque les autre actions du système (en particulier l’écoulement du temps).

Stockage des informations : le calcul des valeurs possibles de retard se fait à partir desinformations stockées dans les variables Di. Les variables sont considérées sépa-rement ou dans un tableau de valeurs. Cet espace de stockage d’information estconséquent et dépend non seulement de l’atteinte de l’exhaustivité vis-à-vis desvaleurs de retard mais dépend aussi du nombre de dates de production et dedates de consommation qui varie en fonction des paramètres des éléments de lachaîne d’acquisition (périodes, temps d’attente, taille des registres et des zonesmémoire de sauvegarde). Pour reduire l’espace de stockage nécessaire à Di, deuxsolutions peuvent être considérées : la première consiste à ne considérer que lesdernières valeurs de retard. La deuxième consiste à faire un affichage ou à émettrechaque valeur mesurée vers une entité externe, par exemple dans un fichier au furet à mesure. La deuxième solution prévoit que l’outil de modélisation intègre cetype d’opérations.Afin de diminuer l’espace possible des retards obtenus, on peutaussi s’appuyer sur une analyse a priori, de type RMA, des retards possibles. Uneanalyse RMA permet de calculer une borne du retard possible appelée retardmax .Si on ne conserve que les valeurs discrètes du retard, le nombre maximum de va-leurs possibles est inférieur à retardmax . Il nous suffit de prévoir alors une zonemémoire permettant de stocker retardmax valeurs de retard possibles.

Afin de remédier aux divers problèmes évoqués, on propose une autre méthode,basée sur la mise en place d’un élément non intrusif dédié à l’observation du système etl’évaluation des caractéristiques temporelles. Par la suite, la caractéristique considéréedans tous les exemples est le retard défini précédemment.

3.3 Observateur d’occurrence

L’approche dévoloppée dans cette section consiste en la mise en place d’un élémentdans la chaîne d’acquisition dédié à l’observation des occurrences, et plus précisementà leur cycle de vie. L’élément dédié à l’observation est appelé observateur ou encore ob-servateur d’occurrence. Dans la suite, on s’intéresse uniquement au retard. L’observateurconsidéré est instrumenté afin d’obtenir un observateur de retard. Dans la suite on notecet élément observateur parObs

3.3. Observateur d’occurrence 63

3.3.1 Caractéristiques et fonctionnement d’un observateur d’occurrence

3.3.1.1 Caractéristiques d’un observateur d’occurrence

L’observateur d’occurrence Obs est un élément de la chaîne d’acquisition, il réagiten fonction des actions, du comportement ou de l’état des autres éléments de la chaîned’acquisition.

Comme classiquement pour les observateurs [DJC94, HLR94, RJL85, JMG88,BGM02, OGO06, Obe99, ABBL98, Bou02, GPVW95, VW86] ce dernier, doit avoir lescaractéristiques suivantes :

1. L’élément Obs doit réagir d’une manière synchrone aux événements et actionsobservables des autres éléments.

2. L’élément Obs doit être l’élément le plus prioritaire de la chaîne d’acquisition.

3. Par hypothèse, un seul élément Obs est mis en place lors d’une évaluation.

4. Les actions exécutées par un l’élément Obs suite à une observation quelconquesont de durée nulle et non préemptibles.

5. L’élément Obs doit être déterministe.

3.3.1.2 Fonctionnement d’un élément observateur

L’élémentObs (cf. figure 3.7) réagit en fonction des événements liés aux éléments dela chaîne d’acquisition et en relation avec la création, la sauvegarde ou l’écrasement desoccurrences de données : Obs surveille le cycle de vie des occurrences dans la chaîned’acquisition de donnée. Pour une occurrence occi donnée,Obs doit réagir en fonction :

• des émissions de l’occurrence occi par un élément Comp, cette production est tra-duite par un signal !occi (ou aussi !production(occi ) par un élément source) ;

• des réceptions de l’occurrence occi par un élément Comp, ces consommations sonttraduites par un signal ?occi (ou aussi ?consommation(occi ) par les élément puits) ;

• des actions de création de copies de l’occurrence occi dans tous les éléments Compde la chaîne d’acquisition, l’action de la création d’une copie de occi dans élémentComp est signalée par un signal !copie(occi) ;

• des actions d’écrasement de l’occurrence occi dans tous les éléments Comp dela chaîne d’acquisition, l’action d’écrasement de occi dans un élément Comp estsignalée par un signal !ecrasement(occi ).

L’observation d’une occurrence occi est arrêtée une fois que toutes les copies de occidans la chaîne d’acquisition sont consommées par les éléments Source ou écrasées pard’autre occurrences occk avec k 6= i dans les autres éléments Comp.

L’observation d’une occurrence occi démarre à l’instant ou occi est créée (créationunique), c’est-à-dire à l’instant de sa production par un élément source concerné. Ce


nombre de copies de occi noté NbrCopiesocci dans la chaîne d’acquisition est alors ini-tialisé à 1 . À chaque création d’une nouvelle copie de occi dans un élément quelconquede la chaîne d’acquisition, NbrCopiesocci est incrémenté de 1. À chaque écrasementde occi par une autre occurrence ou consommation d’une copie de occi par un élé-ment puits, NbrCopiesocci est décrémenté de 1. Une fois que NbrCopiesocci est égal à0, l’observation de occi est arrêtée. Le contrôle du nombre d’occurence NbrCopiesocci sefait uniquement après une action d’écrasement !ecrasement(occi ) ou de consommation?consommation(occi ).

L’algorithme (Algorithme 1) traduit le calcul de nombre des copies de l’occurrenceocci et l’arrêt de l’observation.

3.3. Observateur d’occurrence 65

/*initialisation*/NbrCopiesocci := −1/*observation*/Si (!production(occi ) observed) AlorsNbrCopiesocci := 1

Fin SiTant que (1) faire

Si (!occi observed) AlorsNbrCopiesocci + +

Fin SiSi (?occi observed) AlorsNbrCopiesocci −−

Fin SiSi (!copie(occi) observed) AlorsNbrCopiesocci + +

Fin SiSi (!ecrasement(occi ) observed) AlorsNbrCopiesocci −−Si (NbrCopiesocci = 0) AlorsStop Tant que

Fin SiFin SiSi (?consommation(occi ) observed) AlorsNbrCopiesocci −−Si (NbrCopiesocci = 0) AlorsStop Tantque

Fin SiFin Si

Fait/*fin de l’observation*/

Algorithme 1: Calcul du nombre des copies de occiL’automate de la figure 3.7 représente l’observateur d’une occurrence occi donnée,

l’état ( f in observation occi) est équivalent à l’état ( f in de vie de occi) de l’automate de lafigure 3.6. On peut alors écrire :

∀♦( f in de vie occi) ⇒ ∀( f in observation occi) (3.8)

Cet observateur doit être généralisé pour l’observation de toutes les occurrencesocci d’un flot occ. L’observation de toutes les occurrences occi par l’élément Obs se fait


initial observation occi

controle NbrCopiesocci

f in observation occi

!production(occi ) observed

NbrCopiesocci := 1

NbrCopiesocci = 0

NbrCopiesocci 6= 0

!occi observed; NbrCopiesocci + +

?occi observedNbrCopiesocci −−

!copie(occi) observedNbrCopiesocci + +;

!ecrasement(occi ) observedNbrCopiesocci −−;

?consommation(occi ) observedNbrCopiesocci −−;

FIG. 3.7 – Observation d’une occurrence occi

de manière similaire. L’automate de la figure 3.7 représente ainsi le fonctionnement del’observateurObs des occurrences occi dans la chaîne d’acquisition.

L’observateur Obs permet d’observer les occurrences occi vis-à-vis des évènementsde production, de création d’une copie, d’écrasement et de consommation. Dans lasuite, nous utilisons l’observateur Obs pour l’évaluation du retard. L’observateur deretard est notéObsretard

3.3.2 Observateur d’occurrences pour le calcul du retard

Afin d’évaluer le retard et calculer les valeurs possibles de retard respectives desoccurrence occi, on utilise un vecteur de compteurs de temps noté Xocci . La taille de cevecteur est borné par le nombre maximal d’occurences présentes simultanément dansle système. Nous discuterons par la suite comment évaluer cette borne, que l’on sup-pose à priopri non-infinie. Ces compteurs de temps sont représentés par des horloges etappelés horloges de calcul des durées.

Pour l’observateur de vérification des propriétés, il existe deux états particuliers del’observateur (succès/échec), qui traduisent respectivement (propriétés valide/ proprié-tés non valide). Dans le cas de l’observateur d’évaluation de retard, on ne possède pasd’états d’échec échec car on cherche seulement à obtenir les valeurs possibles du re-

3.4. Synthèse 67

tard. Un état succès est utilisé pour signaler qu’une valeur de retard à été évaluée (oucalculée).

L’observateur de retard Obsretard fonctionne de la manière suivante :

1. dès que la production d’une occurrence occi est observée (!production(occi ) observed),l’observateur Obsretard initialise son compteur de copies à 1 (NbrCopiesocci := 1)et démarre son horloge de calcul de durée (Xocci := 0) ; l’horloge de calcul de retardde occi est ainsi enclenchée ;

2. dès qu’un envoi d’une copie de occi est observé (!occi observed), l’observateurObsretard incrémente son compteur de copies de 1 (NbrCopiesocci + +) ;

3. dès qu’une réception d’une copie de occi est observé (?occi observed), l’observateurObsretard décrémente son compteur de copies de 1 (NbrCopiesocci −−) ;

4. dès qu’une création d’une nouvelle copie de occi est observé (copie(occi) observed),l’observateur Obsretard incrémentée son compteur de copies de 1 (NbrCopiesocci ++) ;

5. dès qu’un écrasement d’une copie de occi est observé (!ecrasement(occi ) observed),l’observateur Obsretard décrémente son compteur de copies de 1 (NbrCopiesocci −−) ;

6. dès qu’une consommation d’une copie de occi est observé (?consommation(occi ) -observed), l’observateur Obsretard décrémente son compteur de copies de 1(NbrCopiesocci − −) et passe dans l’état succès appelé retard_cal pour indiquerqu’une valeur de retard a été calculée (la valeur de retard calculée correspondà la valeur de l’horloge Xocci dans l’état retard_cal ; Et Obsretard revient à l’étatd’observation pour observer les autre copie de occi et les autre occurrences ;

7. une fois qu’il n’y a plus des copies de occi dans la chaîne d’acquisition (NbrCopiesocci =0), alors le compteur de copie de l’occurrence occi est réinitialisé à−1NbrCopiesocci :=−1 et arrête son horloge de calcul de durée (Xocci := −1) noté aussi reset Xocci . Lecontrôle (la vérification) de nombre de copie est fait uniquement après l’observa-tion des actions d’écrasement (!ecrasement(occi ) observed) ou de consommation(?consommation(occi ) observed).

L’automate de la figure 3.8 représente le fonctionnement de l’observateur de calculde retard Obsretard.

3.4 Synthèse

Nous avons présenté dans ce chapitre le cycle de vie d’une occurence occi dans unechaîne d’acquisition composée de plusieurs éléments Comp. Après avoir définit formel-lement une caractéristique temporelle à évaluer vis-à-vis des occurences de données


initial

observation

etat succes : retard_cal

NbrCopiesocci := −1

reset X

?consommation(occi ) observedNbrCopiesocci −−SI NbrCopiesocci = 0 ALORS(NbrCopiesocci := −1; reset Xocci ; )

i

?occi observedNbrCopiesocci −−

!production(occi ) observedNbrCopiesocci := 1Xocci := 0

!ecrasement(occi ) observedNbrCopiesocci −−;

SI NbrCopiesocci = 0 ALORS(NbrCopiesocci := −1; reset Xocci ; )

!occi observedNbrCopiesocci + +

!copie(occi) observedNbrCopiesocci + +

FIG. 3.8 – Observateur de retard Obsretard

3.4. Synthèse 69

occi, à savoir le “ retard ” et donner une démarche formelle d’observation du comporte-ment des occurences occi. Nous avons développé deux approches d’observation :

1. la première est à base de variables d’observation, ces dernièrs sont utilisées pourobserver les occurrences dans un ou plusieurs éléments Comp d’une chaîne d’ac-quisition. Ces variables d’observation varient selon les ou la caractéristique tem-porelle d’une occurrence qu’on désire évaluer ;

2. la seconde approche développée est basée sur la mise en place d’un élément dansla chaîne d’acquisition dédié à l’observation des occurrences, et plus précisementleur cycle de vie. L’élément dédié à l’observation est appelé observateur ou encoreobservateur d’occurrence.

Après avoir défini les bases théorique de l’évaluation de retard nous présentonsdans la suite l’approche de modélisation d’une chaîne d’acquisition à l’aide des auto-mates temporisés communicants IF.

Regrettez-vous les bons jours de minix-1.1, quand les hommes étaient deshommes et écrivaient leurs propres pilotes de périphérique?

Linus Torvalds, 5 octobre 1991, dans Free minix-like kernel sources for 386-AT

4Modélisation

APRÈS avoir défini les bases théoriques de l’évaluation du “ retard ”, nous présentons dans ce cha-pitre deux approches de modélisation de la chaîne d’acquisition et des éléments d’observation. La

première approche est une modélisation basée sur une spécification de la chaîne d’acquisition. La secondeapproche de modélisation est basée sur une implémentation de la chaîne d’acquisition. Les deux modèlessont développés à l’aide des automates temporisés communicants IF.

Plan du chapitre

4.1 Outil et langage de modélisation IF . . . . . . . . . . . . . . . . . . . . 724.1.1 Spécifités d’IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.2 Modélisation formelle d’une chaîne d’acquisition . . . . . . . . . . . . 734.2.1 Modélisation à partir d’un modèle de spécification . . . . . . . 744.2.2 Modèle d’une chaîne d’acquisition à partir d’une implémen-

tation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.2.3 Règles de modélisation . . . . . . . . . . . . . . . . . . . . . . . 804.2.4 Prise en compte des caractéristiques temporelles du système . 824.2.5 Respect des règles de la théorie . . . . . . . . . . . . . . . . . . 82

4.3 Observateur d’évaluation de retard et extraction des résultats . . . . . 854.3.1 Observateur d’évaluation de retard . . . . . . . . . . . . . . . 854.3.2 Problème d’explosion du nombre d’états . . . . . . . . . . . . 864.3.3 Extraction des valeurs de retard . . . . . . . . . . . . . . . . . . 87

4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

72 4. Modélisation

4.1 Outil et langage de modélisation IF

L’évaluation formelle de propriétés, ici des caractéristiques temporelles, passe endeux étapes :

• la première étape appelée conception d’un modèle ou aussi modélisation for-melle de la chaîne d’acquisition et des outils ou mécanismes d’évaluation de lacaractéristique que l’on souhaite évaluer (variables d’observation, observateurs),ici le retard.

• la deuxième étape appelée analyse consiste en l’exécution du modèle ou autre-ment dit la génération des états du système. L’analyse des états du système nousconduit à l’évaluation (calcul) de la caractéristique temporelle.

Pour l’évaluation des caractéristiques temporelles d’une chaîne d’acquisition dedonnées, il est nécessaire de modéliser cette dernière à l’aide d’un formalisme permet-tant une évaluation exhaustive des caractéristiques temporelles.

Dans la suite de ce travail nous avons choisi d’utiliser comme formalisme les au-tomates temporisés communicants et particulièrement le formalisme IF-2.0 [BGM02].Pour l’analyse, nous avons développé des scripts permettant d’extraire les valeurs desretards à partir du LTS généré par IF. Nous avons aussi utilisé la boite à outil CADP[GMLS07] pour la réduction des STEs.

4.1.1 Spécifités d’IF

IF (Intermediate Format) a été développé comme étant un format intermédiaireentre des langages de haut niveau, en particulier SDL et les outils de model checking.Il peut cependant être utilisé directement et offre un pouvoir d’expression semblable àSDL. Dans IF-2.0 (version utilisée pour l’étude), un système est décrit par un ensemblede processus sous forme d’automates temporisés communicants. La communication sefait de manière asynchrone via des signaux ou par partage de données. Au niveau d’unprocessus, les signaux sont gérés par file d’attente.

L’intérêt principal d’IF (dans notre étude) est la possibilité de générer facilementun modèle sémantique sous forme de systèmes à transitions étiquetées de l’ensembledes exécutions possibles du système. Il est en outre possible d’instrumenter le modèleafin de calculer des propriétés lors de la génération du LTS. La sémantique particu-lière d’IF permet de garantir la non-introduction de blocage temporel par compositionde modèles. Cette propriété, non disponible avec les automates temporisés classiquesbasés sur la notion d’invariant, facilite considérablement la modélisation de systèmescomplexes.

Le choix d’IF comme outil (langage) de modélisation et d’évaluation des caracté-ristiques temporelles pour la chaîne d’acquisition de données est fait non seulement àcause des spécifités décrites précédemment, mais aussi :

4.2. Modélisation formelle d’une chaîne d’acquisition 73

1. les automates IF sont temporisés ; ceci est indispensable pour la modélisation etl’évaluation des caractéristiques temporelles telles que le retard ;

2. le découpage en processus des automates IF représente un outil intuitif pour lamodélisation d’une chaîne d’acquisition de données qui est composées de plu-sieurs éléments Comp concurrents et communicants : les processus IF sont concur-rents et communiquent à l’aide de signaux ;

3. l’existence des observateurs dans l’outil IF permet une modélisation simple etefficace de l’observateur d’évaluation de retard, utilisé pour l’évaluation ;

4. quelques caractéristiques liées à l’outil IF :• le langage IF est puissant du point de vue de la modélisation (variables, ta-bleaux, types, boucles, conditionnelles) ;

• la sémantique temporelle d’IF est basée sur l’urgence ;• la génération d’un STEmais aussi d’un fichier de contenu des états (valeurs desvariables et des horloges) ; ce qui permet le calcul et l’évaluation des retards ;

• la possibilité d’utiliser le temps discret, aussi que le temps continu ;• la possibilité d’utiliser directement le LTS généré par IF avec d’autres outils devérification (par exemple CADP).

4.2 Modélisation formelle d’une chaîne d’acquisition

La conception d’un modèle d’une chaîne d’acquisition de données consiste en lamodélisation des éléments de la chaîne d’acquisition présentée dans la section 3.1 etles interactions entre ces éléments (la communication) à l’aide des automates tempori-sés. Pour la modélisation d’éléments de la chaîne d’acquisition, nous suivons les règlessuivantes :

1. un élément de la chaîne d’acquisition est modélisé par un ou plusieurs processusIF, ces processus modélisent l’ensemble des comportements de l’élément Compde la chaîne d’acquisition ;

2. la communication entre éléments (et donc entre processus IF) est modélisée parl’envoi et la réception de signaux (messages) IF ;

3. les registres et les zones mémoire pour la sauvegarde des données sont modéliséspar des variables IF.

Pour la modélisation de la chaîne d’acquisition de données à l’aide des automatestemporisés IF, nous suivons deux approches différentes :

1. la première consiste en la modélisation de la chaîne d’acquisition à partir d’unmodèle d’une spécification ;

2. la seconde consiste à modéliser la chaîne d’acquisition à partir d’un modèle d’im-plémentation d’un pilote d’équipement.

74 4. Modélisation

FIG. 4.1 – Chaîne d’acquisition des données

4.2.1 Modélisation à partir d’un modèle de spécification

Dans un premier temps, nous fournissons un modèle formel, à l’aide des automatestemporisés IF, pour la spécification d’une chaîne d’acquisition représentée par la figure4.1. Dans ce qui suit, nous proposons un modèle du système d’acquisition de donnéesqui permet d’évaluer les caractéristiques temporelles fournies par le pilote. Chaque élé-ment du système (capteur, interface, pilote d’équipement, application de contrôle) estreprésenté par un processus IF. La communication étant asynchrone en IF, une consul-tation de données est modélisée par l’envoi d’une demande de lecture puis l’attented’un message de retour. Afin de respecter les principes énoncés précédament, entre laréception de la demande et l’envoi de la réponse, il n’y a pas d’états intermédiaires.Nous présentons maintenant les paramètres principaux de chaque élément modélisé.

4.2.1.1 Automate du capteur et de l’application

Automate de l’élément capteur

Un capteur physique traite ou convertit des informations en provenance du pro-cédé. Les données sont produites suivant une loi de production définie. Dans notremodèle, on peut considérer des lois périodiques (avec ou sans gigue) (cf. figure 4.2),sporadiques (cf. figure 4.3) ou en rafale (cf. figure 4.4) [ALK05].

Remarque. Les automates présentés dans la suite présentent quelques exemples de mo-délisation parmi plusieurs cas de comportements possibles.

Un envoi en rafale est un envoi de plusieurs données périodiquement ou sporadi-quement sur une durée donnée.

Automate de l’élément application

L’application (cf. figure 4.5) est la partie logicielle qui consomme les données enconsultant les variables mémorisées par le pilote (appel à la primitive read). Nous consi-


initial envoiSet HorlogeC := 0 When HorlogeC = PC

!messageCA(occi)Set HorlogeC := 0

(a) sans gigue

initial attente

envoi

Set HorlogeC := 0

When HorlogeC = PCSet HorlogeG := 0Set HorlogeC := 0

deadline delayableWhen (HorlogeG >= gigueminAND HorlogeG <= giguemax)!messageCA(occi)Reset HorlogeG

(b) avec gigue

FIG. 4.2 – Automate du capteur physique périodique (PC : période capteur)

initial envoiSet HorlogeC := 0

deadline delayable

When (HorlogeC >= PCminAND HorlogeC <= PCmax)!messageCA(occi)

Set HorlogeC := 0

(a) sans gigue

initial attente

envoi

Set HorlogeC := 0

deadline delayableWhen (HorlogeC >= PCminAND HorlogeC <= PCmax)

Set HorlogeG := 0Set HorlogeC := 0

deadline delayableWhen (HorlogeG >= gigueminAND HorlogeG <= giguemax)!messageCA(occi)Reset HorlogeG

(b) avec gigue

FIG. 4.3 – Automate du capteur physique sporadique (PC : période capteur)

76 4. Modélisation

initial attente

attente ra f ale

envoi

Set HorlogeC := 0

deadline delayableWhen HorlogeC = PCSet HorlogeC := 0Set HorlogeRa f := 0; Task N := 0;

When HorlogeRa f = PR!messageCA(occi )Set HorlogeRa f := 0; Task N := N + 1;Provided N < Nbrra f ale

Provided N = Nbrra f ale

FIG. 4.4 – Automate du capteur physique avec un envoi en rafale périodique (PC :période capteur)

initial consommationSet HorlogeA := 0

deadline delayable

When (HorlogePA >= PAminAND HorlogePA <= PAmax)!lectureP()

Set HorlogeA := 0?consommation(occi )

(a) mode scrutation

initial consommation!lectureP(politiqueeven)

?consommation(occi )

(b) mode événementiel

FIG. 4.5 – Automate de l’application de contrôle (PA : période de l’application)

dérons ici une application monotâche. L’application peut fonctionner suivant deuxmodes, scrutation (cf. figure 4.5(a)) ou événementiel (cf. figure 4.5(b)). Leur logiqued’activation est semblable à celle décrite dans la partie précédente. Dans le mode scru-tation, l’application est caractérisée par la période de scrutation. Dans le mode événe-mentiel, l’application consomme les données lorsqu’elles sont produites par le pilote(c’est-à-dire l’application exécute toujours un read en attente active).

Remarque. Les automates présentés dans la suite présentent quelques exemples de mo-délisation parmi plusieurs cas comportements possibles.


initial

attente

initialisations

?messageCA(occi)!ecrasement(bu f f erIC)sauvegarde(occi , bu f f erIC, politique)

!copie(occi)

?lectureIC()!messageIC(bu f f erIC) to Pilote

FIG. 4.6 – Automate de l’interface de communication

4.2.1.2 Automate du pilote d’équipement

Le pilote d’équipement est constitué de deux parties, le pilote matériel appelé iciinterface de communication et le pilote logiciel ou pilote d’équipement proprement dit.

Automate de l’élément interface de communication

L’interface de communication (figure 4.6) récupère les données produites par le cap-teur physique et les sauvegarde suivant une politique donnée (FIFO,LIFO, ...) dans desregistres (caractérisés par leurs tailles) accessibles au pilote. Si les registres sont pleins(données non consommées), la politique d’écrasement peut suivre plusieurs lois (pertede la donnée, ou écrasement de la première ou de la dernière donnée mémorisée).

Remarque. Les automates présentés dans la suite présentent quelques exemples de mo-délisation parmi plusieurs cas de comportements possibles.

Automate du pilote d’équipement

Le pilote (figure 4.7) est la partie logicielle qui permet la prise en charge des don-nées stockées dans les registres et qui assure leur transmission à l’application. Pourgérer les données qui proviennent du capteur et les appels des applications (primitiveread), une architecture multitâche complexe peut être mise en œuvre. Dans cette étude,nous nous limitons à une architecture classique simple monotâche. La tâche consommeles données en lisant les registres de l’interface de communication puis les sauvegardedans une variable. Lors de la consultation par l’application, le pilote renvoie les infor-mations mémorisées dans la variable. Le fonctionnement du pilote est donc défini parla loi d’activation de la tâche (mode scrutation (figure 4.7(b)) et mode événementiel(figure 4.7(a)) et par la politique de stockage des informations. En mode scrutation, lepilote consulte périodiquement les registres de l’interface de communication. En modeévénementiel, le pilote fixe une politique d’envoi à l’interface de communication. Àchaque nouvelle donnée, l’interface de communication vérifie une condition d’envoifixée par le pilote et envoie, si nécessaire, les données au pilote. Pour les politiques destockage, on distingue la taille des buffers de mémorisation des données, la politiquede stockage (FIFO ou LIFO) et les politiques d’écrasement en cas de registre plein.

78 4. Modélisation

initial

attente

?lectureP(politiqueeven)Set HorlogeP := 0

?messageIC(occi)Suivant politiqueevenf orget(occi)

OU !consommation(occi ) to Application

deadline delayable

When (HorlogeP >= PminAND HorlogeP <= Pmax)

!lectureIC()Set HorlogeP := 0

(a) mode scrutation avec l’interface de communication et mode événemen-tielles avec l’application de contrôle

initial

attente

Set HorlogeP := 0

?messageIC(occi)!ecrasement(bu f f erP)sauvegarde(occi , bu f f erP, politique)

!copie(occi)

?lectureP()!consommation(bu f f erP) to Application

deadline delayable

When (HorlogeP >= PminAND HorlogeP <= Pmax)

!lectureIC()Set HorlogeP := 0

(b) mode scrutation avec l’interface de communication et avec l’application decontrôle

FIG. 4.7 – Automate de pilote d’équipement (Pmax et Pmin : période de pilote minimaleet maximale)

Remarque. L’automate présenté dans la suite présente quelques exemples de modélisa-tion parmi plusieurs cas de modélisation (comportement) possibles.

4.2.2 Modèle d’une chaîne d’acquisition à partir d’une implémentation

La deuxième approche consiste en la modélisation à partir d’une implémentationréelle d’un pilote d’équipement (de la chaîne d’acquisition).

4.2.2.1 Structure d’une implémentation d’un pilote d’équipement

Dans cette partie la modélisation de la chaîne d’acquisition en automate tempo-risé IF, se base sur une implémentation d’un pilote d’équipement. Cette implémenta-


FIG. 4.8 – Structure d’une chaîne d’acquisition réel

tion est réalisée sous l’environnement TornadoTMavec le système d’exploitation tempsréel VxWorks R©. Ce dernier fournit les services temps réel (boîte aux lettres, gestion detâches, sémaphores) nécessaires au développement d’applications multitâches et d’unsystème d’entrées/sorties (IOS) pour le développement de pilotes intégrés.

Afin d’évaluer l’implémentation, on travaille dans un premier temps par simula-tion. L’application n’étant pas reliée physiquement à un réseau ou aux capteurs, onsimule l’environnement matériel et spécialement le capteur et donc l’arrivée des don-nées à l’aide d’une ou plusieurs tâches dédiées (SimulSensor), ces tâches simulent aussila gestion des interruptions et des registres des périphériques.

Côté application de contrôle (utilisateur), on a conçu l’architecture du programmequi appelle le pilote via l’IOS. Ce programme est composé d’une ou plusieurs tâches quiréalisent la lecture (read_value). L’architecture du système est représentée par la figure4.8.

80 4. Modélisation

4.2.2.2 Structure d’un modèle d’un pilote d’équipement

Cette partie présente les principes demodélisation du systèmed’acquisition de don-nées en IF. Chaque élément du système est modélisé par un ou plusieurs processus IF.Le pilote d’équipement est modélisé par un ensemble de processus correspondant auxfonctions que l’on trouve dans un pilote d’équipement classique (read(), open(), close()...).On trouve aussi un processus correspondant à la tâche périodique DriverProcess() encharge de l’acquisition des données. Enfin, les processus (DrvInstall, DevAdd...) corres-pondent aux primitives classiques d’installation du pilote et des périphériques. Ils sontcréés selon les besoins exprimés par l’application, de la mêmemanière que les fonctionscorrespondantes sont appelées par l’application. Les capteurs physiques et l’interfacede communication sont modélisés par un processus qui simule le fonctionnement d’unou plusieurs capteurs appelé SimulSensor(). Chaque tâche de l’application temps réelest modélisée par un processus qui lit les données suivant une loi donnée (périodique,sporadique...). L’architecture dumodèle IF de notre chaîne d’acquisition de données estreprésentée par la figure 4.9.

4.2.3 Règles de modélisation

Lamodélisation de la chaîne d’acquisition en IF à partir d’une implémentation d’unpilote d’équipement est réalisée avec les règles suivantes :

1. chaque élément de la chaîne d’acquisition est modélisé par un ou plusieurs pro-cessus IF. Chaque fonction et chaque tâche sont modélisées par un processus IF ;l’appel à une fonction est modélisé par une instanciation du processus qui la mo-délise ; une fois l’appel traité (“ return ”), l’instance du processus se termine ;

2. pour les applications de contrôle et les capteurs, des processus IF modélisent lefonctionnement de ces derniers, comme vu en section 4.2.1 ;

3. dans le cas de la modélisation à partir d’une implémentation d’un pilote d’équi-pement, l’ordre de l’instanciation est le suivant : à chaque ajout de périphérique(DevAdd) un processus capteur (SimulSensor) est instancié et fonctionne jusqu’àl’enlèvement du périphérique (DevRemove). Après l’installation du pilote (Dr-vInstall) un processus driverProcess modélisant la tâche driverProcess est instancié.Il fonctionne jusqu’à la désinstallation du pilote d’équipement DrvUninstall. Lesfonctions DevAdd, DevRemove, DrvInstall, open, read sont instanciées au besoin ets’arrêtent juste après l’accomplissement de la fonctionnalité. Les processus Dri-verProcess, Read_Value, SimulSensor sont instanciés et restent activés jusqu’à leurdésactivation par l’application de contrôle (l’application de contrôle représente leprocessus père de tous les processus de la chaîne d’acquisition de données) ;

4. les registres et les zones mémoires de la sauvegarde des données sont modéli-sés par des variables et des structures de données en IF. La sauvegarde dans les


FIG. 4.9 – Structure de modèle IF d’une chaîne d’acquisition réelle

82 4. Modélisation

registres et les zones mémoires est modélisée par une simple affectation de ladonnée dans leurs variables respectives ;

5. la communication entre éléments de la chaîne d’acquisition estmodélisée par l’en-voi et la réception des signaux IF ;

6. dans le cas de la modélisation à partir d’une implémentation d’un pilote d’équi-pement, la boîte aux lettres de communication entres les tâches SimulSensor et latâche driverProcess est modélisée par l’envoi et la réception des signaux dans laboite aux lettres associée au processus IF. Les données en provenance du capteursont sauvegardées par driverProcess dans des registres partagés accessibles à tra-vers read ;

7. la politique de sauvegarde (FIFO, LIFO, ...) dans les registres est modélisée direc-tement à travers une description en IF ;

8. la production d’une occurrence occi par un capteur se traduit dans le modèle IFpar un envoi de signaux par le processus capteur ayant comme paramètre l’occur-rence ;

9. la consommation d’une occurrence occi par l’application de contrôle se traduitdans le modèle IF par une réception d’un message par le processus application ouRead_value ayant comme paramètre l’occurrence.

4.2.4 Prise en compte des caractéristiques temporelles du système

Dans IF, les transitions se franchissent dans une durée nulle. Le temps n’est consi-déré qu’au travers des dates de tir de transition. Il est possible de fixer via des horloges,des intervalles au sein desquels les transitions peuvent et doivent être franchies (cf.2.2.3). La modélisation des lois de production (périodique avec ou sans gigue, spora-dique, rafales) ne pose donc pas de problème particulier. La modélisation d’une duréede traitement (liée au temps d’exécution des tâches) nécessite la mise en place d’étatsd’attente dans les différents processus. La durée d’attente modélise dans cet état la du-rée du traitement (cf. figure 4.10, l’état Actions est un état instable).

Les durées d’attente sont, dans le cas de l’étude, facile à évaluer, car par hypothèse,le pilote est ordonnancé comme une tâche de forte priorité non préemptible.

4.2.5 Respect des règles de la théorie

Les processus IF (capteur, application, pilote d’équipement, interface de commu-nication) modélisent les éléments Comp de la chaîne d’acquisition, présentés dans lechapitre précédent. Ces processus IF doivent respecter les règles définies par la théorieproposée.

1. Règle : une chaîne d’acquisition de données d’un système de contrôle de processusest composée d’un ensemble d’entités communicantes, notées Comp. Un élément


initial

attente

duree

actions

Initialisation

deadline delayableWhen (HorlogeProc >= PminAND HorlogeProc <= Pmax)Set HorlogeProc := 0Set HorlogeDuree := 0

deadline delayableWhen (HorlogeDuree >= PDureeminAND HorlogeDuree <= PDureemax)Reset HorlogeDuree

Actions

FIG. 4.10 – Automate d’un processus IF avec une prise en compte d’une durée d’exécu-tion

Comp est un composant qui reçoit et émet des flots de données notés occ (occireprésente la iéme occurrence du flot occ véhiculé) ainsi que des flots de contrôlenotés cont.Mise en place : tout processus IF représente un élément de la chaîne d’acquisi-tion. Tout processus est un Comp. La réception ou l’envoi par un Comp d’uneoccurrence de occi se traduit au niveau d’un processus IF par un envoi ou uneréception d’un message (signal) contenant le paramètre occi (le message cotienttous simplement le numéro de l’occurence occi, c’est-à-dire i). De même pourl’envoi et la réception des contrôles cont entre les processus se fait par envoiet réception des messages contenant l’information du contrôle (reading(data),msg_ackDrvInstall(), msg_ackDevAdd(), msg_ackopen( f d_sensor, result)).Vérification : cette règle est assurée par construction (réutilisation de processustype IF). Lors de la construction du modèle, aucune règle de vérification automa-tique n’est développée pour le moment.

2. Règle : un élément Comp de la chaîne d’acquisition de données des systèmes decontrôle de processus peut être soit une source, soit un puits ou un élément inter-médiaire.Mise en place : puisque les flots des occurrences sont produits par des processuscapteurs, alors ces derniers représentent des éléments Comp sources. Ces flots sontacheminés jusqu’aux processus applications de contrôle qui représentent des élé-ments Comp puits.Vérification : cette règle est assurée par construction (réutilisation de processus

84 4. Modélisation

type IF). Lors de la construction du modèle, aucune règle de vérification automa-tique n’est développée pour le moment.

3. Règle : une chaîne d’acquisition est composée de plusieurs éléments Comp. Ellepossède au moins un élément Comp de type source (producteur), au moins un élé-ment Comp de type puits (consommateur), et peut avoir un ou plusieurs élémentsComp de type intermédiaire. De plus une occurrence n’est produite que par un seulélément source.Mise en place : unmodèle de système en IF doit obligatoirement contenir au moinsun processus modélisant un élément Comp source (ici un capteur) et au moinsun processus modélisant un élément Comp puits (ici une application). Le modèleIF peut avoir un ou plusieurs processus Comp intermédiaire (par exemple les pri-mitives du pilote d’équipement). Une occurrence occi est produite (envoyer) uneet une seule fois par un unique processus capteur. Dans le cas où un élémentComp source (par exemple un capteur) est modélisé par plusieurs processus IF,une occurrence occi est produite (envoyée) une et une seule fois par un seul de sesprocessus.Vérification : il suffit de vérifier que le compteur d’occurence est bien incrémentéà chaque envoi. Il faut s’assurer de cette règle en regardant les processus modéli-sant les capteurs et vérifier qu’ils ne produisent pas le même flot de données. Sile capteur est modélisé par plusieurs processus, il faut également s’assurer qu’unseul d’entre eux produit (envoi le message contenant) l’occurrence. On considèredonc que ces règles sont vérifiées par analyse du code IF. On ne considère iciqu’un seul capteur et qu’un seul flot de données.

4. Règle : un flot de données occ est produit par un élément source et il est ache-miné par les éléments intermédiaires jusqu’aux éléments puits. Un flot de donnéess’écoule de la source aux puits. De ce fait, il ne peut pas revenir à un Comp intermé-diaire qui l’a déjà traité. De cette hypothèse, on déduit en particulier qu’un Compne peut pas renvoyer un flot sur lui même (pas de re-bouclage).Mise en place : une même copie d’une occurrence occi ne peut jamais être reçuepar le même processus une deuxième fois. Le flot des données navigué par lesmessages entre les processus IF ne peuvent pas re-boucler dans le système, il estunidirectionnel d’un processus capteur vers un processus application de contrôle.Vérification : cette règle est assurée par analyse du code IF pour vérifier le non re-bouclage du flots de données.

5. Règle : à la réception d’une occurrence occi, un élément Comp peut effectuer lestrois actions suivantes sur une occurrence occi :• “ Transmit ” : renvoyer immédiatement ou après un délai l’occurrence à unautre élément Comp.

• “ Save ” : sauvegarder l’occurrence dans un registre ou une zone mémoire selonune politique d’écriture donnée (FIFO, LIFO...).

• “ Forget ” : ne pas considérer l’occurrence (perte de l’information).

4.3. Observateur d’évaluation de retard et extraction des résultats 85

Mise en place : À la réception d’un message contenant une occurrence occi, un pro-cessus peut la transmettre à un autre processus, la sauvegarder (créer une copie)dans une variable (registre) ou ne pas la considérer. Dans la suite de la modélisa-tion, on ne traite pas ce dernier cas.Vérification : les automates des figures 3.3, 3.4 et 3.5 simule (relation de simulation)l’automate du processus IF avec abstraction de son comportement vis-à-vis desoccurrences occi, cette règle est considérée comme satisfaite.

6. Règle : l’acheminement des flots de contrôle et des flots de données entres les élé-ments de la chaîne d’acquisition est considéré comme sûr. C’est-à-dire durant lacommunication entre les éléments Comp, un flot (de contrôle cont ou de donnéesocc) ne peut subir aucune modification de contenu, ni de perte, ni un délai decommunication infini.Mise en place : la communication interprocessus IF utilisée pour modéliser la com-munication entre les éléments de la chaîne d’acquisition est initialisée commesûre, c’est-à-dire sans perte de message et ses délais de communication (envoide message) sont finis, les files d’attente des processus peuvent stocker tous lesmessages quelquesoit leur nombre.Vérification : on admet que la communication inter-processus IF est sûre, son im-plémentation dans IF satisfaisant cette règle. On peut aussi vérifier cette règle àl’aide d’un observateur qui vérifie si une occurrence envoyée par un processus estbien reçue par son destinataire.

7. Règle : une fois qu’il n’y a plus de copies d’une occurrence occi dans la chaîned’acquisition de données, aucun processus de la chaîne d’acquisition ne peut plusenvoyer ou recevoir un message contenant l’occurrence occi.Mise en place : une fois que la chaîne d’acquisition modélisée par des processus IF,le STE généré doit vérifier les propriétés suivantes :• les propriétés exprimées par les formules (3.2, 3.3, 3.4, 3.8 du chapitre 3, à pro-pos du cycle d’une occurrence.

• L’absence du blocage, attente bloquante d’un message qui n’arrive jamais ouun blocage temporel.

Vérification : ces règles sont déjà exprimées sous la forme des formules en CTL,leur vérification se réduit à utiliser le model cheking avec la boîte à outils CADPpour vérifier ses formules sur le STE du système généré par IF.

4.3 Observateur d’évaluation de retard et extraction des résultats

4.3.1 Observateur d’évaluation de retard

L’observateur est utilisé pour l’évaluation du retard dans le cas de l’approche demodélisation à partir d’une implémentation de pilote d’équipement.

86 4. Modélisation

L’observateur de retard est un observateur IF qui, au lieu de vérifier une propriétéet de donner le résultat sous la forme (échec / succès), fournit un résultat de type valeursde retard. L’observateur de retard observe les occurrences de la donnée. Dès qu’uneoccurrence est reçue par l’application, il passe dans l’état “ succès ” pour signaler qu’ila détecté un retard possible. L’observateur de retard ne contient pas d’état “ échec ”.L’observateur de retard observe les évènements nécessaires pour l’évaluation de retard.Ces évènements sont :

• la production d’une occurrence occi par un capteur, se traduit dans le modèle IFpar l’observation de l’envoi de message !msgSensor(message), message contientsimplement occi, la donnée n’est considérée qu’au travers du numéro de l’occur-rence (en effet, la valeur de la donnée ne nous intéresse pas dans cette étude) ;

• les consommations d’une occurrence occi par les applications read_value, quise traduit dans le modèle IF par l’observation de la réception du message?msg_reading(message), message contenant occi ;

• tous les envois et les réceptions des occi entre les processus IF : en effet, toutecommunication de occi est à surveiller pour suivre son évolution ;

• pour observer toutes les sauvegardes (création des copies) et écrasement des occidans les processus, nous introduisons un envoi d’un message !copie(occi) lorsd’une sauvegarde de occi et d’un message !ecrasement(occi ) lors d’un écrasementd’une copie de occi.

4.3.2 Problème d’explosion du nombre d’états

Àpartir dumodèle décrit à l’aide des automates temporisés, l’outil IF génère un STEqui traduit l’ensemble du comportement du système à évaluer. Ce STE est le produitsynchrone parallèle de tous les processus IF du système et de l’observateur de retard.Le nombre d’états de STE peut exploser, quatre raisons ont été identifiées :

1. une variable qui possède un domaine de valeur infini, donne lieu à un STE infini :vu que le comportement de notre système doit être fini vis-à-vis du retard, les va-riables ont obligatoirement un domaine de valeur fini (par exemple, le retard nepeut pas dépasser une valeur retardmax ). Une seule variable possède un domainede valeur infini et pose un problème d’explosion du nombre d’états c’est la va-riable i qui contient le numéro des occurrences occi. Dans la suite nous proposonsune solution à ce problème ;

2. une horloge qui ne s’arrête pas donne lieu à un STE infini. Par principe de modé-lisation, les automates ne contiennent pas d’horloges qui ne se réinitialisent pas.Les horloges de calcul de retard des occurrences Xocci sont arrêtées une fois qu’iln’y a plus aucune copie de l’occurrence occi dans le système Reset Xocci ;

3. dans certains cas où une configuration présente beaucoup d’entrelacements, lenombre d’états explose. Dans ce cas on ne parle pas d’explosion du STE. Le STEest fini mais les ressources (mémoire, unité de calcul) de la machine utilisée pour

4.3. Observateur d’évaluation de retard et extraction des résultats 87

générer le STE ne sont pas suffisantes pour générer le STE dans sa globalité. Onparle d’une exhaustivité non atteinte ; des solutions pour pallier ce problème sontproposées dans la suite du document ;

4. le nombre d’occurrences simultanées dans le système peut générer un STE infini,dans le cas ou ce nombre n’est pas borné : dans cette étude on ne considère et onne traite que les systèmes finis.

4.3.2.1 Compteur d’occurrences

Les numéros des occurrences sont utilisés pour identifier l’occurrence. Le numéroest utilisé pour l’observation et le calcul de retard. Une fois qu’il n’y a plus de copiesde l’occurrence occi dans le système, le numéro de l’occurrence n’a plus d’utilité etpeut être réutilisé par une nouvelle occurrence. Ceci permet de réduire le domaine devaleur de la variable du numéro des occurrences i au nombre maximum d’occurrencesdistinctes qu’on peut avoir dans le système en même temps. Ce nombre d’occurrencesdistinctes maximal est fini sous la condition suivante :

• une occurrence occi ne peut pas rester infiniment dans la chaîne d’acquisition dedonnées ; une occurrence est soit acheminée en temps borné à l’application decontrôle (il existe toujours un retardmax pour chaque occurrence occi) soit écraséepar une nouvelle occurrence occj dans le registre (les registres ont une taille finie).

Donc, les numéros des occurrences peuvent êtres réutilisés pour numéroter les nou-velles occurrences une fois qu’il n’existe plus aucune copie de l’occurrence dans le sys-tème Nbreocci = 0.

4.3.2.2 Explosion du nombre d’états

Dans certaines situations, les ressources de la machine ne suffisent pas pour générerle STE dans sa globalité à cause du nombre d’états important (à cause du nombre de caset d’entrelacements possibles). Afin de résoudre ce problème, il est possible de mettredes priorités sur les transitions des automates. Ceci revient à faire une réduction d’ordrepartiel. Cette approche permet de réduire considérablement le nombre d’états et destransitions du STE généré. Si cette réduction n’est pas applicable à l’application visée,le problème d’explosion reste donc du domaine des outils de modélisation et d’analyseet sortent du champs de cette étude.

4.3.3 Extraction des valeurs de retard

Le STE généré est un diagramme d’états transition et les valeurs de retard possiblessont les valeurs des horloges Xocci dans l’état retard_cal. Pour récupérer les valeurs deretard possibles, à partir du STE nous récupérons le numéro de l’occurrence occi pour

88 4. Modélisation

lequel on a évalué un retard ; On récupère ensuite les valeurs de l’horloge correspon-dante (Xocci). Des scripts ont été mis au point pour automatiser cette tâche sur le STE.

4.4 Conclusion

Une fois la modélisation de la chaîne d’acquisition en IF terminée, et l’identifi-cation des points d’observation et l’intégration des outils d’observation (soit des va-riables d’observation, soit de l’observateur) relatifs à la caractéristique temporelle àévaluer, ici le retard , on peut passer à une étape d’analyse sur des cas d’études diffé-rents. Ceci permet d’un coté de valider l’intérêt de l’approche développée tout au longde cette thèse vis-à-vis d’autres approches d’évaluation (RMA, calcul mathématique).D’un autre côté, des expérimentations doivent montrer l’intérêt de cette évaluation descaractéristiques temporelles des chaînes d’acquisition, ici le retard.

Troisième partie

Études de cas (expérimentation)

La théorie, c’est quand on sait tout et que rien ne fonctionne. La pratique, c’estquand tout fonctionne et que personne ne sait pourquoi. Ici, nous avons réunithéorie et pratique : rien ne fonctionne... et personne ne sait pourquoi !

Albert Einstein

5Évaluation et expérimentation

DANS ce chapitre, nous présentons à travers plusieurs cas d’études les résultats d’évaluation de retard,mais aussi l’intérêt de ce travail de thèse. Les cas d’études présentés dans ce chapitre s’organisent

de la manière suivante : dans un premier temps on évalue le retard en utilisant la première approchede modélisation, celle basée sur une spécification de la chaîne d’acquisition couplée à observation baséesur les variables d’observation et utilisant du temps discret dans l’outil IF. Ensuite dans un deuxièmetemps, nous utilisons l’approche de modélisation basée sur une implémentation de la chaîne d’acquisitioncouplée avec une observation à l’aide d’observateur de retard. Cette deuxième évaluation est réalisée entemps discret et en temps continu (dense) dans l’outil IF.

Plan du chapitre

5.1 Expérimentations : exemples et valeurs de retard . . . . . . . . . . . . 925.1.1 Évaluation du retard à partir d’un modèle de spécification . . 925.1.2 Évaluation du retard avec le modèle à partir d’une implé-

mentation réel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.2 Langage de retard et utilisation de l’approche pour la configurationdes pilotes d’équipement . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.2.1 Exemple 1 : exemple simple . . . . . . . . . . . . . . . . . . . . 1015.2.2 Exemple 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.2.3 Exemple 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.2.4 Exemple d’utilisation du lagage de retard . . . . . . . . . . . . 101

92 5. Évaluation et expérimentation

5.1 Expérimentations : exemples et valeurs de retard

Afin de valider l’interêt et d’illustrer l’utilisation des modèles proposés, nous pré-sentons dans cette section l’évaluation du retard en fonction de plusieurs paramètresdu système. L’évaluation du retard est réalisée en utilisant les deux modèles présen-tés dans le chapitre précédent (chapitre 4). Dans un premier temps, on commence parl’évaluation du retard en utilisant le modèle de la chaîne d’acquisition à partir d’unespécification (section 4.1). Dans un deuxième temps en utilisant le modèle d’une implé-mentation d’une chaîne d’acquisition (section 4.2). Dans ce dernier cas, nous utilisonsdeux approches d’IF : le temps discret et le temps continu.

5.1.1 Évaluation du retard à partir d’un modèle de spécification

Dans cette partie nous utilisons le modèle IF d’une spécification de la chaine d’ac-quisition de données présenté dans la section 4.1.

5.1.1.1 Retard en fonction de la période du pilote d’équipement (un cas simple)

Nous présentons un premier exemple volontairement simple. Les paramètres dusystème d’acquisition de données sont fixés aux valeurs suivantes :

La production des données par le capteur physique est périodique avec une périodefixe Pc de 10 unités de temps. La taille du registre de l’interface de communication estde 1. Le pilote travaille en mode scrutation. La période Pp n’est pas déterminée a priori.Le pilote gère un buffer de 1 élément. La durée d’exécution du pilote (Cp) est considéréecomme constante et égale à 2 unités de temps. La période de scrutation Pa de l’applica-tion est régulière de 20 unités de temps (sa durée d’exécution est nulle). Enfin, on consi-dère que toutes les activités (capteur, pilote, application) démarrent au même instant.On cherche à quantifier pour cette architecture, les critères de qualité de service liésaux retards (retard maximal et retard minimal). Les paragraphes suivants présententles résultats obtenus grâce à la méthodologie présentée ainsi que leurs justificationsanalytiques.

Évolution du retard en fonction de la période du pilote d’équipement

La figure 5.1 présente l’évolution du retard minimal et du retard maximal en fonc-tion de la période de scrutation du pilote d’équipement. Pour le retard minimal, onconstate trois valeurs possibles égales à 0, 10 et 20 unités de temps. Nous allons main-tenant expliquer cette courbe et justifier des valeurs obtenues par une approche analy-tique.

5.1. Expérimentations : exemples et valeurs de retard 93

0

5

10

15

20

25

30

35

40

45

5 10 15 20 25 30 35

Ret

ard

Periode

retard maxretard min

Pc+Pp+CpPc+Pa+Cp

FIG. 5.1 – Retards minimaux et maximaux en fonction de la période du pilote

Approche analytique : mise en équation

Un retard nul correspond à l’enchaînement de la production, de la scrutation parle pilote (+durée d’exécution) et de la consommation par l’application. Ces correspon-dances peuvent être mises en équation :

n1 ∗ Pc = (n2 ∗ Pp) + Cp = n3 ∗ Pa (5.1)

où :• n1 ∗ Pc représente les différentes dates de production• Cp représente le temps de traitement du pilote• (n2 ∗ Pp) + Cp représente les différentes dates de production par le pilote• n3 ∗ Pa représente les différentes dates de consommation par l’applicationIl s’agit de savoir si l’équation précédente possède des solutions entières positives

en n1, n2 et n3. La résolution de ce type d’équations (dites diophantiennes) est relative-ment simple (basée sur le calcul du plus grand commun diviseur). Si une solution existealors la correspondance est possible et le retard est nul. Les résultats sont cohérents avecla génération exhaustive.


Exemple 5.1.1. Pour Pp = 5 l’équation devient : 10n1 = 5n2 + 2 = 20n3, et ne possèdepas de solution entière positive, puisque pour tout n2 entier positive 5n2 + 2 ne peut être unmultiple entier de 10, donc le retard est différent de 0Pour Pp = 6 l’équation devient : 10n1 = 6n2 + 2 = 20n3, et possède des solutions entièrespositives en n1 = 2, n2 = 3, et n3 = 1. donc le retard est égale 0.

Dans les autres cas, le pilote ne se synchronise pas avec le capteur et l’application.Dans ce cas, au mieux, le retard est de 10 unités de temps (temps passé dans le registre).Il existe un cas particulier pour les multiples de 20. Dans ce cas, on note un retard mi-nimal et maximal très proche, l’écart est égal à 2 unités de temps (équivalent à la duréed’éxécution du pilote d’équipement Cp). En effet, dans ce cas, on note un séquencementparticulier et cyclique. Dans tous les autres cas, du fait de la désynchronisation entre lesdifférentes activités, le pilote arrive toujours au moins une fois à récupérer et fournirune donnée avec un retard de 10 unités de temps.

Approche analytique : RMA (Rate Monotonic Analysis)

Pour l’exemple présenté, il est intéressant de comparer les résultats obtenus à ceuxissus d’une analyse du pire temps de réponse, basé sur les principes du RMA. Nous al-lons maintenant donner le principe d’évaluation des retards avec des hypothèses sim-plificatrices liées à l’exemple traité (périodicité, durées constantes).

1. A priori, le retard minimal est nul et correspond à la synchronisation de la pro-duction, de l’acquisition par le pilote et par l’application

2. Pour le retard maximal, on distingue le cas où le pilote possède une période infé-rieure, de celui où la période est supérieure à celle de l’application.• Dans le premier cas, au pire, la donnée est consommée par le pilote juste avantd’être modifiée par le capteur. Son retard est alors égal à la période du capteur,notée Pc. Ensuite, l’application peut la consommer, au pire, juste avant qu’ellesoit, à nouveau, modifiée par le pilote, soit un retard maximal entre deuxmisesà jour égal à Pp. Au final, le retard maximal est égal à :

Pc + (Pp + Cp) (5.2)

• Dans le deuxième cas, le pilote n’arrive plus à fournir des données assez ra-pidement pour l’application. Dans ce cas, s’il fournit une information, elle estconsommée, au pire, à la prochaine activation de l’application (retard de Pa).En intégrant le retard maximal dû au capteur (cf. ci-avant), au final, la donnéepossède un retard maximal égal à :

Pc + Pa + Cp (5.3)

Dans l’exemple présenté par la figure 5.1, ces résultats correspondent aux droites(RMA) de la figure 5.1. On voit alors aisément l’intérêt d’une approche exhaustive pour


obtenir des résultats réalistes : notament pour les période du pilote d’équipement Ppentre 13 et 20 où le retard est égal à 22 unités de temps alors que RMA donne uneenveloppe plus grande.(par exemple 32 pour la période de 20).

Analyse et conclusion

On remarque évidemment que les propriétés de qualité de service se dégradent avecl’augmentation de la période de scrutation du pilote. Néanmoins, ce n’est pas en scru-tant plus vite que les performances sont obligatoirement meilleures. Enfin, on trouvegénéralement un point limite égal à la période de production du capteur physique. Cetexemple simple a été présenté dans le but de valider l’intérêt de l’approche proposée etaussi de l’illustrer.

Il est à noter que pour cet exemple, les résultats présentent beaucoup d’irrégularités.Cela illustre que la qualité de service fournie par un pilote ne suit pas une loi linéaireet qu’il peut être difficile de la prédire analytiquement, même si chaque valeur trouvéepeut être justifiée analytiquement au prix d’un travail de réflexion important. Ceci jus-tifie, a posteriori, l’utilisation de modèles exhaustifs pour les caractériser. Il est à noterque d’autres paramètres tels que la prise en compte de politiques de stockage augmentela complexité des modèles manipulés et la forme des résultats obtenus. Il apparaît alorsdifficile de produire ou d’estimer a priori un modèle simple et réaliste des propriétésde qualité de service fournie par un pilote d’acquisition.

Enfin, cette première étude démontre que la qualité de service fournie par un com-posant logiciel de type pilote d’équipement ne peut être fournie sans connaissancede son environnement d’exécution ici le capteur et l’application.

5.1.1.2 Retard en fonction de la période du pilote d’équipement

Nous présentons maintenant l’utilisation des modèles dans des contextes d’utilisa-tion plus complexes où l’intérêt de l’approche est encore plus pertinent.

L’exemple précédent peut être, pour bien des raisons, considéré comme élémen-taire. Tout d’abord, le temps de traitement de l’application a été négligé. Il est pris encompte pour l’obtention des retards présentés dans la figure 5.2(a) (considéré commeconstant et égal à 7 unités de temps). Le cas précédeent est très particulier en raison dela synchronisation des différentes entités du système. La figure 5.2(b) présente les résul-tats obtenus pour une période de consommation de 15 unités de temps. Enfin dans descas réalistes, les paramètres temporels considérés ne sont pas constants, mais variablestout en restant bornés. La figure 5.3(a) représente les résultats obtenus pour une du-rée d’exécution de l’application variable dans l’intervalle [6,7]. Pour la figure 5.3(b), onconsidère en plus que la durée d’exécution du pilote est elle aussi variable et comprisedans l’intervalle [1,2].


Influence de la période de l’application

0

5

10

15

20

25

30

5 10 15 20 25 30 35

Ret

ard

Periode


(a) période application : 20 unités de temps

0

5

10

15

20

25

30

5 10 15 20 25 30 35

Ret

ard

Periode


(b) periode application : 15 unités de temps

FIG. 5.2 – Évolution du retard vis-à-vis de la période de scrutation du pilote pour diffé-rentes périodes de l’application.

Comparons, les figures 5.1 et 5.2(a). Le cas de la figure 5.1 est en fait un cas très par-ticulier, car il offre de nombreux points de synchronisation (entre le capteur, le piloteet l’application) où le choix qui est fait dans l’ordre des opérations, à un même ins-tant, va entraîner des résultats totalement différents. Ce phénomène explique la formecomplexe des résultats qui sont détaillés dans la section précédente. Les courbes de lafigure 5.2(a) sont plus lissées. Le retard minimal est maintenant de 7 (lecture toutes les(20k + 7) unités de temps d’une donnée a priori produite par le capteur toutes les (20k)unités de temps). Quelques points remarquables demeurent, correspondants à un sé-quencement particulier, en particulier 10 et 20 où la synchronisation entre l’application,le capteur et le pilote amènent à l’existence d’un séquencement unique entraînant unretard possible unique de 7 unités de temps

Sur la figure 5.2(b), le fait de changer la période de l’application de 20 unités detemps à 15 unités de temps entraîne des changements considérables au niveau, biensûr, des valeurs obtenues, mais aussi de la forme de la courbe.

Influence de durée d’exécution en intervalle

La figure 5.3(a) est encore plus lissée, on retrouve comme uniques points particu-liers, les points de synchronisation 5, 10 et 20. La figure 5.3(b), est très semblable à lafigure 5.3(a), à part quelques petites différences de +/− 1 liés à l’influence de l’inter-valle [1, 2]


0

10

20

30

40

50

5 10 15 20 25 30 35

Ret

ard

Periode


(a) durée d’exécution : application [6, 7], pilote 2

0

10

20

30

40

50

5 10 15 20 25 30 35

Ret

ard

Periode


(b) durée d’exécution : application [6, 7], pilote [1, 2]

FIG. 5.3 – Évolution du retard vis-à-vis de la période de scrutation du pilote pour desdurées d’exécution définies sous la forme d’intervalle.

Conclusions

Nous avons sur cet exemple montré la grande richesse d’expression des modèlesproposés. En particulier, il est possible de prendre en compte l’existence de propriétéstemporelles définies sous forme d’intervalles. Les résultats des approches analytiquesn’ont généralement pas de formes clauses et ne présentent donc pas d’intérêt particu-lier vis-à-vis de ceux obtenus par analyse exhaustive. L’intérêt de l’analyse exhaustiveest de concentrer le travail sur la création des modèles alors que pour une analyse clas-sique un travail important doit être fait pour l’obtention des résultats. Bien entendu, leproblème majeur de l’analyse exhaustive est le risque d’explosion combinatoire.

5.1.1.3 Retard en fonction de la période du pilote d’équipement et de la période de l’appli-cation

L’intérêt de l’évaluation du retard est de trouver le bon compromis entre les para-mètres du système et le retard. Sur un paramètre (période de pilote d’équipement), ilest simple sur la courbe du retard de trouver la meilleure période pour un retard maxi-mal fixé à l’avance. Dans l’exemple qui suit 5.4, nous avons essayé de tracer les valeursdes retards en faisant varier deux paramètres du système, à savoir la période du piloted’équipement et la période de l’application.

Les courbes de la figure 5.4 permettent de fixer les périodes de l’application et dupilote d’équipement en satisfaisant les contraintes exprimées sur le retard et en optimi-sant l’utilisation des ressources.


5.1.2 Évaluation du retard avec le modèle à partir d’une implémentation réel

Dans cette partie nous utilisons le modèle IF d’une implémentation de la chaîned’acquisition de données présenté dans la section 4.2. Dans cette partie nous procédonsavec deux approches. La première utilise le temps discret et la seconde le temps continu.

5.1.2.1 Évaluation du retard en temps discret

Retad en fonction de la période du pilote d’équipement

Dans le but d’évaluer l’intérêt de l’approche proposée, on considère un systèmemono capteur, une application de contrôle monotâche avec les hypothèses suivantes :

• La période de capteur physique Pc vaut 10 unités de temps.• Le pilote est en mode scrutation et sa période Pp est inconnue a priori, la taille deson registre est de 1 avec écrasement de donnée si nécessaire, il a un temps deréponse compris dans [1, 2].

• La période de l’application Pa est égale à 20 unités de temps pour la figure 5.5,15 unités de temps pour la figure 5.6 et 17 unités de temps pour la figure 5.7, letemps de réponse est modifié en intervalle [6,7].

• Enfin, nous considérons que tous les processus du système (capteur, pilote et ap-plication) démarrent au même instant.

Les résultats des valeurs des retards possibles sont présentés dans les figures 5.5, 5.6et 5.7. Dans chaque cas, on évalue le retard dans deux cas (avec ou sans priorité entreles éléments de la chaîne d’acquisition de données, cette priorité est obtenue à traversla priorité sur les transitions).

Analyse

Dans la figure 5.5, le retard minimal est de 6 (lecture toutes les (20k + 6) unités detemps d’une donnée a priori produite par le capteur toutes les (20k) unités de temps).Quelques points remarquables demeurent, correspondant à un séquencement particu-lier, par exemple pour 10 et 20 où la synchronisation entre l’application, le capteur etle pilote amène à l’existence d’un retard maximum égal à 7 unités de temps. Enfin surles figures Fig. 5.6 et Fig. 5.7, le fait de changer la période de l’application de 20 unitésde temps à 15 puis à 17 unités de temps entraîne des changements considérables auniveau, bien sûr, des valeurs obtenues, mais aussi de la forme de la courbe.

On remarque particulièrement que ce n’est pas en scrutant plus vite (17 unitésde temps) c’est-à-dire en chargeant le système qu’on a des retards plus faibles ; aucontraire, le retard maximal est plus faible en scrutant à 20 unités de temps pour cer-taines périodes du pilote d’équipement (en particulier quand Bp est dans les intervalles[10,15], [20,25] et [30,35].


La priorité entre les éléments de la chaine d’acquisition influe sur quelques valeursde retard qui changent suivant qu’on fixe une priorité ou non.Mais dans ce cas, l’impactde la priorité (soit la polotique d’ordenancement) reste faible.

On remarque, dans les courbes en temps discret, que le retard maximal de ceux decette approche de modélisation à partir d’une implémentation a tendance à augmenteren fonction de la période du pilote et par rapport à celui des courbes de la premierapproche où on a utilisé un approche de modélisation à partir d’une spécification atendance à se stabiliser ou à ne pas dépasser une borne donnée. Ceci est dû au fait quepour l’approche 1, à chaque fois qu’on récupère une occurrence pour l’envoyer ou latransmettre d’un registre ou d’une zone mémoire on efface ce dernier, alors que pourl’approche 2, après la récupération d’une occurrence on garde une copie dans le registreou la zone mémoire jusqu’au écrasement par une nouvelle.

Retard en fonction de la période du pilote d’équipement et de la période de l’appli-cation

L’intérêt de l’évaluation du retard est de trouver le bon compromis entre les para-mètres du système et le retard. Sur un paramètre (période du pilote d’équipement), ilest simple sur la courbe de retard de trouver la meilleure période pour un retard maxi-mal fixé à l’avance. Dans l’exemple qui suit (figure 5.8), nous avons essayer de tracer lesvaleurs des retards en faisant varier deux paramètres du système, à savoir la périodedu pilote d’équipement et la période de l’application.

Les courbes de la figure 5.8 permettent de déterminer les périodes de l’applicationet du pilote d’équipement en satisfaisant les contraintes exprimées sur le retard tout enoptimisant l’utilisation des ressources.

5.1.2.2 Évaluation du retard en temps continu

(Dans le but d’évaluer l’intérêt de l’approche proposée) On considère un systèmemono capteur, une application de contrôle monotâche avec les hypothèses suivantes :

• la période de capteur physique Pc vaut 10 unités de temps ;• le pilote est en mode scrutation et sa période Pp est inconnue a priori, la taille deson registre est de 1 avec écrasement de donnée si nécessaire, il a un temps deréponse compris entre [1, 2] ;

• la période de l’application Pa est égale à 20 unités de temps pour la figure 5.9, 15unités de temps pour la figure 5.10 et 17 unités de temps pour la figure 5.11, letemps de réponse est modifié en intervalle [6,7] ;

• enfin, nous considérons que tous les processus du système (capteur, pilote et ap-plication) démarrent au même instant.

Les résultats des valeurs des retard possibles sont présentés dans les figures (Fig.5.9, Fig. 5.10 et Fig. 5.10). Dans chaque cas, on évalue le retard dans deux cas (avec ou


sans priorité entre les éléments de la chaîne d’acquisition de données, cette priorité estobtenue à travers la priorité sur les transitions).

Analyse

Sur les enveloppes les courbes des figures 5.9 5.10 5.11 sont identiques à celles de lasous section 5.1.2.1. Mais il est important de remarquer qu’il y a des valeurs de retardimpossibles (les intervalles de retard ]7,16[ et ]17,25[ ]27,36[ sont des retards impos-sibles dans le cas du système de la figure 5.9). Ces valeurs du reatrd impossibles nousconduisent à exprimer le retard en fonction d’union d’intervalle de retards possibles.

La priorité entre les éléments de la chaine d’acquisition influe sur quelques valeursde retard. Par exemple pour la figure 5.11 entre la période 13 et 35, on a un retard de10 dans le cas ou nous fixons des priorités qui se transforment en un retard [6, 11] si onne fixe pas des priorités entre les éléments de la chaine d’acquisition. Mais l’effet despriorités sur le retard reste limité.

5.1.3 Conclusion

Cette analyse nous montre qu’un intervalle [min,max] n’est pas suffisant pour ca-ractériser le retard pour une configuration donnée et que ceci est dû à l’existence desvaleurs du retard impossible. Bien sûr on pourrait toujours répresenter le retard commeune union d’intervalles de retard possible (par exemple, pour la figure 5.9 et pourPp = 16 unités de temps, on a retard=[6,7]∪[16,17]∪[26,26], mais ceci ne donne pasla dynamique des retards, soit la loi des retards.

Dans la section suivante, nous présentons un autre approche de réprésentation desretards possibles permettant d’exprimer cette loi des retards.

5.2 Langage de retard et utilisation de l’approche pour la configura-tion des pilotes d’équipement

Dans cette section, nous allons à partir du système de transition étiquetée (STE) desystème déterminer l’automate des retards possibles. À partir de cet automate, on peutdéterminer le langage de retard pour une configuration de la chaîne d’acquisition dedonnée.

Afin de produire la LTS de retard possible : pour une configuration de système dedonnée et après la génération du LTS, nous réduisons le LTS à un automate qui contientuniquement les valeurs de retards possibles. Cette réduction est réalisée à l’aide del’outil CADP [GMLS07] avec un STE obtenue à partir d’une exécution en temps continu.

5.2. Langage de retard et utilisation de l’approche pour la configuration des pilotesd’équipement 101

5.2.1 Exemple 1 : exemple simple

Dans un premier lieu nous prenons le cas d’un modèle de la chaîne d’acquisition àpartir d’une implémentation avec les paramètres suivants :

• un capteur physique avec une période de production égale à 10 unités de temps ;• une application de contrôle avec une période de consommation égale à 20 unitésde temps et une durée d’exécution de [6, 7] ;

• un pilote d’équipement avec une période égale à 5 unités de temps et et une duréed’exécution de [1, 2] ;

• le registre de sauvegarde est de taille 1.La figure 5.12 représente l’automate des valeurs de retards possibles pour l’exemple 1.

À partir de cet automate de retard, nous pouvons définir un langage de retard écritsous la forme d’une expression régulière, pour ce premier cas simple, le retard est :

retard = (6∗|7∗)∗ (5.4)

5.2.2 Exemple 2

Dans cet exemple nous gardons les même paramètres sauf pour la période du piloted’équipement qui passe à 9 unités de temps. La figure 5.13 représente l’automate desvaleurs de retards possible pour l’exemple 2.

À partir de cet automate de retard, nous pouvons définir un langage de retard écritsous la forme d’une expression régulière :

retard = ((6|7)(6|7|16|17)2 (6|7)2(6|7|16|17)16(6|7|16)(6|7))∗ (5.5)

5.2.3 Exemple 3

Dans cet exemple nous gardons les mêmes paramètres que pour l’exemple 1 à partpour la période du pilote d’équipement qui passe à 15 unités de temps et la période del’application qui passe à 15 unités de temps. La figure 5.14 représente l’automate desvaleurs de retards possibles pour l’exemple 3.

À partir de cet automate de retard nous pouvons définir un langage de retard écritsous la forme d’une expression régulière :

retard = ((6|7)(11|12))∗ (5.6)

5.2.4 Exemple d’utilisation du lagage de retard

SAIA [DeA07], est un style architectural à base de modèle pour la description del’acquisition de donnée dans les systèmes de contrôle de processus. Leur idée est de


séparer l’aspect techologique de l’acquisition ; de la donnée physique utilisée par lecontrôle. Ainsi, le contrôle est basé sur des données de haut niveau comme par exemple“ vitesse véhicule ”. Ensuite, cette donnée de haut niveau peut être produite par diffé-rents type de drivers d’acquisitions tels que “ drivers de tick de roue ”, “ pilote GPS”, etc ; après adaptation. Afin de pouvoir garantir une certaine précision du contrôlelors de l’utilisation des données de haut niveau, SAIA utilise une description de la QoSen termes de retards, de loi d’arrivée, etc. Ensuite, lors de l’utilisation de driver spé-cifiques, un contrat doit être établit pour satisfaire qu’un driver particulier satisfait laQoS décrite par la donnée de haut nibveau et ainsi assurer la précision du contrôlede l’application. Afin de ne pas restreindre l’ensemble des drivers pouvant servir à laproduction d’une donnée de haut niveau, il leur est nécessaire de décrire la QoS de ladonnée de haut niveau de manière prècise, c’est à dire sous la forme d’un langage telque celui décrit précédemment.

Lors du choix d’un driver spécifique, il leur est alors nécessaire de connaître sonlangage de QoS, représentant une abstraction temporelle prècise du driver réel. Il réa-lise alors un simulateur du driver réel en produisant un flot de données conforme à sonlangage de QoS afin de pouvoir établir le contrat de QoS.

Ce travail montre qu’il peut être intéressant de décrire la QoS sous forme d’un lan-gage afin d’avoir une description fine du comportement temporel dans un flot d’acqui-sition et ainsi de pouvoir en inférer la correction ou non de l’application utilisant ce flotd’acquisition.


5

10

15

20

25

30

35

10 15

20 25 5

10

15

20

25

-5 0 5

10 15 20 25 30 35

Retard

retard max

PeriodeA

PeriodeP

Retard

(a) retard maximal

0

1

2

3

4

5

6

10 15

20 25 5

10

15

20

25

-2

0

2

4

6

Retard

retard min

PeriodeA

PeriodeP

Retard

(b) retard minamal

FIG. 5.4 – Évolution du retard vis-à-vis de la période de scrutation du pilote et la périodede scrutation de l’application.


0

10

20

30

40

50

5 10 15 20 25 30 35

Ret

ard

Periode


(a) avec priorité entre les éléments

0

10

20

30

40

50

5 10 15 20 25 30 35

Ret

ard

Periode


(b) sans priorité entre les éléments

FIG. 5.5 – Évolution du retard vis-à-vis de la période de scrutation du pilote et unepériode de l’application de 20.

0

10

20

30

40

50

5 10 15 20 25 30 35

Ret

ard

Periode



0

10

20

30

40

50

5 10 15 20 25 30 35

Ret

ard

Periode





0

10

20

30

40

50

5 10 15 20 25 30 35

Ret

ard

Periode



0

10

20

30

40

50

5 10 15 20 25 30 35

Ret

ard

Periode





5

10

15

20

25

30

35

10 15

20 25 5

10

15

20

25

0 5

10 15 20 25 30 35 40

Retard

retard max

PeriodeA

PeriodeP

Retard

(a) retard maximal

1

2

3

4

5

6

10 15

20 25 5

10

15

20

25

-4

-2

0

2

4

6

8

10

Retard

retard min

PeriodeA

PeriodeP

Retard

(b) retard minamal

FIG. 5.8 – Évolution du retard vis-à-vis de la période de scrutation du pilote et la périodede scrutation de l’application.


0

10

20

30

40

50

5 10 15 20 25 30 35

Ret

ard

Periode


0

10

20

30

40

50

5 10 15 20 25 30 35

Ret

ard

Periode



0

10

20

30

40

50

5 10 15 20 25 30 35

Ret

ard

Periode


0

10

20

30

40

50

5 10 15 20 25 30 35

Ret

ard

Periode




0

10

20

30

40

50

5 10 15 20 25 30 35

Ret

ard

Periode


0

10

20

30

40

50

5 10 15 20 25 30 35R

etar

d

Periode



0 retard_cal=6 retard_cal=7

FIG. 5.12 – Automate des valeurs de retard possibles pour l’exemple 1.


0

5

retard_cal=7 retard_cal=6

6

retard_cal=17 retard_cal=16 retard_cal=7 retard_cal=6

1

7


8

retard_cal=16

2

4



3



retard_cal=6 retard_cal=7 retard_cal=16

FIG. 5.13 – Automate des valeurs de retard possibles de l’exemple 2.

0

1


FIG. 5.14 – Automate des valeurs de retard possibles de l’exemple 3.

Conclusion et perspectives

CETTE thèse propose une approche pour l’évaluation formelle des caractéristiquestemporelles des chaines d’acquisition de données dans les systèmes de contrôle

de processus. Cette évaluation est basée sur les automates temporisés communicants etles observateurs de propriétés.

Les résultats obtenus dans ce travail se focalisent sur plusieurs aspects.

Le premier point consiste en la mise en place de l’instrumentation d’un observateurd’occurrence pour l’évaluation des propriétés temporelles. L’évaluation des caractéris-tiques temporelles des occurrences d’un flot de données d’une chaîne d’acquisition né-cessite la formalisation du comportement du cycle de vie d’une occurrence de donnéedans une chaîne d’acquisition (production et consommation de l’occurrence, créationet suppression de copie, fin de vie de l’occurrence). L’observation des occurrences estorientée pour l’évaluation du “ retard ”.

Le deuxième point consiste en la modélisation du système, en particulier le piloted’équipement, et en l’évaluation et la caractérisation fine des propriétés temporelles desretards. La modélisation de la chaine d’acquisition est présentée sous la forme de deuxapproches de modélisation de la chaîne d’acquisition et des éléments d’observation. Lapremière approche est une modélisation basée sur une spécification de la chaîne d’ac-quisition. La seconde approche de modélisation est basée sur une implémentation dela chaîne d’acquisition. Les deux modèles sont développés à l’aide des automates tem-porisés communicants IF. L’évolution et la caractérisation des propriétés temporellespasse par une définition des bases théoriques de l’évaluation du “ retard ” et des règlesde l’observation (suivi de la date de production et des dates de consommation).

Le troisième point consiste en l’évaluation du retard proprement dit. L’évaluationet la caractérisation fine des retards d’un pilote d’équipement est réalisée sur plusieursconfigurations possibles de la chaine d’acquisition et du pilote d’équipement. Ces confi-gurations sont fonction des paramètres temporels d’une chaine d’acquisition (capteur,pilote, et application de contrôle). L’évaluation du retard est réalisée par l’analyse et lavérification des propriétés sur les STE obtenus après exécution des modèles IF du sys-tème. Le retard est présenté sous diverses formes : valeurs (intervalles discrets et conti-nus) de retard possibles en fonction d’un paramètre de la chaîne d’acquisition ou d’unlangage du retard (expression régulière) pour une configuration donnée de la chaîned’acquisition.

112

Perspectives

Les résultats obtenus lors de ce travail de thèse permettent d’entrevoir de nom-breuses perspectives de recherche que nous exposons ici sous la forme de trois axes.

Extenstions de l’approche

• L’approche développée permet une caractérisation fine du retard, sous diversesformes (valeurs possibles, langage de retard). Il serait intéressant d’évaluerd’autres caractéristiques temporelles ou non, telles que le taux de perte ou lenombre de pertes successives.

• La mise en place de l’observation (de l’observateur) des occurrences d’un flotde données a été réalisé vis-à-vis du retard malgré le soucis de mettre la notiond’observation d’occurrence en avance. Il serait intéressant de voir par rapportau point précédent les modifications et adaptations de la théorie développéevis-à-vis d’autres caractéristiques. Ceci permettrait de définir une théorie d’ob-servation (observateur) commune par classe ou ensemble des caractéristiquesdonnées.

• Certains points dans la théorie de l’observation des occurrences d’un flot dedonnées a été guidé par le formalisme de modélisation utilisée par la suite, àsavoir, les automates temporisé et surtout IF. Cependant, d’autres formalismesde modélisation existent (par exemple, les RdPT [Pet78, Pet80]), mais aussid’autres outils (par exemple, UPPAAL [BLL+95], KRONOS [DOTY95]). Il seraitintéressant de voir l’influence d’un nouvel outil ou de formalisme demodélisa-tion sur les règles établis durant la mise en place de l’observation d’un flot dedonnées. Ceci permettrait de définir une théorie d’observation (observateur)des occurrences indépendamment du formalisme et de l’outil de modélisation.

Extentions du domaine d’application

• Les caractéristiques temporelles, à savoir le retard, évalué dans ce travailconcerne la chaîne d’acquisition de données dans les systèmes de contrôlede processus. Cependant, il est important pour les systèmes de contrôle deprocessus d’évaluer ces mêmes caractéristiques sur la chaîne complète de com-mandes, à savoir de l’application de contrôle aux actionneurs.

• La mise en place de la théorie de l’observation des occurrences d’un flot dedonnées a été définie indépendamment du type de la donnée manipulée. Il se-rait intéressant d’adapter et d’appliquer cette théorie dans d’autres systèmesoù il y a un flot d’information qui est acheminé entre un élément source et unélément puits. Par analogie, nous pourions nous inspirer de la théorie d’obser-vation développée dans ce travail pour l’évaluation des caractéristiques dansune chaîne de production industrielle, une chaîne de logistique, ou une chaînede transmission d’information.

Perspectives 113

Mise en œuvre et modèles

• Dans ce travail de thèse, la modélisation, l’analyse et l’évaluation des caracté-ristiques temporelles, basés sur l’observation d’un flot de données, sont réa-lisées par différents outils et formalismes de modélisation, des scripts et desoutils d’analyse des STEs. Il serait utile de mettre en place une plateforme in-tégrée de modélisation et d’analyse des flots de données permettant d’intégrerles divers outils et formalismes de modélisation et d’analyse. Il serait aussi in-téressant que la plateforme soit évolutive en acceptant de l’associer à d’autresoutils de modélisation ou d’analyse. Dans cette objectif, les outils autour del’ingéniérie dirigée par les modèles seraient certainement une solution à inves-tiguer.

Bibliographie

[14599] IEEE Std 1451.1-1999. IEEE Standard for a Smart Transducer Interface for Sen-sors and Actuators-Network Capable Application Processor (NCAP) Information

Model. IEEE Standards Office, New York, NY, USA, 1999. 10

[A.01] JANTSCH A. Device driver and dma controller synthesis from hw /swcommunication protocol specifications. Design Automation for EmbeddedSystems, 6 :177–205(29), April 2001. 16

[ABBL98] Luca Aceto, Patricia Bouyer, Augusto Burgueño, and Kim Guldstrand Lar-sen. The power of reachability testing for timed automata. In VikramanArvind and Ramaswamy Ramanujam, editors, FSTTCS, volume 1530 ofLecture Notes in Computer Science, pages 245–256. Springer, 1998. 38, 63

[ACD90] R. Alur, C. Courcoubetis, and D. Dill. Model-checking for real-time sys-tems. In This paper appears in : Logic in Computer Science, 1990. LICS ’90, Pro-ceedings., Fifth Annual IEEE Symposium on e, pages 414–425, Philadelphia,PA, USA, 1990. IEEE Computer Society. 26, 28, 29, 36

[ACH+92] Rajeev Alur, Costas Courcoubetis, Nicolas Halbwachs, David L. Dill, andHowardWong-Toi. Minimization of timed transition systems. InCONCUR’92 : Proceedings of the Third International Conference on Concurrency Theory,pages 340–354, London, UK, 1992. Springer-Verlag. 42

[AD94] Rajeev Alur and David L. Dill. A theory of timed automata. TheoreticalComputer Science, 126(2) :183–235, 1994. 28, 29

[Ake78] Sheldon B. Akers. Binary decision diagrams. IEEE Trans. Computers,27(6) :509–516, 1978. 41

[ALK05] Ahmad Badreddin ALKHODRE. Développement formel de systèmes tempsréel à l’aide de SDL et IF : compilation pour systèmes temps réel. PhD thesis,Insa de Lyon, 2005. 74

[AS85] Bowen Alpern and Fred B. Schneider. Defining liveness. Inf. Process. Lett.,21(4) :181–185, 1985. 35

[AW90] Karl J. Aström and Björn Wittenmark. Computer-controlled systems : theoryand design (2nd ed.). Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1990.21

[Bat98] I. Bate. Scheduling and timing analysis for safetycritical systems, 1998. 19

116 BIBLIOGRAPHIE

[BBDP07] Frédéric Boniol, Marc Boyer, David Doose, and Claire Pagetti. Formalismede description du réseau – Projet ADCN+ – Tache T3.2.1 – Rapport final.Rapport de contrat, IRIT, Université Paul Sabatier, Toulouse, septembre2007. 21

[BBE+07] Henri Bauer, Marc Boyer, Jérôme Ermont, Christian Fraboul, FabriceFrances, Frédéric Ridouard, and Jean-Luc Scharbarg. Outils d’évaluationde borne maximalle de délais des différents élément de l’architecture deréférence – projet adcn+ – tache t3.2.3 – rapport intermediaire. Rapport decontrat IRIT/RT–2007-7–FR, IRIT, Université Paul Sabatier, Toulouse, juin2007. 21

[BGM02] Marius Bozga, Susanne Graf, and Laurent Mounier. If-2.0 : A valida-tion environment for component-based real-time systems. In K.G. LarsenEd Brinksma, editor, Proceedings of CAV’02 (Copenhagen, Denmark), volume2404 of LNCS, pages 343–348. Springer-Verlag, July 2002. 3, 30, 33, 39, 63,72

[BLL+95] Johan Bengtsson, Kim G. Larsen, Fredrik Larsson, Paul Pettersson, andWang Yi. UPPAAL — a Tool Suite for Automatic Verification of Real–TimeSystems. In Proc. of Workshop on Verification and Control of Hybrid SystemsIII, number 1066 in Lecture Notes in Computer Science, pages 232–243.Springer–Verlag, October 1995. 28, 112

[BNC03] Iain Bate, Peter Nightingale, and Anton Cervin. Establishing timing re-quirements and control attributes for control loops in real-time systems.In Proceedings of the 15th Euromicro Conference on Real-Time Systems, Porto,Portugal, jul 2003. 19, 20

[Bor98] S. Bornot. De la composition des systèmes temporisés. PhD thesis, L’UNIVER-SITE JOSEPH FOURRIER - GRENOBLE I, 1998. 30, 33

[Bou02] Patricia Bouyer. Modèles et algorithmes pour la vérification des systèmes tem-porisés. Thèse de doctorat, Laboratoire Spécification et Vérification, ENSCachan, France, April 2002. 38, 63

[Boz99] Dorel Marius Bozga. Symbolic verification for communication protocols. PhDthesis, L’UNIVERSITE JOSEPH FOURRIER - GRENOBLE I, 1999. 28, 30

[BST98] Sébastien Bornot, Joseph Sifakis, and Stavros Tripakis. Modeling urgencyin timed systems. In COMPOS’97 : Revised Lectures from the InternationalSymposium on Compositionality : The Significant Difference, pages 103–129,London, UK, 1998. Springer-Verlag. 30

[CA07] R. de Simone. C. André, F. Mallet. Time modeling in marte. In ECSI Forumon specification and Design Languages (FDL), Sep. 2007. 20

[CES86] E. M. Clarke, E. A. Emerson, and A. P. Sistla. Automatic verification offinite-state concurrent systems using temporal logic specifications. ACMTrans. Program. Lang. Syst., 8(2) :244–263, 1986. 27, 36, 58

BIBLIOGRAPHIE 117

[CGP00] E.M. Clarke, O. Grumberg, and D. Peled. Model Checking. MIT Press, 2000.26

[CPHP87] P. Caspi, D. Pilaud, N. Halbwachs, and J. A. Plaice. Lustre : a declarativelanguage for real-time programming. In POPL ’87 : Proceedings of the 14thACM SIGACT-SIGPLAN symposium on Principles of programming languages,pages 178–188, New York, NY, USA, 1987. ACM. 30

[CSEF06] H. Charara, J.-L. Scharbarg, J. Ermont, and C. Fraboul. Methods for boun-ding end-to-end delays on an afdx network. Real-Time Systems, 2006. 18thEuromicro Conference on, pages 10 pp.–, July 2006. 22

[CSF06] Hussein Charara, Jean-Luc Scharbarg, and Christian Fraboul. Analysingend-to-end delays on an afdx network by simulation. In CommunicationSystems and Networks (IASTED-CSN), Palma de Mallorca, Spain, 28/08/2006-

30/08/2006, ISBN 0-88986-606-6, pages 171–176, http ://www.ieee.org/,2006. IEEE. 22

[DBLY03] A. David, G. Behrmann, K. Larsen, and W. Yi. A tool architecture for thenext generation of uppaal, 2003. 28, 38

[DeA07] Julien DeAntoni. SAIA : un style architectural pour assurer l’indépendancevis-à-vis d’entrées/sorties soumises à des contraintes temporelles. PhD thesis,Institut National des Sciences Appliquée de Lyon, Lyon, octobre 2007. 21,101

[DJC94] Michel Diaz, Guy Juanole, and Jean-Pierre Courtiat. Observer-a concept forformal on-line validation of distributed systems. IEEE Trans. Softw. Eng.,20(12) :900–913, 1994. 40, 45, 63

[DOTY95] C. Daws, A. Olivero, S. Tripakis, and S. Yovine. The tool KRONOS. In Hy-brid Systems III : Verification and Control, volume 1066, pages 208–219, Rut-gers University, New Brunswick, NJ, USA, 22–25 October 1995. Springer.28, 30, 112

[EH82] E. Allen Emerson and Joseph Y. Halpern. Decision procedures and expres-siveness in the temporal logic of branching time. In STOC ’82 : Proceedingsof the fourteenth annual ACM symposium on Theory of computing, pages 169–180, New York, NY, USA, 1982. ACM Press. 26, 27, 36

[Eme90] E. Allen Emerson. Temporal and modal logic. pages 995–1072, 1990. 26,27, 36

[ESF06] Jérôme Ermont, Jean-Luc Scharbarg, and Christian Fraboul. Worst-caseanalysis of a mixed can/switched ethernet architecture. In Internatio-nal Conference on Real-Time and Network Systems (RTNS), Poitiers, 30/05/06-

31/05/06, pages 45–54, http ://www.lisi.ensma.fr, mai 2006. LISI-ENSMA.21

118 BIBLIOGRAPHIE

[ESF07] Jérôme Ermont, Jean-Luc Scharbarg, and Christian Fraboul. Timed analysisof embedded networks using timed automata. In IFAC International Confe-rence On Fieldbuses and Networks in Industrial and Embedded Systems (FeT),

Toulouse, 07/11/07-09/11/07, 2007. 22, 23

[FON08] Benjamin FONTAN. Méthodologie de conception de systémes temps réel et dis-tribués en contexte UML/SysML. PhD thesis, Université Toulouse III, PAULSABATIER, U.F.R Physique Chimie Automatique, Toulouse, 2008. 62

[GMLS07] Hubert Garavel, Radu Mateescu, Frédéric Lang, and Wendelin Serwe.Cadp 2006 : A toolbox for the construction and analysis of distributed pro-cesses. In Werner Damm and Holger Hermanns, editors, CAV, volume4590 of Lecture Notes in Computer Science, pages 158–163. Springer, 2007. 72,100

[God91] Patrice Godefroid. Using partial orders to improve automatic verificationmethods. In CAV ’90 : Proceedings of the 2nd International Workshop on Com-puter Aided Verification, pages 176–185, London, UK, 1991. Springer-Verlag.27

[God04] Karen Godary. Validation temporelle de réseaux embarqués critiques et fiablespour l’automobiles. PhD thesis, INSA Lyon, 2004. 23, 37

[GPVW95] RobGerth, Doron Peled,Moshe Y. Vardi, and PierreWolper. Simple on-the-fly automatic verification of linear temporal logic. In Protocol SpecificationTesting andVerification, pages 3–18, Warsaw, Poland, 1995. Chapman &Hall.37, 63

[HC06] Toivo Henningsson and Anton Cervin. Event-based control over net-works : Some research questions and preliminary results. In Proc. Re-glermöte 2006, Stockholm, Sweden, may 2006. 19

[HLR94] Nicolas Halbwachs, Fabienne Lagnier, and Pascal Raymond. Synchronousobservers and the verification of reactive systems. In AMAST ’93 : Procee-dings of the Third International Conference on Methodology and Software Tech-

nology, pages 83–96, London, UK, 1994. Springer-Verlag. 40, 63

[HM85] MatthewHennessy and Robin Milner. Algebraic laws for nondeterminismand concurrency. J. ACM, 32(1) :137–161, 1985. 38

[Hoa78] C. A. R. Hoare. Communicating sequential processes. Commun. ACM,21(8) :666–677, 1978. 28

[Hol85] G.J. Holzmann. Tracing protocols. AT&T Technical Journal, 64(10) :2413–2433, December 1985. 43

[IT00] ITU-T. Recommendation Z.100. Specification and Description Language(SDL). Technical report, International Telecommunication Union – Stan-dardization Sector, November 2000. 28

BIBLIOGRAPHIE 119

[JJ90] C. Jard and T. Jeron. On-line model checking for finite linear temporallogic specifications. In Proceedings of the international workshop on Automaticverification methods for finite state systems, pages 189–196, New York, NY,USA, 1990. Springer-Verlag New York, Inc. 43

[JJ92] Claude Jard and Thierry Jéron. Bounded-memory algorithms for verifi-cation on-the-fly. In CAV ’91 : Proceedings of the 3rd International Workshopon Computer Aided Verification, pages 192–202, London, UK, 1992. Springer-Verlag. 43

[JM86] F Jahanian and A K Mok. Safety analysis of timing properties in real-timesystems. IEEE Trans. Softw. Eng., 12(9) :890–904, 1986. 36

[JMG88] C. Jard, J. F. Monin, and R. Groz. Development of veda, a prototyping toolfor distributed algorithms. IEEE Trans. Softw. Eng., 14(3) :339–352, 1988. 39,63

[JUM03] Fabrice JUMEL. Définition et gestion d’une qualité de service pour les applica-tions temps réel. PhD thesis, LORIA, Nancy, 2003. 10, 18, 19, 20, 23

[Kap02] Tatjana Kapus. Specification of synchronous sequential circuits using sdland objectgeode. Comput. Stand. Interfaces, 24(3) :257–274, 2002. 39

[KF82] W. H. Ko and C. D. Fung. Vlsi and intelligent transducers. NASA STI/ReconTechnical Report A, 83 :12810–+, 1982. 12

[Koy90] Ron Koymans. Specifying real-time properties with metric temporal logic.Real-Time Syst., 2(4) :255–299, 1990. 36

[Koz83] Dexter Kozen. Results on the propositional mu-calculus. Theor. Comput.Sci., 27 :333–354, 1983. 28, 36

[KRP+93] Mark H. Klein, Thomas Ralya, Bill Pollak, Ray Obenza, and Mi-chael González Harbour. A practitioner’s handbook for real-time analysis. Klu-wer Academic Publishers, Norwell, MA, USA, 1993. 26

[LCCB+06] Manuel Lluesma Camps, Anton Cervin, Patricia Balbastre, Ismael Ripoll,and Alfons Crespo. Jitter evaluation of real-time control systems. In Proc.12th IEEE International Conference on Embedded and Real-Time Computing Sys-

tems and Applications, Sydney, Australia, aug 2006. 22

[Lia01] Feng-Li Lian. Analysis, Design, Modeling, and Control of Networked ControlSystems. PhD thesis, The University of Michigan, 2001. 10, 18

[LLW95] F. Laroussinie, K. G. Larsen, and C. Weise. From timed automata to logic- and back. In Proc. 20th Int. Symp. Math. Found. Comp. Sci. (MFCS’95),Prague, Czech Republic, Aug.-Sep. 1995, volume 969, pages 27–41. Springer,1995. 38

[LPY97] Kim Guldstrand Larsen, Paul Pettersson, and Wang Yi. UPPAAL in a nut-shell. International Journal on Software Tools for Technology Transfer, 1 :134–152, 1997. 30

120 BIBLIOGRAPHIE

[Mar00] S. Martin. Timing problems in distributed real-time computer control sys-tems, 2000. 10, 18, 19

[McM93] Kenneth L. McMillan. Symbolic Model Checking. Kluwer Academic Publi-shers, 101 Philip Drive Assinippi Park Norwell, Mass 02061, 1993. 41

[Mil80] Robin Milner. A Calculus of Communicating Systems, volume 92 of LectureNotes in Computer Science. Springer, 1980. 28

[ML06] Yu-SeungMa and ChaeDeok Lim. Test system for device drivers of embed-ded systems. In ICACT 2006 : Proceedings of the 8th International Conferenceon Advanced Communication Technology, Washington, DC, USA, 2006. IEEEComputer Society. 17

[MMJ05] Sanfridson Martin, Törngren Martin, and Wikander Jan. The effect of ran-domly time-varying sampling and computational delay. In Proceedings ofthe IFAC world progress, Prague, 2005. 1, 10, 18, 19, 20, 23

[MMM93] ROBERT Michel, MARCHANDIAUX Michel, and PORTE Michel. Cap-teurs Intelligents Et Methodologie D’Evaluation. Automatique. Lavoisier, sep-tembre 1993. 2, 11, 13

[MOU92] Laurent MOUNIER. Méthodes de Vérification de Spécifications Comportemen-tales : étude et mise en oeuvre. PhD thesis, L’UNIVERSITE JOSEPH FOUR-RIER - GRENOBLE I, 1992. 42

[MRC+00] F. Merillon, L. Reveillere, C. Consel, R. Marlet, and G. Muller. Devil : Anidl for hardware programming, 2000. 16

[MS00] M. Moy and D.B. Stewart. An engineering approach to determining sam-pling rates for switchesand sensors in real-time systems. In RTAS 2000 :Proceedings of Sixth IEEE Symposium on Real-Time Technology and Applica-

tions, pages 34–45, Washington, DC, USA, 2000. IEEE Computer Society.17

[Muk97] Madhavan Mukund. Linear-time temporal logic and buchi automata. InTutorial talk, Winter School on Logic and Computer Science, Calcutta, 1997. In-dian Statistical Institute. 27, 36, 38, 41

[Obe99] Inulian Ober. Using goal observers to extends the geode simulator. Tech-nical report, 1999. 39, 63

[OGO06] Iulian Ober, Susanne Graf, and Ileana Ober. Validating timed uml modelsby simulation and verification. Int. J. Softw. Tools Technol. Transf., 8(2) :128–145, 2006. 39, 63

[OMG05a] OMG. Uml profile for modeling and analysis of real time and embed-ded systems (marte), request for proposals. Object Management Group, Inc.,OMG document number : realtime/2005-02-06, February 2005. 20

[OMG05b] OMG. Uml profile for schedulability, performance, and time specification.Object Management Group, Inc., OMG document number : formal/05-01-02(v1.1)., January 2005. 20

BIBLIOGRAPHIE 121

[Pet78] J. L. Peterson. An introduction to petri nets. In Tranter, W.H., editor, Proc.of the National Electronics Conference, Chicago, Illinois, Oct. 16–18, 1978., vo-lume 32, pages 144–148. National Engineering Consortium, Inc., 1978. 28,112

[Pet80] J. L. Peterson. A note on colored petri nets. Information Processing Letters,Nr. 1, 11 :40–43, aug 1980. 28, 112

[Rad97] Jane Radatz. The IEEE Standard Dictionary of Electrical and Electronics Terms.IEEE Standards Office, New York, NY, USA, 1997. 20

[Ray89] A. Ray. Introduction to networking for integrated control systems. ControlSystems Magazine, IEEE, 9(1) :76–79, Jan 1989. 19

[Red02] M. Redell, O. ; Sanfridson. Exact best-case response time analysis of fixedpriority scheduled tasks. Real-Time Systems, 2002. Proceedings. 14th Euromi-cro Conference on, pages 165–172, 2002. 19

[RJL85] Jr. Richard J. Linn. The features and facilities of estelle : a formal descriptiontechnique based upon an extended finite state machine model. In Procee-dings of the IFIP WG6.1 Fifth International Conference on Protocol Specification,

Testing and Verification V, pages 271–296, Amsterdam, TheNetherlands, TheNetherlands, 1985. North-Holland Publishing Co. 28, 39, 63

[Rog06] Jean Charles Roger. Exploitation de contextes et d’observateurs pour la valida-tion formelle de modèles. PhD thesis, ENST Bretagne - ENSIETA, 2006. 35,37

[RSF07a] Frédéric Ridouard, Jean-Luc Scharbarg, and Christian Fraboul. Stochasticnetwork calculus for end-to-end delay evaluation of avionics multi-hopvirtual links. In IFAC International Conference On Fieldbuses and Networks inIndustrial and Embedded Systems (FeT), Toulouse, 07/11/07-09/11/07, 2007. 22

[RSF07b] Frédéric Ridouard, Jean-Luc Scharbarg, and Christian Fraboul. Sto-chastic network calculus for end-to-end delays distribution evaluationon an avionics switched ethernet. In IEEE International Conferenceon Industrial Informatics, Vienne, 23/07/2007-26/07/2007, pages 559–564,http ://www.ieee.org/, juillet 2007. IEEE. 22

[SF07a] Jean-Luc Scharbarg and Christian Fraboul. A generic simulation model forend-to-end delays evaluation on an avionics switched ethernet. In IFACFeT, Toulouse, 07/11/07-09/11/07, 2007. 22

[SF07b] Jean-Luc Scharbarg and Christian Fraboul. Simulation for end-to-end de-lays distribution on a switched ethernet. In Emerging Technologies and Fac-tory Automation (ETFA), Patras, 25/09/07-28/09/07, http ://www.ieee.org/,septembre 2007. IEEE. 22

[SIG02] I2O Special Interest Group (I2O SIG). intelligent i/o, 2002. 16

122 BIBLIOGRAPHIE

[SK98] C. Scheering and A. Knoll. Framework for implementing self-organizingtask-oriented multisensor networks. In P. S. Schenker and G. T. McKee,editors, Proc. SPIE Vol. 3523, p. 18-29, Sensor Fusion and Decentralized Controlin Robotic Systems, Paul S. Schenker ; Gerard T. McKee ; Eds., volume 3523of Presented at the Society of Photo-Optical Instrumentation Engineers (SPIE)Conference, pages 18–29, October 1998. 11

[Sta88] John A. Stankovic. Misconceptions about real-time computing : A seriousproblem for next-generation systems. Computer, 21(10) :10–19, 1988. 1, 9

[Tel98] Telelogic. Telelogic tau 3.3 documentation. Telelogic AB, July 1998. 39

[TETG07] F. Thomas, H. Espinoza, S. Taha, and S. Gérard. Marte : le futur standardomg pour le développement dirigée par les modèles des systèmes embar-qués temps réel. Object Management Group, Inc., Génie Logiciel, 2007. 20

[UDI02] Project UDI. Uniform driver interface, 2002. 16, 17

[VW86] Moshe Y. Vardi and Pierre Wolper. An automata-theoretic approach to au-tomatic program verification (preliminary report). In LICS, pages 332–344.IEEE Computer Society, 1986. 37, 63

[WMB03] Shaojie Wang, Sharad Malik, and Reinaldo A. Bergamaschi. Modeling andintegration of peripheral devices in embedded systems. In DATE ’03 :Proceedings of the conference on Design, Automation and Test in Europe, page10136, Washington, DC, USA, 2003. IEEE Computer Society. 17

[WT95] B. Wittenmark and N. Trngren. Timing problems in real-time control sys-tems, 1995. 1, 10, 18, 19, 20, 21

FOLIO ADMINISTRATIF

THESE SOUTENUE DEVANT L'INSTITUT NATIONAL DES SCIENCES APPLIQUEES DE LYON

NOM : BEN HEDIA DATE de SOUTENANCE : 29/11/2008(avec précision du nom de jeune fille, le cas échéant)

Prénoms : Belgacem

TITRE : Analyse temporelle des systèmes d'acquisition de données : une approche a base d'automates temporisés communicants et d'observateurs.

NATURE : Doctorat Numéro d'ordre : 05 ISAL

Ecole doctorale : Ecole Doctorale Informatique Information et Société (EDIIS)

Spécialité : Informatique

Cote B.I.U. - Lyon : T 50/210/19 / et bis CLASSE :

RESUME :

Dans le cadre des applications temps réel de contrôle de procédé, la thèse propose une théorie et des outils formels pour caractériser temporellement le retard des données acquises sur l’état du procédé, acquisition réalisée via un logiciel dédié appelé pilote. Le contexte et le domaine d’étude de la thèse se base sur les éléments constituant une chaîne d’acquisition de données dans un contexte de contrôle de procédé, les différentes caractéristiques temporelles et les approches pour les évaluer vis-à-vis des flots de données acheminés dans la chaîne d’acquisition. Ce travail s’appuie sur un ensemble des bases théoriques requises pour cette caractérisation, particulièrement les automates temporisés communicants, les systèmes de transitions étiquetées et la vérification formelle de propriétés sur ces automates, et en particulier les observateurs. Nous proposons d’abord de formaliser les principes formels de l’évaluation des propriétés temporelles des flots des données. L’approche se concentre sur le comportement des occurrences d’un flot de données dans une chaîne d’acquisition et sur la mise en place de l’observation pour l’évaluation de leurs caractéristiques temporelles et spécialement le retard. Ensuite, nous donnons les clefs techniques de la modélisation de notre approche en IF et nous proposons des exemples de modélisation de quelques éléments de la chaîne d’acquisition, mais aussi la modélisation de l’observation pour l’évaluation des caractéristiques temporelles. Cette modélisation s’appuie sur deux approches différentes de modélisation de la chaîne d’acquisition, un premier à un niveau de spécification et un autre à un niveau d’implémentation. Enfin, nous donnons les résultats de l’approche proposée sur des exemples de chaînes d’acquisition, et nous présentons plusieurs utilisations possibles des résultats obtenus (paramétrage ou tuning d’un pilote d’équipement, détermination du langage de retard pour une chaîne d’acquisition). Au final, l’étude de l’évaluation du retard montre l’influence des paramètres de configuration du pilote sur les retards des données traitées par l’application.MOTS-CLES : Temps Réel, Systèmes Embarqués, Automates Temporisés, Pilotes d’Equipements, Validation Temporelle, Qualité de Service, Évaluation Formelle des Propriétés Temporelles, Observateur

Laboratoire (s) de recherche : CITI

Directeur de thèse: − Jean-Philippe Babau, Professeur, UBO, Brest− Riadh Robbana, Professeur, EPT, Tunis

Composition du jury :

− Boniol Frédéric, Professeur, ENSEEIHT de Toulouse− Néjib Ben Hadj Aloane, Professeur, ENSI, Tunis − Belhassen Zouari, Professeur, Directeur de l'ANSI, Tunis− Philippe Dhaussy, Ens./Chercheur, ENSIETA de Brest − Fabrice Jumel, Enseignant-Chercheur, CPE Lyon

Analyse temporelle des systèmes d'acquisition de données : une...

Documents

Transcript of Analyse temporelle des systèmes d'acquisition de données : une...