Cas de modélisation d`une application temps réel avec UML

Modélisation UML
d’un Système d’acquisition
Cas d’étude
S. Anvar
CEA / DAPNIA
Schéma de principe
V
µ
t
Station
de Travail
Photomultiplicateur
Photomultiplicateur
Photomultiplicateur
Ethernet
SDRAM
Bus A32/D32
40 MHz
ϕ
Ethernet
Horloge de
référence
20 MHz (REFCLK)
Intégrateur/
Intégrateur/
Numériseur
Intégrateur/
Numériseur
(ASIC)
Numériseur
(ASIC)
(ASIC)
CPU
Acquisition
FPGA
I/O et interruptions
2
Protocole série
propriétaire
Max 20 Mb/s
REFCLK
Expression du besoin
n
n
n
n
n
n
3
Dans un but scientifique, un ensemble de 3 capteurs (photomultiplicateurs) détecte de
faibles émissions de lumière dans les abysses dues à la radioactivité.
Chaque capteur génère un signal électrique à partir de la réception d’un photon.
L’intégrale du signal est une fonction croissante de l’énergie du photon. Ce signal est
transmis à un ASIC d’intégration / numérisation (un pour chaque capteur).
L’ASIC produit sous une forme numérique (train de données de 6 octets) la valeur de
l’intégrale du signal ainsi qu’une étiquette temporelle l’instant d’arrivée du signal.
Le FPGA assure la lecture des données depuis l’ASIC par un protocole série propriétaire.
Il écrit les données en mémoire SDRAM selon une logique de type « buffer circulaire ». Il
y a un buffer par PM.
Toutes les 10 ms, le FPGA interrompt le processeur et définit ainsi une « trame » de
données par PM. Des registres du FPGA visibles dans l’espace d’adresse du processeur
fournissent la longeur des trames.
Le processeur d’acquisition retransmet ensuite ces données à travers un réseau Ethernet
à une station de travail dédiée au traitement et stockage des données.
Contraintes
n
n
n
n
4
Comme dans la plupart des projets, l’accent doit être mis la simplicité
et la minimisation des efforts de développement (réutiliser l’existant
quand c’est possible)
Le taux de photons reçu par chaque capteur peut fluctuer fortement
en raison de la bioluminescence des abysses.
Le FPGA doit être reprogrammé par le CPU Acquisition après chaque
extinction du système depuis un système de fichiers.
Le système électronique implanté dans le FPGA doit être initialisé par
le CPU Acquisition avant le lancement de l’application
Questions (1) : Modèle fonctionnel abstrait
n
Faire les diagrammes d’instance / collaboration faisant intervenir les
différents objets du système. Spécifier des appels d’opérations
synchrones et asynchrones sans se soucier des mécanismes
d’implémentation.
n
n
n
n
n
n
n
5
Objets hardware (non analogiques)
Objets actifs
Objets passifs
Appels synchrones et asynchrones d’opérations entre objets
Faire les diagrammes de classe obtenus par abstraction des
diagrammes précédents
Organiser les classes en paquetages pertinents
Faire les diagrammes de séquences spécifiant la production, le
formatage et l’envoi des données ainsi que le contrôle de flux
Questions (2) : Modèle d’implémentation
n
n
n
n
6
Faire les diagrammes de déploiement spécifiant les composants où résident les
classes décrites ainsi que les nœuds sur lesquels ces composants doivent être
chargés
Spécifier des classes de types « proxy » et « skeleton » ainsi que toutes autres
classes nécessaires pour assurer les appels distants synchrones à travers le réseau
(Remarque: il sera peut-être nécessaire d’expliciter les séquences de
communication)
Spécifier des classes de types « proxy » et « skeleton » ainsi que toutes autres
classes nécessaires pour assurer la communication FPGA ↔ processeur
(interruption, mémoire partagée, Xon, Xoff) (Remarque: il sera peut-être nécessaire
d’expliciter les séquences de communication)
Supposer l’existence d’un paquetage RealTime incluant les classes Thread et
Semaphore. Transformer les classes actives de l’application en tenant compte de ce
paquetage
Questions (3) : Modèle d’instanciation
n
n
n
7
Spécifier un objet central assurant le contrôle de la
création/initialisation/destruction des différents objets du
système.
Attacher à cet objet une machine d’état de type
Off àBooted à Initialized àRunning
Rééxprimer en conséquence le déploiement