//**************************************************************** ** ** Infos concernant la gestion desiree pour les TRs/Modules ** dans une IHM ** ** Author : Roger Pissard-Gibollet - Soraya Arias ** Date : 29/11/2002 ** ******************************************************************// 0. Vocabulaire: - TR = Tâche Robot - PR = Procédure Robot - PhR = Ressource Physique - 3 types d'entités sont concernées par la spécification o le module o la TR o la PR 1. Remarques générales concernant la spécification et l'édition : * Généralités : - 1 format de fichier pour les spécifications fonctionnelles (.xml) par type d'entités. - 1 format de fichier pour la description graphique (.graph) par type d'entités. Les fichiers .graph sont liés aux éditeurs qui permettent de rentrer les spécifications. Ils décrivent la présentation. Pour les éditeurs prévus : o éditeur de modules : il n'y a pas de fichier graphique car la présentation est déduite des spécifications. o éditeur de TRs : le fichier graphique doit contenir les positions et tailles des modules, des ports, des liens, les couleurs … o éditeur de PrRs : pas de fichier graphique pour la version Esterel textuelle - Les entités se pointent entre elles : une application robotique spécifiée via Orccad consiste est un ensemble de fichiers prr.xml, tr.xml, module[i..j].xml. - Les fichiers .graph sont liés aux éditeurs graphiques qui permettent à l'utilisateur de rentrer les spécifications pour chaque entité. - POINT IMPORTANT : il faut assurer la cohésion entre les données de description graphique d'une entité et les données de description fonctionnelle de l'entité, i.e entre le fichier .graph et le fichier .xml les données doivent être cohérentes. * Philosophie d'édition : - L'utilisateur dispose à la base d'un éditeur de TR à travers lequel il pourra éditer des modules, soit pour en créer de nouveau ou pour mettre à jour des modules déjà créés. - L'éditeur de Modules permet de spécifier les données fonctionnelles du module. La présentation est "standard". - L'éditeur de TR permet de rajouter/supprimer des modules, de modifier au niveau module : leur taille, la position des ports, et permet de créer, mettre à jour les liens entre module. Pour ce qui est des données fonctionnelles d'un module (ajout ou suppression d'un port) il faut passer par l'éditeur de module intégré - Les TRs pointent sur des modules partagés ou non entre TRs mais à l'édition du module, on peut le locker pour interdire la modification des données fonctionnelles (lock sur le fichier .xml) mais on pourra modifier les caractéristiques graphiques, par exemple : les positions des ports, la taille du module (modification du fichier .graph) - Dans le cas d'un module partagé : o Si on supprime un port : dans les TRs concernés, le port doit disparaître avec le lien associé o Si on ajoute un port : dans les TRs concernés, le port doit apparaître sans lien o Si on supprime un module : dans les TRs concernés, le module doit disparaître avec les liens associés o La mise à jour dans les TRs se fait à l'ouverture ou si la TR est en cours d'édition quand on sauvegarde le module. * Philosophie d'"ouverture" du logiciel pour rajout de nouvelles fonctionnalites - "Ouverture" au niveau de l'éditeur de TR, de PR et de la partie execution - "Ouverture" par ajout d'un ensemble de caractéristiques particulières, par rapport aux caractéristiques de base des modules, TRs et PRs. Ces caractéristiques peuvent affecter : * Au niveau TR : o la description des ports/des liens pour les besoin de synchronisation o la description des contraintes temporelles des modules algorithmiques o la description des paramètres o la description du typage des évenements, données logiques o la description des commentaires o ... * Au niveau PR: o la description des paramètres o la description des commentaires o la description du générateur de code pour le contrôleur o ... - Chaque ensemble de caractéristiques est identifié par un nom (prop_set_name1 dans le schéma correspondant à l'"ouverture"). Pour chaque ensemble de caractéristiques : o le fichier TR_i.xml pointe sur 1 fichier XML décrivant les caractéristiques. o au niveau de l'IHM de la TR, on peut lever un panneau de caractéristiques, défini par l'utilisateur pour rentrer ces données de caractérisation, après clic sur l'entité concernée (port, lien, module, événement ...). o on peut lancer un générateur de code associé à chaque ensemble de caractéristiques. Au niveau IHM, il faut prévoir de pouvoir paramétrer le générateur, par exemple en levant un panneau. [ PEUT-ETRE un peu lourd comme solution .... a voir ...] - MISC: o On peut prendre un exemple, dans lequel on doit rajouter les contraintes temporelles pour réaliser un générateur de code multi-cadence et d'autre part rajouter des commentaires supplémentaires pour réaliser un générateur de doc ... o Dans la phase d'implantation, on peut ne pas utiliser de mécanisme dynamique de librairies mais prévoir un nombre max d'ensembles de propriétés avec un index. 2. Description des données - Module : * Entité : o soit de calcul (module algorithmique) o soit de ressource physique : - controlée - type capteur non controlée Pour chaque entité, communication via des ports d'entrée-sortie particuliers à chaque entité, et différents type de traitements associés. * Exemple de description (non définitif ...) de fichier .xml pour le partie données fonctionnelles Algorithmic <\ID> Jacobian<\NAME> Module to compute a Jacobian input data InVect float 1 4 input data InMat double 2 2 Event ConvStatus output data OutMat double 2 2 Parameter NbLoop integer 1 0 <\MODULE> PhR Controlled <\ID> Bipede<\NAME> Module representating the Bipede robot input data InMotG float 1 4 putCmdMotG.c input data InMotD float 1 4 putCmdMotD.c input data InSpeed float 1 4 putSpeed.c output data OutState double 1 0 getBipStatus.c Event Status <\MODULE> Sensor <\ID> USBelt<\NAME> Module representating the US Belt set on the Bipede robot output data Status OutVect double 1 4 getVectVal.c Event Status <\MODULE> - TR : * Entité qui est spécifiée par: o une liste de modules o des contraintes temporelles représentées soit par : - une période/fréquence unique - une période/fréquence principale et des sous-périodes/fréquences qui affectent certains modules algorithmiques composant la TR. - autre chose + complexe (... pour la gestion du multicadence ....) o une liste de paramètres définies au niveau des modules composant la TR dont il faut préciser si ce sont des constantes (donner la valeur) ou des variables. o une liste d'événements typés (T1, T2 ou T3) et qui sont définis au modules composant la TR. * Contraintes au niveau de la spécification de la TR: o 1 PhR contrôlé et une seule o pas de boucle dans le graphe (à préciser ...) o tous les ports d'entrée de chaque module doivent être connectés o les ports d'entrée de chaque module reçoivent 1 lien et un seul o aucun lien sur les ports événements et paramètres * Exemple de description (non définitif ...) de fichier .xml pour le partie données graphiques d'une TR <\ID> InitBipede Bipede 10 5 100 80 InMotG 50 50 .... driver-data PortIDOrig PortIDDest data-data PortIDOrig PortIDDest <...> * Exemple de description (non définitif ...) de fichier .xml pour le partie données fonctionnelles d'une TR Cet exemple ne prend pas en compte la description de propriétés. <\ID> InitBipede<\NAME> Robot Task that initializes the main characteristics on the Bipede robot <\PATH> <\ID> Bipede PhR Controlled <\PATH> <\EVENT_T1> <\EVENT_T2> Status <\ID> Jacobian Algorithmic <\PATH> <\FREQUENCY> Conv_Status NB_LOOP 100 <\ID> US_Belt Sensor <\PATH> Status <\ID> Sick Sensor <\PATH> Transfert_Mode Status <\EVENT_T3>