TP AADL: analyses temporelles

L’objectif de ce TP est d’illustrer les méthodes d’analyses temporelles vues en cours. Nous illustrerons en particulier la complémentarité entre analyse de temps de réponse des tâches et analyse de temps de latence des données.

Description de l’exemple étudié

Nous nous intéressons dans ce TP à l’architecture d’un système logiciel de commande de trajectoire d’un robot. Ce logiciel calcul les commandes à envoyer à un moteur à partir de données fournies par des capteurs de position et de distance.

Le moteur, ainsi que les capteurs, sont modélisés par des device AADL:

  • le device « engine » s’active périodiquement, toutes les 200 ms. Il reçoit deux informations pour commander le moteur: une commande correspondant à l’accélération à appliquer sur le moteur et une information de détection d’obstacle indiquant si le moteur doit être arrêté ou non.
  • le device « distance_sensor » s’active périodiquement, toutes les 100ms. Il fournit la distance de l’objet le plus proche. Ce capteur sert à détecter la présence d’obstacles.
  • le device « position_sensor » s’active périodiquement toutes les 50 ms. Il fournit la position du robot afin d’en calculer la vitesse et les commandes à envoyer au moteur.

L’architecture logicielle est composée d’un unique processus hébergeant trois tâches:

  • une tâche obstacle_detection
    • période: 100 ms.
    • temps d’exécution: compris entre 5 et 10 ms.
    • informations en entrée: la distance séparant le robot d’un objet; distance mesurée par le capteur de distance.
    • informations en sortie: une donnée de type « obstacle_detected« . Cette donnée doit être envoyé au moteur pour commander l’arrêt du robot.
  • une tâche speed_computation
    • période: 50 ms.
    • temps d’exécution: compris entre 10 et 15 ms.
    • informations en entrée: la position du robot, mesurée par le capteur de position.
    • informations en sortie: la vitesse du robot, qui doit être envoyée vers la tâche de calcul de la commande (décrite ci-après)
  • un tâche command_computation
    • période: 200 ms.
    • temps d’exécution: compris entre 60 et 70 ms.
    • informations en entrée: la vitesse du robot, calculée par la tâche speed_computation.
    • informations en sortie: l’accélération à imposer sur le robot, qui correspond à la valeur de la commande à appliquer sur le moteur. Cette valeur d’accélération est donc envoyée au moteur.

Le but de ce TP est de montrer que nous pouvons garantir un temps de latence compris entre

  • 120 et 450 ms pour les traitements allant du capteur de position jusqu’à la commande envoyée au moteur.
  • 20 et 400 ms pour les traitements allant du capteur de distance jusqu’à l’envoie de la détection d’obstacle envoyée au moteur.

Prise en main de l’environnement

Lancement de l’outil

Dans ce TP, l’environnement utilisé pour l’édition et la visualisation de modèles AADL est OSATE (Open-Source AADL Tool Environment). OSATE est développé au Software Engineering Institute de l’Université Carnegie Mellon (USA).

Lancez OSATE depuis le terminal (si vous utilisez l’outil sur vos propres machines, vous pouvez lancer l’outil directement, i.e. sans script, depuis le répertoire d’installation):

/comelec/softs/opt/aadl-tools/osat2-2.10.2/osate &

Choisissez un workspace à l’emplacement de votre choix (conseil: créez un répertoire dédié à un emplacement dont vous vous rappellerez, par ex: $(HOME)/studies/se206/osate_workspace).

Comme vous pouvez le voir, il s’agit d’un environnement basé sur Eclipse. De nombreuses fonctionnalités sont ainsi disponible (Ctrl+click, ou Ctrl+space par exemple).

Import de l’exemple

Avec cet exemple, nous allons commencer par une petite présentation des outils:

  1. Téléchargez l’archive qui se trouve ici, et désarchivez la.
  2. Importez le projet: cliquez sur « File –> Import …« .
  3. Dépliez le répertoire « General » puis sélectionnez « Existing projects in Workspace« , cliquez sur « next« .
  4. Sélectionnez le répertoire résultant de l’étape 1 (champ « Select root directory:« ).
  5. Sélectionnez le projet « simple-latency-analysis« .
  6. Cliquez sur Finish.

Visualisation du modèle

Après réalisation des actions décrites ci-dessus, vous avez obtenu un projet « simple-latency-analysis » qui contient plusieurs fichiers AADL: data.aadl, hadware.aadl, software.aadl, et integration.aadl.

Ouvrez ces modèles AADL, et consulter leur contenu pour comprendre l’architecture décrite. Identifiez en particulier les composants et propriétés utiles aux analyses temporelles vues en cours.

Pour vous aider à visualiser le contenu du fichier, vous pouvez

  • utiliser la vue « Outline« , sur la droite de l’environnement OSATE;
  • utiliser la vue graphique:
    1. sélectionnez un composant, par exemple control_application.impl (soit dans la vu « Outline », soit en sélectionnant son nom complet)
    2. clique droit
    3. cliquez sur Open Diagram; la représentation graphique du composant sélectionné apparait. Pour information, cette vue graphique est synchronisée avec le contenu du modèle textuel et peut aussi servir d’éditeur graphique (vous pouvez modifier le modèle à partir de cette visualisation graphique).

Nous vous conseillons d’utiliser la vue graphique pour vérifier les connections entre composants, ainsi que les spécifications de chemins de flux de données.

Description de l’architecture fournie

L’architecture fourni est un début de modélisation du système considéré (architecture décrite au début du sujet de TP). Les packages à compléter sont: « software.aadl » et « integration.aadl », et les parties à compléter sont identifiées avec un commentaire « — TO BE COMPLETED ». Quelques indications supplémentaires:

  • data.aadl: fourni une description des données échangées entre les devices et les threads. Ces données correspondent à celles décrites au début de ce sujet de TP.
  • integration.aadl: Il y a ici deux systèmes différents:  « main_sys.rta » et « main_sys.fla ».
    main_sys.rta représente une vue du système dédiée à l’analyse de temps de réponse des tâches. Dans ce système, la propriété compute_execution_time correspond au temps d’exécution du thread sans prendre en compte les interférences entre tâches.
    main_sys.fla représente une vue du système dédiée à l’analyse de temps de latence des données. Dans ce système, la propriété compute_execution_time correspond au temps de réponse du thread en prenant en compte les interférences entre tâches.

Instructions: complétez le modèle AADL pour qu’il corresponde à la description du système fournie au début du sujet de TP. Complétez également les chemins de flux de données dans les composants logiciels.

Vérification des contraintes temporelles

Dans cette section, nous expliquons comment lancer les outils d’analyse de temps de réponse et de temps de latence. Dans ce TP, pour automatiser les analyses de temps de réponse des tâches, nous utiliserons l’outil AADL Inspector développé par la société Ellidiss (France).

Analyse de temps de réponse des tâches

Lancez AADL Inspector.

  • Sur Linux, il faut taper la commande: <AADLInspector_InstallDir>/bin/AADLInspector. Sur les machines de l’école, <AADLInspector_InstallDir>/comelec/softs/opt/aadl-tools/AI-1.8/bin/AADLInspector/
  • Sur Windows, lancez l’exécutable AADLInspector1-7Windows.exe

Cliquez sur « File –> Load » puis sélectionnez dans le répertoire de votre projet (où se trouvent les fichiers aadl), le fichier simple_latency_analysis.aic –> open.

  • pour connaître le pire temps de réponse des threads, cliquez sur l’onglet « Timing Analysis » dans la fenêtre en haut à droite de l’outil; cliquez sur la petite icone « THE » (pour Theoretical Schedulability Test); dépliez la partie « worst case response time« 
  • pour visualiser le chronogramme d’ordonancement, cliquez sur le petit fromage (outil français ) à gauche de « THE« . Un warning apparaitra dans l’onglet Report mais vous pouvez l’ignorer.
  • Si vous voulez en savoir plus, jouez un peu avec l’outil et n’hésitez pas à poser des questions.

Analyse de temps de latence des données

Instanciation du modèle

Dans OSATE, les plugins d’analyse s’appuient sur une représentation plus synthétique du modèle qui s’appelle le modèle d’instance. Par analogie avec les langages orientés objets, nous « pourrions considérer » un type de composant AADL comme une « interface », une implémentation de composant AADL comme une « classe », et une instance de composant comme un « objet ».

En AADL, les instances sont construites à partir d’une implémentation de système racine: en prenant les sous-composants de ce système racine,  puis leurs sous-composants, on obtient un arbre de composants et chaque noeud de l’arbre correspond à une instance.

Pour instancier un modèle AADL, faites un click droit sur un « System Imp » (appelé système racine de l’instanciation) dans le « outline view » (compartiment de droite de Eclipse), puis cliquez sur « Instantiate« . Dans votre projet, un répertoire « instances » a été créé, il contient le modèle d’instance correspondant à l’arborescence de composants contenus dans le système racine que vous avez sélectionné.

ATTENTION: dans OSATE, il faudra refaire cette phase d’instantiation chaque fois que vous modifiez le modèle et que vous voulez relancer une nouvelle analyse.

Analyse

Pour automatiser les analyses de temps de latence, nous utiliserons un plugin de l’outil OSATE.

Etapes à suivre pour connaitre le pire temps de latence des données:
1. instanciez le système main_sys.fla
2. cela produit, dans un répertoire instances, un nouveau fichier qui correspond au modèle d’instance
3. sélectionnez le fichier produit
4. cliquez sur l’onglet Analyses (tout en haut de l’environnement), puis cliquez sur « Check Flow Latency« .
5. cela crée, dans le répertoire instances, un fichier Excel qui constitue un rapport d’analyse.

Objectif des analyses dans ce TP

Instruction: Modifiez le modèle AADL pour vous assurer que le temps de latence est bien compris entre

  • 120 et 450 ms pour les traitements allant du capteur de position jusqu’à la commande envoyée au moteur.
  • 20 et 400 ms pour les traitements allant du capteur de distance jusqu’à l’envoie de la détection d’obstacle envoyée au moteur.

Evidemment, vous ne pouvez pas modifier les informations correspondant à la description de l’architecture fournie en début de TP. Vous devez en revenche vous intéresser au temps de latence et à la gigue dus aux communications entre tâches. Reportez vous pour cela aux planches de cours qui présentent la différence entre les différentes valeurs de la propriété « Timing ».

Attention, avant de relancer une analyse, n’oubliez pas de ré-instancier le système racine à chaque fois que vous modifiez le modèle.

Exigences sur le temps de latence

Examinez la vue « Problems » dans Eclipse. Contient-elle des erreurs?

Il est possible de spécifier les valeurs de propriétés de latence attendues pour des End-to-End Flow en AADL. Ces propriétés sont déjà spécifiées dans le composant système « main_sys.fla » du fichier « integration.aadl« . Vérifiez qu’elles correspondent bien aux exigences de cet exercice…

Un peu de prise de recul

Dans ce TP, nous avons illustré la complémentarité des analyses de temps de réponse et de temps de latence: l’analyse de temps de réponse fournit les données d’entrée d’une analyse de temps de latence.

L’exercice que vous venez de faire a permis d’illustrer l’intérêt de l’usage de modèles d’architectures pour prédire les caractéristiques temporelles des fonctions implémentées. Nous avons pour cela utilisé des modèles pour prédire ces caractéristiques temporelles. Cette prédiction contient (comme toute prédiction) une part d’incertitude, notamment en ce qui concerne les temps d’exécution associées aux fonctions. L’usage de ce type de modèle est cependant très utile pour dimensionner des budgets temporels dans des spécifications techniques entre MOA et MOE.

Notez aussi l’aspect « compositionnel » de ces analyses: elles peuvent être menées indépendamment l’une de l’autre, ce qui permet de décomposer le problème d’analyse d’architecture dans son ensemble en plus petits problèmes (analyses par processeur, par bus, puis globales).

Enfin, notez que les temps de latence associés aux bus ont été fournis. En toute rigueur, il aurait fallu les calculer en utilisant un modèle mathématique proche (mais sensiblement différent) de celui dédié au calcul de temps de réponse des tâches. Le calcul d’ordonnancement multi-processeur pourra être vu en 3ème année.