Nous nous intéressons dans cette partie du TP à la possibilité de migrer notre solution point à point, définie dans le TP précédent, sur une architecture réseaux AFDX. Nous souhaitons savoir l’impact d’un tel choix sur le temps de latence de bout en bout des flot e2e_cmd et e2e_obst.
L’objectif de ce TP est d’explorer différentes solutions d’architectures informatiques pour évaluer la faisabilité d’utiliser un réseaux AFDX, synchrone, ou pointà point pour satisfaire une exigence de temps de latence de bout en bout.
Les slides de cours correspondant à cette partie du TP sont disponibles ici.
Prise en main de l’outil d’analyse de réseaux switchés
Nous commençons par vous guider sur l’utilisation d’un outil d’évaluation du temps de transmission.
Lancez l’outil en exécutant la commande:
$source /infres/s3/borde/Install/env_osate
$/infres/s3/borde/Install/osate2-2.3.5/osate &
Téléchargez (ici) l’archive qui contient un exemple très simple. Depuis OSATE, cliquez sur “File->Import…” Selectionnez “General->archive file” puis sélectionnez l’archive que vous venez de télécharger.
Depuis le fichier SimpleExample.aadl, instanciez main.impl. Selectionnez le fichier (d’extension .aaxl2) créé lors de cette instanciation puis cliquez sur le menu SEFA et clickez sur AFDX trajectory analysis.
L’exécution crée un fichier d’extension .csv qui décrit succinctement le résultat du calcul.
Archive du projet à compléter
Téléchargez (ici) l’archive qui contient une solution (différente) des parties précédentes.
Le package AADL SwitchedEthernetNetworkExample contient la définition de l’architecture réseaux vue en cours.
Vous devez modifier le modèle pour mettre à jour l’évaluation du temps de latence de bout en bout avec cette nouvelle architecture. Vous pouvez créer de nouvelles versions du fichier integration_p2p.aadl pour explorer différentes solutions.
La seule contrainte imposée est:
- le capteur de position est placé sur le end system 1
- le processus de contrôle est placé sur le end system 2
- le capteur de distance est placé sur le end system 3
- le contrôle moteur est placé sur le end system 4
En dehors de cette contrainte, vous êtes libre de modifier le modèle qui vous est fourni comme vous voulez. Ces modifications devront être décrites dans votre rapport en termes de préconisations pour choisir une architecture particulière ou imposer de modifications dans les caractéristiques temporelles des composants.
Indications utiles pour structurer le modèle:
- la propriété actual_connection_binding peut être utilisée pour binder un virtual bus sur un autre virtual bus.
- la propriété transmission_time peut être associée à un virtual bus.
Notez également que les exigences de temps de latence on changé:
- e2e_f_cmd : temps de latence de 100 ms .. 600 ms
- e2e_f_obst : temps de latence de 20 ms .. 500 ms
Le modèle obtenu doit permettre de remplacer “facilement” l’architecture matérielle pour évaluer différentes configurations (tous les composants logiciels sur un même processeur par exemple).
Vous devez livrer au moins une variante de l’architecture initiale, décrire vos solutions, et comparer les résultats obtenus (modèle et temps de latence) avec le résultat obtenu sur le modèle sans AFDX.