Projet tutoré

Conception et développement
d'un réseau de capteurs sans fil

Projet réalisé par : Badet Mathieu

Bonneau Willy
Bodet Cédric

Encadré par : Belloir Nicolas

Hoang Natacha

Master 2ème année Technologies de l'Internet

Université de Pau et des Pays de l'Adour
Année 2006-2007

1
Table des matières
1Introduction à SysML...............................................................................................................3
1.1 Descriptif..........................................................................................................................3
1.2Schéma des évolutions apportés par SysML.....................................................................4
2SysML appliqué sur notre système...........................................................................................5
2.1Le diagramme d'exigences................................................................................................5
2.2Les diagrammes dynamiques............................................................................................6
2.2.1Les diagrammes de cas utilisation.............................................................................6
2.2.2Diagramme d’états.....................................................................................................8
2.2.3Les diagrammes d’activités ......................................................................................9
2.2.4Diagramme de séquence..........................................................................................12
2.3Les diagrammes de structure...........................................................................................16
2.3.1Block Diagram Definition.......................................................................................16
2.3.2Les diagrammes de blocs internes...........................................................................18
2.3.3Le diagramme paramétrique....................................................................................19
2.4Conclusion sur SysML....................................................................................................19
3Modélisation UML..................................................................................................................20
3.1Les diagrammes dynamiques..........................................................................................20
3.1.1Les diagrammes de cas d'utilisation........................................................................20
3.1.2Les diagrammes d'états............................................................................................22
3.1.3Les diagrammes d'activités......................................................................................23
3.1.4Les diagrammes de séquence...................................................................................25
3.2Les diagrammes statiques................................................................................................26
3.2.1Les diagrammes de classes......................................................................................26
4Implémentation en NesC.........................................................................................................28
4.1Code de l'application à déployer sur les capteurs non reliés...........................................28
4.2Code de l'application à déployer sur les capteurs reliés au PBC.....................................29
4.3Code de l'application à déployer sur les capteurs mobiles..............................................31
5Diagrammes de Gantt du projet..............................................................................................34
5.1Diagramme prévisionnel.................................................................................................34
5.2Diagramme réel...............................................................................................................34
6Conclusion..............................................................................................................................35

2
1Introduction à SysML

1.1 Descriptif
L'ingénierie logicielle a exprimé un besoin pour expliciter les concepts d'un système
complexe. Il s'agit d'avoir un langage facile à prendre en main. La pratique d'UML étant très
présente, un langage proche d'UML 2 aide fortement.
SysML est une extension d'UML 2.0 pour l'ingénierie des sytemes. Il a été développé
par OMG, Incose et AP233. La norme de la version 1.0 est sortie en juillet 2006. SysML
permet la spécification, l'analyse, la vérification et la validation des systèmes complexes
possédant une partie hardware, software, utilisateurs et les équipements.
SysML est seulement une représentation (avec notations et sémantiques) mais n'est pas
une méthode de conception.

Le but d'un langage de modélisation est la transition entre un cahier des charges(« basé
document ») et un modèle plus formel.
Les apports de SysML sur UML sont :
 les besoins(requirements),
 modèles fonctionnels,
 modèles de performances,
 modèle de composants du systèmes,
 et aussi d'autres modèles (couts, qualité, etc..)

Les avantages qu'apportent SysML sont les suivant :

 Améliore la communication entre les participants au projet.
 Aide au management des systèmes complexes en modélisant hiérarchiquement les
parties du système.
 Améliore l'impact de l'analyse des besoins sur le système.
 Propose un développement et une conception évolutive.
 Évite les ambiguités par une repésentation plus complète dûe aux modèles.
 Possibilité de réduire les risques de conception par une vérification et une
validation précoce et à la volée.

3
1.2 Schéma des évolutions apportés par SysML.

Dans le schéma suivant on peut voir la complétude de UML 2.0 et SysML 1.0

Le schéma ci-dessous présente l'arborescence des diagrammes UML avec les

suppléments apportés par SysML.

SysML Diagram

Behavior Requirement Structure

Diagram Diagram Diagram

Use Case Timing Block Definition Internal Block

Instance Diagram
Diagram Diagram Diagram Diagram

Activity Sequence State Machine Parametric

Package Diagram
Diagram Diagram Diagram Diagram

Same as UML 2

Modified from UML 2

New diagram type

4
2SysML appliqué sur notre système

2.1 Le diagramme d'exigences

Diagramme d'exigences

Descriptif :
Ce diagramme est nouveau dans SysML. Il permet de représenter les exigences du
cahier des charges par un modèle. La modélisation des exigences rend la communication
meilleure au sein d'une équipe de conception notamment lors de projets très volumineux
(aéronautique, automobile, etc...).

Les choix :
A partir des spécification du système, nous avons dégagé deux exigences principales :
une exigence au niveau de la communication et une durée de vie optimale.

5
 Pour l'exigence de performance de communication, nous l'avons spécialisé(« derive »)
en deux sous-exigences : performance de réception et d'émission. Ces deux exigences sont
satisfaites par le block radio qui va prendre en charge l'émission et la réception des messages.
Ces deux exigences (broadcasting, receive) sont utiliées dans les cas d'utilisations « Transmit
presence » et « Receive » (« refine »), et dérivent de l'exigence d'alimentation
(PowerSupplyPerformance) tout comme l'exigence de longévité. L'exigence sur l'alimentation
est garantie pas le bloc batterie.

Ce diagramme apparaît comme très pratique pour définir et expliciter les exigences et
les qualités d'un système. Son utilisation semble incontournable lors de la conception de gros
systèmes, en effet le travail de plusieurs équipes sur un projet peut entrainer des ambiguités
ou des différences d'interprétations. Ce diagramme permet de « formaliser » les exigences
dans le but d'améliorer la communication.

2.2 Les diagrammes dynamiques

2.2.1 Les diagrammes de cas utilisation

TopLevelUseCase

L’objectif de notre système est d’étudier les flux des personnes dans le centre ville de
Pau. Dans le cas d'utilisation haut niveau, l’acteur principal est le collecteur de données qui
récolte les données collectées par le réseau de capteurs. Ce relevé des informations doit
permettre la sortie de statistiques sur les flux de personnes.

6
 SensorNetworkUseCase

Diagramme de cas d'utilisation plus détaillé présentant les différents acteurs du

système, le passant pour qui les passages seront étudiés, le data’s collector qui récupèrera les
passages pour en calculer les statistiques.

SavePassage

Présentation détaillée des interactions que peut avoir le passant disposant d’un capteur
mobile avec le système de capteurs fixes. Pour que le cas d'utilisation « Collect datas » ait
lieu, le système doit être allumé (« Sensor ON »). Ce cas d'utilisation inclut deux sous cas :
Receive et Stock.

7
2.2.2 Diagramme d’états

SN_Statechart

Présente l’état d’un capteur lors de son fonctionnement. Nous voyons que l’état du
capteur dépend du PowerSource, autrement dit de son énergie ou batterie. Un capteur se
trouve soit en veille (attente qu'un événement le réveille), soit en activité. La fin de l'activité le
fait revenir en veille.

8
2.2.3 Les diagrammes d’activités

UnlinkedSensorActivity

Diagramme d’activité d’un capteur fixe non relié au Pau Broadband Country (PBC).
Son action dans le système est d’émettre, avec un délai Timer, un message de présence.
Un Timer est utilisé afin ne pas émettre continuellement, ce qui nuirait aux exigences
de communications, car les capteurs mobiles (avec une ressource énergétique limitée) se
trouveraient inondés de messages ce qui causerait une baisse de leur longévité.

9
 LinkedSensorActivity

Diagramme d’activité d’un capteur fixe relié au PBC. A la différence d’un capteur non
relié, celui-ci réceptionne des données de la part du capteur mobile (contenant la liste des
passages des capteurs non reliés au PBC) et doit lui confirmer la bonne réception de ce
message.

10
 MobileSensorActivity

Diagramme d’activité d’un capteur mobile. Nous pouvons voir qu’il est à un moment
donné dans l’activité CalculateReceiveSignalStrenghtIndicator, soit calculer la puissance du
signal reçu. Ce seuil sera déterminant afin qu’il envoie ses données au capteur fixe relié.
L’équation de calcul du RSSI se retrouve dans le diagramme paramétrique
ReceiveSignalStrenghtIndicatorOfSensor.

11
2.2.4 Diagramme de séquence

NetworkBlackBox

Diagramme de séquence expliquant les communications entre un capteur mobile et un capteur

fixe non relié ou un capteur mobile et un capteur fixe relié au PBC ( représenté par alt). Si le
message provient d'un capteur fixe non relié, la seule chose à faire est d'enregistrer le
message. Dans le cas d'un message envoyé par un capteur fixe relié, le capteur mobile répond
en envoyant sa liste des passages, et attend l'acquittement du capteur fixe.

12
 IdentificationBlackBox

Vue de haut niveau : un capteur fixe émet sa présence au capteur mobile.

IdentificationWhiteBox

13
Vue de bas niveau : représente l’émission du message de présence suivant que le capteur soit
relié ou non. Dans les 2 cas, le capteur enregistre le message.
Si [typeCapt =0] signifie que le capteur fixe est non relié, [else] signifie qu’il est relié.

ResponseBlackBox

Vue de haut niveau : Le capteur mobile transmet ses données au système de réseaux de
capteurs (sa liste de passages).

ResponseWhiteBox

Vue de bas niveau : Si le message capteur émetteur du message d’identification est de type
relié, (typeCapt =1) le capteur mobile envoi le total des informations qu’il possède à ce
capteur. Le capteur fixe réceptionne les données et les écrits dans sa mémoire.

14
 AcknowledgmentBlackBox

Vue de haut niveau : Le capteur fixe envoi un acquittement au capteur mobile.

AcknowledgmentWhiteBox
Vue de bas niveau : Une fois que le message envoyé par le capteur mobile a été reçu, celui-ci
attend la confirmation de la part du capteur fixe afin de pouvoir vider sa mémoire interne.

15
2.3 Les diagrammes de structure

2.3.1 Block Diagram Definition

Le bloc « SensorNetworkDomain » représente le système dans sa totalité. Il comprend

deux acteurs (les passants et l'administrateur chargé de récupérer les données), un block
modélisant les capteurs mobiles et un autre modélisant la partie fixe du système (les capteurs
fixes reliés ou non). Pour plus de clarté, chaque bloc va être détaillé ci-dessous.

Ce diagramme représente la structure d'un capteur mobile. Sa structure hardware est

une plateforme.

16
 Ce diagramme représente la structure hardware complète d'une plateforme et donc
d'un capteur mobile.

Le diagramme précédent présente la structure harware des capteurs fixes. Ils

composent le réseau de capteur et sont composés comme les capteurs mobiles d'une

17
plateforme (voir diagramme précédent). A noter que les capteurs fixes reliés au PBC
disposent d'une interface de connexion au PBC.

2.3.2 Les diagrammes de blocs internes

Le diagramme de bloc interne permet de représenter pour un bloc (dans ce cas le bloc
« plateform »), les flux échangés entre les différents blocs le composant. SysML permet
(contrairement à UML) la représentation de tous les types de flux : électrique, liquides, ondes
...etc.

18
2.3.3 Le diagramme paramétrique

Le diagramme paramétrique permet de modéliser des contraintes sur des valeurs

systèmes (dans notre systèmes, les 3 valeurs issues du bloc « radio »). Il va permettre de
modéliser le calcul d'équations ou de relations mathématiques. Dans notre système, le capteur
mobile doit calculer la puissance du signal de réception du message qu'il vient de recevoir,
suivant la puissance le traitement sera différent. Ce diagramme permet de modéliser la
manière avec laquelle le bloc « radio » va le faire.

Ce diagramme paraît très intéressant pour des systèmes temps réel ou des systèmes
complexes. Il apporte un réel plus vis à vis d'UML.

2.4 Conclusion sur SysML

SysML est née en réponse à un besoin des grands comptes de l'industrie pour
harmoniser et permettre une modélisation des systèmes complexes. Après avoir étudié et
manipulé SysML, il nous semble que cette modélisation apporte un plus vis à vis d'UML,

19
dont elle en reprend des aspects et rajoute des diagrammes importants (requirement et
parametric) qui facilite la communication avec une modélisation appropriée aux systèmes.

3Modélisation UML
Après avoir modélisé le système à l'aide de SysML, la deuxième partie du projet
consistée à implémenter les applications à déployer sur chaque type de capteur. Nous vous
présentons içi la modélisation des applications.

3.1 Les diagrammes dynamiques

Cette partie présente donc les diagrammes de cas d'utilisation, d'états, d'activités et de
séquences.

3.1.1 Les diagrammes de cas d'utilisation

Cas d'utilisation haut niveau

Cas d'utilisation pour les capteurs reliés au PBC

20
 Cas d'utilisation pour les capteurs non reliés

Diagramme de cas d'utilisation pour les capteurs mobiles

21
3.1.2 Les diagrammes d'états

Diagramme d'états pour un capteur non relié au PBC

Diagramme d'états d'un capteur fixe relié au PBC

22
 Diagramme d'état d'un capteur mobile

3.1.3 Les diagrammes d'activités

Diagramme d'activité pour un capteur fixe non relié

23
Diagramme d'activité pour un capteur fixe relié au PBC

Diagramme d'activité d'un capteur mobile

24
3.1.4 Les diagrammes de séquence

Diagramme de séquence entre un capteur fixe non relié et un capteur mobile

Diagramme de séquence entre un capteur relié au PBC et un capteur mobile

25
3.2 Les diagrammes statiques
Après avoir présenté les diagrammes dynamiques, nous allons présenter la partie
statique de la modélisation UML. Nous avons traité uniquement les diagrammes de classes
qui nous semblaient les plus pertinents pour l'implémentation.

3.2.1 Les diagrammes de classes

Diagramme de classe d'un capteur fixe non relié au PBC

Diagramme de classes d'un capteur fixe relié au PBC

26
Diagramme de classe d'un capteur mobile

27
4Implémentation en NesC
4.1 Code de l'application à déployer sur les capteurs non reliés

Fichier UnlinkedSensor.nc
configuration UnlinkedSensor {
}
implementation {
components Main, UnlinkedSensorM, TimerC,GenericComm as Comm;

Main.StdControl -> UnlinkedSensorM.StdControl;

Main.StdControl -> TimerC;

Main.StdControl -> Comm;
UnlinkedSensorM.Timer ->TimerC.Timer[unique("Timer")];
UnlinkedSensorM.SendMsg -> Comm.SendMsg[65];
}

Fichier UnlinkedSensorM.nc
module UnlinkedSensorM {
provides {
interface StdControl;
}
uses {
interface Timer;
interface StdControl as TempControl;
interface SendMsg;
}
}
implementation {

TOS_Msg beacon_packet;
uint16_t typeSensor;
uint16_t numSensor;
uint16_t loopTime;

command result_t StdControl.init(){

typeSensor = 0;
numSensor = TOS_LOCAL_ADDRESS;
loopTime = 10000;

return SUCCESS;
}

command result_t StdControl.start() {

call Timer.start(TIMER_REPEAT, loopTime);

return SUCCESS;
}

28
command result_t StdControl.stop() {
call Timer.stop();
return SUCCESS;
}

event result_t Timer.fired() {

*((int16_t *)beacon_packet.data[2]) = 1;
*((int16_t *)beacon_packet.data[3]) = numSensor;
*((int16_t *)beacon_packet.data[1]) = typeSensor;
call SendMsg.send(TOS_BCAST_ADDR, sizeof(int16_t), &beacon_packet);
return SUCCESS;
}

event result_t SendMsg.sendDone(TOS_MsgPtr msg, bool success) {

dbg(DBG_USR1, ">>> envoi effectué, success=%d\n", success);
return SUCCESS;
}

4.2 Code de l'application à déployer sur les capteurs reliés au PBC

Fichier LinkedSensor.nc :
configuration LinkedSensor {
}
implementation {
components Main, LinkedSensorM, TimerC,GenericComm as Comm;

Main.StdControl -> LinkedSensorM.StdControl;

Main.StdControl -> TimerC;

Main.StdControl -> Comm;
LinkedSensorM.Timer -> TimerC.Timer[unique("Timer")];
LinkedSensorM.SendMsg -> Comm.SendMsg[65];
LinkedSensorM.ReceiveMsg -> Comm.ReceiveMsg[65];

Fichier LinkedSensorM.nc:

/*
data[1] = type du message
0 : message d'un capteur non relié(présence)
1 : message d'un capteur relié(présence)
2 : message d'un capteur relié(acquittement)
3 : message d'un capteur mobile(envoi de toutes les données)
4 : message d'un capteur mobile(présence)

data[2] = nombre d'elements du tableau contenant tous les passages

bArrayOfMessage
data[3] et superieur jusqu'a data[29], les capteurs non relié rencontrés

*/

29
module LinkedSensorM {
provides {
interface StdControl;
}
uses {
interface Timer;
interface StdControl as TempControl;
interface SendMsg;
interface ReceiveMsg;

}
}
implementation {

TOS_Msg beacon_packet;
int16_t typeSensor;
uint16_t loopTime;
uint16_t bArrayOfMessage[1000]; //stock the nums of sensors
uint16_t sizeOfbArrayOfMessage = 0;

command result_t StdControl.init(){

typeSensor = 1; // 0 unlinked 1 linked 2 mobile
loopTime = 10000;

return SUCCESS;
}

command result_t StdControl.start() {

call Timer.start(TIMER_REPEAT, loopTime);

return SUCCESS;
}

command result_t StdControl.stop() {

call Timer.stop();
return SUCCESS;
}

event result_t Timer.fired() {

*((int16_t *)beacon_packet.data[1]) = typeSensor;
call SendMsg.send(TOS_BCAST_ADDR, sizeof(int16_t), &beacon_packet);
return SUCCESS;
}

event result_t SendMsg.sendDone(TOS_MsgPtr msg, bool success) {

dbg(DBG_USR1, ">>> envoi effectué, success=%d\n", success);
return SUCCESS;
}

event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr recv_packet) {

int i;
uint16_t nodeaddr = *((uint16_t *)recv_packet->addr);
int16_t typeMessage = *((int16_t *)recv_packet->data[1]);
int16_t messageSize = *((int16_t *)recv_packet->data[2]);
if(typeMessage == 3){
// send the aknowledge
*((int16_t *)beacon_packet.data[1]) = 2; // 2 for acknowledge
call SendMsg.send(nodeaddr, sizeof(int16_t), &beacon_packet);

30
}

//store the list from the mobile (data[] of the mobile sensor must contain
nums of all sensors he met)

for(i = 3;i < messageSize+3; i++) {

bArrayOfMessage[sizeOfbArrayOfMessage] = *((int16_t *)recv_packet-
>data[i]);
sizeOfbArrayOfMessage = sizeOfbArrayOfMessage + 1;
dbg(DBG_USR1, "<<<I received a message :
%d\n",bArrayOfMessage[sizeOfbArrayOfMessage-1]);
}

return recv_packet;
}

4.3 Code de l'application à déployer sur les capteurs mobiles

Fichier MobileSensor.nc :

configuration MobileSensor {
}
implementation {
components Main, MobileSensorM, GenericComm as Comm;

Main.StdControl -> MobileSensorM.StdControl;

Main.StdControl -> Comm;
MobileSensorM.SendMsg -> Comm.SendMsg[65];
MobileSensorM.ReceiveMsg -> Comm.ReceiveMsg[65];

Fichier MobileSensorM.nc :

/*
data[1] = type du message
0 : message d'un capteur non relié(présence)
1 : message d'un capteur relié(présence)
2 : message d'un capteur relié(acquittement)
3 : message d'un capteur mobile(envoi de toutes les données)
4 : message d'un capteur mobile(présence)

data[2] = nombre d'elements du tableau contenant tous les passages

bArrayOfMessage
data[3] et superieur jusqu'a data[29], les capteurs non relié rencontrés

*/

31
module MobileSensorM {
provides {
interface StdControl;
}
uses {
//interface Timer;
interface StdControl as TempControl;
interface SendMsg;
interface ReceiveMsg;

}
}

implementation {

TOS_Msg beacon_packet;
int16_t typeSensor;
uint16_t loopTime;
uint16_t bArrayOfMessage[27]; //stock the nums of sensors,
uint16_t sizeOfbArrayOfMessage = 0;
uint16_t dejarecu=0;

command result_t StdControl.init(){

typeSensor = 2; // 0 unlinked 1 linked 2 mobile
loopTime = 10000;
return SUCCESS;
}

command result_t StdControl.start() {

//call Timer.start(TIMER_REPEAT, loopTime);

return SUCCESS;
}

command result_t StdControl.stop() {

//call Timer.stop();
return SUCCESS;
}

event result_t SendMsg.sendDone(TOS_MsgPtr msg, bool success) {

dbg(DBG_USR1, ">>> envoi effectué, success=%d\n", success);
return SUCCESS;
}

event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr recv_packet) {

int i=0;
uint16_t nodeaddr = *((uint16_t *)recv_packet->addr);
uint16_t Strength = *((uint16_t *)recv_packet->strength);
int16_t typeMessage = *((int16_t *)recv_packet->data[1]);
//int16_t messageSize = *((int16_t *)recv_packet->data[2]);

if(typeMessage == 0){
// Store the unlinked sensor num
if(dejarecu != nodeaddr) {
dejarecu = nodeaddr;

32
 else if( (dejarecu == nodeaddr) && (Strength < 40) ){
dejarecu = 0;

}
bArrayOfMessage[sizeOfbArrayOfMessage] = *((int16_t
*)recv_packet->data[3]);
sizeOfbArrayOfMessage = sizeOfbArrayOfMessage + 1;
}

else if(typeMessage == 1){

if(dejarecu != nodeaddr){
*((int16_t *)beacon_packet.data[1]) = 3;
*((int16_t *)beacon_packet.data[2]) = 1;
*((int16_t *)beacon_packet.data[3]) =
TOS_LOCAL_ADDRESS;

for(i = 0;i<sizeOfbArrayOfMessage;i++){
*((int16_t *)beacon_packet.data[i+4]) =
bArrayOfMessage[i];
call SendMsg.send(nodeaddr, sizeof(int16_t),
&beacon_packet);
dejarecu = nodeaddr;
}
}
else if( (dejarecu == nodeaddr) && (Strength < 40) ) {
*((int16_t *)beacon_packet.data[1]) = 4;
*((int16_t *)beacon_packet.data[2]) = 1;
*((int16_t *)beacon_packet.data[3]) =
TOS_LOCAL_ADDRESS;
call SendMsg.send(nodeaddr, sizeof(int16_t),
&beacon_packet);
dejarecu = 0;
}

else if(typeMessage == 2){

if(dejarecu != nodeaddr){
sizeOfbArrayOfMessage=0;
dejarecu = nodeaddr;

return recv_packet;
}
}

33
5Diagrammes de Gantt du projet
5.1 Diagramme prévisionnel

5.2 Diagramme réel

En comparant les 2 diagrammes, on s'apercoit que la modélisation SysML a duré la

quasi-totalité du projet. En effet, la norme SysML étant très récente, des articles sont parus
durant le projet et certaines choses ont été comprises que plus tard, ce qui s'est répercuté sur la
planification du travail.

34
6Conclusion

Ce projet avait pour but d'étudier la possible implémentation d'une application capable
de relever des données concernant les flux urbains à l'aide d'un réseau de capteurs.

La partie principale de ce projet consistait à modéliser de façon complète le système et

l'application à l'aide d'UML et de SysML, tout récent langage de modélisation pour les
systèmes.
Après une phase d'étude et de pratique avec SysML, nous pouvons dire que cette
modélisation apparaît comme un complément pertinent à UML. En effet, SysML permet
d'intégrer les analyses techniques sur les systèmes au sein de nouveaux diagrammes, ce qui
lève certaines ambiguités dûes à l'impossibilité de les modéliser avant.
SysML offre une gamme complète de diagramme permettant la modélisation complète
d'un système et est une source de meilleure communication entre différentes équipes
travaillant sur des systèmes complexes.

Une perspective possible à ce projet serait sans doute une modélisation SysML d'un
système plus complexe, car c'est dans ce cas là qu'il s'avère le plus efficace à notre avis. En
effet, les grands comptes industriels ont demandé son apparition pour justement répondre aux
ambiguités qui été générées par la non modélisation « uniforme » des systèmes omplexes.

35