Rapport de Mémoire Master Recherche

République Tunisienne
Ministère de l'enseignement supérieur,
de la recherche scientique et des technologies de
l'information et de la communication
Université de Farhat Hached
Mémoire de Mastère
Présenté en vue de l'obtention du
Diplôme National de Mastère de Recherche
Option: Génie Logiciel
MODÉLISATION ET VÉRIFICATION FORMELLES DU
PROTOCOLE S-TDMA SUR LES RÉSEAUX DE
CAPTEURS CORPORELS SANS FILS (WBAN)
Réalisé par
Roua BEN HAMOUDA
Encadré par
Mme. Imen Ben Hafaeidh
Année Universitaire : 2015-2016

Dédicaces
Je dédie ce travail
À l'âme éternelle de mon père Jallel ,
Aucune dédicace ne saurait exprimer l'amour, l'estime, le dévouement et le respect
que j'ai toujours eu pour vous. Rien au monde ne vaut les eorts fournis jour et nuit
pour mon éducation et mon bien être. Ce travail est le fruit de tes sacrices que tu as
consentis pour mon éducation et ma formation.
À ma mère Jamila ,
Que Dieu la protège, pour tous les sacrices consentis, pour tous les encouragements
qu'elle a su prodiguer aux moments diciles ; Qu'elle trouve dans ce travail, le témoi-
gnage de ma vive gratitude et de ma grande reconnaissance, pour l'énergie qu'elle a su
implanter en moi à tous les moments de mes études.
À mes soeurs Amal et Rim ,
pour leurs sacrices et leurs précieuses directives, pour tout ce que nous avons partagé.
Que vous trouviez, dans ce travail, le témoignage de ma sincère fraternité et de mon
éternel attachement familial.
À mes chers petite nièces Ghalia et Ghazal ,
Aucune dédicace ne saurait exprimer tout l'amour que j'ai pour vous, Votre joie et
votre gaieté me comblent de bonheur. Puisse Dieu vous garder, éclairer votre route et
vous aider à réaliser à votre tour vos voeux les plus chers.
A ma très chère binome Yasmin Bichiou ,
Pour son aide précieuse dans les moments diciles et pour sa prise douce par la main
pour traverser ensemble des épreuves pénibles... Je te suis très reconnaissante, et je
ne te remercierai jamais assez pour ton amabilité et ta générosité.
À toute ma famille,
À mes chers amis,
À tous ceux qui ont contribué de près ou de loin à l'élaboration de ce travail,
Qu'ils trouvent ici, l'expression de mes sincères remerciements.
ii

Remerciements
En préambule à ce mémoire, je souhaite adresser mes remerciements les plus sincères
aux personnes qui m'ont apporté leurs aides et qui ont contribué à l'élaboration de ce
mémoire ainsi qu'à la réussite de cette année universitaire.
Nos remerciements s'adressent au premier lieu à notre Présidente du jury, pour l'hon-
neur qu'elles nous font de juger notre travail. Comme nous tenons également à exprimer
nos sentiments de respect à tous les membres de jury.
Nous sommes particulièrement redevables à notre tutrice Mme.Imen Ben Hafaiedh
, pour sa disponibilité à travers ses critiques et ses propositions d'amélioration, sa
collaboration, sa modestie et sa sympathie, pour ses compétences, sa pédagogie et ses
directives fructueuses qu'elle n'a cessé de nous prodiguer tout au long de ce projet,
qu'elle soit avisé ici de notre sincère remerciement.
J'exprime aussi ma gratitude à Mme.Maroua Ben Slimane, qui s'est toujours montré à
l'écoute et très disponible tout au long de la réalisation de ce mémoire, ainsi que pour
le temps qu'il a bien voulu me consacrer.
Par la même occasion, nous adressons nos remerciements à tous nos enseignants pour
leurs eorts qui ont guidé nos pas et enrichi nos connaissances tout au long de nos
études universitaires.
iii

Table des matières
Dédicaces ii
Remerciements iii
Table des gures vi
Liste des tableaux viii
Introduction générale ix
1 Etat De L'art 1
1.1 Les réseaux de capteurs sans ls (WSN) . . . . . . . . . . . . . . . . . 1
1.1.1 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Protocoles d'accès au medium (MAC) pour les WSNs . . . . . . 2
1.1.3 Vérication des protocoles MAC dans WSNs . . . . . . . . . . . 4
1.1.4 Domaines d'application . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Les réseaux de capteurs corporels sans ls (WBAN) . . . . . . . . . . . 5
1.2.2 Protocoles MAC pour les WBANs . . . . . . . . . . . . . . . . . 6
1.2.3 Vérication des protocoles MAC dans WBANs . . . . . . . . . . 7
1.3 TDMA : Time Division Multiple Access . . . . . . . . . . . . . . . . . . 9
1.3.2 Vérication formelle des systèmes basés sur TDMA . . . . . . . 9
1.4 S-TDMA : Statistical frame based TDMA . . . . . . . . . . . . . . . . 10
2 Préliminaires : l'environnement à base de composants BIP 13
2.1 Description de BIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Architecture 3-tiers de BIP . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Les composants du framework BIP . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Composants atomiques . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Connecteurs et intéractions . . . . . . . . . . . . . . . . . . . . 18
2.3.3 Priorité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 La boite à outils de BIP . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 Discussion : choix du BIP . . . . . . . . . . . . . . . . . . . . . . . . . 23
iv

Table des matières v
3 Modèle formel du protocole S-TDMA 25
3.1 Architecture du protocole S-TDMA . . . . . . . . . . . . . . . . . . . . 25
3.2 Le modèle formel proposé . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Les comportements internes des composants . . . . . . . . . . . 27
3.2.2 Connecteur de synchronisation ”αsyn” . . . . . . . . . . . . . . . 30
3.2.3 Connecteur de requête ”αR” . . . . . . . . . . . . . . . . . . . 30
3.2.4 Connecteur statistique αS . . . . . . . . . . . . . . . . . . . . 32
3.2.5 Connecteurs de données αD . . . . . . . . . . . . . . . . . . . 34
4 Vérication formelle et résultats expérimentaux 36
4.1 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.1 Environnement de travail : BIP . . . . . . . . . . . . . . . . . . 37
4.1.2 Le code BIP du modèle proposé . . . . . . . . . . . . . . . . . . 38
4.1.3 La compilation et la liaison avec le code généré . . . . . . . . . 41
4.2 Analyse et résultats expérimentaux . . . . . . . . . . . . . . . . . . . . 43
4.2.1 Analyse de la consommation énergétique avec le protocole S-TDMA 43
4.2.2 Vérication formelle du modèle proposé . . . . . . . . . . . . . 46
Conclusion et perspectives 51
Bibliographie 52
Annexe I 59
Annexe II 67

Table des gures
1.1 Le modèle de communication OSI . . . . . . . . . . . . . . . . . . . . . 2
1.2 Structure du superframe STDMA . . . . . . . . . . . . . . . . . . . . . 11
2.1 Structure d'un modèle BIP . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Exemple : Composant atomique . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Exemple de connecteurs simples . . . . . . . . . . . . . . . . . . . . . . 19
2.4 La diusion atomique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 La boite à outils de BIP . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Compilateur et moteurs d'exécution dans BIP . . . . . . . . . . . . . . 22
3.1 Architecture du S-TDMA . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Modélisation haut niveau du protocole S-TDMA pour un coordinateur
et N n÷uds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Le comportement interne du coordinateur . . . . . . . . . . . . . . . . 27
3.4 Le comportement interne d'un n÷ud de capteur . . . . . . . . . . . . . 29
3.5 Le processus de synchronisation : connecteurs, ports et interactions . . 30
3.6 Le processus de demande de créneaux horaires : connecteurs, ports et
interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.7 Le processus de l'envoie/réception de la trame statistique : connecteurs,
ports et interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.8 Le processus de l'envoie/réception de données : connecteurs, ports et
interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1 La liste des commandes fourni par BIP . . . . . . . . . . . . . . . . . . 37
4.2 La procédure d'exécution d'un chier BIP . . . . . . . . . . . . . . . . 38
4.3 Dénition du type de composant ”Noeuds” . . . . . . . . . . . . . . . 39
4.4 L'implémentation du connecteur ”C − Beacon” . . . . . . . . . . . . . 40
4.5 L'implémentation des ports . . . . . . . . . . . . . . . . . . . . . . . . 40
4.6 La déclaration des types et des fonctions externes . . . . . . . . . . . . 41
4.7 La déclaration du composé ”system” . . . . . . . . . . . . . . . . . . . 41
4.8 La génération du code . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.9 La liaision des chiers générés . . . . . . . . . . . . . . . . . . . . . . . 42
4.10 Le résultat obtenu lors de la liaision des chiers générés . . . . . . . . . 43
4.11 Augmentation de la période du sommeil avec la diminution de nombre
de paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.12 Eet de l'augmentation du nombre des composants lors de la détection
de l'interblocage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
vi

Table des figures vii
4.13 Temps de vérication des propriétés : Exclusion Mutuelle (EM) et Inva-
riance (Inv) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Liste des tableaux
1.1 Classement des protocoles MAC . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Étude comparative entre WSN et WBAN . . . . . . . . . . . . . . . . . 7
1.3 Formats des trames modélisées . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Les types de ports et des connecteurs simples . . . . . . . . . . . . . . 19
3.1 Ensemble des interactions possibles du connecteur ”αsyn” . . . . . . . . 31
3.2 Ensemble des interactions possibles des connecteurs αRi
. . . . . . . . . 32
3.3 Ensemble des interactions possibles du connecteur αS . . . . . . . . . . 33
3.4 Ensemble des interactions possibles des connecteurs αDi . . . . . . . . 34
4.1 Durée de sommeil pour une personne qui marche . . . . . . . . . . . . 45
4.2 Durée de sommeil pour une personne qui court . . . . . . . . . . . . . . 45
4.3 Durée de sommeil pour une personne qui dort . . . . . . . . . . . . . . 46
4.4 Le temps de vérication du détection du deadlock . . . . . . . . . . . . 47
4.5 Le temps de vérication de l'invariance . . . . . . . . . . . . . . . . . . 48
4.6 Le temps de vérication de la propriété d'exclusion mutuelle . . . . . . 49
4.7 Vérication de l'équité sur le protocole S-TDMA . . . . . . . . . . . . . 50
viii

Introduction générale
L'un des dés majeurs du monde de ces dernières décennies a été l'augmentation
continue de la population des personnes âgées dans les pays développés. D'où la néces-
sité de fournir des soins de qualité à une population en croissance rapide, tout en rédui-
sant les coûts des soins de santé. Dans ce contexte, de nombreux travaux de recherche
portent sur l'utilisation des réseaux de capteurs corporels sans l (WBAN :Wireless
Body Area Network), pour faciliter et améliorer la qualité du soin et de surveillance
médicale à distance.
Dans les WBANs, les n÷uds de capteurs sont de petites tailles avec une faible
puissance et des capacités de calcul limitées. Ils sont attachés ou implantés au corps
humain pour la mesure des signes physiologiques (les patterns respiratoires, le rythme
cardiaque, la température, etc). Par conséquent, les WBANs doivent détecter, traiter
et communiquer des données d'une manière ecace et économique.
La couche de contrôle d'accès au support (MAC : Medium Access Control) est
utilisée pour coordonner l'accès de n÷ud au support sans l partagé. Elle est le c÷ur
de la pile des protocoles des communications, qui fournit la base pour la réalisation de
la qualité de service (QoS : Quality of Service) dans tous les réseaux sans l.
An de résoudre ecacement la consommation d'énergie et le trac d'urgence des
problèmes dans les WBAN, plusieurs protocoles MAC ont été conçus. La plupart de
ces protocoles sont basés sur l'architecture TDMA (Time Division Multiple Access) vu
sa faible probabilité de collision et son ecacité énergétique.
S-TDMA (Statistical Frame based TDMA) [NLH+
15, CNI+
13] est un un des proto-
coles MAC les mieux connus, basé sur TDMA et destiné pour les réseaux de capteurs
corporels sans ls. La validation des protocoles déjà proposés pour les WBANs est en
générale basée sur les tests et les simulations voir même sur des observations. Ce qui
ne garantie pas l'absence de bugs dans ces protocoles, ni leurs conformité à leurs spéci-
cations de départ. Vu l'aspect critique de ce type de systèmes, la validation formelle
de ses protocoles devient une nécessité dont nous ne pouvons plus s'en passé.
Dans ce contexte, les travaux menés dans ce mémoire portent sur la modélisation
formelle du protocole MAC S-TDMA, l'analyse de ses performances énergétique et
temporelles et la vérication formelle de quelques propriétés (l'exclusion mutuelle, l'in-
variance, l'équité et l'absence de l'interblocage).
La suite de ce document est organisée comme suit. Dans le premier chapitre, nous
présentons le contexte de ce travail et nous faisons un état de l'art sur les contraintes
des réseaux de capteurs corporels sans ls, et en particulier sur les protocoles MAC
ix

x
destinés pour ces réseaux ainsi que la description du protocole étudié. Ensuite, dans
le deuxième chapitre, nous présentons, les préliminaires, s'agissant du framework à
base des composants BIP, qui va nous orir l'environnement formel nécessaire pour la
modélisation et les outils permettant la vérication. Dans le troisième chapitre, nous
présentons notre modèle haut niveau proposé. Ce modèle nous a permis de vérier
formellement certaines propriétés décrites en logique temporelle sur le système étudié,
ce qui est présenté dans le quatrième chapitre. Ce dernier chapitre décrit brièvement
l'implémentation, les résultat expérimentaux étudiants la performance énergétique et
la vérication formelle du protocole S-TDMA. En conclusion, nous résumons notre
proposition et nous vous proposons des perspectives possibles pour ce travail.

1Etat De L'art
Introduction
Ce premier chapitre situe ce travail à la croisée des domaines des réseaux de capteurs
sans l classiques et corporels, de l'architecture TDMA et de la vérication formelle
des systèmes informatiques. L'objectif de ce mémoire de recherche est d'augmenter la
abilité des réseaux de capteurs corporels sans l à l'aide d'une modélisation de haut
niveau ainsi qu'une vérication formelle d'un protocole basé sur l'architecture TDMA,
appliqué sur un réseau de capteurs corporels sans l.
1.1 Les réseaux de capteurs sans ls (WSN)
Les avancées récentes dans le domaine de communication sans l et les technolo-
gies MEMS (Micro-electro-mechanical systems) ont permis le développement des
micro-composants qui intègrent des dispositifs de captages et de communication sans
l dans un seul circuit, à dimension réduite, et avec un coût raisonnable.
Ces composants, communément appelés micro-capteurs, ont favorisé l'idée de dévelop-
per les réseaux de capteurs basés sur l'eort collaboratif d'un grand nombre de noeuds
opérant d'une façon autonome et communiquant entre eux via des transmissions à
courte portée [KB04].
1.1.1 Présentation générale
Un capteur est un petit appareil autonome capable d'eectuer des mesures simples
sur son environnement immédiat. Il se diérencie du détecteur et du senseur par sa
possibilité de délivrer une grandeur physique directement utilisable pour une mesure ou
une commande. Un réseau de capteurs sans l (RCSF dit en anglais WSN), est composé
d'un ensemble d'unités de traitements embarquées, appelées motes, communiquant
1

1.1 Les réseaux de capteurs sans fils (WSN) 2
via des liens sans l [KB04].
Suivant leur utilisation, les réseaux de capteurs peuvent être composés de diérents
de noeuds capteurs hétérogènes, tels que les capteurs séismiques, thermiques, visuels,
infrarouges, acoustiques et radar, ils sont capables de surveiller une grande variété de
phénomènes ambiants, notamment :
ˆ Température
ˆ Humidité
ˆ Mouvement des véhicules
ˆ Pression
ˆ Taux de bruits
ˆ Présence ou absence de certains types d'objets
ˆ Taux de frottement sur des objets attachés, et
ˆ D'autres caractéristiques tel que la vitesse, la direction et le volume d'un objet
donné.
1.1.2 Protocoles d'accès au medium (MAC) pour les WSNs
Dans le modèle de communication OSI(Open System Interconnection)(Voir la Fi-
gure 1.1), la couche MAC est une sous-couche de la couche liaison de données (couche
2) et est préoccupée par le partage de la connexion physique au réseau entre plusieurs
ordinateurs[Rou11].
Figure 1.1: Le modèle de communication OSI

Un protocole MAC dans un réseau de capteurs sans l auto-organisé doit accomplir
deux objectifs essentiels :
ˆ La création de l'infrastructure de communication : Comme ce type de
réseau est construit de milliers de n÷uds capteur éparpillés d'une manière dense
sur le champs de captage, le protocole MAC doit assurer l'établissement des liens
de communication pour le transfert des données entre ces n÷uds. Ceci formera
l'infrastructure de base requise pour la communication saut-par-saut et donnera
au réseau une capacité d'auto-organisation.
ˆ Le partage des canaux de communication : le second objectif du protocole
MAC est le partage ecace et équitable des canaux de communication entre les
n÷ud capteurs.
Les schémas traditionnels des protocoles MAC, peuvent être classés suivant les méca-
nismes adoptés pour le partage des ressources de communication. Le tableau 1.1 fournit
une vue globale sur les avantages, les inconvénients et les domaines d'applications de
chaque classe.
Catégories Modes de partage
des ressources
Domaines
d'application
Inconvénients
Assignement
dédié ou
Allocation xe
Une allocation xe
prédéterminée
Approprié au trac
continu et donne
des délais bornés
Non ecace pour
le trac discontinu
Basé sur la
demande
Suivant la
demande ou la
requêtes de
l'utilisateur
Utile pour les taux
de transmission
variables et le
trac multimédia
Messages de
contrôle
supplémentaires à
cause du processus
de réservation
Accès aléatoire
ou basé sur la
contention
Concurrence sur le
canal quand les
paquets à
transmettre sont
disponibles
Convenable pour le
trac discontinu
Non ecace pour
le trac sensible au
délai de
transmission
Table 1.1: Classement des protocoles MAC
Un protocole MAC conçu pour les réseaux de capteurs sans l doit donc décider
à quel moment un n÷ud doit entrer dans l'une des trois phases suivantes : mise en
veille, transmission et écoute/réception. Ces diérentes phases doivent s'alterner tout
en essayant de fournir un accès able, une faible latence et un débit équitable pour
tous les n÷uds.
Le médium sans l est half-duplex, ce qui signie qu'un n÷ud ne peut pas simul-
tanément transmettre et réceptionner des données. La coordination entre les diérents
n÷uds est primordiale pour éviter les transmissions simultanées brouillant le signal
radio, ce qui génère des collisions.

Comme les noeuds capteurs sont des composant micro-électroniques, il ne peuvent
être équipés que par des sources limitées d'énergie (0.5 Ampère-heure, 1.2 V)[KB04].
Pour réduire drastiquement la consommation énergétique des noeuds, la solution prin-
cipale consiste à placer le composant radio en mode veille le plus souvent possible. Ceci
risque cependant de poser un problème de synchronisation. En eet, les données seront
perdues si la radio d'un noeud est en veille lorsqu'une transmission lui est adressée. Les
protocoles MAC adaptés aux réseaux de capteurs sans l devront faire en sorte que la
source et le destinataire d'une trame soient éveillés durant la même période pour que
la transmission soit un succès [Rot12].
1.1.3 Vérication des protocoles MAC dans WSNs
Plusieurs protocoles MAC dédiés pour les réseaux de capteurs corporels sans l ont
été proposés, chacun a des caractéristiques spéciques. Une étude sur les protocoles
MAC les plus connus a été proposé dans [DEA+
06].
Certaines applications qui impliquent des systèmes complexes exigent un niveau de
sûreté et de abilité élevé. L'utilisation des méthodes de spécication et de vérication
dans le cycle de développement de tels systèmes permet d'assurer un développement
able, de réduire le coût de maintenance et d'avoir un système sûr de fonctionnement.
Dans la littérature on trouve plusieurs techniques de vérication. La méthode tradi-
tionnelle de vérication est la simulation, puis vient la vérication formelle.
1.1.3.1 Vérication par la simulation
La technique de vérication principale des protocoles de MAC conçus pour WSNs
est la simulation. Cette méthode consiste à l'essai de tester le bon fonctionnement d'un
composant en le soumettant à un système réel d'évaluation.
Le comportement de certains protocoles MAC de la norme IEEE 802.15.4 [C+
03] ont
été largement vérié par des simulations dans des réseaux à un seul saut dont [MSM06,
PDMS+
09, PEE+
08].
L'évaluation de performance du mécanisme CSMA/CA (Carrier Sense Multiple Ac-
cess with Collision Avoidance) de l'IEEE 802.15.4 MAC a aussi attiré une grande atten-
tion. Il a été par conséquent évalué en utilisant l'enchaînent du Markov dans [MM05]
et [MSM05]. Les résultats analytiques proposés ont illustré le débit et le délai d'accès
dans le réseau.
1.1.3.2 Vérication formelle
La validation formelle est un processus [CW] qui permet de prouver qu'un sys-
tème se comporterait en parfait accord avec sa spécication. Cela revient à utiliser des
approches mathématiques qui permettent de montrer que l'implémentation satisfait
la spécication. Dans ce cas une considération de tous les cas possibles est implicite.
Cette méthode de vérication consiste à construire un modèle du système à l'aide d'un
formalisme, à exprimer les propriétés qui doivent être satisfaites par le système à l'aide
d'un autre formalisme, puis à eectuer la vérication des propriétés par le modèle à
l'aide d'outils mathématiques.

1.2 Les réseaux de capteurs corporels sans fils (WBAN) 5
Des travaux importants de la vérication formelle des protocoles MAC pour RCSFs
ont été proposés :
ˆ Le protocole S-MAC [YHE04] :
les auteurs dans [BM06] ont vérié l'accessibilité des paquets vers le coordinateur
(sink) pour un modèle de réseau simple de 3-hop. En particulier, ils ont vérié
la propriété suivante Combien de temps faut-il pour les paquets envoyés par le
noeud source pour atteindre la destination (coordinateur)?. Après cela, par le
marquage du modèle avec des valeurs de coût, il a été possible d'évaluer le temps
de latence de communication et de la consommation d'énergie attendue. Bien que
le modèle probabiliste de contrôle S-MAC au sein de PRISM [HKNP06] a été
fait avec succès, ce travail soure du problème commun de l'explosion des états.
ˆ Le protocole ECO-MAC [ZBADB07] :
La vérication du modèle probabiliste de ECO-MAC au sein de PRISM [ZBA10]
a mis l'accent sur la procédure de backo aléatoire. Les propriétés liée aux ex-
péditeurs cachés tel que la propriété suivante si les deux expéditeurs cachés ont
commencé leur transmission simultanément, une collision se produit et détecté
par le récepteur , a été veriée avec succès. Pendant le processus de vérication,
un problème imprévisible lié à l'explosion des états est apparu après plus de 4
heures de la construction de modèles.
1.1.4 Domaines d'application
L'intérêt des réseaux de capteurs est réellement vu à travers l'éventail très large
des domaines d'application. Ces derniers peuvent être subdivisés en plusieurs familles,
entre autres le domaine militaire (détection des attaques biologiques et chimiques;
surveillance de la position des soldats), le domaine environnemental (le suivi les mou-
vements des oiseaux, de petits animaux et des insectes; la détection des incendies de
forêt; recherche météorologique et géophysique), le domaine des maisons intelligentes
(réglage de l'éclairage en fonction de la position des habitants), le domaine de l'indus-
trie (la construction d'espaces de bureaux intelligents; la surveillance de la fatigue des
matériaux), et le domaine de la santé (la télésurveillance des données physiologiques
humaines; le suivi des médecins ainsi que des patients dans un hôpital) [ASSC02].
Nous allons développer ce dernier domaine d'application des réseaux de capteurs sans
ls dans ce qui suit.
1.2 Les réseaux de capteurs corporels sans ls (WBAN)
Dès la n du 20ème siècle, on observe une évolution dans l'utilisation des réseaux
de capteurs sans l. Ces derniers sont adoptés pour la surveillance des personnes âgées
plus que 65 ans. Leur nombre augmente graduellement qu'il peut dépassé 761 millions
en 2025. C'est pourquoi, l'utilisation de ce réseaux peut aider à surmonter la penurie
du personnels médicals dans les établissements de santé autour du monde [IJZ04]. Les
systèmes d'automatisation de soins de santé basés sur les réseaux de capteurs sans l
sont appelés les réseaux corporels.

Les réseaux de corps sans l signient la technologie naissante avec le potentiel
pour révolutionner des services médicaux en permettant la santé discrète contrôlant
pendant de longues périodes de temps [IJZ04] [RMJ04].
Un WBAN typique se compose d'un certain nombre de plateformes de capteurs peu
coûteux, légers et miniatures, chacune comportant un ou plusieurs capteurs physio-
logiques : détecteurs de mouvement, électrocardiogrammes (ECG), électromyographie
(EMG), et/ou des électroencéphalogrammes (EEG). Les capteurs peuvent être situés
sur le corps comme de minuscules taches intelligentes, intégrées dans les vêtements, ou
implantés sous la peau ou les muscles.
L'institut des ingénieurs électriciens et électroniciens (IEEE Institute of Electrical
and Electronics Engineer ) a publié un premier standard pour les WBAN en 2012
(IEEE 802.15.6) [A+
12b] et en donne la dénition suivante :
Une norme de communication optimisée pour les appareils à basse consommation et
qui fonctionnent sur, dans ou autour du corps humain (mais non limitée aux humains)
pour servir une diversité d'applications (y compris médicales), l'électronique grand pu-
blic, le divertissement et autre.
Les WBANs se distinguent des réseaux de capteurs classiques (WSN) par de nom-
breux points clés résumés dans le tableau 1.2 [LBM+
11]. Également, quatre préoccu-
pations particulières devraient être prises en compte dans WBAN :
1. les n÷uds de capteurs sont xés sur/dans le corps, de sorte qu'ils sont libres de
la mobilité ;
2. la distance entre deux noeuds de capteurs sont toujours à la portée du bras
d'une personne (2 m), ce qui les rend moins consommant de l'énergie à la
synchronisation [FL06][Cha12];
3. les n÷uds de capteurs doivent être équipés de batteries en petites dimensions
qui orent une puissance continue pendant quelques mois voire plusieurs années
[LKR04][EM12].
4. L'éclatement de détection des événements comme des alertes d'urgence, les don-
nées physiologiques critiques, et des ux multimédias, sont souvent arrivés et
tracs de déclenchement.
1.2.2 Protocoles MAC pour les WBANs
Selon la norme IEEE 802.15.6, Le WBAN doit avoir un hop et un certain nombre de
noeuds, qui vont de zéro à mMaxBANSize(64) [UMA13]. L'ordonnancement de trans-
fert de ux de messages entre ces composants est le rôle du protocole MAC implémenté
dans le réseau.

Caractéristiques WSN WBAN
Taille m/km cm/m
Nombre de
n÷uds
Grand nombre,
grande couverture
Petit nombre, espace
limité
Taille des n÷uds Petit taille préférée,
mais pas nécessaire
Petite taille nécessaire
Débit des n÷uds Souvent homogènes Souvent hétérogènes
Fiabilité Obtenue par la
redondance des
n÷uds
Obtenue par la
robustesse des n÷uds
Remplacement
des noeuds
Faisable facilement,
possibilité de noeuds
jetables
Dicilement
réalisable, surtout en
cas d'implants
Récupération
d'énergie
Solaire ou Eolien Mouvements ou
chaleur du corps
Compatibilité
Biologique
Peu considérée Grande importance
Niveau de
sécurité
Faible Élevée (informations
médicales)
Eet de la perte
de données
Compensée par la
redondance
Critique, requiert des
mesures spéciques
Technologie
sans l
Bluetooth, ZigBee,
GPRS...
Technologie à faible
puissance requise
Table 1.2: Étude comparative entre WSN et WBAN
Il existe des protocoles MAC conçus pour RCSFs en général, mais ils pourraient
aussi être utilisés pour les WBANs. La norme IEEE 802.15.4 a été considéré comme
l'un des plus protocole approprié pour les WBANs pour de nombreuses raisons tels que
la prise en charge des communications de faible puissance et des applications à faible
débit de données.
De nombreux chercheurs ont proposé divers protocoles MAC pour WBAN. Certains
d'entre eux ont été soumis au Groupe 6, qui a été formé en 2007 pour faire face aux
problèmes/questions de WBAN et de dénir des normes pertinentes. En raison de la
similitude des WBAN et WPAN (Wireless Personal Area Network), les protocoles les
plus proposés sont basés sur la structure de superframe de l'IEEE 802.15.4. Toutefois,
les exigences de communication et de haute qualité de service à temps critique sont
nécessaires pour WBAN, dont IEEE 802.15.4 tombe court. Pour atteindre les exigences
de qualité de service pour les applications temps critique de WBANs , un certain
nombre de protocoles qui ne sont pas basées sur IEEE 802.15.4 ont été proposées
jusqu'à présent [SZ09, ZD09, MPS+
09, AALUK11, EHDELR03].
1.2.3 Vérication des protocoles MAC dans WBANs
Le test et la vérication des systèmes d'information de santé est une question dicile
et importante, car les défauts de ces systèmes critiques peuvent conduire à la perte de

vies humaines, et dans les meilleurs cas, la perte d'argent et de réputation. Cependant,
au mieux de notre connaissances, il n'existe aucune proposition de vérication formelle
pour des protocoles MAC d'un réseaux corporel dans l.
Cette section couvre les avantages et les inconvénients de certains de ces protocoles
MAC proposés pour WBANs. Les protocoles sont introduits en mettant l'accent sur
la consommation d'énergie et de la façon dont ils abordent l'inecacité énergétique
causée par collision, idle listening, overhearing, et le contôle des entêtes des paquets.
1.2.3.1 Le protocole MedMAC
Medmac [TS09] est l'un des protocoles proposés basés sur TDMA pour WBANs
an d'améliorer l'ecacité énergétique et l'accès au canal. Un nouveau mécanisme
avec multisuperframe est utilisé pour la synchronisation périodique. Une période de
contention optimale est utilisée pour l'initialisation du réseau, pour le trac d'urgence,
et pour la faible diusion de données.
Des simulations sont eectuées en utilisant OPNET [Cha99] pour comparer les per-
formances de MedMAC avec celle de l'IEEE 802.15.4 en termes de dissipation d'énergie.
D'après les résultats de simulation dans [FD09], il est observé que MedMAC surpasse
IEEE 802.15.4 en termes de consommation d'énergie.
Cependant, medmac prend des applications de trac à faible données en considéra-
tion, ce qui n'est pas toujours applicable dans WBANs où les taux de données pour les
n÷uds de capteurs du corps humain peut être élevé [XR15].
1.2.3.2 Le protocole Heartbeat-Driven MAC
Heartbeat-Driven est un protocole basé sur TDMA qui utilise le rythme cardiaque
pour la synchronisation [LT10]. Ce protocole utilise un réseau topologie en étoile avec
une allocation GTS(Guaranteed Time Slot) pour la communication de données sans
collision. Les rythmes cardiaque sont utilisés à la place des messages de contrôle pério-
diques pour la synchronisation de réseau requise par le mécanisme de TDMA. Infor-
mations du rythme cardiaque sont extraits à partir des données sensorielles par chaque
noeud de biocapteur pour la synchronisation. Le coordinateur est responsable d'attri-
buer des créneaux temporels à des noeuds individuels et calculer le nombre de cycles
de trame pour la synchronisation. L'utilisation du rythme pour la synchronisation du
rythme cardiaque réduit la consommation d'énergie.
Cependant, le rythme cardiaque ne peut pas être à la disposition de tous dans/sur
ou autour des n÷uds de capteurs de corps humains. Dans de tels cas, il est dicile de
se synchroniser avec le système. D'autre part, la complexité augmente si les noeuds de
capteurs sans information de rythme cardiaque sont intégrés avec d'autres noeuds de
capteurs [XR15].
1.2.3.3 Le protocole CIGALE
Un protocole inter-couche, CIGALE (Cascading Information retrieval by Control-
ling Access with Distributed slot Assignment) a été proposée dans [LBM+
07] pour le

1.3 TDMA : Time Division Multiple Access 9
faible retard et l'ecacité énergétique. Les auteurs ont utilisé une approche de Spanning
Tree pour déterminer la présence/l'absence de noeuds next-hop, et donc le calendrier
de transfert de données. En tirant parti de la topologie du réseau, CICADA applique
un mouvement descendant de l'information de contrôle et d'information vers le haut
des données le long de l'arbre de recouvrement. Cela permet le routage simplié, l'inter-
férence inférieure et à l'écoute de repos ; qui tous contribuent à l'ecacité énergétique
des réseaux de corps.
Les résultats de la simulation prouve que le protocole ore un faible retard et une
bonne résistance à la mobilité. La consommation d'énergie est faible, car les n÷uds
peuvent se mettre en mode sleep dans des slots où ils ne transmettent/reçoivent pas.
1.3 TDMA : Time Division Multiple Access
De manière générale, les réseaux de communication, notamment les réseaux sans
l utilisent un protocole d'accès multiple qui est conçu pour éviter les collisions de
paquets de données en raison d'une transmission simultanée des paquets de données
par de multiples émetteurs sur le réseau en utilisant le même canal. Un protocole qui
est entré en usage répandu est connu comme TDMA.
Time Division Multiple Access est une méthode d'accès au canal (CAM) utilisé
pour faciliter le partage de canaux sans interférence.Il permet à plusieurs noeuds de
partager et d'utiliser le même canal de transmission en divisant les signaux en diérents
intervalles de temps. Les utilisateurs transmettent en succession rapide, et chacun uti-
lise son propre intervalle de temps. Ainsi, plusieurs stations peuvent partager le même
canal de fréquence, mais seulement utiliser une partie de sa capacité.
L'aectation d'intervalle de temps peut être soit xe (TDMA classique) ou variable
(TDMA sur la base de réservation). Dans les deux cas, puisque le nombre de noeuds
est ni, les données sont généralement transmises dans TDMA frame, qui assurent
que les retards rencontrés par les diérents utilisateurs sont nis [Ngo03].
Par exemple, selon TDMA classique, la trame TDMA est constitué du nombre total
de slots horaires attribués à tous les noeuds, après quoi le frame TDMA répète.
Dans le cas de TDMA sur la base de réservation, un encadrement naturel se produit
en termes de diérentes phases de la trame TDMA, constitué généralement d'une
phase de contrôle dans lequel les réservations sont demandées et attribuées, et une
phase de données dans lequel le les données sont transmises par les diérents noeuds
dans leurs tranches de temps respectives aectées.
1.3.2 Vérication formelle des systèmes basés sur TDMA
Une caractéristique importante des systèmes basés sur TDMA est que ce sont des
systèmes en temps réel. Par conséquent, l'utilisation des automates temporisés en tant

1.4 S-TDMA : Statistical frame based TDMA 10
que modèles pour les systèmes TDMA est un choix naturel. Les applications indus-
trielles des systèmes à base TDMA comportent un grand nombre de composants. Mo-
délisation de telles applications industrielles utilisant des automates temporisés va donc
impliquer un grand nombre d'automates. Raisonnant sur ces systèmes en général re-
quieres une composition des composants. Un problème commun dans le modèle de
vérication de ces modèles, est le problème que l'on appelle l'explosion de l'État.
Lönn et Pettersson [LP97] considèrent les algorithmes de start-up pour les systèmes
TDMA, et vériez l'un d'entre eux en utilisant UPPAAL [LPY97]. Leur modèle est
limité à quatre n÷uds et ne traite pas les défauts. Lönn et Pettersson ont noté que
l'extension de l'analyse à plus de quatre n÷uds sera très dicile, que la vérication
d'un système à quatre n÷uds était proche de l'épuisement de la mémoire 2 Go de
leur ordinateur, et le coup exponentielle des automates temporisés lorsque le nombre
d'horloges augmente.
Dans [Rod15], une étude de la vérication formelle des systèmes basés TDMA a été
établi en applicant la théorie des automates temporisés [BL11] et en évitant le problème
de l'explosion d'état pour accélérer les temps de vérication.
1.4 S-TDMA : Statistical frame based TDMA
S-TDMA [NLH+
15] est un un nouveau protocole MAC, conçu pour WBAN, qui
a été implémenté sur une plateforme HBC (Human Body Communication) où quatre
n÷uds de capteur et un coordinateur sont attachés sur un corps humain [NLH+
15][CNI+
13].
Dans notre mémoire de recherche, nous avons choisi d'étudier la abilité ainsi que la
cohérence de ce protocole MAC, en appliquant sa vérication formelle sur le modèle
que nous proposions aussi.
Par rapport aux protocoles traditionnels, les résultats démontrent que S-TDMA
répond avec succès aux exigences de retard et de l'ecacité de transmission de HBC
tout en conservant une faible consommation d'énergie.
La structure du superframe :
La supertrame de S-TDMA dure une seconde et consiste en deux périodes : une période
active et une période inactive, comme il est illustré sur la Figure 1.1, avec n est le
nombre de n÷uds de capteurs.
La durée des créneaux horaires destinés pour la procédure de l'envoi/réception des
données est ajustée par le coordinateur sur la base des caractéristiques de trac actuel.
Pour économiser de l'énergie, une période d'inactivité est réservée aux n÷uds, en leur
permettant d'entrer au mode Sommeil.
La partie active se compose de plusieurs types de trames (tableau 1.2) :
ˆ Trame de synchronisation Beacon
Le coordonnateur transmet régulièrement un paquet beacon pour la synchroni-
sation de réseau

Figure 1.2: Structure du superframe STDMA
ˆ Trame des requêtes
Les n÷uds de capteurs envoient leurs demandes au coordinateur pendant leurs
slots assignés. Étant donné que le nombre de n÷uds de capteurs dans un WBAN
est toujours limité, il est applicable à donner tout les n÷uds leurs slots par défaut
par programmation.
Quand un nouveau n÷ud est associé au réseau, le coordinateur alloue un slot
pour le nouveau venu automatiquement an qu'il puisse envoyer une trame de
requête pendant son propre intervalle de temps alloué. Il est à noter que le slot
attribué au nouveau n÷ud est toujours après les anciens.
ˆ Trame statistique
le coordinateur ordonne tous les slots nécessaires demandés par les n÷uds pour
former une trame statistique. Par conséquent, la trame statistique contient le
temps total de slots demandé et les diérentes requêtes de tous les n÷uds de cap-
teurs. Ensuite, le coordinateur envoie la trame statistique avec des informations
de planication à tous les n÷uds de capteurs.
ˆ Trame de données
Après recevoir les informations de planication, chaque n÷ud attendra jusqu'à
ce que le slot accordé vient pour envoyer son paquet de données.
ˆ Trame de retransmission acknowledgement
le coordinateur additionne toutes les paquets de données reçus, extraire leurs
informations et les comparer à ceux des trames de requêtes. De cette façon, le
coordinateur détermine les n÷uds de capteurs qui ont subi une perte de paquets.

Nom du
trame
Format du trame
Trame de
synchroni-
sation
Type de
Trame
Adresse de
destina-
taire
Adresse de
l'émetteur
Temps de
synchroni-
sation
CRC
Trame de
requête
Type de
Trame
Adresse de
destina-
taire
Adresse de
l'émetteur
Nombre de
slots
demandés
CRC
Trame
statistique
Type de
Trame
Adresse de
destina-
taire
Adresse de
l'émetteur
le totale
des slots
ID de
noeud et
slots
aectés
CRC
Trame de
données
Type de
Trame
Adresse de
destina-
taire
Adresse de
l'émetteur
la
séquence
de frame
Données CRC
Trame de
retrans-
mission
Type de
Trame
Adresse de
destina-
taire
Adresse de
l'émetteur
Temps de
synchroni-
sation
ID de
noeud et
slots
aectés
CRC
Table 1.3: Formats des trames modélisées
Il organise des slots pour eux dans la période de retransmission. Enn, il envoi
le paquet de ackowledgement à tous les n÷uds sauf ceux du mode Sommeil.
Les auteurs aussi utilisent l'allocation dynamique des slots pour gérer les change-
ments dans le comportement des noeuds. Tout d'abord, après la mise sous tension
et l'initialisation de la plate-forme, le coordinateur envoie la trame beacon à tous les
n÷uds de capteurs pour la synchronisation de réseau. Deuxièmement, chaque noeud de
capteur synchronise son horloge en temps réel (RTC) selon les informations reçues et
envoie alors une trame de requête au coordinateur en fonction du nombre de paquets de
données qu'il doit envoyer. En troisième lieu, le coordinateur traite toutes les requêtes
et envoie des informations de planication à tous les n÷uds de capteurs [BCF+
09].
De cette façon, la structure de la supertrame change dynamiquement en fonction des
circonstances. l'attribution des slots dynamique permet également de réduire la période
active dans chaque cycle, rendant ainsi WBAN plus économe en terme d'énergie.
Conclusion
Dans ce chapitre, nous avons donné une vue globale des protocoles MAC dans les
réseaux de capteurs corporels sans l. Nous indiquons que notre but est de concevoir un
modèle à un haut niveau d'abstraction du protocole S-TDMA. Aussi bien, nous allons
étudier en détails les outils et les langages utilisés durant la phase de réalisation.

2Préliminaires : l'environnement à base de
composants BIP
Introduction
Une idée centrale dans l'ingénierie des systèmes est que les systèmes complexes
sont construits par assemblage de composants. Les concepteurs de systèmes traitent
avec une grande variété de composants, chacun ayant des caractéristiques diérentes,
à partir d'une grande variété de points de vue, chacun mettant en évidence les dif-
férentes dimensions d'un système. Le problème central rencontré par les concepteurs
est la composition signicative des composants hétérogènes pour assurer leur correcte
interopérabilité.
BIP (Behavior, Interaction, Priority) est un framework rigoureux à base de com-
posants qui permet de construire des modèles complexes et hiérarchiques à partir de
composants atomiques caractérisés par leur comportements et leurs interfaces. Il fournit
un langage et une théorie pour la composition incrémental de composants hétérogènes,
assurant l'exactitude par la construction des propriétés essentielles du système telles
que l'exclusion mutuelle, deadlock freedom et le progrès. En outre, il permet la véri-
cation formelle[Yov15]. Nous exposons la sémantique formelle du cadre BIP, comme
est déni dans [BBB+
11b, Yov15, Bas08].
2.1 Description de BIP
BIP est un framework englobant une conception rigoureuse. Il utilise le langage
BIP et un ensemble d'outils associés supportant le ux de conception. Le langage BIP
est une notation qui permet de construire des systèmes complexes en coordonnant
le comportement d'un ensemble de composants atomiques. Le comportement est dé-
crit comme un réseau de Petri étendu avec les données et les fonctions décrites dans
13

2.2 Architecture 3-tiers de BIP 14
C[BBB+
11a].
BIP utilise des connecteurs pour spécier les intéractions possibles entre les compo-
sants et les priorités pour sélectionner parmi les intéractions possibles. Les intéractions
expriment des contraintes de synchronisation entre les activités des composantes com-
posées, et les priorités ltrent les interactions possibles pour orienter l'évolution du
système en vue d'atteindre les exigences de performance. Enn, BIP prend en charge
un ux de conception rigoureuse caractérisée par ce qui suit :
ˆ Il est à base de modèle ; tout le logiciel et les descriptions de système utilisées le
long du ux de design(conception) devraient être basées sur un modèle séman-
tique unique.
ˆ Il est à base de composants; qui fournit des primitives pour construire des com-
posants composites comme la composition de composants plus simples.
ˆ Il se repose sur la théorie traitable ce qui garantit l'exactitude de la construction
an d'éviter autant que possible la vérication a posteriori monolithique.
Le ux de conception BIP est soutenu par un ensemble d'outils comprenant des
traducteurs de diérents modèles de programmation en BIP, transformateurs source à
source, ainsi qu'un compilateur pour générer un code exécutable par un des moteurs
dédiés. Une nouvelle version de BIP (BIP2), qui comprend actuellement seulement un
compilateur C++ ciblant la génération de code et les moteurs monothread centralisés
correspondants [BBB+
11a].
2.2 Architecture 3-tiers de BIP
BIP est basé sur une architecture 3-tier. Les composants sont constitués par la
superposition de trois couches suivantes (Voir la Figure 2.1) [Bas08] :
Figure 2.1: Structure d'un modèle BIP
ˆ Comportement :
Décrit le comportement dynamique d'un composant. Il se compose d'un ensemble
de systèmes de transition étiqueté (LTS : Labeled Transition System). Chaque
transition a un port, une garde et une fonction. Les gardes sont des conditions
en fonction de l'état local. Les ports caractérisent l'aptitude du composant à
interagir avec un environnement donné.

2.3 Les composants du framework BIP 15
ˆ Intéractions :
Décrivent les contraintes architecturales sur le comportement. Ce sont des chan-
gements d'état conjoints des composants composés utilisés pour coordonner leur
exécution.
ˆ Priorités :
Fournissent un mécanisme pour limiter le comportement global des couches en
dessous par ltrage parmi les interactions possibles. Ils aident à réduire la non-
déterminisme dans l'exécution des interactions entre les composants. Ils sont
utiles pour l'application de l'état des propriétés invariantes telles que l'exclusion
mutuelle et les règles de planication
2.3 Les composants du framework BIP
Le langage BIP soutient une méthodologie pour la construction de composants à
partir de composants atomiques, de connecteurs et de relations de priorité [BBS06].
2.3.1 Composants atomiques
Les composants atomiques sont les composants les plus simples avec un compor-
tement décrit par un automate ou un réseau de Petri étendu avec des données. Un
composant atomique est déclaré avec la directive atom type qui contient :
1. une liste éventuellement vide de variables pour stocker les données. Les déclara-
tions de données peuvent être exportées pour devenir accessible aux priorités.
Dans BIP2, les variables(données) sont utilisées pour stocker des données. Pour
la déclaration d'une variable, nous utilisons la primitive Data [BBS06]. Par
exemple, dans ce qui suit nous déclarons une variable de type entier nommée x :
data int x
2. une liste facultative de déclarations de ports qui peuvent référencer des variables.
Les ports exportés sont accessibles aux connecteurs.
Les atomes ont des ports déclarés avec la directive port qui se compose d'un
type, un nom et une liste facultative de variables précédemment déclarées. Un
erreur se déclenche si les types des variables précédemment déclarées ne corres-
pondent pas au type des paramètres de port correspondant [BBS06].
La déclaration implicite n'est pas autorisée. Par exemple, si un paramètre pré-
cédemment déclaré est de type oat, un paramètre de port de type int n'est pas
autorisé. Dans le code extrait suivant, trois variables nommées a, b et c sont
associés aux trois paramètres du port avec le type PortT [BBS06] :
3. un automate ou un réseau de Petri qui dénit le comportement de l'atome. Le
comportement est décrit par un ensemble de transitions qui modient l'état de
l'atome en réaction aux ports activés. Dans notre étude, nous avions besoin de
modéliser le temps et alors nous avons utilisé les automates temporisées pour
dénir les comportement de nos composants.

port type PortT(int x, oat y, someType z)
atom type SomeType()
data int a
data oat b
data someType c
port PortT p(a, b, c)
...
end
Les automates temporisés [ALU 94a] ont été introduits par R.Alur et D.Dill dans
les années 1990. Il s'agit d'automates classiques munis d'horloges qui évoluent
de manière continue et synchrone avec le temps. Chaque transition contient une
garde (sur la valeur des horloges) décrivant quand la transition peut être exécutée
et un ensemble d'horloges qui doivent être remises à zéro lors du franchissement
de la transition. Chaque état de contrôle contient un invariant (une contrainte
sur les horloges) qui peut restreindre le temps d'attente dans l'état et donc forcer
l'exécution d'une transition d'action [BL11].
Le domaine de temps peut être N, l'ensemble des entiers naturels, ou bien Q=0,
l'ensemble des rationnels positifs, ou bien même R=0, l'ensemble des réels posi-
tifs. Ici, nous supposerons que c'est R=0, mais il faut remarquer que la plupart
des résultats ne sont pas modiés lorsque l'on considère Q=0 ou N [BL11].
Quelques notations
ˆ Soit X un ensemble d'horloges à valeur dans R=0. Une valuation v pour X est
une fonction (v : X → R=0) qui associe à chaque horloge x sa valeur v(x). On
note RX
=0 l'ensemble des valuations pour X. Étant donné un réel d ∈ R=0, on
note v + d la valuation qui associe à l'horloge x la valeur v(x) + d. Si r est un
sous-ensemble de X, v représente la valuation v dénie par : v (x) = 0 pour tout
x ∈ r et v (x) = v(x) pour x ∈ X r [BL11].
ˆ On note C(X) l'ensemble des contraintes d'horloges sur X, i.e. l'ensemble des
combinaisons booléennes de contraintes atomiques de la forme x c avec x ∈ X,
b ∈ {=, , ≤, , ≥} et c ∈ N. On désigne par C(X) la restriction de C(X)
aux combinaisons positives ne contenant que des contraintes x ≤ c ou x c.
Les contraintes d'horloges s'interprètent de manière naturelle sur les valuations
d'horloges : une valuation v satisfait une contrainte atomique x c lorsque
v(x) c, l'extension aux contraintes quelconques est alors immédiate. Lorsqu'une
valuation v satisfait une contrainte g, on écrit v |= g [BL11].
Formellement, un automate temporisé A est un 6-uplet (L, l0, X, Inv, T, Σ) où [BL11] :
ˆ L est un ensemble ni d'états de contrôle ou localités,
ˆ l0 ∈ L est la localité initiale,
ˆ X est un ensemble ni d'horloges,

ˆ T ⊆ L×C(X)×Σ×2X
×L est un ensemble ni de transitions; e = l, g, a, r, l ∈
T représente une transition de l vers l , g est la garde associée à e, r est l'ensemble
d'horloges devant être remises à zéro et a est l'étiquette de e,
ˆ Inv : L → C(X) associe un invariant à chaque état de contrôle,
ˆ Σ est un alphabet d'action.
Un état ou une conguration d'un automate temporisé est une paire (l, v) ∈ L ×
RX
=0 où l représente l'état de contrôle courant et v une valuation pour les horloges.
La sémantique d'un automate temporisé est dénie sous la forme d'un système de
transitions temporisé qui comporte des transitions d'action (étiquetées par un élément
de Σ) et des transitions de temps (étiquetées par des durées réelles) [BL11].
Un système de transition temporisé (STT) est un quadruplet S = (S, s0, →, Σ) où
S est un ensemble (éventuellement inni) d'états, s0 ∈ S est l'état initial et →⊆
S ×(Σ∪R=0)×S est la relation de transition. La relation → vérie les trois propriétés
suivantes ; (1) si s
0
−→ s , alors s = s , (2) si s
d
−→ s et s
d
−→ s” avec d, d'∈
R=0, alorss
d+d
−→ s”, et (3) si s
d
−→ s avec d∈ R=0, alorspourtout0≤ d ≤ d, il existe
s” ∈ S tel que s
d
−→ s” [BL11].
Exemple 1 : Un composant atomique
Figure 2.2: Exemple : Composant atomique
La Figure 2.2 montre un composant K avec une interface composée de ρ = {in, out}.
Les ports in et out étiquettent les transitions de K, qui a aussi une transition interne
marquée par τ et qui correspond à un calcul interne eectué par K et qui ne sont
pas synchronisés avec l'environnement à eectuer. Les invariants des deux états de
K sont dénis sur la variable d'état y. De même, les gardes sur les transitions sont
également dénies sur des variables d'état y1 et y2. Cependant, pour l'échange de

données avec son environnement, K utilise les variables transitoires x1 et x2 associés à
ses ports. En eet, le transfert des données est eectué dans les prédicats des fonctions
associés aux transitions marquées par ces ports. Le comportement global de K prend
une valeur de l'environnement (autres composants), faisant quelques calculs locaux en
utilisant ces valeurs, puis il donne les nouvelles valeurs résultants à l'environnement
par l'intermédiaire du port out.
2.3.2 Connecteurs et intéractions
Un connecteur est un ensemble de ports de composants qui peuvent être impliqués
dans une interaction. Le nombre d'interactions d'un connecteur peut croître de façon
exponentielle au nombre de ports. Graphiquement, les connecteurs sont représentés
comme des arbres avec des ports à leurs feuilles [Bas08].
Sur la base de la structure des interactions représentées par des connecteurs, ils sont
classés comme connecteur simple et connecteur structuré.
2.3.2.1 Connecteur simple
Un connecteur simple est déni par un ensemble de ports. Une interaction d'un
simple connecteur est un sous-ensemble non vide de son ensemble de ports. Par exemple,
un simple connecteur constitué par les ports p1, p2 et p3; l'ensemble des interactions
possibles : {p1}, {p2}, {p3}, {p1 p2}, {p2 p3}, {p1 p3} et {p1 p2 p3} (Voir Tableau 2.1).
Chaque interaction non triviale, à savoir, l'interaction avec plus d'un port, représente
une synchronisation entre les transitions marquées avec ses ports. Les auteurs dans
[Bas08] utilisent le terme connecteur pour désigner des connecteurs simples.
Après des résultats dans [GS05], [Bas08] introduit un mécanisme qui précise les
interactions possibles d'un connecteur, et en particulier pour exprimer les deux modes
de base de synchronisation suivants :
ˆ Une forte synchronisation ou rendez-vous, quand la seule interaction possible d'un
connecteur est le maximum, à savoir, contenant tous les ports.
ˆ synchronisation faible ou diusion, lorsque les interactions possibles sont celles
contenant un port particulier qui déclenche l'émission.
Exemple 2 : Un connecteur simple
La Figure 2.3 représente deux exemples de connecteurs simples. Dans (a), le connecteur
γa relie les ports synchrones P1 et P2 à un port exporté Pγa. Dans ce connecteur la
seule interaction possible est {P1P2}. Dans (b), P1 est un élément déclencheur, et peut
se produire seul, même si P2 est impossible. Néanmoins, la présence de P2 nécessite la
présence de P1. Ainsi, les interactions dénies par (b) sont {P1, P1P2}.

Un port synchrone est passif, donc
il a besoin de synchroniser avec
d'autres ports, et est désigné par
un cercle. Une interaction possible
d'un connecteur est un ensemble
de ses ports de telle sorte que soit
il contient un certain trigger, ou
elle est maximale, à savoir, tous les
ports sont synchrone.
Un trigger est un port actif qui
peut initier une interaction sans
synchroniser avec d'autres ports. Il
est représentée graphiquement par
un triangle.
Dans ce connecteur, la seule inter-
action possible est {abc}.
Dans ce connecteur, l'ensemble
des interactions possibles est
{{a},{ab},{ac},{abc}}.
Table 2.1: Les types de ports et des connecteurs simples
Figure 2.3: Exemple de connecteurs simples
2.3.2.2 Connecteur structuré
Les connecteurs ont parfois besoin d'être structuré, à savoir, d'avoir des types asso-
ciés à des groupes de ports. Cela est nécessaire pour représenter certaines interactions,
qui, autrement, ne peuvent pas être représentés par un connecteur simple.
Considérons par exemple la diusion atomique (Figure 2.4), où nous avons besoin
de restreindre les interactions possibles à a et abc. Il est impossible de représenter cet
ensemble d'interactions par le biais d'un simple connecteur tel que présenté dans la
section précédente.

2.4 La boite à outils de BIP 20
Figure 2.4: La diusion atomique
La représentation des connecteurs structurés nécessite des connecteurs à être traités
comme des expressions. Cela a conduit à la formalisation de l'algèbre des connecteurs
dénis dans [BS10, BS08].
2.3.3 Priorité
Les priorités sont utilisés pour favoriser l'exécution d'un sous-ensemble d'interac-
tions activées appelé les interactions maximales. Ils peuvent être utilisés pour résoudre
les conits entre les interactions ou d'exprimer certaines politiques de planication[BCJ+
15].
Les priorités d'un composant, forment une relation d'ordre partiel qui correspond à
la fermeture transitive des règles de priorité dénies. Un ensemble de règles de priorité
est automatiquement dérivée basée sur le principe de progression maximale, à savoir les
interactions qui impliquent plusieurs connecteurs ont une priorité plus élevée [BCJ+
15].
Les règles de priorité dénis par l'utilisateur sont de la forme I J, où I et J sont
les interactions des connecteurs exprimées dans l'une des formes suivantes :
2.4 La boite à outils de BIP
La boite à outils de BIP fournit des moyens pour la modélisation, la simulation, la
génération de code et la vérication des modèles BIP. Une vue d'ensemble de la boite
à outils est illustré à la Figure 2.5. Les diérentes composantes de la boîte à outils BIP
sont présentés ci-dessous :
Le langage BIP
Le langage BIP est utilisé pour dénir types (pour les composants et connecteurs) et
décrire les architectures de composants (assemblage des instances de types) [BBB+
11a].
Traduction en BIP BIP Factories
Un système réel comprend plusieurs modèles de programmation. La traduction du
langage de programmation avec laquelle le système a été codé à un modèle BIP permet
sa représentation comme un framework sémantique et rigoureux.
Il existe plusieurs traductions de plusieurs modèles de programmation en BIP, y compris
LUSTRE [BSS09], MATLAB/Simulink [STS+
], AADL [CRBS08], les applications
GENOM [BGL+
08], les applications NESC/TinuOS [BMP+
07], le logiciel C et les
systèmes DOL [BBB+
10].

Figure 2.5: La boite à outils de BIP
Il existe une méthode générale pour générer des modèles BIP à partir d'un langage L,
qui comprend trois étapes :
1. la traduction des composants atomiques de la langue source en composantes BIP,
2. la traduction des mécanismes de coordination entre les composants système en
des connecteurs et des priorités dans le modèle BIP cible,
3. la génération d'un composant BIP modélisant la sémantique opérationnelle du
langage [BSS09].
Le compilateur Moteurs d'exécution dans BIP
Le compilateur BIP cible des moteurs d'exécution BIP. Le code généré et les moteurs
sont en C++. Les middleware sont responsable de la coordination des composants
atomiques, ils appliquent la sémantique des couches d'interaction et de priorité de BIP.
Les moteurs d'exécution peuvent être utilisés pour l'exécution, la simulation, le débo-
gage ou pour l'exploration des états de l'espace de modèles BIP [BBB+
11a].
Il existe actuellement trois moteurs d'exécution disponibles, single-thread [GS], multi-
thread [GS] et en temps réel [GS].

Figure 2.6: Compilateur et moteurs d'exécution dans BIP
Le méta-modèle BIP
Il est utilisé comme la représentation intermédiaire des modèles BIP. Il a été utilisé
pour mettre en ÷uvre des transformations de modèles [BBB+
11a].
Les transformateurs
La transformation d'un modèle abstrait BIP à un modèle BIP concret (à savoir les
implémentations) est obtenu en exprimant les mécanismes de coordination de haut
niveau, par exemple, des interactions et des priorités en utilisant des primitives de la
plate-forme d'exécution [BBB+
11a].
La génération du code
Le code monolithique C est généré à partir des ensembles de composants d'interaction
exécutés par la même unité de traitement. Cette transformation permet la mise en
÷uvre ecace en évitant le surcharge existant en raison de la coordination entre les
composantes [BSS09].
RTD-Finder
L'outil RTD-Finder met en ÷uvre une méthode pour la vérication des systèmes temps
réel à base de composants. Il vise à éviter l'exploration des espaces d'état qui sourent
en général de l'explosion des espaces d'état pour les systèmes avec un grand nombre
de composants. L'idée de base est de déduire les propriétés d'un système à partir des
propriétés de ses composants leurs interactions [Com15].
An de suivre la synchronisation temporelle entre les diérents composants, les auteurs
dans [Com15] utilise des horloges historiques supplémentaires, qui n'inuent pas sur le
comportement du système, et qui sont utilisés au cours du processus de vérication.

2.5 Discussion : choix du BIP 23
Pour chaque action (intéraction), les auteurs dans [Com15] associe une horloge de l'his-
toire qui est remis à zéro à chaque fois que l'action connexe se produit. L'historique
des horloges des actions est pris en compte lors du calcul des invariants locaux des
composants. Ceci induit des relations entre les horloges de chaque composant et de
ses horloges d'historisées. D'autre part, les relations entre les horloges historisées des
diérents composants sont déduites de la structure des intéractions. Ils sont formulés
dans un invariant supplémentaire que les horloges de l'historique des contraintes. Par
transitivité, les relations entre les horloges internes des diérents composants sont in-
duits. L'outil calcule l'invariant d'intéraction, ce qui limite les emplacements globaux
du système, comme dans l'outil DFinder qui a été conçu pour les systèmes untimed.
2.5 Discussion : choix du BIP
Le but de cette recherche est de concevoir un modèle de haut niveau et abstrait du
protocole S-TDMA pour un réseau de capteurs corporel sans ls. Ce modèle est très
avantageux pour analyser et pour vérier le bon fonctionnement et la performance du
protocole. En outre, nous proposons de générer automatiquement une implémentation
correcte du système.
Ainsi, la réalisation de notre contribution exige nécessairement un framework englo-
bant la conception rigoureuse, basé sur le modèle sémantique englobant la composition
des composants hétérogènes et fournissant des outils qui permettent de générer auto-
matiquement des implémentations correctes. En outre, l'outil de conception que nous
avons besoin doit être fondée sur un langage formel pour garantir une description abs-
traite, précise et complète de notre système. Cette formalité permet d'eectuer une
analyse rigoureuse qui est très utile pour évaluer correctement le protocole étudié dans
ce travail.
Au surplus, la formalité détermine des propriétés importantes telles que la cohérence,
le deadlock et la satisfaction des exigences de haut niveau ou l'exactitude d'une concep-
tion proposée. Également, grâce à cette modélisation formelle, nous pourrons analyser
les performances de notre système d'une manière abstraite telles que la consommation
énergétique, la latence des données et l'ecacité de la transmission. Ainsi, notre fra-
mework adopté doit fournir des outils de vérication formels an de valider la justesse
de notre modèle.
En outre, plusieurs outils de conception ont été développés en permanence pour
atténuer la complexité des systèmes critiques comme Java, C ++, UML, et CORBA
etc. Malgré les avantages oerts par ces outils, ces langues manquent à la sémantique
formelle qui rend la génération automatique de code dur et plus, ils ne fournissent pas
des outils pour les problèmes de vérication qui est essentiel pour vérier les propriétés
critiques.
Comme le cas du langage semi-formel et orienté objet UML (Unied Modeling Lan-
guage) qui fournit une description de haut niveau des systèmes et des moyens pour
dénir le comportement du système, mais ni la validation du comportement conçu ni
la génération automatique de code est possible.

2.5 Discussion : choix du BIP 24
En particulier, nous avons opté BIP comme langage formel de modélisation qui est
susant pour la réalisation de nos contributions. En eet, le framework BIP englobe
des concepts et des mécanismes de structuration de haut niveau. Il prend en charge la
distinction entre les comportements, les canaux et les directeurs. Aussi, BIP ore des
mécanismes basées sue les interactions et le contrôle pour l'intégration des composants.
Les deux types de mécanismes correspondent à la coopération et la concurrence, deux
concepts fondamentaux complémentaires pour l'organisation du système.
L'architecture de BIP(Voir section 2.2) fournit quelques caractéristiques intéres-
santes :
ˆ Tout d'abord, BIP prévoit la séparation des préoccupations [BBS06], ce qui si-
gnie que toute les combinaisons des modèles de comportement, d'interaction et
de priorité dénit véritablement un composant. La séparation des préoccupations
est essentiel pour dénir le processus de construction d'un composant comme la
superposition des transformations élémentaires le long de chaque dimension.
Deuxièmement, BIP prévoit l'unication qui signie les diérentes sous-classes
de composants, par exemple, non temporisé/temporisé, asynchrone/synchrone,
déclenché par un événement/déclenché par des données, peuvent être uniés par
des transformations dans l'espace de construction. Ceci permet une meilleure
compréhension des relations entre les cadres sémantiques existantes en termes de
transformations architecturales, comportementales et élémentaires.
ˆ Enn, BIP ore l'exactitude par construction : l'espace de construction des com-
posants fournit une base pour l'étude des transformations de l'architecture per-
mettant la préservation des propriétés de comportement sous-jacent. Les caracté-
risations de ces transformations peuvent fournir; des conditions susantes pour
l'exactitude de construction tels que compositionnalité et composabilité résultats
pour deadlock-freedom [GS] et la vivacité.
Comme suit, le framework BIP est tout ce que nous avons besoin an de répondre
à nos exigences et ainsi de réaliser parfaitement nos contributions.
Conclusion
Dans ce chapitre, nous avons introduit le framework à base de composants BIP
avec lequel nous avons réalisé notre travail. Dans le chapitre suivant, nous présentons
la première contribution dans ce mémoire qui est la modélisation formelle du protocole
S-TDMA.

3Modèle formel du protocole S-TDMA
Introduction
L'intérêt principale de l'approche formelle est qu'elle oblige le spécieur à énon-
cer sans ambiguïté ce que doit faire son programme, ainsi les problèmes sont soulevés
dès le début.
Dans ce chapitre, la première section comporte la description de l'architecture du
protocole étudié. Cette section présente aussi le modèle formel proposé dans ce mé-
moire, basé sur le langage BIP. Enn, nous discutons le choix du BIP comme un
système de conception.
3.1 Architecture du protocole S-TDMA
Le schéma de base pris en compte dans ce travail est illustrée sur la Figure 3.1. Il se
compose d'un coordinateur connecté à trois n÷uds de capteurs. Cependant le modèle
formel que nous proposons dans ce travail est décrit pour un nombre N de composant.
Où N est une variable qui peut être paramètrée selon les besoins du désigner. Et vu
que le protocole étudié S-TDMA est destiné pour les WBANs, le nombre de noeuds de
capteurs maximale N est égale à 64 [A+
12a].
Notre but est de proposer une conception formelle et de haut niveau à base de
modèles d'un protocole MAC basé sur une architecture TDMA, nommé S-TDMA. En
fait, nous prenons les avantages de l'expressivité du framework BIP pour présenter
d'une manière abstraite le protocole S-TDMA dans un réseau de capteurs corporel
sans l.
25

3.2 Le modèle formel proposé 26
Figure 3.1: Architecture du S-TDMA
La plupart des WBAN présentés dans les travaux ont une topologie en étoile à un seul
saut avec un assistant numérique personnel (PDA) ou un ordinateur individuel (le PC)
servant comme un coordinateur de réseau [UK10][YBO09]. Par conséquent, un réseau
en étoile à un seul saut basé sur la technique HBC (Human Body Communication) est
modélisé dans notre travail.
3.2 Le modèle formel proposé
Notre modèle sera composé des composants suivants :
ˆ Le composant C qui est un composant atomique (Voir la section 2.3.1) centrale
modélisant le coordinateur qui est obligatoirement lié à tous les autres composants
du modèle. Ce composant atomique contient (2N + 4) ports nommés : SB, RRi,
SS, RDi, SLP et END.
ˆ Les composants N1..NN qui sont des composants atomiques identiques modéli-
sant les n÷uds de capteurs présents dans notre modèle proposé. Chacun de ces
composants contient cinq ports nommés : RBi, SRi, RSi, SDi, SLPi et ENDi ;
avec i est l'identiant unique de chaque composant.
Tous ces composants interagissent en respectant les contraintes d'un modèle d'inter-
actions de BIP (voir section 2.3.2) dénie par un ensemble de connecteurs (voir section
2.3.2.1) reliant les ports de ces composants.
Un modèle BIP formel pour le système étudié est représenté sur la Figure 3.2, où nous
fournissons la description des diérents composants, connecteurs, ports et variables. La
communication entre les composants est modélisée par des interactions BIP.

Figure 3.2: Modélisation haut niveau du protocole S-TDMA pour un coordinateur et N
n÷uds
3.2.1 Les comportements internes des composants
Nous introduisons une représentation formelle du système où les composants sont
identiés par une abstraction de leurs comportements qui sont représentés par des
automates temporisés et étiquetés par des actions (qui sont aussi appelées des ports).
Figure 3.3: Le comportement interne du coordinateur
La Figure 3.3 ci-dessus représente le comportement interne du coordinateur. Le
comportement de ce composant représente quatre états de contrôle (Start, Req, Data
et Sleep). Dans ce qui suit, nous représentons l'ensemble des transitions représentants
le comportement interne du coordinateur :

1. Initialement, nous introduisons le nombre des n÷uds de capteurs qui seront pré-
sents dans le modèle et leurs créneaux horaires réservés à l'envoie/réception des
requêtes et calculés avec la fonction CrenHor(). Le coordinateur paramètre son
radio au mode de Transmission ce qui est présenté par la fonction paramé-
trée Radio(”S”, ”T”) ; le premier paramètre présente le mode précédent du radio
Sommeil et le deuxième paramètre présente le prochain mode Transmission.
2. La transition marquée par le port SB a lieu si le composant est à l'état Start.
Avec cette transition, la quantication du temps globale y recommence à chaque
cycle ainsi que la quantication du temps locale ts, avec la fonction reset(ts, y).
Aussi, le coordinateur modie son radio au mode Recevoir ce qui est présenté
par la fonctionRadio(”T”, ”R”) ;
3. Les transitions marquées par les ports RRi avec i ∈ [1..n] ont lieu successivement
lorsque le composant est à l'état Req. Le coordinateur a réservé pour chaque
n÷ud un créneaux horaire, ce qui est représenté par l'invariant du l'état Req
[ts = 500µs]. La transition se déclenche lorsqu'il aura lieu [t == tsi] avec
ts = timeslot présentant l'horloge de départ du créneau horaire assigné pour le
noeudi.
4. Après avoir nir de recevoir les demandes de créneaux horaires, la transition
marquée par le port SS a lieu si le composant est à l'état Req. Aussi, le coor-
dinateur modie son radio au mode Rception ce qui est présenté par la fonction
Radio(”T”, ”R”) ;
5. Les transitions marquées par les ports RDi avec i ∈ [1..n] ont lieu lorsque le
composant est à l'état Data et aux créneaux horaires réservés pour chaque n÷ud.
A la n ce cette procédure de réception des données le coordinateur modie son
radio au mode Sommeil ce qui est présenté par la fonction Radio(”R”, ”S”) ;
6. La transition interne étiquetée par le port SLP se déclenche après la réception
des données [x sum] lorsque le composant est à l'état Data. Aussi, le coordi-
nateur modie son radio au mode Sommeil ce qui est présenté par la fonction
Radio(”R”, ”S”) ;
7. Finalement, la transition END se déclenche pour recommencer un nouveau cycle
lorsque le temps globale y atteint une seconde [t == 1] et le coordinateur modie
le mode de son radio au Transmission.
La Figure 3.4 ci-dessus représente le comportement interne des n÷uds de capteur. Le
comportement de ce composant représente cinq états de contrôle (Start, Req, Stat, Data
et Sleep). Dans ce qui suit, nous représentons l'ensemble des transitions représentants
le comportement interne du chaque n÷ud de capteur :
1. Initialement, nous introduisons le créneau horaire de chaque n÷ud réservé pour
l'envoie du requête et le n÷ud modie son radio au mode de Rception ce qui est
présenté par la fonction paramétrée Radio(”S”, ”R”).

Figure 3.4: Le comportement interne d'un n÷ud de capteur
2. La transition marquée par le port RB a lieu si le composant est à l'état Start. Dès
le déclenchement de cette transition chaque n÷ud ajuste son horloge y à l'horloge
globale du système diusé par le coordinateur. Les n÷uds modient leurs radios
au mode Transmission ce qui est présenté par la fonction Radio(”R”, ”T”).
3. La transition marquée par le port SR a lieu lorsque le créneau horaire réservé
pour le n÷ud aura lieu et si le composant est à l'état Req. Avec cette transition
envoi le nombre de slots NbrRs qui veulent réserver pour envoyer les données.
Les n÷uds modient aussi avec cette transition leurs radios au mode Recevoir,
avec la fonction Radio(”T”, ”R”), an d'être prêts à recevoir la trame statistique.
4. La transition marquée par le port RS a lieu si le composant est à l'état Stat. Avec
cette transition les n÷uds modient leurs radios au mode Transmission après
avoir reçu de la part du coordinateur les informations de planication contenant
tous les créneaux horaires réservés à chaque n÷ud pour envoyer leurs données.
5. La transition marquée par le port SD a lieu lorsque le créneau horaire réservé
aura lieu [t == ts], si le n÷ud a encore de données à transmettre [Event == true]
et si le composant est à l'état Data ou à l'état Sleep.
6. La transition marquée par le port SLP a lieu si le composant est à l'état Data et
que l'horloge globale du système est diérent du créneaux horaires réservé pour
le composant. Dès le déclenchement de cette transition, le n÷ud modie le mode
de son radio au Sommeil, ce qui est présenté par la fonction Radio(”T”, ”S”).
Le noeud reste à l'état Sleep en attendant le prochain créneau qui lui est assigné
ou le prochain cycle.
7. A la n du cycle, lorsque l'horloge globale du système atteint une seconde [t==1],
la transition marquée par le port END se déclenche pour arriver à l'état Start
et recommencer un nouveau cycle.

Dans ce qui suit, nous présentons le modèle d'interaction de notre modèle. En eet,
nous dénissons les connecteurs ainsi que leurs interactions. Notre système comprend
quatre procédures qui correspondent au processus de synchronisation, processus du l'en-
voi/réception des requêtes, processus de planication et processus de l'envoi/réception
des données.
3.2.2 Connecteur de synchronisation ”αsyn”
La Figure 3.5 représente le connecteur lié à la procédure de synchronisation. Ce qui
signie le connecteur permettant de propager les informations de synchronisation sur
le corps humain en tant que support de propagation.
αsyn est un connecteur de diusion (synchronisation faible) qui possède un port de
déclenchement SB(Send Beacon) et N ports de réception RBi (Receive Beacon node
i), avec i ∈ [1..N].
Figure 3.5: Le processus de synchronisation : connecteurs, ports et interactions
La dénition du connecteur de diusion ”αsyn” présente le processus de synchroni-
sation entre le coordinateur et les n÷uds présents dans le réseau modélisé.
Par exemple, si nous avons déni un connecteur de rendez-vous, une synchronisa-
tion forte aura lieu. Ensuite, la seule interaction possible du connecteur serait {SB,
RB1,..,RBi,..,RBN }. Dans ce cas, tous les n÷uds seraient obligés de recevoir la trame
de synchronisation simultanément ce qui peut causer un blocage du système dans le
cas où un ou plusieurs n÷uds quittent le réseau brusquement (batterie épuisée).
Toutefois, le comportement de notre système est que tous les n÷uds présents dans le
réseau et en bon état doivent recevoir la trame de synchronisation du coordinateur, si-
multanément. Ainsi, nous voulons modéliser un connecteur qui son ensemble réalisable
d' s est toutes les combinaisons possibles de SB et RBi, avec i ∈ [1..N].
Le tableau 3.1 détaille toutes les interactions possibles du connecteur αsyn pour un
coordinateur et trois n÷uds.
3.2.3 Connecteur de requête ”αR”
La Figure 3.6 représente le connecteur lié à la procédure de l'envoie/réception des
requêtes. Ce connecteur lie chaque n÷ud du réseau au coordinateur séparément, ce qui
signie dans notre modèle nous admettons αR1,..,αRN .

Interactions δ Garde G Fonctions (up,down)
SB, RBi Avec
i ∈ {1, 2, 3}
on SB RBi
down
RBi.FT=SB.FT ;
RBi.IDc=SB.IDc ;
RBi.IDi=SB.IDi ;
RBi.TimeSY N=SB.TimeSY N ;
RBi.CRC=SB.CRC ;
SB, RB1, RB2 on SB RB1 RB2
down
RB1.FT=SB.FT ;RB2.FT=SB.FT ;
RB1.IDc=SB.IDc ; RB2.IDc=SB.IDc ;
RB1.ID1=SB.ID1 ;RB2.ID2=SB.ID2 ;
RB1.TimeSY N=SB.TimeSY N ;
RB1.CRC=SB.CRC ; RB2.CRC=SB.CRC ;
down
RB1.FT=SB.FT ; RB3.FT=SB.FT ;
RB1.ID1=SB.ID1 ; RB3.ID3=SB.ID3 ;
down
RB2.FT=SB.FT ; RB3.FT=SB.FT ;
RB2.ID2=SB.ID2 ; RB3.ID3=SB.ID3 ;
Table 3.1: Ensemble des interactions possibles du connecteur ”αsyn”
αRi
est un connecteur de diusion (synchronisation faible) qui possède un port de type
synchrone SRi(Send Request node i) et un port de type trigger RR (Receive Request).
Le choix de types des ports est lié à l'ensemble des interactions possibles qui doit
respecter le fonctionnement du système modélisé. Par exemple, si nous avons déni le
port SRi de type trigger, l'interaction {SRi} peut avoir lieu et alors un noeud peut
envoyer un trame pour demander des créneaux horaires mais le coordinateur peut ne
recevoir cette trame ce qui n'est pas acceptable dans un système critique. Aussi, Dans
le cas où nous modions le port RR de type synchrone, l'interaction {RR} ne peut
plus avoir lieu et le système va se bloquer si un n÷ud n'envoie pas sa trame.

Toutefois, nous voulons modéliser un connecteur que son ensemble réalisable d'inter-
actions est {{RR}, {RR SRi}, avec i ∈ [1..N]. Le tableau 3.2 détaille les interactions
possibles du connecteur αR.
Figure 3.6: Le processus de demande de créneaux horaires : connecteurs, ports et interac-
tions
Interactions δ Gardes G Fonctions (up,down)
RR, SRi Avec
i ∈ [1..N]
when
[t == tsi]
on RR SRi
down RR.FT=SRi.FT ;
RR.IDc=SRi.IDc ;
RR.IDni=SRi.IDi ;
RR.NbrRS=SRi.NbrRS ;
RR.CRC=SRi.CRC;
Table 3.2: Ensemble des interactions possibles des connecteurs αRi
3.2.4 Connecteur statistique αS
La Figure 3.7 représente le connecteur αS lié à la procédure de l'envoie/réception
de la trame statistique qui contient tous les informations de planication.
Figure 3.7: Le processus de l'envoie/réception de la trame statistique : connecteurs, ports
et interactions

αS est un connecteur de diusion (synchronisation faible) qui possède un port de
déclenchement SS(Send Statistical frame) de type trigger et N ports synchrones de
réception RSi (Receive Statistical Frame node i) avec i ∈ [1..N]. Le choix du type des
ports dans ce connecteur est justié par les mêmes arguments que le connecteur de
synchronisation αsyn.
Le tableau 3.3 détaille toutes les interactions possibles du connecteur αS pour un
coordinateur et trois n÷uds.
Interactions δ Garde G Fonctions (up,down)
SS, RSi Avec
i ∈ {1, 2, 3}
on SS RSi
down
RSi.FT=SS.FT ;
RSi.IDc=SS.IDc ;
RSi.IDi=SS.IDi ;
RSi.TTs=SS.TTs ;
RSi.InfoP=SS.InfoP ;
RSi.CRC=SS.CRC ;
SS, RS1, RS2 on SS RS1 RS2
down
RS1.FT=SS.FT ;RS2.FT=SS.FT ;
RS1.IDc=SS.IDc ; RS2.IDc=SS.IDc ;
RS1.ID1=SS.ID1 ;RS2.ID2=SS.ID2 ;
RS1.TTs=SS.TTs ; RS2.TTs=SS.TTs ;
RS1.InfoP=SS.InfoP ;
RS1.CRC=SS.CRC ; RS2.CRC=SS.CRC ;
down
RS1.FT=SS.FT ; RS3.FT=SS.FT ;
RS1.ID1=SS.ID1 ; RS3.ID3=SS.ID3 ;
down
RS2.FT=SS.FT ; RS3.FT=SS.FT ;
RS2.ID2=SS.ID2 ; RS3.ID3=SS.ID3 ;
Table 3.3: Ensemble des interactions possibles du connecteur αS

3.2.5 Connecteurs de données αD
La Figure 3.8 représente le connecteur lié à la procédure de l'envoie/réception de
données. Ce connecteur lie chaque n÷ud du réseau au coordinateur séparément, ce qui
signie dans notre modèle nous admettons αD1,..,αN . Ces connecteurs ont été déni
une seul fois mais seront appelés autant de fois selon le nombre de créneaux horaires
réservés pour chaque n÷ud.
Figure 3.8: Le processus de l'envoie/réception de données : connecteurs, ports et interac-
tions
αD est un connecteur de diusion (synchronisation faible) qui possède un port de
type synchrone SDi(Send Data node i) et un port de type trigger RD (Receive Data).
Toutefois, nous voulons modéliser un connecteur que son ensemble réalisable d'inter-
actions est {{RD}, {RD SDi}, avec i ∈ [1..N].
Le tableau 3.4 détaille toutes les interactions possibles des connecteurs αD.
Interactions δ Gardes G Fonctions (up,down)
RD, SDi Avec
i ∈ [1..N]
when
[t ==
tsi]∧Event
on RD SRi
down RD.FT=SDi.FT ;
RD.IDc=SDi.IDc ;
RD.IDi=SDi.IDi ;
RD.FSi=SDi.FSi ;
RD.Datai=SDi.Datai ;
RD.CRC=SDi.CRC;
Table 3.4: Ensemble des interactions possibles des connecteurs αDi
Conclusion
Dans ce chapitre, nous avons présenté notre modèle formel de haut niveau pro-
posé pour le protocole S-TDMA basé sur l'architecture TDMA et spécique pour les
réseaux de capteurs corporels sans ls. Nous avons utilisé BIP comme langage formel
pour concevoir notre système. Dans le chapitre suivant, nous présentons quelques résul-
tats expérimentaux obtenus à partir de notre implémentation dérivée automatiquement

à l'aide des outils de BIP an d'analyser la performance énergétique du protocole étu-
dié, ainsi que les résultats de la vérication formelle du modèle proposé.

4Vérication formelle et résultats
expérimentaux
Introduction
An de couronner les principaux aspects traités dans notre modèle proposé dans
le chapitre précédent, il est propice d'eectuer dans le cadre de ce chapitre son im-
plémentation et ce dans l'objectif de montrer la faisabilité et la mise en évidence des
diérentes contributions proposées. A cet égard, nous commençons par la présenta-
tion des technologies adoptés. Ensuite, nous présentons en détail la mise en ÷uvre
et la compilation du système, ainsi que les évaluations expérimentales obtenus grâce
à la génération automatique de code. Et enn nous présentons les résultats obtenus
de la vérication formelle de l'invariance, l'équité, l'exclusion mutuelle et l'absence de
l'interblocage sur notre modèle proposé.
4.1 Implémentation
Le modèle qui a été présenté dans le chapitre précédent est basé sur un formalisme
graphique aui respecte la sémantique BIP présenté dans [BBS06, BBB+
11b].
Jusqu'à aujourd'hui, il n'y a pas un outil qui permet de générer automatiquement le
code BIP du formalisme précédent. C'est pour cette raison qu'il fallait coder à la main
en langage BIP le modèle déjà représenté dans le 3me
chapitre. Dans cette section, nous
présentons le code et la compilation de la modélisation du protocole S-TDMA étudié
dans notre recherche.
36

4.1 Implémentation 37
4.1.1 Environnement de travail : BIP
BIP est un framework à base de composants pour la conception des systèmes avec
des interactions complexes. Son principe de base est qu'il devrait y avoir une séparation
claire entre le comportement et les parties architecturales des systèmes (Voir Chapitre
3).
L'installation des outils de BIP exige certaines contraintes. En eet, le compilateur
nécessite Java VM (Virtual Machin), la version 6. Pour compiler le code généré C++,
nous avions également besoin d'installer un compilateur C++ standard nommé g++
(version 4.8) et d'installer CMake qui est utilisé pour contrôler le processus de compi-
lation. En outre, le moteur d'exécution BIP est fourni uniquement pour les systèmes
exécutant GNU/Linux d'où le besoin de travailler sur une machine fonctionnant sur le
système d'exploitation Linux.
La version de BIP2 qu'on a utilisé dans nos expérimentations a été installé sur la
version 14.04 de ubuntu (64 bits). Une fois BIP2 est installé, la liste des commandes
qu'il ore est présenté dans la Figure.4.1.
Figure 4.1: La liste des commandes fourni par BIP

4.1.2 Le code BIP du modèle proposé
La boite à outils de BIP propose plusieurs chaînes de compilation, ciblant diérentes
plates-formes d'exécution . Une fois le code est généré par le compilateur de BIP et
les moteurs sont en C++, les moteurs d'exécution prennent la responsabilité de la
coordination des composants en appliquant la sémantique des couches d'interaction et
de priorité de BIP (Voir la Figure 4.2).
Figure 4.2: La procédure d'exécution d'un chier BIP
Le code BIP de notre modèle pour le protocole S − TDMA est représenté dans
l'Annexe I. Ce code est composé des sous parties suivantes :
ˆ Le codage des composants atomiques; nous présentons comme un exemple, la
déclaration du composant atomique nommé ”Noeud” qui est représentée dans la
Figure 4.3. Le type atomique ”Noeud” dénie les composants N1, N2 et N3 qui
représentent dans notre modèle l'ensemble des n÷uds de capteurs corporels.
Dans cette dénition de composant, nous avons déclaré cinq variables de type
entier (idn, idc, NbreRS, x et TTs), deux variables de type chaine de caractère
(L et CRC), une variable de type réel (TimeSYN) et un tableau d'entiers de type
tab InfoP.
Également, nous avons déni les places de ce composants nommées Start, Req,
Stat, Data et Sleep. Ensuite, nous avons déclaré un port RB de type Beacon,
un port SD de type Dataa, un port SR de type Requesting et un port RS de
type StatF.

Figure 4.3: Dénition du type de composant ”Noeuds”
ˆ Le codage des connecteurs ; nous présentons comme un exemple, la déclaration
du connecteur nommé C − Beacon qui est représenté dans la Figure 4.4; après
cette dénition, nous avions déclaré une seule instance de ce connecteur qui a été
le responsable de la procédure de synchronisation :
connector C − Beacon b(C.SB, N1.RB, N2.RB, N3.RB)
L'appel de ce connecteur déclenche les transitions, marqués par le port SB et
RB, des composants C, N1, N2 et N3.

Figure 4.4: L'implémentation du connecteur ”C − Beacon”
ˆ Le codage des types de ports de notre modèle qui est représenté dans la Figure 4.5;
Nous avions besoin de dénir quatre types de port (Beacon, StatF, Requesting,
Dataa). Ces types de ports se dièrent entre eux par le nombre et les types
de variables passées en paramètre qui représente l'échange de données entre les
composants.
Figure 4.5: L'implémentation des ports
ˆ Le codage des types externes (tab) et des fonctions externes (printf(), initVD(),
Radio(), rempVD() et StatFrame()) est représenté dans la Figure 4.6. Ces fonc-
tions sont codées indépendamment en C++ dans des chiers. Le lien de ces
derniers avec le chier BIP se fait avec la ligne de code suivante.
@cpp(src = ”hello.cpp”, include = ”hello.hpp”, include = ”stdio.h”)

Figure 4.6: La déclaration des types et des fonctions externes
ˆ Le codage du notre système composé nommé system est représenté dans la Figure
4.7. Dans cette dénition nous trouvons l'appel de toutes les connecteurs de notre
modèle ainsi que la déclaration de nos composants atomiques.
Figure 4.7: La déclaration du composé ”system”
Dans cet exemple de déclaration du composé, nous avons mis l'hypothèse que le
n÷ud ayant l'identiant unique 2 n'a pas de trame à envoyer et que les n÷uds 1 et 3
ont deux trames de données à envoyer dans le même cycle d'où le besoin de réserver
pour chacun deux créneaux horaires dans la phase de l'envoie/réception des données.
4.1.3 La compilation et la liaison avec le code généré
La compilation du notre code BIP a été établie en exécutant la commande suivante
dans le terminale du Linux :

bipc.sh − p hello − I /home/roua/hello/ − d ”system()” − −gencpp − output −
dir output
-p : Le nom du paquet
-I : Le chemin du chier bip
-d : Le nom du composé de notre modèle
gencpp-output-dir : Le nom de chier contenant les chiers générés lors de l'exé-
cution
Après avoir écrit et compilé notre code BIP, il faut générer le code C + + de notre
système pour pouvoir créer notre projet. Cette tâche a été établi en respectant les
étapes suivante :
1. La création d'un répertoire de construction nommé build. Ce répertoire sera
l'hôte de tous les chiers créés lors de la compilation et la liaison du code gé-
néré. Ce répertoire peut être nettoyé si nécessaire, sans la nécessité d'exécuter à
nouveau le compilateur BIP.
2. A partir de ce nouveau répertoire, nous avons exécuté la commande ”cmake..”
en pointant sur le répertoire contenant le code généré (Voir la Figure 4.8).
Figure 4.8: La génération du code
3. Ensuite, pour faire réellement compiler et lier tout ensemble, nous avions exécuté
la commande ”make” (Voir la Figure 4.9).
Figure 4.9: La liaision des chiers générés

4.2 Analyse et résultats expérimentaux 43
Un message est aché lors de l'accomplissement de cette tache (Voir la Figure
4.10).
Figure 4.10: Le résultat obtenu lors de la liaision des chiers générés
4.2 Analyse et résultats expérimentaux
Dans la section précédente, nous avons décrit en détail l'implémentation ainsi que
la compilation de notre modèle. Nous proposons maintenant d'analyser et de vérier
certaines propriétés sur notre modèle à l'aide de l'ensemble des outils proposés par BIP.
Nous commençons par une étude sur la consommation d'énergie dans le réseau étudié vu
que l'énergie représente la contrainte principale lors de conception de protocoles pour
les réseaux de capteurs. Ensuite, nous passons à la vérication formelle de quelques
propriétés logiques sur notre modèle proposé.
La modélisation, l'analyse ainsi que la vérication proposés dans ce mémoire se
basent sur les hypothèses suivantes qui sont inspirées sur les expérimentations réalisées
dans [NLH+
15, CNI+
13]. :
ˆ La période d'inactivité peut également être utilisé pour la retransmission de pa-
quets de données perdus. Mais dans notre modèle nous supposons qu'aucun pa-
quet n'a été perdu et que le coordinateur ne vérie pas l'exactitude des données
reçues.
ˆ Nous n'avons pas considéré les cas d'urgences ni dans la modélisation ni dans
l'expérimentation.
ˆ Nous avons xé la taille d'un créneau horaire égale à la taille minimale (500
microsecondes) [A+
12a].
4.2.1 Analyse de la consommation énergétique avec le protocole
S-TDMA
Aujourd'hui, il est possible de construire de très petits périphériques avec une com-
munication sans l pour la surveillance et la mesure des valeurs diverses de l'environ-
nement. Dans les réseaux de capteurs corporels sans l, les n÷uds de capteurs ont des
exigences de bande passante diérentes, par conséquent, le trac hétérogène est créé.

4.2 Analyse et résultats expérimentaux 44
Pour fournir les niveaux de confort et de discrétion requise pour l'adoption généra-
lisée, les n÷uds de capteurs doivent être de petites tailles et fourni avec des batteries
qui peuvent durer de quelques jours à plusieurs années en fonction de l'application
[BSM+
12]. L'exigence de taille limite évidemment la taille des batteries qui alimente-
ront les n÷uds de capteurs. En outre, en raison de la forte consommation d'énergie
supposée, l'application de l'ISM (Bandes de radio industrielles, scientiques et mé-
dicales) basées sur des réseaux WBAN/WBSN dans les applications sur le corps est
gênant en raison de la nécessité de remplacement de la batterie. Donc, les n÷uds cap-
teurs doivent être extrêmement frugal dans leur consommation d'énergie.
Le réseau modélisé dans notre travail contient un coordinateur et N n÷uds. Nous
avons mis les n÷uds pour transmettre des données pendant 5 minutes divisées en 20
secondes. Notons que les résultats expérimentaux présentés ci-dessous ont été obtenus
à partir de la valeur moyenne de 15 expériences (chaque essai dure 20 s).
Nous nous concentrons sur la consommation énergétique des radio des n÷uds de
capteurs et du coordinateur. Il y a quatre états : écouter, transmettre, recevoir et
sommeil pour un dispositif de radio, et chaque état a un niveau de consommation
d'énergie diérent [SB08]. En conséquence, la consommation totale d'énergie, noté E,
peut être modélisée en déterminant le temps fractionnaire que le radio reste dans chaque
état par unité de temps.
EE,EE, ET , ER et ES sont dénies comme l'énergie consommée dans chaque état, et
le temps passé dans chaque état du coordinateur comme Tct et Tcr respectivement, des
n÷uds de capteurs comme Tne, Tnt, Tnr et Tns respectivement.
La consommation totale d'énergie pour les n÷uds de capteurs et pour le coordinateur :
E = Ec + Enoeuds (1)
La consommation d'énergie pour le coordinateur :
Ec = ET Tct + ERTcr (2)
le période de transmission attendue pour le coordinateur, avec Tsyn est le temps de
transmission du trame de synchronisation et Tstat est le temps de transmission du
trame statistique :
Tct = Tsyn + Tstat (3)
La période de réception attendue pour le coordinateur, avec Tr est le temps de réception
des trames de requêtes et Tdata est le temps de réception des trames de données :
Tcr = Tr + Tdata (4)
La consommation d'énergie pour les n÷uds de capteur :
Enoeuds = EETne + ET Tnt + ERTnr + ESTns (5)
Le temps de sommeil pour les n÷uds de capteurs, avec T représente la durée d'un
cycle :

Rapport de Mémoire Master Recherche

Rapport de Mémoire Master Recherche

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Rapport de Mémoire Master Recherche

Similaire à Rapport de Mémoire Master Recherche (20)

Dernier

Dernier (9)

Rapport de Mémoire Master Recherche