Partie I Spécification SART. Document de synthèse sur les méthodologies SART. Programmation sur exécutif temps réel

Transcription

1 Partie I Spécification SART Programmation sur exécutif temps réel Document de synthèse sur les méthodologies SART Document réalisé à partir de «Systèmes temps réel de contrôle-commande, conception et implémentation», F. Cottet et E. Grolleau, Dunod, Introduction La méthode SA-RT a été mise au point à la fin des années 80 pour exprimer les spécifications des applications temps réel. La méthode SA-RT intègre trois aspects fondamentaux d une méthode de spécification : - L aspect fonctionnel (ou transformation de données) : représentation de la transformation que le système opère sur les données et spécification des processus qui transforment les données ; - L aspect évènementiel (piloté par les évènements) : représentation des évènements qui conditionnent l évolution d un système et spécification de la logique de contrôle qui produit des actions et des évènements en fonction d événement en entrée et fait changer le système d état ; - L aspect informationnel (données) : spécification des données sur les flots ou dans les stockages. Ce dernier aspect, qui est en général assez négligé dans ce type d application, doit faire l objet d une description spécifique. 2. Syntaxe graphique de SA-RT 2.1. Flot de données Processus fonctionnel : représente une transformation de données. Un ou plusieurs flux de données en entrée sont traités pour donner un ou plusieurs flux de données en sortie. Un processus est représenté par un cercle avec un étiquette formée d un verbe décrivant la transformation avec d éventuels qualificatifs, et d un numéro pour l indexer. Figure 1 : Exemple de processus Flot de données : supporte ou transporte les valeurs d une certaine information. Ce concept représente le cheminement des données. Le flot de données est représenté par un arc orienté avec une étiquette formée d un nom (plus d éventuel qualificatif). INSA 4ème année I 2008/2009 Pierre-Emmanuel Hladik Figure 2 : Exemple de flot de données INSA Toulouse 2007/2008 4I PEH 2

2 Le flot de données peut représenter aussi bien une donnée de type continu qu une donnée discrète codée par un booléen. Une donnée peut décrire une donnée élémentaire ou bien une donnée structurée intégrant plusieurs données élémentaires. La spécification détaillée est faite dans le dictionnaire des données (voir ci-après). Stockage de données : modélise le besoin de mémorisation d une donnée de telle façon que sa valeur puisse être relue plusieurs fois. Il est représenté par deux traits horizontaux encadrant l étiquette de la donnée. Les arcs arrivants et sortants ne sont pas étiquetés. Les évènements sont souvent liés à l activation ou la désactivation des processus fonctionnels. Ces évènements spécifiques ont été formalisés et prédéfinis : - E pour Enable (activation d un processus périodique) ; - D pour Disable (désactivation d un processus périodique) ; - T pour Trigger (synchrone). On note entre parenthèse le type d événement sur l arc servant au flot de contrôle (voir figure 6). Les deux premiers évènements sont utilisés pour piloter un processus fonctionnel de type boucle sans fin ou périodique, c est-à-dire que le processus fonctionnel débute avec l événement E et est stoppé par l événement D. Entre les deux il a un comportement périodique. L événement T est utilisé pour activer une seule fois le processus fonctionnel. Figure 3: Exemple de stockage de données Terminaison : représente une entité extérieure au système échangeant des données avec le système modélisé. Ce peut être une entité logicielle (programme, base de données, ) ou matérielle (capteurs, actionneurs, réseau, ). Elle est représentée par un rectangle et nommée par une étiquette composée d un nom (plus d éventuels qualificatifs). Figure 4 : Exemple de terminaison 2.2. Flot de contrôle Le déclenchement de l exécution des processus de transformation de données peut être lié au rythme d apparition des données mais aussi par l occurrence d évènements. Le flot de contrôle est représenté par un arc orienté pointillé avec un étiquette composée d une nom avec d éventuels qualificatifs. La figure 5.a représente le pilotage de l exécution d un processus par une donnée alors que la Figure 6 : Exemple d événements spécifiques 3. Organisation de la méthode SA-RT La méthode est structurée de manière hiérarchique descendante et met en avant les aspects fonctionnels et comportementaux de l application analysée. La figure 7 représente l organisation générale de la méthode SA-RT avec l enchaînement des différents étapes et l ensemble des documents produits. Nous trouvons : - Diagramme de contexte : premier diagramme de flot de données permettant de décrire l environnement de l application à développer ; - Diagramme préliminaire : diagramme de flot de données présentant le premier niveau de l analyse fonctionnelle de l application ; - Diagramme de décomposition : diagramme de flot de données présentant les analyses des processus fonctionnels non primitifs ; - Spécifications des processus fonctionnels primitifs : spécification textuelle des fonctions réalisées par les processus fonctionnels ; - Spécifications des processus de contrôle : diagramme état/transition décrivant le fonctionnement des processus de contrôle (ce point ne sera pas abordé ici) ; - Dictionnaire des données : liste exhaustive des données et des évènements utilisés dans la spécification. Figure 5 : Exemple de flot de contrôle INSA Toulouse 2007/2008 4I PEH 3 INSA Toulouse 2007/2008 4I PEH 4

3 modélise les éléments qui fournissent ou consomment les données ou évènements de cette application. Il n y qu un seul processus fonctionnel dans un diagramme de contexte Diagramme préliminaire Le diagramme préliminaire est la première décomposition du diagramme de contexte. Le diagramme préliminaire représente la liste des processus fonctionnels nécessaires à l application avec le flot de données et de contrôle correspondant. Le nombre de processus fonctionnels composant ce diagramme doit être limité pour permettre une meilleure lisibilité (5 à 9 processus semble acceptable). On ne représente plus les terminaisons et on doit retrouver l ensemble des données et des évènements en entrée et en sortie du diagramme de contexte. Le passage des données entre les processus fonctionnels peut être réalisé selon les besoins avec les deux méthodes de base : flot de données directe ou unité de stockage Diagramme de décomposition Les diagrammes de décomposition permettent de raffiner la décomposition fonctionnelle de chaque élément du diagramme préliminaire. Lorsqu il n y a plus d intérêt à décomposer un processus fonctionnel, celui-ci est appelé processus primitif et doit être décrit par une spécification sous forme textuelle. Les règles suivantes doivent être respectées : - L ensemble des flots de données et des évènements entrants et sortants du processus décomposé doit se retrouver dans le diagramme de décomposition de ce processus avec le même typage ; - La numérotation des différents processus fonctionnels doit intégrer le numéro du processus fonctionnel analysé N sous la forme N.x ; - Les stockages doivent apparaître dans tous les diagrammes où les processus qui les utilisent Spécification des processus primitifs Tous les processus primitifs doivent être spécifiés textuellement. Cette spécification doit comprendre le nom du processus, son mode d activation, son mode de désactivation (s il existe), les données et évènements en entrée et en sortie et une description en pseudo-code du traitement à réaliser par le processus. La figure 8 donne un exemple de spécification pour un processus fonctionnel devant asservir les moteurs du bras manipulateur. Figure 7 : Organisation générale de la méthode SA-RT 3.1. Diagramme de contexte Le diagramme de contexte est une première étape importante qui représente l interaction entre le système et l environnement. Un processus fonctionnel numéroté 0 traduit l application à réaliser par le concepteur. Autour de ce processus fonctionnel, un ensemble de terminaisons INSA Toulouse 2007/2008 4I PEH 5 INSA Toulouse 2007/2008 4I PEH 6

4 Nom : Asservir moteurs Activation : mise en marche de l application Désactivation : jamais Evènement en entrée : mise_en_marche Donnée en entrée : consigne, positions_actuelles Donnée en sortie : commande_moteurs Description : Début Faire à chaque période Commande_moteurs <- calcul_commande(consigne, positions_actuelles) ; Fin Faire Fin Figure 8 : Exemple de spécification d un processus fonctionnel 3.5. Spécification des données Toutes les données qui apparaissent dans les diagrammes doivent être spécifiées par leur nom, leur rôle et leur type. Nom : Consigne Rôle : fournit la consigne d entrée de l asservissement du bras Type : donnée structurée de consigne_epaule et de consigne_coude Nom : consigne_epaule Rôle : fournit la consigne d entrée de l asservissement de l épaule Type : entier Figure 9 : Exemple de spécification de données Partie II Conception 1. Introduction L étape de conception a pour but de décrire les éléments qui seront manipulés lors de l implémentation pour répondre aux exigences de la spécification. 2. Conception Une méthode de conception doit permettre d exprimer les différents éléments constituants une application. Pour un système temps réel, on doit trouver : - Les tâches avec leur type d activation et les paramètres ou données en entrée et en sortie ; - Les relations entre les tâches : synchronisation de type asynchrone ou synchrone (rendez-vous) et les communications avec les données qui transitent entre les tâches ; - Le partage des ressources critiques Eléments graphiques de la conception Modélisation des tâches Une tâche représente l entité de base de l architecture. Elle peut avoir un ou plusieurs flots de données en entrée et un ou plusieurs flots de données en sortie. Elle est modélisée par un rectangle qui comporte une étiquette formée d un nom avec d éventuels compléments d objet. Figure 1 : Représentation d une tâche Modélisation de synchronisations et des communications On distingue deux types de synchronisation entre tâches : - asynchrone : la tâche en réception est bloquée et attend la réception d un événement pour continuer son traitement ; - synchrone : les deux tâches ont un rendez-vous (elles doivent être toutes les deux au point de synchronisation en même temps). Les synchronisations sont représentées par un arc entre deux tâches sur lequel figure un symbole permettant de distinguer le cas asynchrone du synchrone (voir figure 2). INSA Toulouse 2007/2008 4I PEH 7 INSA Toulouse 2007/2008 4I PEH 8

5 Figure 2 : Représentation des synchronisations Le moyen de réaliser cette synchronisation n est pas du niveau de la conception mais de la programmation. Des tâches peuvent aussi échanger des données, on parle alors de communication. Une communication est caractérisée par la taille de la zone d échange des données et éventuellement un mode de synchronisation. La communication est modélisée par des éléments de type boîte à lettre (BAL) qui permettent de caractériser la taille de la zone de communication et le mode de gestion des données. Une communication est représentée par un arc orienté, étiqueté par un identifiant, avec son mode synchronisation et sa taille (fig.3). Figure 3 : représentation des communications La figure 4 présente un exemple de BAL de taille 10 avec une gestion FIFO des données et qui est bloquante pour le récepteur. Figure 4 : Exemple d une BAL FIFO de taille 10 bloquant en réception Activation des tâches Une tâche peut être activée soit de manière périodiques soit suite à une interruption. Ces deux cas sont représentés par une ligne brisée orientée avec une étiquette spécifique : HTR(+ durée de la période) pour les activations périodiques et IT(+ nom de l interruption) pour les activations apériodiques. Figure 4 : Représentation des activations externes Modélisation des stockages de données Une ressource critique est représentée par un rectangle associé à des entrées permettant de réaliser une action sur les données : LIRE, ECRIRE, etc. Elle est qualifiée par un nom avec d éventuels compléments d objet. Figure 5 : Représentation d une ressource critique Plusieurs tâches peuvent demander l accès à une ressource critique qui sera gérée en exclusion mutuelle. Sa mise en œuvre au niveau de l implémentation n est pas spécifié dans la conception Mise en œuvre de la méthode de conception Phase 1 : Création des tâches. Chaque processus fonctionnel primitif est traduit en une tâche avec éventuellement une tâche de contrôle si le flux de contrôle est complexe. On peut établir deux autres règles découlant de cette étape : - Règle 1.1 : Une tâche est créée pour chaque processus fonctionnelle du diagramme SA-RT. - Règle 1.2 : Une tâche supplémentaire est associée au processus de contrôle du diagramme SA-RT si le processus de contrôle est complexe, c est-à-dire qu il possède au moins une structure conditionnelle. Phase 2 : Détermination de l activation des tâches. L activation de chaque tâche est définie soit sur un évènement externe soit sur une synchronisation avec d autres tâches. Relativement à cette phase, on peut énoncer les règles suivantes : - Règle 2.1 : Une tâche en entrée (acquisition de données) est obligatoirement déclenchée par l horloge temps réel (ex. tâche de scrutation d un paramètre physique), soit par une interruption provenant du procédé (ex. tâche d alarme). - Règle 2.2 : Les autres tâches sont activées sur un événement logiciel (activation par synchronisation ou communication avec les autres tâches), soit sur un événement interne (horloge temps réel, chien de garde, ). - Règle 2.3 : Les événements importants du diagramme flot de données de SA-RT peuvent être traduits par des synchronisations qui sont utilisés pour activer des tâches logicielles. Phase 3 : Mise en place des transferts de données. Le transfert des données est traduit par des communications ou par des ressources critiques. Il peut être nécessaire de revoir le dessin de l étape 2. Les relations de communication sont traduites par des boîtes aux lettres ou par des modules de données. Leur établissement peut se faire en se basant sur les deux règles suivantes : - Règle 3.1 : les communications directes entre les processus fonctionnels (flot de données d un processus fonctionnel à un autre) sont traduites préférentiellement par des boîtes aux lettres. - Règles 3.2 : Les communications par une zone de stockage entre les processus fonctionnels sont traduites préférentiellement par des modules de données, en particulier si cette zone de stockage se trouve partagée par plus d une tâche. INSA Toulouse 2007/2008 4I PEH 9 INSA Toulouse 2007/2008 4I PEH 10

6 Phase 4 : regroupement ou rassemblement des tâches. Afin d améliorer et de simplifier la première conception, le diagramme multitâche est de nouveau analysé pour regrouper certaines tâches. Ce regroupement peut être dû à : - la cohésion temporelle : le regroupement se fait pour des tâches ayant le même évènement d activation ou ayant la même période. - la cohésion séquentielle : le regroupement concerne des processus fonctionnels qui doivent s exécuter en séquence. - la cohésion fonctionnelle : le regroupement concerne des processus fonctionnels ayant une fonctionnalité commune. Phase 5 : Caractérisation des objets de la conception. Chaque objet du modèle doit être caractérisé pour en spécifier son comportement. Une tâche doit avoir : - Une description textuelle de son rôle - Une description algorithmique de son comportement, en portant une attention particulière aux appels de services. - Une priorité, éventuellement déterminée par des règles de type Rate Monotonic. - Un budget temporel qui représente une estimation de son temps d exécution. Un élément de communications doit être caractérisé par : - Les données qu il transportent (taille et type). 2.3 Un exemple simple de conception L application modélisée dans la figure 6 a pour but de lire, d afficher et de stocker l état d un bouton. La fonction d affichage et de mesure ne doivent pas être regroupée pour des raisons de modularité. Les solutions proposées sont viables, mais présentent chacune des inconvénients et surtout ne sont pas complètes Figure 6 : Exemple de conception INSA Toulouse 2007/2008 4I PEH 11 INSA Toulouse 2007/2008 4I PEH 12