• Expliquer le modèle AADL d'AOCS.
• Expliquer le fonctionnement d'OSATE.
• Décrire quelles sont les analyses disponibles dans OSATE applicables à des modèles AADL et ceux que vous avez pu appliquer au modèle AOCS.

Exploration d'architectures : CC UE VFS partie ordonnancement/AADL 2018/2019

1. L'ensemble des modèles AADL élaborés pour chaque question ; modèles que l'on doit pouvoir analyser avec AADLInspector.
2. Un rapport qui contient les réponses aux questions ci-dessous.

• La chaudière comporte une sonde thermique dont l'objet est de capturer la température de la chaudière. La température mesurée par cette sonde thermique est lue périodiquement par le traitement LIRE_CAPTEUR.
• La chaudière comporte un mécanisme d'arrêt d'urgence, utilisable par exemple, quand la température de la chaudière dépasse un seuil donné. Ce mécanisme est implanté par un actionneur qui coupe l'alimentation électrique de la chaudière. Le traitement ACTIVER_ARRET envoie la commande d'arrêt de la chaudière lorsque la situation le demande.
• La chaudière est également connectée à un thermostat dont l'objet est de régler la température à atteindre dans le local à chauffer. Le traitement TRANSMETTRE_THERMOSTAT a pour rôle l'envoie de la température de la chaudière au thermostat.
• Enfin un écran d'affichage permet de transmettre à l'utilisateur la température actuelle de la chaudière. Cet écran est piloté par le traitement AFFICHAGE.

• Permet de respecter les échéances des tâches.
• Permet de minimiser certaines latences, comme celle entre le moment où une température est lue par LIRE_CAPTEUR et le moment où le thread ACTIVER_ARRET émet la commande vers le dispositif d'arrêt d'urgence.
• Permet de minimiser, voire de supprimer le risque de perte de données.
• Permet de maximiser l'efficacité concernant l'utilisation des ressources: comme par exemple réduire le nombre de préemption, de commutation de contexte, de messages lus plusieurs.
• Etc

• La priorité d'AFFICHAGE est 1.
• La priorité d'ANALYSE est 4.
• La priorité de LIRE_CAPTEUR est 3.
• La priorité d'ACTIVER_ARRET est 5.
• La priorité de TRANSMETTRE_THERMOSTAT est 2.

• Proposer un modèle AADL où chaque traitement est modélisé par un thread et les échanges de données entre threads sont assurés par un ou plusieurs composants data. Cet ensemble de thread doit être ordonnancé selon un algorithme à priorité fixe préemptif.
• Expliquer:
  1. Que représente le composant AADL processor et la propriété actual_ processor_binding d'un modèle AADL ?
  2. En général, que peut on modéliser par un composant data ?
  3. Pourquoi peut il être intéressant de déclarer un composant data dans un paquetage séparé ?
• Analyser le comportement de votre modèle. Par exemple: Quels sont les pires temps de réponse des threads ? Dans le pire cas, quelle est la latence maximale entre le moment où une température est lue par LIRE_CAPTEUR et le moment où le thread ACTIVER_ARRET émet la commande vers le dispositif d'arrêt d'urgence? Peut on perdre des mesures ?

• Modifier votre modèle en employant des data port.
• Expliquer:
  1. Quelles sont les différences entre une connexion data port immediate et une connexion sampling ?
  2. Nous pourrions modéliser la sonde thermique et le thermostat avec des composants AADL devices (cette modification du modèle n'est pas demandée). En général, que représente un composant AADL device ?
• Analyser le comportement de ce nouveau modèle, d'abord quand les connextions sont de type sampling, puis de type delayed. Que constatez vous ? Par exemple: Quels sont les pires temps de réponse des threads ? Dans le pire cas, quelle est la latence maximale entre le moment où une température est lue par LIRE_CAPTEUR et le moment où le thread ACTIVER_ARRET émet la commande vers le dispositif d'arrêt d'urgence? Peut on perdre des mesures ?
  
  Si les résultats d'analyse sont différents de ceux de la question 1, expliquer alors ces différences.

• Dans les question 1 et 2, nous avons donc élaboré deux solutions architecturales différentes à partir d'une spécification. D'après vous, quelle est celle qui vous semble la plus appropriée, du point de vue des latences et des pires temps de réponse, mais également vis à vis de tout autre point de vue qui vous semble important de prendre en compte.
• Avez vous des suggestions pour améliorer ces modèles architecturaux ? On ne vous demande pas ici le modèle AADL amélioré mais seulement d'indiquer si des pistes d'amélioration vous semble possibles.

• On souhaite appliquer un mécanisme de redondance active sur le traitement ANALYSE. Modifier votre modèle AADL de la question 1 de sorte que :
  • Plusieurs instances d'ANALYSE recoivent la température mesurée et calculent donc autant de températures vérifiées.
  • Un nouveau traitement nommé VOTEUR recoit les températures vérifiées par les instances d'ANALYSE afin de détecter la présence d'une panne, pour finalement transmettre la donnée aux traitements ACTIVER_ARRET, AFFICHAGE et TRANSMETTRE_THERMOSTAT. Le traitement VOTEUR possède la même période qu'ANALYSE et une capacité de 1 ms.
• Comme dans les questions précédentes, analyser le comportement de ce modèle. Quels sont les pires temps de réponse des threads ? Dans le pire cas, quelle est la latence maximale entre le moment où une température est lue par LIRE_CAPTEUR et le moment où le thread ACTIVER_ARRET émet la commande vers le dispositif d'arrêt d'urgence ?
• Plus le nombre d'instance d'ANALYSE est grand, plus le système pourra tolérer de fautes d'ANALYSE. Combien de fois au maximum peut on instancier le composant ANALYSE sans manquer d'échéance ? Combien de pannes d'ANALYSE cela peut il permettre de tolérer ?

Projet CC UE VFS partie "ordonnancement" 2017/2018

1. Autosar/EAST-ADL.
2. MARTE/UML et Mast.
3. TASTE.
4. Symta/S.
5. Times.
6. Polychrony.
7. SCADE.
8. UPPAAL.
9. HRT HOOD.
10. Giotto.

• De vous organiser en groupe de 3 étudiants.
• Chaque groupe doit :
  1. Choisir une de ces approches sachant que chaque approche sera traitée par un groupe et un seul.
  2. Lire le document choisi. Il est, par ailleurs, facile de compléter cette lecture par d'autres documents disponibles sur Internet. Pour trouver d'autres articles sur chacune de ces approches, vous pouvez utiliser scholar.google.fr par exemple qui est un moteur de recherche pour les publications scientifiques.
  
  
  
• Pour début janvier, il vous est demandé de livrer un rapport de 4 pages maximum décrivant l'approche choisie en répondant aux questions suivantes :
  • Quels sont les systèmes ciblés ?
  • Comment les systèmes à vérifier sont il décrits/spécifiés ? En particulier comment sont modélisées les données temps réel de ces systèmes ?
  • Si une vérification d'ordonnancement est possible, comment est elle conduite ? Quelles sont les techniques de vérification et les modèles formels utilisés ? Les outils ?
  • Peut on réaliser une génération de code et pour quelles cibles ?
  
  
  
• Enfin, courant janvier, il vous sera demandé de présenter votre travail d'analyse lors d'une soutenance de 10 minutes de présentation, complétée par des questions.

Exercice 6, modélisation et analyse d'un switch

• D'un ensemble de ports d'entrée et de sortie.
• Chaque port d'entrée et chaque port de sortie mémorise un message.
• Chaque port d'entrée et associé à un port de sortie où ses messages sont envoyés.
• Pour chaque port d'entrée, une tâche copie le message du port d'entrée vers le port de sortie associé toutes les 50 ms.
• Nous supposons dans un premier temps que le commutateur ne comporte que 4 ports d'entrée et de sortie, soit 4 tâches nommées PORT_1, PORT_2, PORT_3 et PORT_4 ci-dessous.
• Une tâche, dont le nom est STAT, collecte toutes les 21 ms des statistiques sur l'utilisation des ports d'entrée et de sortie.
• Enfin, une tâche de supervision, dont le nom est SUPER, permet aux utilisateurs de configurer l'équipement.

package commutateurs
public 

  thread tache_periodique
    properties
         Dispatch_Protocol => Periodic;
  end tache_periodique;

  thread implementation tache_periodique.Impl
  end tache_periodique.Impl;

  process implementation Application.Impl
  subcomponents
    SUPER : thread tache_periodique.Impl;
    STAT  : thread tache_periodique.Impl;
  end Application.Impl;

  processor cpu
  end cpu;

  system commutateur
  end commutateur;

  system implementation commutateur.Impl
  subcomponents
    process1 : process application.Impl;
    cpu1 : processor cpu;
  end commutateur.Impl;

end commutateurs;

Exercice 7, modélisation et analyse d'un réfrigérateur

package refrigerateur
public 

  thread tache_periodique
    properties
         Dispatch_Protocol => Periodic;
  end tache_periodique;

  thread implementation tache_periodique.Impl
  end tache_periodique.Impl;
 


  process implementation Application.Impl
  subcomponents
    thermostat : thread tache_periodique.Impl;
    porte : thread tache_periodique.Impl;
    lampe : thread tache_periodique.Impl;
    alarme : thread tache_periodique.Impl;
    sonde : thread tache_periodique.Impl;
  end Application.Impl;

  processor cpu
  end cpu;

  system froid
  end froid;

  system implementation froid.Impl
  subcomponents
    process1 : process application.Impl;
    cpu1 : processor cpu;
  end froid.Impl;

end refrigerateur;

Exercice 9, analyse et génération de code pour la simulation d'un réfrigérateur avec Ocarina

1. Dans un premier temps, récupérer les fichiers de ce répertoire. Il s'agit d'un exemple de modèle AADL composé de 2 threads périodiques indépendantes(threads tic et tac). Cet exemple vous montre comment ocarina génére le code de l'application. Pour ce faire, il est nécessaire de procéder de cette façon:
   • Mettre en place l'environnement de travail avec la commande :

      source ocarina.bash

   • Générer le code C à partir du modèle AADL avec :

      ocarina -x scenario.aadl

     .
   • Le code C généré est stocké dans le répertoire root_impl. Il peut être compilé par :

     make

     dans ce même répertoire.
     Vous avez alors un exécutable Linux (fichier node_a) pouvant être lancé depuis le shell.
2. Etudier les fichiers générés activity.h et activity.c, deployment.h et deployement.c ainsi que main.c, puis indiquer leur rôle respectif.
3. Compléter/adapter l'exemple ci-dessus afin de pouvoir générer avec Ocarina le programme C correspondant à votre modèle de la question 1. Ce programme C constitue un simulateur de l'application permettant de se rapprocher de la mise en oeuvre du système.

1. On vous donne un nouvel exemple de modèle AADL, disponible ici qui vous montre comment intégrer un composant data avec Ocarina. La donnée partagée est modélisée par le composant Counter.
2. Etudier, générer le code avec Ocarina, compiler et tester ce modèle.
3. Expliquer le rôle des composants tic_sequence et tac_sequence.
4. Modifier votre modèle du réfrigérateur pour intégrer la donnée partagée entre Alarme et Thermostat.
5. Tester ce nouveau modèle avec Ocarina.

• Les tâches Alarme et Thermostat ainsi que leur donnée partagée sont déployées sur le premier processeur.
• Les tâches Sonde, porte et Lampe sont déployées sur le second processeur.
• Modifier votre modèle AADL en conséquence, puis, générer/tester le code avec Ocarina.
• Quelles sont les principales différences sur le code généré ?

Exercice 8, example d'utilisation d'OSATE

• Récupérer les fichiers zip et les ouvrir sur le bureau.
• Lancer osate ; créer un projet AADL composé d'un package contenant ce modèle AADL.
• Positionner les propriétés du property set Cheddar_Parameters_Properties afin de pointer sur le répertoire où vous avez stocké l'exécutable de cheddar.
• Générer le modèle d'instance et vérifier l'ordonnancement de ce jeu de tâches.