Le simulateur Castalia utilise un diagramme de classe pour modéliser ses composants. Aussi, avant de commencer à implémenter le modèle interne du produit actif, nous avons décomposé notre modèle de produit actif en classes. La figure 33 est le diagramme de classes de l’application à implémenter sous Castalia. On différencie dans nos travaux trois groupes de classes dans ce diagramme :
IV.1.Le premier groupe de classes :
Ce sont les classes qui existent déjà sous Castalia et qui n’ont pas été modifiées :
- BypassRoutingModule : cette classe implémente les fonctionnalités de la couche réseau. Sous Castalia 2.0, on a le choix entre trois types de routage :
BypassRouting : c’est un algorithme de routage trivial. Il y a deux destinations possibles pour un paquet : BROADCAST (diffusion) ou l’adresse d’un nœud destinataire MultipathRingsRouting : le protocole sauvegarde une trace du chemin traversé (les adresses des nœuds traversés).
SimpleTreeRouting : dans cette implémentation et celle du multipathRingsRouting, les messages sont retransmis d’un nœud à l’autre jusqu’à ce qu’il atteigne le puits. Les nœuds sont reliés de façon à former un arbre : chaque nœud a des nœuds parents et à travers eux, il communique avec les autres.
On a choisi d’utiliser la classe BypassRouting puisqu’elle contient les fonctionnalités de base de routage nécessaires à notre application.
126
- TunableMacModule : elle implémente la couche Mac (couche liaison), on peut choisir entre trois protocoles :
BypassMac : cette classe n’implémente que les fonctionnalités de base d’une couche MAC.
TunableMac : ils ont ajouté dans cette classe le mécanisme du protocole CSMA : le temps est composé en intervalles égaux. Le noeud actif ne peut accéder au media que dans des fractions d’intervalles bien définies selon la capacité d’énergie dédiée à chaque produit. Cette fraction est définie par le paramètre dutyCycle.
TMac : TMac est un protocole très utilisé dans les réseaux de capteurs.
- RadioModule : ce module a pour intérêt de réaliser les caractéristiques radios de faible capacité comme celui utilisé dans les plateformes réseaux de capteurs. Il supporte différents états (transmission, réception/écoute, veille), avec des puissances de consommation et de délais différents d’une transmission entre deux nœuds.
- RessourceGenericManager : garde des traces de différentes ressources des nœuds. Les autres classes l’utilisent lorsqu’ils ont besoin des ressources (exp. l’énergie).
IV.2.Le deuxième groupe de classes :
Ce sont les classes qui existent sous Castalia mais qui ont été modifiées :
- WirelessChannel : Castalia23 est le simulateur le plus proche d’un fonctionnement de canal sans fil. Cette classe contient les méthodes et les propriétés nécessaires pour qu’elle se comporte comme un vrai canal sans fil. Cette classe traite des statistiques sur les paquets envoyés et les paquets perdus provoqués notamment par des interférences. On a ajouté à la fonction finish() de cette classe l’affichage de la probabilité de pertes des paquets (totalRxFailedNodes/transmissions) pour un nombre de nœuds donnés (numNodes).
- SensorDevMgrModule : la classe applicationModule utilise cette classe pour accéder aux phénomènes surveillés (Physical Process). Généralement, elle reçoit des requêtes de lecture des valeurs ambiantes à partir de la classe applicationModule sous forme des messages de type (APP_2_SDM_SAMPLE_REQUEST), et elle répond aussi par des messages de type (SDM_2_APP_SENSOR_READING). Dans le reste de ce chapitre, on utilise l’abréviation « SDM » pour désigner ce module.
- CustomizablePhysicalProcess : cette classe correspond au composant physique qui surveille l’environnement. Ce composant est le capteur. Pour cela, ce composant doit avoir
23
127
toutes les caractéristiques souhaitées liées à un capteur. On a ajouté ici plusieurs attributs décrits comme des paramètres de configuration dans le modèle interne des produits actifs. La liste des attributs ajoutés sont les suivants : securityLevelTable, electronicCodeTable, symbolTable, substanceNameTable, substanceIdTable, addressTable, vMaxTable, vMinTable, dMaxTable, dMinTable. Ce module est appelé « Processus physique ».
IV.3.Le troisième groupe de classes :
Ce sont les classes ajoutées. Dans notre cas, on a ajouté une seule classe :
- ApplicationModule : cette classe représente la partie essentielle de l’implémentation du
modèle. Cette classe contient les mêmes attributs ajoutés à CustomizablePhysicalProcess avec le paramètre theRSSI (Received Signal Strength Indicator) [Bahl and Padmanabhan, 2000] [Niculescu and Nath, 2001] [Savarese et al., 2002] qui correspond à la valeur du RSSI envoyé avec chaque message. La figure IV.2 donne un extrait du fichier application_CMD1Packet.msg qui contient la structure du paquet CMD1.
Dans la méthode handleMessage, on a ajouté le traitement approprié à chaque message reçu. Ex : après la réception d’un message CMD1, le produit actif doit mettre à jour ses paramètres de configuration en utilisant ceux envoyés dans le paquet CMD1. S’il possède aussi les règles de sécurité, il peut alors commencer à lire les valeurs ambiantes et envoyer le message de salutation GRE (voir figure IV.3).
message application_CMD1Packet extends App_GenericDataPacket { fields: string substanceId; string substanceName; int symbol; string electronicCode; string address; };
128
case CMD1: {
printf("node: %d -> received APP_DATA_PACKET(CMD1) from %d at %f\n", self, atoi(msgSender.c_str()), simTime());
if (self == 0)
printf("ERROR: CMD1 must be sent by the supervisor to the node\n");
else { cmd1Received = true; valuePropagation_CMD1Packet *dataPacket; dataPacket = check_and_cast<valuePropagation_CMD1Packet *>(msg); theSymbol = dataPacket->getSymbol(); theSubstanceName = dataPacket->getSubstanceName(); theSubstanceId = dataPacket->getSubstanceId(); theElectronicCode = dataPacket->getElectronicCode(); theAddress = dataPacket->getAddress(); isConfigured = true; send2NetworkACK(msgSender.c_str() ,ACKCMD1, 1); if (hasSecurityRules == true) {
printf("node: %d is now Configured and it has SecurityRules at %f\n", self, simTime());
scheduleAt(simTime()+ DRIFTED_TIME(APP_SAMPLE_INTERVAL)/* to avoid missed receptions due to not yet started-up nodes */, new
App_ControlMessage("Application self message (request sample)", APP_SELF_REQUEST_SAMPLE));
scheduleAt(simTime() + DRIFTED_TIME(GRE_DELAY), new
App_ControlMessage("Application --> Application (self)", APP_NODE_GRE)); }
} break; }
Figure IV. 3. Extrait du code de l'application: traitement du message CMD1
129
Dans la figure IV.4, les flèches hachées signifie qu’il y a des relations de dépendance (utilisation entre les deux classes liées), et les flèches en continu désignent des relations d’héritage.
A des fins d’évaluation, nous avons implémenté le modèle des produits actifs développé avec les réseaux de Petri sous le simulateur Castalia. L’implémentation du modèle Réseaux de Petri sous Castalia se fait comme suit :
La figure IV.5 décrit un exemple traduit sous Castalia du modèle RdP de la figure III.12 qui modélise le passage de l’état « attente d’acquittement » à l’état « envoie NCF0 », « envoie NCF1» ou « envoie NCF2». La transition correspond à la réception du message ACKCTR, qui se traduit sous Castalia au « case AKCTR ».
Le traitement consiste à vérifier le type de configuration du produit actif. On a 3 possibilités de transition comme le montre le diagramme d’état/transition de la figure II.39 ou le modèle de la figure III.12, et selon le type de configuration, on passe à l’état « Envoie NCF0 »,
case ACKCTR: {
if (self == 0)
printf("ERROR: ACK must be sent by the supervisor to the node\n");
else
{
isAckCtr = 1;
theSecurityLevel = 0;
if (!isConfigured && !hasSecurityRules) {
printf("node: spentEnergy before sending NCF0 %f\n", resMgrModule->getSpentEnergy());
send2NetworkNCF(msgSender.c_str(),0, 1); }
else
if (isConfigured && !hasSecurityRules) {
printf("node: spentEnergy before sending NCF1 %f\n", resMgrModule->getSpentEnergy());
send2NetworkNCF(msgSender.c_str(),1, 1); }
else
if (!isConfigured && hasSecurityRules) {
printf("node: spentEnergy before sending NCF2 %f\n", resMgrModule->getSpentEnergy()); send2NetworkNCF(msgSender.c_str(),2, 1); } } break; }
130
« envoie NCF1» ou « envoie NCF2». Sous Castalia, cela correspond à la méthode « send2NetworkNCF » qui envoie NCF0, NCF1 ou NCF2.
Ce travail d’implémentation sous Castalia a été réalisé pour tous les RdP présentés dans le chapitre précédent.