TP 1 Castalia: utiliser, comprendre et modifier l'application
valueReporting
Les chemins d'accès indiqués dans le TP sont relatif
à la racine de Castalia (normalement ~/Castalia-3.2)
1. Lancer une simulation
- Aller dans Simulations/valueReporting
- Effacer si besoin le fichier de trace CastaliaTrace.txt
- Lancer la simulation avec ../../CastaliaBin
- Lancer la simulation en mode Express
- Quitter OMNET++ (l'interface graphique) une fois la simulation
terminée
- Regarder le contenu (avec un éditeur de texte par exemple)
du fichiers Castalia-Trace.txt.
- Que fait l'application?
- Quel capteur collecte les données?
2. Analyser un peu plus les traces écrites dans
Castalia-Trace.txt
- Afficher les informations de routage (routage simple en arbre)
avec grep
"level" Castalia-Trace.txt
- Afficher toutes les valeurs reçues par le capteur qui
collecte toutes les données, qui envoie ces données?
- Que constatez-vous?
- Combien de fois les capteurs envoient-ils leurs données?
- Afficher tous les instants d'envois de données par les
capteurs n°27 et n°15. Sont-ils identiques? Quelle est la
fréquence des envois?
3. Comprendre des paramètres du modèle
- Dans Castalia, chaque élément de simulation est
défini par une fichier .ned qui décrit dans un langage
spécifique la structure et les paramètres de
l'élément. Pour l'application ValueReporting, ce fichier
est src/node/application/valueReporting/ValueReporting.ned. Afficher ce fichier
et étudier le.
- Quels sont les
paramètres importants de cette application? Quels
paramètres ont des valeurs par défaut?
4. Modifier les paramètres de simulation de l'application
valueReporting
- Les paramètres pour lancer une simulation sont dans un
fichier omnetpp.ini
dans Simulations/valueReporting.
Ce fichier
définit par exemple le nombre de noeuds, la couche radio, la
couche MAC et la couche routage à utiliser. Il y a aussi les
paramètres liés à l'application, ces
paramètres étant normalement ceux défini dans le
fichier .ned associée à cette application (voir point
précédent)
- Quelle est la fréquence de capture des valeurs?
- Changer la fréquence de capture des valeurs à une
capture toutes les 3s
- Relancer la simulation et comparer les différents
résultats. Refaites de même pour une fréquence de
capture encore élevée: 0.5s
ATTENTION: les traces sont ajoutés au fichier de trace
précédent, effacez ce fichier au préalable si vous
ne
voulez pas conservez les anciennes traces
- Augmenter la taille du terrain de déploiement à
150mx150m et mettez 60 capteurs, relancez la simulation et regarder les
résultats. Refaîtes la même chose avec un terrain de
50x50 et 60 capteurs. Que constatez-vous?
5. Comprendre le code de l'application valueReporting
- Aller dans src/node/application/valueReporting
- Editer le fichier ValueReporting.cc
- Repérer les 2 méthodes startup()
et firedTimerCallback().
D'après vous, que font ces méthodes?
- Que fait la méthode handleSensorReading()d'après
vous?
- Dans une simulation, la méthode la plus courante pour
représenter les événements ou les interactions
physiques est par l'envoi de messages. Repérer les types de
messages qui sont utilisés dans cette application.
- Quels sont les différents modules du capteur qui sont
sollicités dans cette application?
- Quelle fonction envoie sur le réseau les packets contenant
les valeurs
captés ?
6. Modifier le code de l'application valueReporting
- Le modèle de simulation actuel utilise le module physicalProcess
pour récupérer une valeur de
température
- Repérer dans le code la portion de code qui permet au
capteur de récupérer les valeurs captées et de les
envoyer
- Modifier le code pour que chaque capteur envoie une valeur de
température aléatoire
entre 37,8° et 45,5° (avec OMNET++, la fonction
genk_dblrand(index)
renvoie un double
uniformément réparti entre (double)0
et (double)1
pour le
générateur aléatoire index. Nous
utiliserons le plus souvent index=0.
- Relancer la simulation et vérifier que vos modifications
ont été bien prises en compte.