Ce mémoire présente une recherche sur la modélisation et la vérification formelle du protocole S-TDMA pour les réseaux de capteurs corporels sans fil (WBAN). Il aborde des thèmes tels que les réseaux de capteurs, les protocoles d'accès au médium et la vérification des systèmes TDMA. Le travail inclut des remerciements, une introduction générale et une analyse expérimentale des résultats obtenus.

1. 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

2. 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

3. 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

4. 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.1 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . . 6
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.1 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . . 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

5. 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

6. 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

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

8. 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

9. 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

10. 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.

11. 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

12. 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

13. 1.1 Les réseaux de capteurs sans fils (WSN) 3
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.

14. 1.1 Les réseaux de capteurs sans fils (WSN) 4
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.

15. 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.

16. 1.2 Les réseaux de capteurs corporels sans fils (WBAN) 6
1.2.1 Présentation générale
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.

17. 1.2 Les réseaux de capteurs corporels sans fils (WBAN) 7
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

18. 1.2 Les réseaux de capteurs corporels sans fils (WBAN) 8
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

19. 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.
1.3.1 Présentation générale
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

20. 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

21. 1.4 S-TDMA : Statistical frame based TDMA 11
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.

22. 1.4 S-TDMA : Statistical frame based TDMA 12
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.

23. 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

24. 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é.

25. 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.

26. 2.3 Les composants du framework BIP 16
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,

27. 2.3 Les composants du framework BIP 17
ˆ 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

28. 2.3 Les composants du framework BIP 18
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}.

29. 2.3 Les composants du framework BIP 19
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.

30. 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].

31. 2.4 La boite à outils de BIP 21
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].

32. 2.4 La boite à outils de BIP 22
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.

33. 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.

34. 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.

35. 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

36. 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.

37. 3.2 Le modèle formel proposé 27
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 :

38. 3.2 Le modèle formel proposé 28
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”).

39. 3.2 Le modèle formel proposé 29
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.

40. 3.2 Le modèle formel proposé 30
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 .

41. 3.2 Le modèle formel proposé 31
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 ;
RB2.TimeSY N=SB.TimeSY N ;
RB1.CRC=SB.CRC ; RB2.CRC=SB.CRC ;
SB, RB1, RB3 on SB RB1 RB3
down
RB1.FT=SB.FT ; RB3.FT=SB.FT ;
RB1.IDc=SB.IDc ; RB3.IDc=SB.IDc ;
RB1.ID1=SB.ID1 ; RB3.ID3=SB.ID3 ;
RB1.TimeSY N=SB.TimeSY N ;
RB3.TimeSY N=SB.TimeSY N ;
RB1.CRC=SB.CRC ; RB3.CRC=SB.CRC ;
SB, RB2, RB3 on SB RB2 RB3
down
RB2.FT=SB.FT ; RB3.FT=SB.FT ;
RB2.IDc=SB.IDc ; RB3.IDc=SB.IDc ;
RB2.ID2=SB.ID2 ; RB3.ID3=SB.ID3 ;
RB2.TimeSY N=SB.TimeSY N ;
RB3.TimeSY N=SB.TimeSY N ;
RB2.CRC=SB.CRC ; RB3.CRC=SB.CRC ;
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.

42. 3.2 Le modèle formel proposé 32
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

43. 3.2 Le modèle formel proposé 33
α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 ;
RS2.InfoP=SS.InfoP ;
RS1.CRC=SS.CRC ; RS2.CRC=SS.CRC ;
SS, RS1, RS3 on SS RS1 RS3
down
RS1.FT=SS.FT ; RS3.FT=SS.FT ;
RS1.IDc=SS.IDc ; RS3.IDc=SS.IDc ;
RS1.ID1=SS.ID1 ; RS3.ID3=SS.ID3 ;
RS1.TTs=SS.TTs ; RS3.TTs=SS.TTs ;
RS1.InfoP=SS.InfoP ;
RS3.InfoP=SS.InfoP ;
RS1.CRC=SS.CRC ; RS3.CRC=SS.CRC ;
SS, RS2, RS3 on SS RS2 RS3
down
RS2.FT=SS.FT ; RS3.FT=SS.FT ;
RS2.IDc=SS.IDc ; RS3.IDc=SS.IDc ;
RS2.ID2=SS.ID2 ; RS3.ID3=SS.ID3 ;
RS2.TTs=SS.TTs ; RS3.TTs=SS.TTs ;
RS2.InfoP=SS.InfoP ;
RS3.InfoP=SS.InfoP ;
RS2.CRC=SS.CRC ; RS3.CRC=SS.CRC ;
Table 3.3: Ensemble des interactions possibles du connecteur αS

44. 3.2 Le modèle formel proposé 34
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

45. 3.2 Le modèle formel proposé 35
à 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é.

46. 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

47. 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

48. 4.1 Implémentation 38
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.

49. 4.1 Implémentation 39
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.

50. 4.1 Implémentation 40
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”)

51. 4.1 Implémentation 41
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 :

52. 4.1 Implémentation 42
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

53. 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éé.

54. 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 :

55. 4.2 Analyse et résultats expérimentaux 45
Tns = T − Tcr − Tct (6)
Scénarios expérimentaux et analyse Pour évaluer la performance du protocole
S-TDMA dans des diérents scénarios, un modèle formel du protocole S-TDMA basé
sur WBAN a été implémenté en utilisant le framework BIP présentée. Le but de l'expé-
rience est d'analyser la consommation énergétique d'un réseau appliquant le protocole
S-TDMA comme un protocole MAC. Vu que le mode sommeil du radio d'un capteur
est le mode le plus économiste (presque négligeable) en terme d'énergie, nous allons
calculer la durée moyenne que les n÷uds de capteurs sont en sommeil. Les valeurs nu-
mériques sont relevées du trace (Voir Annexe II) générée lors de l'exécution du notre
modèle sur le framework BIP.
Dans nos expériences, nous avons considéré les mêmes tailles et nombres de paquets
qu'un noeud de capteur doit transmettre que les auteurs du [NLH+
15] ont considérés.
Ces paramètres changent selon les mouvements humains [RJH08], c'est pourquoi nous
avons appliqué nos expériences en considérant les trois états suivants qu'une personne
peut prendre :
ˆ Une personne entrain de marcher
Un n÷ud de capteur a besoin de transmettre dix trames de données par seconde
dans cet état. Les résultats obtenus sont représenté dans le tableau 4.1.
Résultats obtenus en microseconde Résultats calculés en microseconde
Tsyn = 0, 005 | Tstat = 0, 006 (3)Tct = 0, 011
Tr = 1500 | Tdata = 15000 (4)Tcr = 16500
T = 1000000 (6)Tns = 983499, 989
Table 4.1: Durée de sommeil pour une personne qui marche
ˆ Une personne entrain de faire un course
Un noeud de capteur a besoin de transmettre quinze trames de données par
seconde dans cet état. Les résultats obtenus sont représenté dans le tableau 4.2.
Résultats obtenus en microseconde Résultats calculés en microseconde
Tsyn = 0, 005 | Tstat = 0, 006 (3)Tct = 0, 011
Tr = 1500 | Tdata = 22500 (4)Tcr = 24000
T = 1000000 (6)Tns = 975999, 989
Table 4.2: Durée de sommeil pour une personne qui court
ˆ Une personne entrain de dormir
Un n÷ud de capteur a besoin de transmettre vingt-cinq trames de données par
seconde dans cet état. Les résultats obtenus sont représenté dans le tableau 4.3.
Nous remarquons que la période de sommeil des n÷uds de capteurs dans le réseau
est très élevée, il est clair donc que, S-TDMA montre une consommation d'énergie plus
forte par rapport aux protocoles qui n'admettent pas la période d'inactivité dans leurs

56. 4.2 Analyse et résultats expérimentaux 46
Résultats obtenus en microseconde Résultats calculés en microseconde
Tsyn = 0, 005 | Tstat = 0, 006 (3)Tct = 0, 011
Tr = 1500 | Tdata = 37500 (4)Tcr = 39000
T = 1000000 (6)Tns = 960999, 989
Table 4.3: Durée de sommeil pour une personne qui dort
cycles. Par contre, cette période se réduit avec l'augmentation du nombre des n÷uds
dans le réseau et avec le nombre de trames à envoyer dans chaque cycle. La Figure 4.11
illustre la relation entre l'état du corps humain et la période du sommeil des n÷uds et
donc la consommation énergétique.
Figure 4.11: Augmentation de la période du sommeil avec la diminution de nombre de
paquets
4.2.2 Vérication formelle du modèle proposé
Après avoir modélisé le protocole étudié, nous proposons à ce stade de vérier des
propriétés logiques présentant les aspects les plus importants dans un protocole MAC.
4.2.2.1 L'interblocage (Deadlock)
L'une des propriétés principales d'exactitude des programmes concurrents est l'ab-
sence de blocage. Un programme concurrent est dans un état d'interblocage (Deadlock)
si un ensemble de processus (n÷uds de capteurs) sont privés de progresser à cause de
leurs demandes mutuelles de ressources additionnelles (canale de transmission).
Basé sur RTD-Finder, nous avons prouvé qu'un interblocage ne peut jamais avoir
lieu dans notre modèle. L'extension de notre modèle à n'importe quel nombre de com-
posants est facilement fournie par le fait que tous les n÷uds ont le même comportement.
Ainsi, nous avons généré des codes BIP de notre modèle pour diérents nombres de
n÷uds de capteurs ce qui nous a permis de constater que l'augmentation du nombre de

57. 4.2 Analyse et résultats expérimentaux 47
composants augmente le nombre d'interactions (NbrInter), le nombre d'actions d'his-
torique d'horloge (NbrHclock), le nombre de ports exportés (ExpPort) et le nombre de
variables d'horloge du système (SysClock) ce qui nécessite donc un temps d'exploration
(TVerif) plus important pour détecter les blocages.
Nombre de
n÷uds
2 6 10 15
Temps de
vérication(ms)
10,38 58,39 164,55 398,98
Table 4.4: Le temps de vérication du détection du deadlock
Les résultats numériques obtenus sont représentés dans le Tableau 4.4. Ce dernier
illustre en détails les valeurs exactes captés lors des expériences appliquées sur le modèle
proposé. Ensuite et an de rendre la lecture plus facile nous avons visualisé les données
dans la Figure 4.12 qui montre clairement l'eet de l'augmentation du nombre de
composants sur la vérication du propriété de l'interblocage sur le modèle proposé.
Figure 4.12: Eet de l'augmentation du nombre des composants lors de la détection de
l'interblocage
4.2.2.2 L'invariance
Le protocole S-TDMA découpent le temps en slots, chaque slot de temps est alloué à
un seul n÷ud pour lui garantir l'accès au canal an qu'il puisse transmettre ses données.
An de représenter ces contraintes d'horloges, nous avons déni dans la modélisation
des comportements du coordinateur ainsi que des n÷uds des invariants (Voir Section
2.3.1) {[TSRc = 500µs],[TSDc = 500µs],[TSDNi
= 500µs]} dans les trois états
{Reqc, Datac,Datai},respectivement avec i ∈ [1..N].

58. 4.2 Analyse et résultats expérimentaux 48
Nous proposons à ce stade de vérier formellement que notre modèle satisfait la
propriété temporelle [Pnu77] d'invariance qui est décrite formellement en dessous avec
le model-checker fourni par BIP. La première propriété concerne le composant atomique
représentant un n÷ud. La satisfaction de cette propriété prouve qu'un n÷ud ne peut
pas dépasser le créneau qui lui a été assigné pour envoyer sa trame de données. Les deux
dernières propriétés concernent le composant atomique représentant le coordinateur.
Ces deux propriétés prouve que le coordinateur ne dépasse pas la durée d'un slot
lorsqu'il attend à recevoir la trame de requête ou bien celle du données de la part des
n÷uds.
1) AG (Datani =⇒(tsDni = 500))
2) AG (Reqc =⇒(tsReqc = 500))
3) AG (Datac =⇒(tsDc = 500))
Après l'exploration de tous les états possibles, le model cheker a prouvé que le modèle
formel représentant le protocole S-TDMA satisfait l'invariance quelque soit le nombre
de composants. Le résultat obtenu montre que le temps de vérication varie avec le
nombre de composants dans le modèle, comme il est représenté dans le Tableau 4.5.
Nombre de
n÷uds
2 6 10 15
Temps de
vérication (ms)
11,85 58,58 166,37 397,85
Table 4.5: Le temps de vérication de l'invariance
4.2.2.3 L'exclusion mutuelle
La validation de cette propriété signie que c'est impossible d'armer plus d'une
subvention à un moment. En d'autres termes, le scénario, que deux ou plusieurs n÷uds
obtiennent l'accès au canal en même temps, ne pourrait jamais avoir lieu. Pour être sûr
que le pire des cas ne peut jamais avoir lieu, notre modèle doit satisfaire la propriété
suivante :
Supposons que i, j ∈ [1..N] avec (i j), les composants sont en exclusion mutuelle
en eectuant la procédure d'envoi de requêtes.
AG ¬(SRi ∧SRj)
Supposons que i, j ∈ [1..N] avec (i j), les composants sont en exclusion mutuelle
en eectuant la procédure d'envoi de leurs données.
AG ¬(SDi ∧SDj)

59. 4.2 Analyse et résultats expérimentaux 49
En eet, dans notre modèle représenté sur la Figure 3.3 nous avons déni des connec-
teurs séparés pour s'assurer qu'une seule interaction {RRi, SRi}, avec i ∈ [1..N], peut
se produire à la fois dans un cycle pour la procédure d'envoi/réception des requêtes et
c'est équivalent pour la procédure d'envoi/réception des données. Par conséquent, cette
propriété est garantie par la séparation des connecteurs dans le modèle, c'est à dire
que pour chaque instance du composant N÷ud du réseau, le composant Coordinateur
consacre un port et alors un connecteur an d'eectuer cette procédure. D'où deux
n÷uds ne peuvent jamais envoyer leurs trames de requêtes ou de données au même
instant. Ainsi, notre modèle satisfait la propriété d'exclusion mutuelle.
Comme RTD-Finder nous permet de vérier systématiquement les propriétés sur
des modèles formels, nous avons aussi vérié l'exclusion mutuelle sur notre modèle ce
qui nous a permis de nous assurer que le modèle proposé satisfait la propriété déjà
citée. Le tableau 4.6 représente le temps que nous avons passé pour la vérication de
la satisfaction de la propriété d'exclusion mutuelle dans notre modèle en modiant à
chaque fois le nombre de composants.
Nombre de
n÷uds
2 6 10 15
Temps (ms) 10,45 60,62 167,38 418,91
Table 4.6: Le temps de vérication de la propriété d'exclusion mutuelle
L'histogramme représenté dans la Figure 4.13 illustre le temps de vérication des
propriétés de l'Exclusion Mutuelle (EM) et de l'Invariance (Inv) sur notre modèle
formel avec l'outil RTD-Finder. La gure représente clairement la variation de temps
de vérication des propiétés avec la variation des nombres des n÷uds, ce qui est logique
puisque à chaque fois que nous augmentons le nombres de composants dans le modèle,
le nombre d'états et d'interactions augmente.
Figure 4.13: Temps de vérication des propriétés : Exclusion Mutuelle (EM) et Invariance
(Inv)

60. 4.2 Analyse et résultats expérimentaux 50
4.2.2.4 L'équité
Comme le protocole S-TDMA est considéré équitable, la vérication de la propriété
de l'équité est essentielle. En eet, l'équité est une propriété clé en ce qui concerne
les protocoles MAC [NKGB00]. Assurer l'équité par un protocole signie que tous
les n÷uds auront nalement un canal s'ils le demandent. La propriété de l'équité est
formellement décrite en utilisant la logique temporelle comme suit :
AG (SRi =⇒ (F SDi U (size == 0)))
Le tableau 4.7 illustre les résultats liés à la propriété d'équité qui sont obtenus à
partir de l'exécution en temps réel de modèle comme proposé précédemment.
Nombre d'accès au ca-
nal par scène
N÷ud 1 N÷ud 2 N÷ud 3
Personne qui marche 11 11 11
Personne qui court 16 16 16
Personne qui dort 26 26 26
Table 4.7: Vérication de l'équité sur le protocole S-TDMA
Nous avons calculé pour chaque n÷ud le nombre d'accès au canal pendant 10 mi-
nutes. Les résultats montrent que tous les n÷uds obtiennent un accès au canal équita-
blement et alors notre modèle proposé satisfait la propriété de l'équité.
Conclusion
Grâce au modèle obtenu dans le chapitre précédent et par model-checking, nous
avons validé formellement que le comportement du protocole est bien celui que les
auteurs [CNI+
13] souhaitions, et que les bornes temporelles de ses diérents services
(trame de synchronisation, trame de requêtes, trame statistique, trame de données)
sont bien égales à celles que les avaient trouvées de manière analytique.

61. Conclusion et perspectives
Ce travail est parti du constat que la plupart des travaux de la littérature présentent
des descriptions informelles de leurs protocoles proposés, où la vérication de la faisabi-
lité et l'analyse de la performance se résultent de l'application de plusieurs tests, ce qui
est insusant surtout pour des systèmes critiques tel que le système étudié dans ce mé-
moire. Ici, nous nous sommes intéressés à la validation formelle de certaines propriétés
sur le modèle haut niveau que nous avions proposé décrivant formellement le protocole
S-TDMA, ainsi qu'à l'étude de ses performance en terme de l'ecacité énergétique.
Nous avons proposé une conception formelle pour le protocole MAC S-TDMA en
posant des hypothèses aussi réalistes que possible. Nos évaluations sont basées sur
l'alternance entre trois modes que le corps humain peut prendre : un corps entrain de
marcher, un corps de faire une course, un corps entrain de dormir.
Par conséquent, une validation comportementale et temporelle a été eectuée à l'aide
d'une méthodologie basée sur le model-checking avec l'outil BIP. À la suite de nos
expériences, le protocole S-TDMA satisfait l'invariance, l'équité, l'exclusion mutuelle
et l'abscence de l'interblocage.
Il y a des directions diérentes pour les travaux de futur pouvant avoir lieu comme :
ˆ La vérication d'autres propriétés logiques sur le système modélisé.
ˆ Proposer des modèles formels pour les protocoles MAC ayant des caractéristiques com-
munes avec S-TDMA (basés sur l'architecture TDMA, protocole basé sur la demande
les requêtes..) et essayer de les comparer formellement avec ce protocole MAC an
d'aider les décisionnels à choisir le meilleur protocole pour leurs application.
ˆ En raison de la complexité du framework BIP, il serait intéressant de développer un
framework ou une interface rendant ces modèles plus facile pour les non experts de
BIP.
51

62. Bibliographie
[A+
12a] IEEE Standards Association et al. Ieee standard for local and metro-
politan area networks-part 15.6 : wireless body area networks. IEEE
Standard for Information Technology, IEEE, (6) :1271, 2012.
[A+
12b] A Astrin et al. Ieee standard for local and metropolitan area networks
part 15.6 : Wireless body area networks : Ieee std 802.15. 6-2012. The
document is available at IEEE Xplore, 2012.
[AALUK11] Moshaddique Al Ameen, Jingwei Liu, Sana Ullah, and Kyung Sup Kwak.
A power ecient mac protocol for implant device communication in
wireless body area networks. In 2011 IEEE Consumer Communications
and Networking Conference (CCNC), pages 11551160, 2011.
[ASSC02] Ian F Akyildiz, Weilian Su, Yogesh Sankarasubramaniam, and Erdal
Cayirci. Wireless sensor networks : a survey. Computer networks, pages
393422, 2002.
[Bas08] Ananda Basu. Component-based modeling of heterogeneous real-time
systems in bip. PhD thesis, Université Joseph-Fourier-Grenoble I, 2008.
[BBB+
10] P Bourgos, A Basu, S Bensalem, K Huang, and J Sifakis. Integrating ar-
chitectural constraints in application software by source-to-source trans-
formation in bip. Technical report, Technical Report TR-2011-1, Veri-
mag Research Report, 2010.
[BBB+
11a] Ananda Basu, Bensalem Bensalem, Marius Bozga, Jacques Combaz,
Mohamad Jaber, Thanh-Hung Nguyen, and Joseph Sifakis. Rigorous
component-based system design using the bip framework. IEEE soft-
ware, 2011.
[BBB+
11b] Ananda Basu, Saddek Bensalem, Marius Bozga, Paraskevas Bourgos,
Mayur Maheshwari, and Joseph Sifakis. Component assemblies in the
context of manycore. In International Symposium on Formal Methods
for Components and Objects, pages 314333, 2011.
[BBS06] Ananda Basu, Marius Bozga, and Joseph Sifakis. Modeling heteroge-
neous real-time components in bip. In Fourth IEEE International Confe-
rence on Software Engineering and Formal Methods (SEFM'06), pages
312, 2006.
52

63. Bibliographie 53
[BCF+
09] Heribert Baldus, Steven Corroy, Alberto Fazzi, Karin Klabunde, and
Tim Schenk. Human-centric connectivity enabled by body-coupled com-
munications. IEEE Communications Magazine, pages 172178, 2009.
[BCJ+
15] Simon Bliudze, Alessandro Cimatti, Mohamad Jaber, Sergio Mover,
Marco Roveri, Wajeb Saab, and Qiang Wang. Formal verication of
innite-state bip models. In International Symposium on Automated
Technology for Verication and Analysis, pages 326343, 2015.
[BGL+
08] Ananda Basu, Matthieu Gallien, Charles Lesire, Thanh-Hung Nguyen,
Saddek Bensalem, Félix Ingrand, and Joseph Sifakis. Incremental
component-based construction and verication of a robotic system. In
ECAI, pages 631635, 2008.
[BL11] Patricia Bouyer and François Laroussinie. Vérication par automates
temporisés. Systemes temps-réel, 1 :121150, 2011.
[BM06] Paolo Ballarini and Alice Miller. Model checking medium access control
for sensor networks. In Leveraging Applications of Formal Methods, Ve-
rication and Validation, 2006. ISoLA 2006. Second International Sym-
posium on, pages 255262. IEEE, 2006.
[BMP+
07] Ananda Basu, Laurent Mounier, Marc Poulhies, Jacques Pulou, and
Joseph Sifakis. Using bip for modeling and verication of networked
systemsa case study on tinyos-based networks. In Sixth IEEE Interna-
tional Symposium on Network Computing and Applications (NCA 2007).
IEEE, 2007.
[BS08] Simon Bliudze and Joseph Sifakis. The algebra of connec-
torsstructuring interaction in bip. IEEE Transactions on Computers,
pages 13151330, 2008.
[BS10] Simon Bliudze and Joseph Sifakis. Causal semantics for the algebra of
connectors. Formal methods in system design, pages 167194, 2010.
[BSM+
12] Athanassios Boulis, David Smith, Dino Miniutti, Lavy Libman, and Yu-
riy Tselishchev. Challenges in body area networks for healthcare : The
mac. IEEE Communications Magazine, 50, 2012.
[BSS09] Marius Dorel Bozga, Vassiliki Sfyrla, and Joseph Sifakis. Modeling syn-
chronous systems in bip. In Proceedings of the seventh ACM internatio-
nal conference on Embedded software, pages 7786, 2009.
[C+
03] LAN/MAN Standards Committee et al. Part 15.4 : wireless medium
access control (mac) and physical layer (phy) specications for low-rate
wireless personal area networks (lr-wpans). IEEE Computer Society,
2003.
[Cha99] Xinjie Chang. Network simulations with opnet. In Proceedings of the 31st
conference on Winter simulation : Simulationa bridge to the future-
Volume 1, pages 307314. ACM, 1999.

64. Bibliographie 54
[Cha12] Sekchin Chang. An ecient synchronization scheme for cooperative
wban in wireless medical telemetry systems. IEICE Transactions on
Communications, pages 30963099, 2012.
[CNI+
13] Hong Chen, Zedong Nie, Kamen Ivanov, Lei Wang, and Ran Liu. A
statistical mac protocol for heterogeneous-trac human body communi-
cation. In 2013 IEEE International Symposium on Circuits and Systems
(ISCAS2013), pages 22752278. IEEE, 2013.
[Com15] Jacques Combaz. Rtd-nder. 2015.
[CRBS08] M Yassin Chkouri, Anne Robert, Marius Bozga, and Joseph Sifakis.
Translating aadl into bip-application to the verication of real-time sys-
tems. In International Conference on Model Driven Engineering Lan-
guages and Systems, pages 519, 2008.
[CW] Edmund M Clarke and Jeannette M Wing. Formal methods : State
of the art and future directions. ACM Computing Surveys (CSUR),
28 :626643.
[DEA+
06] Ilker Demirkol, Cem Ersoy, Fatih Alagoz, et al. Mac protocols for wireless
sensor networks : a survey. IEEE Communications Magazine, 44, 2006.
[EHDELR03] Amre El-Hoiydi, J-D Decotignie, Christian Enz, and Erwan Le Roux.
Wisemac, an ultra low power mac protocol for the wisenet wireless sensor
network. In Proceedings of the 1st international conference on Embedded
networked sensor systems, pages 302303, 2003.
[EM12] Jocelyne Elias and Ahmed Mehaoua. Energy-aware topology design for
wireless body area networks. In 2012 IEEE international conference on
communications (ICC), pages 34093410, 2012.
[FD09] Gengfa Fang and Eryk Dutkiewicz. Bodymac : Energy ecient tdma-
based mac protocol for wireless body area networks. In Communications
and Information Technology, 2009. ISCIT 2009. 9th International Sym-
posium on, 2009.
[FL06] Rui Fan and Nancy Lynch. Gradient clock synchronization. Distributed
Computing, pages 255266, 2006.
[GS] Gregor Gössler and Joseph Sifakis. Composition for component-based
modeling. Science of Computer Programming, 55.
[HKNP06] Andrew Hinton, Marta Kwiatkowska, Gethin Norman, and David Par-
ker. Prism : A tool for automatic verication of probabilistic systems. In
International Conference on Tools and Algorithms for the Construction
and Analysis of Systems, pages 441444, 2006.

65. Bibliographie 55
[IJZ04] Robert SH Istepanian, Emil Jovanov, and YT Zhang. Guest editorial
introduction to the special section on m-health : Beyond seamless mobi-
lity and global wireless health-care connectivity. IEEE Transactions on
information technology in biomedicine, pages 405414, 2004.
[KB04] Lyes Khelladi and Nadjib Badache. Les réseaux de capteurs : état de
l'art. Faculté électronique et informatique Bab Ezzouar-Algérie, 2004.
[LBM+
07] Benoit Latre, Bart Braem, Ingrid Moerman, Chris Blondia, Elisabeth
Reusens, Wout Joseph, and Piet Demeester. A low-delay protocol for
multihop wireless body area networks. In Mobile and Ubiquitous Sys-
tems : Networking Services, 2007. MobiQuitous 2007. Fourth Annual
International Conference on, pages 18, 2007.
[LBM+
11] Benoît Latré, Bart Braem, Ingrid Moerman, Chris Blondia, and Piet
Demeester. A survey on wireless body area networks. Wireless Networks,
pages 118, 2011.
[LKR04] Gang Lu, Bhaskar Krishnamachari, and Cauligi S Raghavendra. An
adaptive energy-ecient and low-latency mac for data gathering in wire-
less sensor networks. In Parallel and Distributed Processing Symposium,
2004. Proceedings. 18th International, page 224, 2004.
[LP97] Henrik Lonn and Paul Pettersson. Formal verication of a tdma proto-
col start-up mechanism. In Fault-Tolerant Systems, 1997. Proceedings.,
Pacic Rim International Symposium on, 1997.
[LPY97] Kim G Larsen, Paul Pettersson, and Wang Yi. Uppaal in a nutshell. In-
ternational Journal on Software Tools for Technology Transfer (STTT),
pages 134152, 1997.
[LT10] Huaming Li and Jindong Tan. Heartbeat-driven medium-access control
for body sensor networks. IEEE Transactions on Information Technology
in Biomedicine, pages 4451, 2010.
[MM05] Jelena Mi²i¢ and Vojislav B Mi²i¢. Access delay for nodes with nite
buers in ieee 802.15. 4 beacon enabled pan with uplink transmissions.
Computer Communications, pages 11521166, 2005.
[MPS+
09] Stevan Jovica Marinkovic, Emanuel Mihai Popovici, Christian Spagnol,
Stephen Faul, and William Peter Marnane. Energy-ecient low duty
cycle mac protocol for wireless body area networks. IEEE Transactions
on Information Technology in Biomedicine, pages 915925, 2009.
[MSM05] Jelena Mi²i¢, Shairmina Sha, and Vojislav B Mi²i¢. The impact of mac
parameters on the performance of 802.15. 4 pan. Ad Hoc Networks, pages
509528, 2005.
[MSM06] Jelena Misic, Shairmina Sha, and Vojislav B Misic. Performance of a
beacon enabled ieee 802.15. 4 cluster with downlink and uplink trac.
IEEE Transactions on Parallel and Distributed Systems, 17, 2006.

66. Bibliographie 56
[Ngo03] Chiu Y Ngo. Method of mac synchronization in tdma-based wireless
networks, 2003.
[NKGB00] Thyagarajan Nandagopal, Tae-Eun Kim, Xia Gao, and Vaduvur Bhar-
ghavan. Achieving mac layer fairness in wireless packet networks. In
Proceedings of the 6th annual international conference on Mobile com-
puting and networking, pages 8798, 2000.
[NLH+
15] Zedong Nie, Zhao Li, Renwei Huang, Yuhang Liu, Jingzhen Li, and Lei
Wang. A statistical frame based tdma protocol for human body com-
munication. Biomedical engineering online, 14, 2015.
[PDMS+
09] Pangun Park, Piergiuseppe Di Marco, Pablo Soldati, Carlo Fischione,
and Karl Henrik Johansson. A generalized markov chain model for ef-
fective analysis of slotted ieee 802.15. 4. In 2009 IEEE 6th International
Conference on Mobile Adhoc and Sensor Systems, pages 130139. IEEE,
2009.
[PEE+
08] Soe Pollin, Mustafa Ergen, Sinem Coleri Ergen, Bruno Bougard, Lies-
bet Van der Perre, Ingrid Moerman, Ahmad Bahai, Pravin Varaiya, and
Francky Catthoor. Performance analysis of slotted carrier sense ieee
802.15. 4 medium access layer. IEEE Transactions on wireless commu-
nications, pages 33593371, 2008.
[Pnu77] Amir Pnueli. The temporal logic of programs. In Foundations of Com-
puter Science, 1977., 18th Annual Symposium on, pages 4657. IEEE,
1977.
[RJH08] Lei Ren, Richard K Jones, and David Howard. Whole body inverse
dynamics over a complete gait cycle based only on measured kinematics.
Journal of biomechanics, 41(12), 2008.
[RMJ04] Dejan Raskovic, Thomas Martin, and Emil Jovanov. Medical monitoring
applications for wearable computing. The Computer Journal, pages 495
504, 2004.
[Rod15] Marco Antonio Muñiz Rodríguez. Model Checking for Time Division
Multiple Access Systems. PhD thesis, zur Erlangung des Doktorgrades
der technischen Fakultät der Albert-Ludwigs-Universität Freiburg im
Breisgau, 2015.
[Rot12] Damien Roth. Gestion de la mobilité dans les réseaux de capteurs sans
l. PhD thesis, Université de Strasbourg, 2012.
[Rou11] Margaret Rouse. Media Access Control layer (MAC layer). TechTarget,
2011.
[SB08] MOAD Soane and Nizar Bouabdallah. La consommation d'énergie
dans les réseaux de capteurs sans l. Rapport de recherche, Institut De
formation supérieure en informatique et communication IFSIC, Rennes,
2008.

67. Bibliographie 57
[STS+
] Vassiliki Sfyrla, Georgios Tsiligiannis, Iris Safaka, Marius Bozga, and Jo-
seph Sifakis. Compositional translation of simulink models into synchro-
nous bip. In International Symposium on Industrial Embedded System
(SIES), pages 217220.
[SZ09] Hang Su and Xi Zhang. Battery-dynamics driven tdma mac protocols
for wireless body-area monitoring networks in healthcare applications.
IEEE Journal on selected areas in communications, pages 424434, 2009.
[TS09] Nick F Timmons and William G Scanlon. An adaptive energy ecient
mac protocol for the medical body area network. In Wireless Commu-
nication, Vehicular Technology, Information Theory and Aerospace
Electronic Systems Technology, 2009. Wireless VITAE 2009. 1st Inter-
national Conference on, pages 587593, 2009.
[UK10] Sana Ullah and Kyung Sup Kwak. Performance study of low-power
mac protocols for wireless body area networks. In Personal, Indoor and
Mobile Radio Communications Workshops (PIMRC Workshops), 2010
IEEE 21st International Symposium on, pages 112116, 2010.
[UMA13] Sana Ullah, Manar Mohaisen, and Mohammed A Alnuem. A review
of ieee 802.15. 6 mac, phy, and security specications. International
Journal of Distributed Sensor Networks, 2013.
[XR15] Feng Xia and Azizur Rahim. MAC Protocols for Cyber-Physical Systems.
Springer, 2015.
[YBO09] Bashir Yahya and Jalel Ben-Othman. Towards a classication of energy
aware mac protocols for wireless sensor networks. Wireless Communi-
cations and Mobile Computing, pages 15721607, 2009.
[YHE04] Wei Ye, John Heidemann, and Deborah Estrin. Medium access
control with coordinated adaptive sleeping for wireless sensor networks.
IEEE/ACM Transactions on networking, pages 493506, 2004.
[Yov15] Sergio Yovine. Bip : Language and tools for component-based construc-
tion. 2015.
[ZBA10] Hafedh Zayani, Kamel Barkaoui, and Rahma Ben Ayed. Probabilistic
verication and evaluation of backo procedure of the wsn eco-mac pro-
tocol. arXiv preprint arXiv :1005.2050, 2010.
[ZBADB07] Hafedh Zayani, Rahma Ben Ayed, Karim Djouani, and Kamel Barkaoui.
Eco-mac : an energy-ecient and low-latencyhybrid mac protocol for
wireless sensor networks. In Proceedings of the 2nd ACM workshop on
Performance monitoring and measurement of heterogeneous wireless and
wired networks, pages 6871, 2007.

68. Bibliographie 58
[ZD09] Yan Zhang and Guido Dolmans. A new priority-guaranteed mac proto-
col for emerging body area networks. In Wireless and Mobile Commu-
nications, 2009. ICWMC'09. Fifth International Conference on, pages
140145, 2009.

69. Annexe I
Le code BIP du système modélisé :
@cpp(src=hello.cpp, include=hello.hpp, include=stdio.h)
package S-TDMA
const data oat ts = 0.05
const data int N = 3
extern data type tab
extern function printf(string, int)
extern function printf(string, int, int)
extern function print(string, string)
extern function printf(string, int, int, int, int)
extern function initVD(tab, int)
extern function int initNoeud()
extern function oat initTs()
extern function Radio(string, string)
extern function rempVD(int, int, tab, tab)
extern function int StatFrame(int, tab, tab)
extern function int getSTAT(tab,int,int)
extern function ache(tab)
port type Beacon(string ft, int idc, int idn, oat TimeSYN, string CRC)
port type Dataa(string ft, int idc, int idn, string L, string CRC)
port type Requesting(string ft, int idc, int idn, int NbrRS,string CRC)
port type StatF(string ft, int idc, int idn, int TTs, tab InfoP,string CRC)
port type HelloPortt3()
connector type C-Beacon(Beacon s, Beacon r1, Beacon r2, Beacon r3)
dene s' r1 r2 r3
on s r1 r2 r3 down{
r1.ft=s.ft;r2.ft=s.ft;r3.ft=s.ft ;
r1.idc=s.idc;r2.idc=s.idc ;r3.idc=s.idc;
59

70. 60
r1.idn=s.idn;r2.idn=s.idn;r3.idn=s.idn ;
r1.TimeSYN=s.TimeSYN;r2.TimeSYN=s.TimeSYN;r3.TimeSYN=s.TimeSYN;
r1.CRC=s.CRC ;r2.CRC=s.CRC;r3.CRC=s.CRC;}
on s r1 r2 down{
r1.ft=s.ft; r2.ft=s.ft;
r1.idc=s.idc; r2.idc=s.idc;
r1.idn=s.idn; r2.idn=s.idn;
r1.TimeSYN=s.TimeSYN; r2.TimeSYN=s.TimeSYN;
r1.CRC=s.CRC ; r2.CRC=s.CRC ;}
on s r1 r3 down {
r1.ft=s.ft; r3.ft=s.ft;
r1.idc=s.idc; r3.idc=s.idc;
r1.idn=s.idn; r3.idn=s.idn;
r1.TimeSYN=s.TimeSYN; r3.TimeSYN=s.TimeSYN;
r1.CRC=s.CRC ; r3.CRC=s.CRC ;}
on s r2 r3 down{
r2.ft=s.ft; r3.ft=s.ft;
r2.idc=s.idc; r3.idc=s.idc;
r2.idn=s.idn; r3.idn=s.idn;
r2.TimeSYN=s.TimeSYN; r3.TimeSYN=s.TimeSYN;
r2.CRC=s.CRC ; r3.CRC=s.CRC ;}
on s r1 down{
r1.ft=s.ft;
r1.idc=s.idc;
r1.idn=s.idn;
r1.TimeSYN=s.TimeSYN;
r1.CRC=s.CRC ;}
on s r2 down{
r2.ft=s.ft;
r2.idc=s.idc;
r2.idn=s.idn;
r2.TimeSYN=s.TimeSYN;
r2.CRC=s.CRC ;}
on s r3 down{
r3.ft=s.ft; r3.idc=s.idc; r3.idn=s.idn; r3.TimeSYN=s.TimeSYN; r3.CRC=s.CRC;}
on s down{
printf(I'm %d : all nodes are sleeping, s.idc);}
end

71. 61
connector type C-STAT(StatF s, StatF r1, StatF r2, StatF r3)
dene s' r1 r2 r3
on s r1 r2 r3 down{
r1.ft=s.ft; r2.ft=s.ft; r3.ft=s.ft;
r1.idc=s.idc; r2.idc=s.idc; r3.idc=s.idc ;
r1.idn=s.idn; r2.idn=s.idn; r3.idn=s.idn;
r1.TTs=s.TTs; r2.TTs=s.TTs; r3.TTs=s.TTs;
r1.InfoP=s.InfoP; r2.InfoP=s.InfoP; r3.InfoP=s.InfoP;
r1.CRC=s.CRC ; r2.CRC=s.CRC ; r3.CRC=s.CRC ;}
on s r1 r2 down{
r1.ft=s.ft; r2.ft=s.ft;
r1.idc=s.idc; r2.idc=s.idc;
r1.idn=s.idn; r2.idn=s.idn;
r1.TTs=s.TTs; r2.TTs=s.TTs;
r1.InfoP=s.InfoP; r2.InfoP=s.InfoP;
r1.CRC=s.CRC ;r2.CRC=s.CRC;}
on s r1 r3 down {
r1.ft=s.ft; r3.ft=s.ft;
r1.idc=s.idc; r3.idc=s.idc;
r1.idn=s.idn; r3.idn=s.idn;
r1.TTs=s.TTs; r3.TTs=s.TTs;
r1.InfoP=s.InfoP; r3.InfoP=s.InfoP;
r1.CRC=s.CRC ; r3.CRC=s.CRC ;}
on s r2 r3 down{
r2.ft=s.ft; r3.ft=s.ft;
r2.idc=s.idc; r3.idc=s.idc;
r2.idn=s.idn; r3.idn=s.idn;
r2.TTs=s.TTs; r3.TTs=s.TTs;
r2.InfoP=s.InfoP; r3.InfoP=s.InfoP;
r2.CRC=s.CRC ; r3.CRC=s.CRC ;}
on s r1 down{
r1.ft=s.ft; r1.idc=s.idc; r1.idn=s.idn; r1.TTs=s.TTs; r1.InfoP=s.InfoP; r1.CRC=s.CRC;}
on s r2 down{
r2.ft=s.ft; r2.idc=s.idc; r2.idn=s.idn; r2.TTs=s.TTs; r2.InfoP=s.InfoP; r2.CRC=s.CRC;}
on s r3 down{
r3.ft=s.ft; r3.idc=s.idc; r3.idn=s.idn; r3.TTs=s.TTs; r3.InfoP=s.InfoP; r3.CRC=s.CRC;}
end

72. 62
connector type N-Data(Dataa r, Dataa s)
dene r s
on r s down{
s.ft=r.ft; s.idc=r.idc; s.idn= r.idn ; s.L= r.L; s.CRC=r.CRC;}
end
connector type N-Request(Requesting r, Requesting s )
dene r s
on r s down{
s.ft=r.ft; s.idc=r.idc; s.idn=r.idn; s.NbrRS=r.NbrRS ; s.CRC=r.CRC ;}
end
connector type synch(HelloPortt3 s, HelloPortt3 r1, HelloPortt3 r2, HelloPortt3 r3)
dene s r1' r2' r3'
end
atom type Coordinateur(int id)
clock y,ts unit 1 second
data int idn
data int idc
data string ft
data oat TimeSYN
data string CRC
data int NbrRS
data int x
data tab VD
data tab VD1
data tab InfoP
data string packet
data int sum
data int i
data string L
data int TTs
export port Beacon RB(ft,idc,idn,TimeSYN,CRC)
export port Dataa RD1(ft,idc,idn,L,CRC)
export port Dataa RD2(ft,idc,idn,L,CRC)
export port Dataa RD3(ft,idc,idn,L,CRC)
export port Requesting RR1(ft,idc,idn,NbrRS,CRC)
export port Requesting RR2(ft,idc,idn,NbrRS,CRC)
export port Requesting RR3(ft,idc,idn,NbrRS,CRC)
export port StatF SS(ft,idc,idn,TTs,InfoP,CRC)

73. 63
export port HelloPortt3 ENDD()
place START, Request, Data, Sleep, Request3, Request1, Request2, Data1,Data2,Data3
initial to START
do {initVD(VD,3);idc=id; CRC=00; TimeSYN=0.00 ; printf(I'm %d, : , id); Ra-
dio(S,T); ft=Beacon Frame ;}
on RB
from START to Request
eager
reset y
do {printf(I'm %d, sending Beacon...., idc); printf(I'm %d, : , idc); Radio(T,R);}
on RR1
from Request to Request1
reset ts
do {rempVD(1,NbrRS,VD,VD1); printf(I'm %d, Request received from %d,idc, 1);printf(I'm
%d, : , idc); Radio(R,T);}
on RR2
from Request1 to Request2
when (ts == 500 microsecond)
do {rempVD(2,NbrRS,VD,VD1); printf(I'm %d, Request received from %d,idc, 2);
printf(I'm %d, : , idc); Radio(R,T);}
on RR3
from Request2 to Request3
when (ts == 1000 microsecond)
do {rempVD(3,NbrRS,VD,VD1); printf(I'm %d, Request received from %d,idc, 3);
printf(I'm %d, : , idc); Radio(R,T); ft=Statisticale Frame;}
on SS
from Request3 to Data
do {sum=StatFrame(3,VD,InfoP); printf(I'm %d, sending Statistical frame...., idc);
x=1; i=1 ; printf(I'm %d, : , idc); Radio(T,R);}
on RD1
from Data to Data1
provided (i==1 x=sum)
when (ts ==1500 microsecond)
reset ts
do {printf(I'm %d, Data received from %d,idc, i); x=x+1;i=2;}
on RD2
from Data to Data2

74. 64
provided (i==2 x=sum)
when (ts == 500 microsecond)
do {printf(I'm %d, Data received from %d,idc, i); x=x+1; i=3;}
on RD3
from Data to Data3
provided (i==3 x=sum)
when (ts == 1000 microsecond)
do {printf(I'm %d, Data received from %d,idc, i); x=x+1; i=1;}
on ENDD
from Sleep to START
when (y==1)
do {printf(I'm %d End of Beacon , idc);}
internal
from Data to Sleep
provided (xsum)
do {printf(I'm %d, : , idc); Radio(R,S);}
internal from Data1 to Data do {}
internal from Data2 to Data do {}
internal from Data3 to Data do {}
invariant inv1 at Request1 when (ts500 microsecond)
invariant inv2 at Request2 when (ts1000 microsecond)
invariant inv3 at Request3 when (ts1500 microsecond)
invariant inv4 at Data1 when (ts500 microsecond)
invariant inv5 at Data2 when (ts1000 microsecond)
invariant inv6 at Data3 when (ts1500 microsecond)
end
atom type Noeud (int ident, int size, string packet, bool ok)
clock y,ts unit 1 second
data int idc
data int idn
data string ft
data oat TimeSYN
data string CRC
data int NbrRS
data int x
data tab InfoP
data string L
data int TTs

75. 65
export port Beacon RB(ft,idc,idn,TimeSYN,CRC)
export port Requesting SR(ft,idc,idn,NbrRS,CRC)
export port StatF RS(ft,idc,idn,TTs,InfoP,CRC)
export port Dataa SD(ft,idc,idn,L,CRC)
export port HelloPortt3 ENDD()
place START,Request, Stat, Data, Sleep
initial to START do {NbrRS=size; idn=ident; idc=55; CRC=00; L=packet;
printf(I'm %d, : , ident); Radio(S,R);}
on RB
from START to Request
eager
reset y
reset ts
do {printf(I'm %d, Beacon received from %d, ident, idc) ;printf(I'm %d, : , ident);
Radio(R,T); ft=Request Frame;}
on SR
from Request to Stat
do {printf(I'm %d, sending Request...., ident);printf(I'm %d, : , ident); Radio(T,R);
}
on RS
from Stat to Data
do {printf(I'm %d, Statistical frame received from %d, ident, idc); printf(I'm %d, :
, ident); Radio(R,T); x=1; ft=Data Frame ;}
on SD
from Data to Data
provided (x=size ok==true)
do {x=x+1; printf(I'm %d, : , ident); print(sending Data...., L);}
on ENDD
from Sleep to START
when (y==1)
do {printf(I'm %d End of Beacon , ident);}
internal
from Data to Sleep
provided (ok==false)
do{printf(Node %d is sleeping, ident);}
internal from Data to Sleep
provided (xsize ok==true)

76. 66
do{printf(Node %d is sleeping, ident);}
end
compound type system()
component Coordinateur s(55)
component Noeud r1(1,10,Temp=37degre,true)
component Noeud r2(2,10, SpO2= 97% ,true)
component Noeud r3(3,10,NorHertbeat ,true)
connector C-Beacon b(s.RB, r1.RB, r2.RB, r3.RB)
connector N-Request rq1(r1.SR, s.RR1)
connector N-Request rq2(r2.SR, s.RR2)
connector N-Request rq3(r3.SR, s.RR3)
connector C-STAT st(s.SS, r1.RS, r2.RS, r3.RS)
connector N-Data d1(r1.SD, s.RD1)
connector N-Data d2(r2.SD, s.RD2)
connector N-Data d3(r3.SD, s.RD3)
connector synch sss(s.ENDD, r1.ENDD, r2.ENDD, r3.ENDD)
end

77. Annexe II
Exemple de trace d'exécution du système modélisé :
[BIP ENGINE] : BIP Engine (version 2015.06.152313-DEV )
[BIP ENGINE] : initialize components...
[BIP ENGINE] : random scheduling based on seed=1475657115
I'm 1, : ***Radio in mode Receive***
I'm 2, : ***Radio in mode Receive***
I'm 3, : ***Radio in mode Receive***
I'm 55, : ***Radio in mode Transmit***
[BIP ENGINE] at global time 0 and state 0 : 1 interaction :
[BIP ENGINE] : [0] ROOT.b : s.RB(?) r1.RB( ?) r2.RB(?) r3.RB(?) [ -INFTY, +INFTY
] eager
[BIP ENGINE] : - choose [0] ROOT.b : s.RB(?) r1.RB(?) r2.RB(?) r3.RB(?) at
global time 0
I'm 55, sending Beacon....
I'm 55, : ***Radio in mode Receive***
I'm 1, Beacon received from 55 I'm 1, : ***Radio in mode Transmit***
I'm 2, Beacon received from 55 I'm 2, : ***Radio in mode Transmit***
I'm 3, Beacon received from 55
I'm 3, : ***Radio in mode Transmit***
[BIP ENGINE] at global time 0 and state 1 : 1 interaction :
[BIP ENGINE] : [0] ROOT.rq1 : r1.SR(?) s.RR1(?) [ -INFTY, +INFTY ]
[BIP ENGINE] : - choose [0] ROOT.rq1 : r1.SR( ?) s.RR1(?) at global time 17ns
I'm 1, sending Request....
I'm 1, : ***Radio in mode Receive***
number of slots requested from node 1 = 10
I'm 55, Request received from 1
I'm 55, : ***Radio in mode Transmit***
[BIP ENGINE] at global time 17ns and state 2 : 1 interaction :
[BIP ENGINE] : [0] ROOT.rq2 : r2.SR(?) s.RR2(?) [ 500us17ns, 500us17ns ]
[BIP ENGINE] : - choose [0] ROOT.rq2 : r2.SR(?) s.RR2(?) at global time 500us17ns
I'm 2, sending Request....
I'm 2, : ***Radio in mode Receive***
number of slots requested from node 2 = 10
I'm 55, Request received from 2
I'm 55, : ***Radio in mode Transmit***
[BIP ENGINE] at global time 500us17ns and state 3 : 1 interaction :
67

78. 68
[BIP ENGINE] : [0] ROOT.rq3 : r3.SR(?) s.RR3(?) [ 1ms17ns, 1ms17ns ]
[BIP ENGINE] : - choose [0] ROOT.rq3 : r3.SR(?) s.RR3(?) at global time 1ms17ns
I'm 3, sending Request....
I'm 3, : ***Radio in mode Receive***
number of slots requested from node 3 = 10
I'm 55, Request received from 3
I'm 55, : ***Radio in mode Transmit***
[BIP ENGINE] at global time 1ms17ns and state 4 : 1 interaction :
[BIP ENGINE] : [0] ROOT.st : s.SS(?) r1.RS(?) r2.RS(?) r3.RS(?) [ -INFTY, +INFTY
]
[BIP ENGINE] : - choose [0] ROOT.st : s.SS(?) r1.RS(?) r2.RS(?) r3.RS( ?) at global
time 1ms28ns
total time slots requested = 30
Node 1 must sent at t= 1
Node 1 must sent at t= 4
Node 1 must sent at t= 7
Node 1 must sent at t= 10
Node 1 must sent at t= 13
Node 1 must sent at t= 16
Node 1 must sent at t= 19
Node 1 must sent at t= 22
Node 1 must sent at t= 25
Node 1 must sent at t= 28
Node 2 must sent at t= 2
Node 2 must sent at t= 5
Node 2 must sent at t= 8
Node 2 must sent at t= 11
Node 2 must sent at t= 14
Node 2 must sent at t= 17
Node 2 must sent at t= 20
Node 2 must sent at t= 23
Node 2 must sent at t= 26
Node 2 must sent at t= 29
Node 3 must sent at t= 3
Node 3 must sent at t= 6
Node 3 must sent at t= 9
Node 3 must sent at t= 12
Node 3 must sent at t= 15
Node 3 must sent at t= 18
Node 3 must sent at t= 21
Node 3 must sent at t= 24
Node 3 must sent at t= 27
Node 3 must sent at t= 30
I'm 55, sending Statistical frame....
I'm 55, : ***Radio in mode Receive***
I'm 1, Statistical frame received from 55

79. 69
I'm 1, : ***Radio in mode Transmit***
I'm 2, Statistical frame received from 55
I'm 2, : ***Radio in mode Transmit***
I'm 3, Statistical frame received from 55
I'm 3, : ***Radio in mode Transmit***
[BIP ENGINE] at global time 1ms28ns and state 5 : 1 interaction :
[BIP ENGINE] : [0] ROOT.d1 : r1.SD(?) s.RD1( ?) [ 1ms500us17ns, 1ms500us17ns ]
[BIP ENGINE] : - choose [0] ROOT.d1 : r1.SD(?) s.RD1(?) at global time 1ms500us17ns
I'm 1, : sending Data.... Temp=37degre
I'm 55, Data received from 1
[BIP ENGINE] at global time 1ms500us17ns and state 6 : 1 interaction :
[BIP ENGINE] : [0] ROOT.d2 : r2.SD(?) s.RD2( ?) [ 2ms17ns, 2ms17ns ]
[BIP ENGINE] : - choose [0] ROOT.d2 : r2.SD( ?) s.RD2(?) at global time 2ms17ns
I'm 2, : sending Data.... SpO2= 97I'm 55, Data received from 2
[BIP ENGINE] at global time 2ms17ns and state 7 : 1 interaction :
[BIP ENGINE] : [0] ROOT.d3 : r3.SD(?) s.RD3( ?) [ 2ms500us17ns, 2ms500us17ns ]
[BIP ENGINE] : - choose [0] ROOT.d3 : r3.SD(?) s.RD3(?) at global time 2ms500us17ns
I'm 3, : sending Data.... NorHertbeat
I'm 55, Data received from 3
[BIP ENGINE] at global time 2ms500us17ns and state 8 : 1 interaction :
[BIP ENGINE] : [0] ROOT.d1 : r1.SD(?) s.RD1( ?) [ 3ms17ns, 3ms17ns ]
...
[BIP ENGINE] : - choose [0] ROOT.d1 : r1.SD(?) s.RD1(?) at global time 15ms17ns
I'm 1, : sending Data.... Temp=37degre
Node 1 is sleeping
I'm 55, Data received from 1
[BIP ENGINE] at global time 15ms17ns and state 33 : 2 interactions :
[BIP ENGINE] : [0] ROOT.d2 : r2.SD(?) s.RD2(?) [ 15ms500us17ns, 15ms500us17ns
]
[BIP ENGINE] : [1] ROOT.sss : r1.ENDD(?) [ 1s, 1s ]
[BIP ENGINE] : - choose [0] ROOT.d2 : r2.SD(?) s.RD2(?) at global time 15ms500us17ns
I'm 2, : sending Data.... SpO2= 97Node 2 is sleeping
I'm 55, Data received from 2
[BIP ENGINE] at global time 15ms500us17ns and state 34 : 2 interactions :
[BIP ENGINE] : [0] ROOT.d3 : r3.SD(?) s.RD3( ?) [ 16ms17ns, 16ms17ns ]
[BIP ENGINE] : [1] ROOT.sss : r1.ENDD(?) r2.ENDD(?) [ 1s, 1s ]
[BIP ENGINE] : - choose [0] ROOT.d3 : r3.SD(?) s.RD3(?) at global time 16ms17ns
I'm 3, : sending Data.... NorHertbeat
Node 3 is sleeping
I'm 55, Data received from 3
I'm 55, : ***Radio in mode Sleep***
[BIP ENGINE] at global time 16ms17ns and state 35 : 1 interaction :
[BIP ENGINE] : [0] ROOT.sss : r1.ENDD(?) r2.ENDD(?) r3.ENDD(?) s.ENDD(?) [
1s, 1s ]

80. 70
[BIP ENGINE] : - choose [0] ROOT.sss : r1.ENDD(?) r2.ENDD(?) r3.ENDD(?)
s.ENDD(?) at global time 1s
I'm 1 End of Beacon
I'm 2 End of Beacon
I'm 3 End of Beacon
I'm 55 End of Beacon