Systemes temps reel de controle-commande : Conception et implementation | Francis Cottet, Emmanuel Grolleau | download\nMain Systemes temps reel de controle-commande : Conception et implementation\nnon autorisée est282\nla photocopie non282\nphotocopie non autorisée282\nest un délit282\nautorisée est un282\nLabVIEW — Programmation et applications, Dunod, 2001\nISBN 2 10 007893 3\n1.3 Développement des applications de contrôle-commande\n2 • Spécification selon la méthode SA-RT\nIntroduction générale à la méthode SA-RT\nPrésentation de la syntaxe graphique de la méthode SA-RT\nLes diagrammes flot de données\nL’aspect contrôle de la méthode SA-RT\nSpécification des processus primitifs\nOrganisation générale de la méthode SA-RT\nExtensions de la méthode SA-RT\n3 • Conception selon la méthode DARTS\n3.2 Présentation de la méthode DARTS\n3.3 Exemples de conception avec la méthode DARTS\n4 • Architectures systèmes\n4.3 Réseaux et bus de terrain\n5 • Exécutifs temps réel\nConcepts des exécutifs temps réel\nPrincipales normes temps réel\nExemples d’exécutifs temps réel\n6 • Programmation des systèmes multitâches\n6.1 Programmation C, Ada et LabVIEW\n6.2 Programmation multitâche en langage C\n6.3 Programmation multitâche en langage Ada\n6.4 Programmation multitâche en langage LabVIEW\n7 • Traitement complet d’une application industrielle\n7.4 Implémentation sur simulateur\n7.5 Spécification et conception adaptées\n7.6 Implémentation de la commande réelle\n7.; 7 Conclusion\n8 • Étude avancée des systèmes temps réel\n8.2 Modélisation des tâches\n8.3 Ordonnancement des tâches indépendantes périodiques\n8.4 Ordonnancement des tâches indépendantes apériodiques\n8.5 Ordonnancement des tâches périodiques dépendantes\n8.6 Analyse d’ordonnançabilité en environnement monoprocesseur\n8.7 Ordonnancement en environnement multiprocesseur\nA • Représentation de l’information\nB • Standards POSIX\nC • Module de boîtes aux lettres POSIX\nD • Module de communication Ada\nLes applications informatiques dites de contrôle-commande ont envahi l’environnement industriel et notre vie quotidienne. Depuis quelques décennies, les besoins\nde plus en plus accrus en termes de technicité ont conduit à intégrer une très forte\nautomatisation dans tous les produits industriels ou destinés à l’usage « grand\npublic ». La liste infiniment longue des exemples contient des produits aussi divers\nqu’un téléphone mobile, un véhicule automobile, un four à micro-onde, une console\nde jeu, un satellite d’exploration, etc. Le dénominateur commun à toutes ces applications est la fourniture de fonctionnalités toujours plus sophistiquées : interface\nhomme-machine (écran couleur de haute définition, écran tactile, commande\nvocale…), nombre élevé de fonctions débordant largement l’utilisation de base du\nproduit (visualisation des commandes, liaison Internet…), sûreté de fonctionnement\n(robustesse, tolérance aux fautes, répartition, maintenance rapide et aisée…).\nPour ces raisons, les trois grands domaines permettant ces développements : l’électronique, l’automatique et l’informatique, ont dû progresser et s’adapter.\n– Électronique : processeur multifonctions (microcontrôleur), processeur à faible\nconsommation, réalisation de circuits électroniques dédiés (FPGA, FPLA), etc.\n– Automatique : lois de régulations adaptées, régulation numérique, etc.\n– Informatique : méthodes et méthodologies de développement, systèmes d’exploitation ou exécutifs embarqués, langages applicatifs, méthodes de tests et de\nLes domaines de l’électronique et de l’automatique ne sont pas le propos de cet\nouvrage. Toutefois, étant donné le développement lié entre les deux parties « matériel\net logiciel », une présentation succincte du matériel est faite. En revanche, nous\nallons nous intéresser particulièrement à l’aspect informatique ou plus exactement\nà l’aspect génie logiciel, c’est-à-dire la ou les méthodes permettant de développer\ncorrectement ces applications. La signification du terme « correctement » est précisée dans le chapitre suivant, mais nous pouvons déjà annoncer que ces applications\ndoivent être développées avec un grand souci de rigueur étant donné que leurs utilisations peuvent avoir un impact financier important, un effet nuisible sur l’environnement, ou plus gravement, mettre en jeu des vies humaines. Aussi la méthodologie de développement des applications de contrôle-commande doit assurer\nune qualité de réalisation en termes de fiabilité, d’efficacité, de maintenabilité,\nIl est important de noter qu’il n’est pas possible de parler des applications de contrôlecommande comme un ensemble homogène au sens de leur réalisation. En effet,\nentre les développements de l’application informatique gérant un four à microonde et celle pilotant une navette spatiale, la distance est immense : criticité de\nl’application, taille du logiciel, évolution de l’application… Le seul lien en commun\nest que toutes ces applications mettent en relation un programme informatique\navec un procédé externe.\nD’autre part, le développement des applications de petite taille ou de taille moyenne\na souvent été conduit par des professionnels du monde de l’automatique ou de\nl’électronique. Les régulations de type électromécanique ou électronique analogique\nont rapidement fait place à des systèmes purement numériques ; seuls les capteurs\net les actionneurs, faisant le lien vers le monde réel, sont toujours analogiques. Les\nconcepteurs de ces applications ont des méthodes basées sur l’aspect fonctionnel :\nschémas blocs, grafcets, etc. En effet, la spécification et la conception de telles\napplications sont plus aisées lorsqu’elles sont pensées en termes de fonctions ou de\ntraitements des données. Aussi les langages dédiés à ce type d’applications sont\ntout naturellement des langages fonctionnels à exécution séquentielle comme le\nlangage C, les assembleurs ou le langage flot de données LabVIEW.\nDans le domaine informatique, en parallèle, ces applications ont conduit à la mise\nen place de méthodes de spécification ou de conception répondant à ces besoins,\nc’est-à-dire des méthodes basées sur la description de l’aspect fonctionnel, soit\nl’analyse structurée (SA), l’analyse structurée temps réel (SA-RT), la conception\nstructurée (SD), etc. Ces méthodes correspondent parfaitement à ces besoins à\ncondition que les applications ne deviennent pas de grande taille et n’impliquent\ndes nombreuses données complexes (données structurées). D’autre part, il est important de noter que ces méthodes ont une dérivation très directe vers une implémentation multitâche qui permet de répondre à la fois à la logique du parallélisme du\nmonde réel en termes de conception et aux contraintes temporelles exigées.\nEn ce qui concerne les applications informatiques dites classiques (applications\nbureautiques, bases de données…), des méthodes basées sur les données ont été\nélaborées afin de répondre à un besoin fort de modélisation des données et de leurs\névolutions. Ces méthodes, dites orientées objets, permettent une spécification et une\nconception des applications en pensant avant tout en termes de données et d’actions\nsur ces données, mais en négligeant dans les premières étapes l’aspect fonctionnel,\nc’est-à-dire l’enchaînement, le séquencement ou l’exécution des différentes parties\nde l’application. Ces méthodes orientées objets, unifiées sous le nom UML (Unified\nModeling Language), sont devenues incontournables pour le développement des\nActuellement, ces méthodes orientées objets sont de plus en plus utilisées dans le\ndomaine des applications de contrôle-commande, domaine non concerné initialement par ce type de modélisation objet. Il est concevable et acceptable de suivre une\ntelle démarche pour des applications informatiques, même de contrôle-commande,\nde grande taille possédant souvent des données conséquentes de type complexe.\nMais il ne semble pas naturel de vouloir imposer ce type d’outils pour des applications de contrôle de procédés de petite ou moyenne taille ayant des données en\nnombre réduit et de type simple. D’autant plus que, comme nous l’avons noté précédemment, les utilisateurs de ces outils ont une culture de conception de type fonctionnel qui a une très grande efficacité. Ensuite les méthodes orientées objets vont\nconduire à des difficultés pour passer à l’étape de l’implémentation multitâche ;\ncette rupture de la chaîne de développement diminue fortement l’intérêt de ces\nméthodes de spécification et de conception.\nCet ouvrage a donc pris le parti de présenter une méthodologie complète de développement d’applications de contrôle-commande basé sur un aspect fonctionnel conduisant naturellement vers une implémentation multitâche. Sans rejeter les méthodes\norientées objets largement répandues aujourd’hui, il semble contraire aux règles\ndu génie logiciel d’utiliser une méthodologie non cohérente avec le domaine des\napplications ciblées, non cohérente à la fois en termes de logique d’analyse de bout\nen bout et d’objectifs applicatifs. Notre méthodologie, basée sur une approche\nfonctionnelle au niveau de l’analyse et une approche multitâche au niveau de\nla conception, s’adapte parfaitement aux applications de contrôle-commande\nde petite taille ou de taille moyenne mettant en jeu des données simples.\nLe premier chapitre présente l’environnement de développement des systèmes de\ncontrôle-commande en décrivant la spécificité de ces applications en termes d’architectures logicielles et matérielles. Le second chapitre traite de la méthode de spécification fonctionnelle choisie SA-RT (Structured Analysis for Real Time systems). La\nméthode de conception DARTS (Design Approach for Real-Time Systems) qui est la\nsuite logique de SA-RT est décrite dans le chapitre 3. Les environnements matériels\net logiciels (exécutifs temps réel) très particuliers de ces applications sont présentés\ndans les chapitres 4 et 5 afin de mieux comprendre la partie implémentation de ces\nsystèmes de contrôle-commande. Le chapitre 6 est dédié à l’implémentation des\napplications de contrôle-commande en déclinant trois environnements : noyau temps\nréel et langage de type langage C, langage Ada et enfin un environnement spécifique\nbasé sur LabVIEW. Les précédents chapitres sont illustrés par des exemples simples\nmais réalistes ; en revanche, le chapitre 7 propose le développement complet d’une\napplication réelle industrielle. Enfin, le chapitre 8 ouvre le développement de ces\napplications vers des aspects avancés concernant l’ordonnancement.\nVous trouverez en téléchargement sur le site www.dunod.com les codes sources de\ntous les programmes présentés dans cette ouvrage.\n1 • DÉVELOPPEMENT DES SYSTÈMES\nNous pouvons définir un système de contrôle-commande comme un système informatique en relation avec l’environnement physique réel externe par l’intermédiaire\nde capteurs et/ou d’actionneurs, contrairement aux systèmes d’informatiques scientifiques (gestion de base de données, CAO, bureautique…) qui ont des entrées\nconstituées de données fournies par des fichiers ou éventuellement un opérateur.\nLes grandeurs physiques acquises permettent au système de contrôle-commande\nde piloter un procédé physique quelconque. Donnons ainsi une définition générale\nd’un système de contrôle-commande (figure 1.1) :\n« Un système de contrôle-commande reçoit des informations sur l’état du\nprocédé externe, traite ces données et, en fonction du résultat, évalue une\ndécision qui agit sur cet environnement extérieur afin d’assurer un état\nCette notion d’état stable peut être différente selon les applications ou procédés.\nIl dépend du cahier des charges de l’application (maintien d’une température de\nconsigne, régime moteur, qualité de service…). Deux caractéristiques font qu’un\nsystème de contrôle-commande ne possède pas les propriétés classiques des systèmes\nd’informatiques scientifiques :\n– indépendance du résultat produit par rapport à la vitesse d’exécution. Le résultat\nd’un calcul effectué à partir de données d’entrée similaires est indépendant de la\nvitesse du calculateur. En revanche, l’état stable d’un procédé dépend de la dynamique du procédé par rapport à la vitesse d’exécution du système de contrôlecommande ;\n– comportement reproductible. Un calcul effectué à partir de données d’entrée\nidentiques donne toujours le même résultat. En revanche, dans le cas de données\nd’entrée (grandeurs physiques) obtenues par des capteurs, le système de contrôlecommande travaille sur un domaine de données réelles approximées qui sont\ntrès rarement identiques.\n1 • Développement des\nFigure 1.1 – Représentation schématique d’un système de contrôle-commande.\nL’interaction du système de contrôle-commande avec le procédé extérieur à piloter\nse décompose en deux parties (figure 1.2) :\n– observations par l’intermédiaire de capteurs (sensors) qui permettent d’obtenir\ndes informations sous la forme des interruptions (information tout ou rien) ou\ndes mesures (information continue) en provenance du procédé physique ;\n– actions réalisées par l’intermédiaire d’actionneurs (actuators) qui permettent d’agir\nsur le procédé physique sous la forme de commandes (modification d’état physique du système) ou simplement sous la forme d’un affichage (diodes, lampes,\nafficheurs, écrans, etc.).\nCette définition des systèmes de contrôle-commande ayant été faite, nous pouvons\nreplacer ces systèmes par rapport aux autres systèmes informatiques en faisant trois\n– les systèmes transformationnels qui utilisent des données fournies à l’initialisation par l’utilisateur. Ces données, leurs traitements et l’obtention du résultat\nn’ont aucune contrainte de temps ;\n– les systèmes interactifs dans le sens où les données sont produites par interaction avec l’environnement sous différentes formes (clavier, fichier, réseaux,\nsouris, etc.). Mais le temps n’intervient pas en tant que tel si ce n’est avec un\naspect confort de travail ou qualité de service ;\n– les systèmes de contrôle-commande ou réactifs qui sont aussi en relation avec\nl’environnement physique réel pour les données en entrée ; mais, dans ce cas,\nFigure 1.2 – Représentation schématique de l’interaction\ndu procédé physique piloté et du système de contrôle-commande.\nou de contrôle-commande\n(ex. : bureautique, CAO)\n(ex. : code de calcul)\nDonnées produites par l’environnement\nDonnées à l’initialisation\nFigure 1.3 – Comparaison des systèmes de contrôle-commande\npar rapport aux autres applications informatiques.\nl’aspect « temps » a une place importante sous la forme d’un temps de réaction,\nd’une échéance à respecter, etc.\nNous terminons cette section par des définitions qualifiant des systèmes de contrôlecommande ayant des spécifications particulières. La première de ces catégories\nconcerne les systèmes temps réel (real-time system) dont la définition est : « un système de contrôle-commande dans lequel l’exactitude des applications ne dépend\npas seulement du résultat mais aussi du temps auquel ce résultat est produit. Si les\ncontraintes temporelles de l’application ne sont pas respectées, on parle de défaillance du système ». Ces contraintes temporelles peuvent être de deux types :\n– contraintes temporelles relatives ou lâches (temps réel mou : soft real-time) :\nles fautes temporelles sont tolérables (ex. : jeux vidéo, applications multimédia,\ntéléphonie mobile…) ;\n– contraintes temporelles strictes ou dures (temps réel dur : hard real-time) : les\nfautes temporelles ne sont pas tolérables (ex. : avionique, véhicules spatiaux,\nautomobile, transport ferroviaire…).\nDans le cas des systèmes temps réel à contraintes temporelles relatives, nous pouvons\nparler de systèmes de contrôle-commande classiques.\n– système de contrôle-commande embarqué (embedded real-time system) : pas\nd’intervention humaine directe (pas de modification du programme ou des paramètres du programme) ;\n– système de contrôle-commande dédié (dedicated real-time system) : les architectures matérielles ou logicielles sont spécifiques à l’application (noyau, processeur…) ;\n– système de contrôle-commande réparti ou distribué (distributed real-time\nsystem) : l’architecture matérielle est constituée de plusieurs processeurs reliés\nentre eux par un bus ou un réseau.\nIl est évident que ces différentes spécifications d’un système de contrôle-commande\npeuvent se combiner comme par exemple un système de contrôle-commande\ndédié, distribué et à contraintes temporelles strictes (application pour un véhicule\n1.1.2 Principales caractéristiques des systèmes de contrôle-commande\nConsidérons un exemple représentatif d’une application de contrôle-commande\nreprésenté sur la figure 1.4. Cet exemple de contrôle-commande d’un moteur à combustion est repris de façon détaillée dans le chapitre suivant. Le contrôle-commande\nde cette application est fait par l’intermédiaire d’un ensemble de capteurs et d’actionneurs (pédale d’accélérateur, température air, pression air, température eau, rotation\nvilebrequin, capteurs de pollution, injection essence, allumage, admission air, etc.)\net d’une connexion au réseau interne à l’automobile. L’analyse de cet exemple d’application permet de mettre en exergue les principales caractéristiques des systèmes de\n– grande diversité des dispositifs d’entrées/sorties : les données à acquérir qui\nsont fournies par les capteurs et les données à fournir aux actionneurs sont de types\ntrès variés (continu, discret, tout ou rien ou analogique). Il est aussi nécessaire\nde piloter un bus de terrain pour les communications ;\nCommande de ré-injection\nCommande admission air\nFigure 1.4 – Exemple d’une application de contrôle-commande\nd’un moteur à combustion.\n– prise en compte des comportements concurrents : l’ensemble de ces donnés\nphysiques qui arrivent de l’extérieur et le réseau qui permet de recevoir des messages ne sont pas synchronisés au niveau de leurs évolutions, par conséquent, le\nsystème informatique doit être capable d’accepter ces variations simultanées des\n– respect des contraintes temporelles : la caractéristique précédente impose de\nla part du système informatique d’avoir une réactivité suffisante pour prendre\nen compte tous ces comportements concurrents et en réponse à ceux-ci, de faire\nune commande en respectant un délai compatible avec la dynamique du système ;\n– sûreté de fonctionnement : les systèmes de type contrôle-commande mettent\nsouvent en jeu des applications qui demandent un niveau important de sécurité\npour raisons de coût ou de vies humaines. Pour répondre à cette demande, il est\nnécessaire de mettre en œuvre toutes les réponses de la sûreté de fonctionnement\n(développements sûrs, tests, méthodes formelles, prévisibilité, déterminisme,\ncontinuité de service, tolérance aux fautes, redondance, etc.).\n1.1.3 Caractéristique temporelle des systèmes de contrôle-commande\nLe respect des contraintes temporelles d’une application de contrôle-commande\ndépend essentiellement de la dynamique du procédé. Cette caractéristique temporelle\npeut être très différente suivant l’application (figure 1.5) :\nCe paramètre temporel correspond à l’ordre de grandeur de la capacité de réponse\nou de traitement du système de contrôle-commande.\nFigure 1.5 – Comparaison de la dynamique\nde différentes applications de contrôle-commande.\nMais, comme nous le verrons dans le chapitre 8, il est nécessaire de préciser et de\nformaliser cette caractéristique temporelle qui peut prendre de nombreuses formulations. Ainsi, nous pouvons définir de manière non exhaustive :\n– Durée d’exécution d’une activité : l’activité d’une application, qui peut être\nl’enchaînement de plusieurs activités élémentaires (acquisition, traitement, commande, affichage…), possède une durée d’exécution qui peut être mesurée de\ndiverses manières. Cette durée n’est pas constante à chaque occurrence de cette\nactivité puisque les programmes et les enchaînements de programmes ne sont pas\ntoujours identiques (branchement conditionnel, itération, synchronisation…).\n– Cadence de répétition ou périodicité d’une activité : l’acquisition d’une donnée\nou la commande d’un actionneur peuvent nécessiter une régularité liée par exemple\nà la fréquence d’échantillonnage.\n– Date au plus tôt ou date de réveil : dans certains cas, un traitement doit être\ndéclenché à une date précise relative par rapport au début de l’exécution de l’application ou absolue (plus rarement). Cette date de réveil n’implique pas obligatoirement l’exécution ; il peut y avoir un délai de latence dû à l’indisponibilité du\n– Date d’activation : cet instant correspond à l’exécution effective de l’activité.\n– Date au plus tard ou échéance : le traitement ou la commande d’un actionneur\ndoivent être terminés à un instant fixé par rapport au début de l’exécution de\nl’application. Dans le cas d’applications à contraintes temporelles strictes, cette\néchéance doit être respectée de façon impérative, sinon il y a faute temporelle et\nl’application est déclarée non valide.\n– Temps de réponse : cette caractéristique peut s’appliquer à une activité de régulation ou à un ensemble d’activités de régulation ; elle est directement liée à la\ndynamique du système. Ce paramètre correspond à la différence entre la date de\nréveil et la date de fin de l’activité.\n– Gigue temporelle : ce paramètre caractérise la répétabilité d’une activité au fur\net mesure de ses occurrences. En effet, entre deux exécutions successives d’une\nmême activité, ses caractéristiques temporelles peuvent changer : date d’activation,\ndurée d’exécution, temps de réponse, etc.\n1.1.4 Quelques exemples d’applications\nNous pouvons citer quelques exemples d’applications de contrôle-commande :\n– Robot de production : un robot, réalisant une activité spécifique (peinture,\nassemblage, tri) sur une chaîne de production, doit effectuer son travail en des\ntemps fixés par la cadence de fabrication. S’il agit trop tôt ou trop tard, l’objet\nmanufacturier traité sera détruit ou endommagé conduisant à des conséquences\nfinancières ou humaines graves (oubli d’un ou plusieurs rivets sur un avion).\n– Robot d’exploration : ce robot doit se déplacer dans un environnement en\nprincipe non connu (zone radioactive après un accident, planète, épave sous la\nmer…). Il est important qu’il puisse réagir aux obstacles fixes ou mobiles afin de\nne pas conduire à sa perte.\n1.2 Architecture des applications\n– Téléphone mobile : le système de contrôle-commande doit remplir plusieurs\nfonctions dont certaines ont des contraintes temporelles fortes pour avoir une\nbonne qualité de service (QoS : Quality of Service). Ainsi, la première fonction\nest de transmettre et de recevoir les signaux de la parole (577 µs de parole émises\ntoutes les 4,6 ms et 577 µs de parole reçues toutes les 4,6 ms à des instants différents). En parallèle, il est nécessaire de localiser en permanence le relais le plus\nproche et donc de synchroniser les envois par rapport à cette distance (plus tôt si\nla distance augmente et plus tard si la distance diminue). Des messages de comptes\nrendus de la communication sont aussi émis avec une périodicité de plusieurs\nsecondes. Les contraintes temporelles imposées au système doivent être imperceptibles à l’utilisateur.\n– Système de vidéoconférence : ce système doit permettre l’émission et la réception d’images numérisées à une cadence de 20 à 25 images par seconde pour avoir\nune bonne qualité de service. Afin de minimiser le débit du réseau, une compression des images est effectuée. D’autre part la parole doit aussi être transmise.\nBien que correspondant à un débit d’information moindre, la régularité de la\ntransmission, qualifiée par une gigue temporelle, est nécessaire pour une reproduction correcte. De plus ce signal doit être synchronisé avec le flux d’images.\nL’ensemble de ces traitements (numérisations images et parole, transmission,\nréception, synchronisation…) sont réalisés en cascade, mais avec une cohérence\n– Pilotage d’un procédé de fabrication (fonderie, laminoir, four verrier…) : par\nexemple la fabrication d’une bobine d’aluminium (laminage à froid) exige un\ncontrôle en temps réel de la qualité (épaisseur et planéité). Cette vérification en\nproduction de la planéité nécessite une analyse fréquentielle (FFT) qui induit\nun coût important de traitement. Le système doit donc réaliser l’acquisition d’un\ngrand nombre de mesures (246 Ko/s) et traiter ces données (moyenne, FFT…)\nà la période de 4 ms. Ensuite, il affiche un compte rendu sur l’écran de l’opérateur\ntoutes les 200 ms et enfin imprime ces résultats détaillés toutes les 2 s. Un fonctionnement non correct de ce système de contrôle de la qualité peut avoir des\nconséquences financières importantes : production non conforme à la spécification\n1.2.1 Architecture logicielle des applications de contrôle-commande\nm Architecture multitâche\nLe comportement concurrent des événements et grandeurs physiques externes amène\nà décrire l’environnement comme un système fortement parallèle. Cela conduit\nnaturellement à adapter les méthodes de conception et de réalisation du système de\ncontrôle-commande d’un tel environnement à ce parallélisme. Aussi, l’architecture\nla mieux adaptée pour répondre à ce comportement parallèle du procédé externe\nest une architecture multitâche. Ainsi, au parallélisme de l’environnement, la\nréponse est le parallélisme de conception. Nous pouvons définir la tâche ou activité\nou processus comme « une entité d’exécution et de structuration de l’application ».\nCette architecture logicielle multitâche facilite la conception et la mise en œuvre et\nsurtout augmente l’évolutivité de l’application réalisée.\nD’une manière très générique, la figure 1.6 donne l’architecture logicielle d’une\napplication de contrôle-commande multitâche. Nous pouvons ainsi découper cet\nensemble de tâches ou activités selon les groupes suivants :\n– Tâches d’entrées/sorties : ces tâches permettent d’accéder aux données externes\npar l’intermédiaire de cartes d’entrées/sorties et ensuite de capteurs et d’actionneurs directement liés au procédé géré. Ces tâches peuvent être activées de façon\nrégulière ou par interruption.\n– Tâches de traitement : ces tâches constituent le cœur de l’application. Elles intègrent des traitements de signaux (analyse spectrale, corrélation, traitement d’images,\netc.) ou des lois de commande (régulation tout ou rien, régulation du premier\nordre, régulation PID, etc.). Dans le cadre de cet ouvrage, nous considérerons\nces tâches comme des boîtes noires, c’est-à-dire que le traitement effectué par ces\ntâches relève des domaines comme le traitement du signal, le traitement d’images\nou l’automatique, disciplines qui débordent largement le contexte de ce livre.\n– Tâches de gestion de l’interface utilisateur : ces tâches permettent de présenter\nl’état du procédé ou de sa gestion à l’utilisateur. En réponse, l’opérateur peut modifier les consignes données ou changer les commandes. Ces tâches peuvent être très\ncomplexes et coûteuses en temps de calcul si l’interface gérée est de taille importante (tableau de bord) ou de type graphique (représentation 3D).\nFigure 1.6 – Architecture logicielle d’une application de contrôle-commande multitâche.\n– Tâches de communications : ces tâches sont destinées à gérer les messages envoyés\nou reçus à travers un ou plusieurs réseaux ou bus de terrain. Si ce type de tâches\nexiste, l’application est dite distribuée ou répartie.\n– Tâches de sauvegarde : ces tâches permettent de stocker l’état du système à des\ninstants fixés. Cette sauvegarde peut être utilisée a posteriori pour analyser le\nfonctionnement de l’application ou lors d’une reprise d’exécution à une étape\nAprès l’analyse et la conception de l’application, nous obtenons un ensemble de\ntâches ou activités qui coopèrent afin de réaliser le contrôle-commande du procédé\ngéré. Ces tâches appartiennent aux différents groupes listés précédemment : tâches\nd’entrées/sorties, tâches de traitement, tâches de gestion de l’interface utilisateur,\ntâches de communications et tâches de sauvegarde. Ce découpage purement fonctionnel peut être modifié dans certains cas en utilisant une conception tournée\nvers les entités ou « objets » à contrôler. Cet aspect de la conception et de la mise\nen œuvre est présenté dans les chapitres suivants.\nLes tâches obtenues, qui constituent l’application de contrôle-commande, ne sont\npas des entités d’exécution indépendantes. En effet, certaines tâches sont connectées\nvers l’extérieur pour les entrées/sorties. De plus elles peuvent être liées par des relations de type (figure 1.7) :\n– synchronisation : cela se traduit par une relation de précédence d’exécution entre\n– communications : à la notion de précédence, traduite par la synchronisation,\ns’ajoute le transfert de données entre les tâches ;\n– partage de ressources : les tâches utilisent des éléments mis en commun au niveau\ndu système comme des zones mémoire, des cartes d’entrées/sorties, cartes réseau,\netc. Certaines de ces ressources, comme par exemple les zones mémoire, ne sont\npas ou ne doivent pas être accessibles, pour avoir un fonctionnement correct,\npar plus d’une tâche à la fois, elles sont dites ressources critiques.\nFigure 1.7 – Représentation schématique\nde l’architecture multitâche d’une application de contrôle-commande.\nCes différents concepts sont étudiés de façon détaillée dans le chapitre 4.\nm Modèles d’exécution et ordonnancement\nCette architecture logicielle peut être vue comme un ensemble de tâches synchronisées, communicantes et partageant des ressources critiques. Le rôle essentiel du\nsystème informatique est donc de gérer l’enchaînement et la concurrence des tâches\nen optimisant l’occupation du processeur, cette fonction est appelée l’ordonnancement. Ce principe d’ordonnancement est un point crucial des systèmes de contrôlecommande ; en effet l’ordonnancement va déterminer les caractéristiques temporelles et être le garant du respect des contraintes de temps imposées à l’exécution de\nNous pouvons distinguer deux modèles d’exécution de ces systèmes de contrôlecommande : l’exécution dite synchrone et l’exécution asynchrone. Nous allons présenter ces deux modèles d’exécution à l’aide d’un modèle d’application très simple.\nCette application, constituée d’un ensemble de tâches pour gérer le procédé, intègre\nen particulier les deux tâches suivantes :\n– Tâche de lecture des données entrées par l’opérateur à l’aide d’un clavier, appelée\n« Lecture_consigne ». L’intervention humaine fait que cette tâche peut être longue.\n– Tâche d’alarme qui se déclenche sur un événement d’alerte correspondant au\ndépassement d’un paramètre critique, appelée « Alarme ». Celle-ci doit s’exécuter\nau plus vite pour éviter l’endommagement du procédé.\nPour mettre en avant les différences entre les deux modèles d’exécution, nous allons\nétudier la situation dans laquelle la tâche « Lecture_consigne » s’exécute et la tâche\n« Alarme » demande son exécution alors que la tâche « Lecture_consigne » n’est\nDans le modèle d’exécution synchrone, la perception de l’occurrence de tout événement par le système est différée du temps d’exécution de la tâche en cours. Dans\nl’exemple proposé, nous pouvons constater que la prise en compte d’un signal d’alerte\nn’est effective que lors de la fin de la tâche « Lecture_consigne » (figure 1.8). D’un\npoint de vue du procédé, la réaction est perçue comme différée, alors que du point\nde vue du système informatique, elle est perçue comme immédiate. L’occurrence\nRéaction perçue comme immédiate\nFigure 1.8 – Modèle d’exécution synchrone d’une application de contrôle-commande.\ndes événements externes a donc été artificiellement synchronisée avec le système\ninformatique, d’où le nom d’exécution synchrone.\nCe retard peut affecter la prise en compte de n’importe quel événement, quelle\nqu’en soit la gravité pour l’application. Il faut donc vérifier que l’architecture opérationnelle choisie permettra de prendre en compte les contraintes temporelles :\nhypothèse de la fenêtre de visibilité des événements ou d’instantanéité des actions.\nLa capacité du système à appréhender un événement externe est caractérisée par la\ndurée de la tâche la plus longue puisque les tâches sont non interruptibles ou non\nDans le cas du modèle synchrone d’exécution, nous avons un système d’ordonnancement complètement prévisible et, en conséquence, il est possible en faisant une\nanalyse exhaustive de l’exécution de produire une séquence d’exécution qui est jouée\nde façon répétitive. Cette étude de la séquence est appelée analyse de l’ordonnancement hors ligne. L’ordonnancement peut se réduire à un séquencement. Nous\navons alors un environnement informatique très simple de l’application développée\npuisqu’il se réduit à une liste de tâches à exécuter. L’environnement informatique\npour piloter cette liste de tâches se réduit à un système très simple : un séquenceur.\nDans le modèle d’exécution asynchrone, l’occurrence de tout événement est immédiatement prise en compte par le système pour tenir compte de l’urgence ou de\nl’importance. Dans l’exemple proposé, nous pouvons constater que la prise en\ncompte d’un signal d’alerte est immédiate sans attendre la fin de la tâche « Lecture_\nconsigne » (figure 1.9). La prise en compte de l’événement « alerte » est identique\npour le procédé et le système informatique. L’occurrence des événements externes\nn’est pas synchronisée avec le système informatique, d’où le nom d’exécution asynchrone.\nDans ce contexte, nous avons des tâches qui sont interruptibles ou préemptibles.\nEn conséquence, l’ordonnancement n’est pas totalement prévisible et l’analyse de\nl’exécution des tâches doit se faire en ligne par simulation ou par test. Cela nécessite\nl’utilisation d’un gestionnaire centralisé des événements et de la décision d’exécution : exécutif ou noyau temps réel.\nLes événements sont immédiatement perçus\nFigure 1.9 – Modèle d’exécution asynchrone d’une application de contrôle-commande.\nPour terminer cette section, nous allons rappeler trois définitions importantes que\nnous avons utilisées et fixer le contexte de cet ouvrage. Nous avons ainsi défini :\n– Tâche non préemptible ou préemptible :\n• Une tâche non préemptible ne peut être interrompue qu’à des endroits spécifiques et à la demande de la tâche elle-même : fin_de_tâche, attente_signal…\nDans ce cas, la programmation et plus simple et aucun mécanisme de partage\nde ressources critiques n’est à prévoir. En revanche, des temps de réponse longs\n• Une tâche préemptible peut être interrompue à n’importe quel instant et le\nprocesseur affecté à une autre tâche. Dans ce cas, les temps de réponse à un événement externe peuvent être très courts ; mais nous avons alors une programmation plus complexe avec un besoin de mécanisme de partage de ressources\n– Analyse de l’ordonnancement hors ligne ou en ligne :\n• Une analyse de l’ordonnancement hors ligne correspond à la construction\nd’une séquence d’exécution complète sur la base des paramètres temporels des\ntâches en utilisant une modélisation (réseaux de Petri…) ou une simulation\n(animation ou énumération du modèle). L’ordonnanceur nécessaire est minimal\npuisque la séquence d’exécution est prédéfinie, il se réduit à un séquenceur.\nEn revanche, l’application ainsi figée est peu flexible.\n• Une analyse de l’ordonnancement en ligne correspond à un choix dynamique\nde la prochaine tâche à exécuter en fonction des paramètres de la tâche en utilisant une modélisation de l’algorithme d’ordonnancement et une simulation de\nl’exécution. L’ordonnancement a un coût temporel non négligeable ; en revanche,\nl’application peut réagir à des événements ou des situations non prévus.\n– Exécution synchrone ou asynchrone :\n• Une exécution est dite synchrone si les tâches sont non préemptibles et s’exécutent les unes après les autres dans un ordre qui peut être défini par une analyse\nhors ligne de l’ordonnancement.\n• Une exécution est dite asynchrone si les tâches sont préemptibles et s’exécutent\nselon l’ordonnancement. Une analyse de la séquence doit se faire obligatoirement en ligne.\nDans la suite de cet ouvrage, nous nous intéressons plus particulièrement aux systèmes asynchrones composés de tâches préemptibles avec un ordonnancement en\nligne. Ainsi, l’architecture logicielle de l’application est composée de plusieurs tâches\nréalisées par le concepteur et d’un environnement spécifique, le noyau temps réel,\nque nous allons décrire. Le point essentiel de cet environnement est l’ordonnanceur\nqui permet d’affecter à tout instant le processeur à une tâche afin de respecter\nl’ensemble des contraintes temporelles attachées à la gestion du procédé.\nm Exécutif ou noyau temps réel\nCet environnement particulier d’exécution, exécutif ou noyau temps réel, peut être\nassimilé à un système d’exploitation de petite taille dédié aux applications de\ncontrôle-commande. La caractéristique fondamentale est son déterminisme d’exé12\ncution avec des paramètres temporels fixés (temps de prise en compte d’une interruption, changement de contexte entre deux tâches, etc.). Nous pouvons comparer\nles différences au niveau des objectifs fixés pour le noyau d’exécution d’un système\ninformatique classique et d’un système informatique de contrôle-commande.\nUn système classique n’a pas été conçu pour permettre de respecter des contraintes\ntemporelles, mais il suit les règles suivantes :\n– politiques d’ordonnancement des activités basées sur le partage équitable du processeur : affectation identique du temps processeur à tous les processus en cours ;\n– gestion non optimisée des interruptions ;\n– mécanismes de gestion mémoire (cache…) et de micro-exécution engendrant des\nfluctuations temporelles (difficulté pour déterminer précisément les durées des\n– gestion des temporisateurs ou de l’horloge pas assez fine (plusieurs millisecondes) ;\n– concurrence de l’application temps réel avec le système d’exploitation toujours\n– gestion globale basée sur l’optimisation d’utilisation des ressources et du temps\nde réponse moyen des différents processus en cours.\nUn système informatique de contrôle-commande s’attache aux caractéristiques\n– efficacité de l’algorithme d’ordonnancement avec une complexité limitée ;\n– respect des contraintes de temps (échéances…). Ces contraintes temporelles se\ntraduisent plus en termes de choix d’une activité à exécuter à un instant donné\nplutôt que de rapidité d’exécution de toutes les activités ;\n– prédictibilité (répétitivité des exécutions dans des contextes identiques) ;\n– capacité à supporter les surcharges ;\n– possibilité de certification pour les applications de certains domaines comme\nEn général, contrairement à un noyau temps réel, les contraintes temporelles ne sont pas garanties\ndans un système d’exploitation classique (Unix, Windows NT…).\nUne application temps réel étant par définition un système multitâche, le rôle essentiel\ndu noyau temps réel est donc de gérer l’enchaînement et la concurrence des tâches en\noptimisant l’occupation de l’unité centrale du système informatique. Les principales\nfonctions d’un noyau temps réel peuvent être scindées en trois groupes :\n1. gestion des entrées/sorties (gestion des interruptions, gestion des interfaces\nd’entrées/sorties, gestion des réseaux de communications…) ;\n3. relations entre les tâches (synchronisation, communication, accès à une ressource\ncritique en exclusion mutuelle, gestion du temps…).\nIl important de noter que les tâches sont les unités actives du système ; le noyau temps\nréel n’est actif que lors de son appel. Une tâche activée peut appeler le noyau temps\nréel par une requête. Les différentes requêtes sont servies par des modules du noyau\ntemps réel appelées primitives. Ensuite le noyau temps réel réactive une tâche de\nl’application selon l’algorithme d’ordonnancement utilisé (figure 1.10). Ainsi, le\nnoyau temps réel centralise toutes les demandes d’activation des tâches et gère des\ntables lui permettant de comparer les priorités (ou les urgences) et l’état de ces diverses\ntâches, ainsi que l’état d’occupation des ressources. La décision d’activation d’une\ntâche étant prise, le noyau temps réel lance les modules de programmes correspondant à cette tâche et lui alloue les ressources disponibles. La tâche activée occupe le\nprocesseur jusqu’à la fin de son exécution sous le respect des conditions suivantes :\nprimitives et ordonnanceur\nFigure 1.10 – Interaction entre les tâches et le noyau temps réel.\nNous pouvons donc décrire schématiquement le contexte complet d’exécution d’une\napplication temps réel avec les deux parties : tâches et noyau temps réel (figure 1.11).\nEn conclusion de cette section sur l’ordonnancement qui est étudié de façon plus\ncomplète dans le chapitre 8, l’ordonnancement dans le cas des systèmes temps réel\nà contraintes temporelles strictes a pour objectif principal de répondre aux deux cas\n– Fautes temporelles : cela correspond à un non respect d’une contrainte temporelle\nassociée à une tâche comme le dépassement de la date limite d’exécution ou\néchéance. Cela induit la notion d’urgence d’une tâche.\n– Surcharge : lors de l’occurrence d’une ou plusieurs fautes temporelles, l’ordonnanceur peut réagir en supprimant une ou plusieurs tâches de l’application, ce qui\namène à la notion d’importance, c’est-à-dire le choix d’une tâche à exécuter par\nrapport aux spécifications fonctionnelles de l’application.\nm Implémentation des applications de contrôle-commande\nComme nous le verrons au cours de cet ouvrage, les langages de développement des\napplications de contrôle-commande sont très divers. Mais, par rapport à l’environnement d’exécution que nous venons de décrire (noyau temps réel avec les trois\nNoyau ou Exécutif\nFigure 1.11 – Architecture de l’application : tâches et noyau temps réel.\nfonctions décrites : 1. gestion des interruptions, 2. ordonnancement, 3. relations\nentre les tâches), il est possible de décliner les langages en trois groupes (figure 1.12) :\n– langages standards (langage C…) : le noyau temps réel qui supporte ce type de\nlangage doit être complet puisque le langage n’intègre aucune spécificité de ce\ndomaine de contrôle-commande multitâche ;\n– langages multitâches (langage Ada…) : ces langages permettent de décrire\nl’application en termes de tâches ; ainsi le noyau peut être plus réduit et ne\ncomporter que les deux premières fonctions ;\nFigure 1.12 – Langages utilisés pour développer les applications de contrôle-commande\navec un noyau temps réel (1. gestion des interruptions, 2. ordonnancement, 3. relations\nentre les tâches).\n– langages réactifs (langages Lustre, Esterel, Signal…) : ces langages donnent non\nseulement la possibilité de décrire les fonctionnalités du programme, mais aussi\nl’enchaînement des différentes parties. Le noyau est donc limité à une couche\nproche du matériel lié notamment à la gestion des interruptions. En revanche,\nétant donné la possibilité très limitée d’expression de l’aspect fonctionnel, ils\nsont souvent associés à un langage standard pour palier ce manque.\n1.2.2 Architecture matérielle des applications de contrôle-commande\nComme nous l’avons vu en introduction, l’aspect matériel a une très grande importance dans les applications de contrôle-commande. Cette implication est liée d’une\npart à la connexion directe avec le monde physique réel à l’aide d’une grande diversité de systèmes d’entrées/sorties et d’autre part au matériel informatique parfois\nspécifique et développé pour une application donnée. Ce dernier point concerne les\napplications dites dédiées et embarquées ; le matériel a été conçu et créé spécifiquement pour une application, comme un téléphone portable, une caméra vidéo, etc.\nÀ titre d’exemple, les différents calculateurs embarqués dans un véhicule automobile\nsont dédiés et spécialement développés pour cette application (figure 1.13). Dans\nces matériels, nous trouvons un processeur de type microcontrôleur redondé pour\navoir un haut niveau de sécurité, des composants spécifiques (ASIC : Application\nSpecific Integrated Circuit), une alimentation électrique… Tout ce matériel est ensuite\nencapsulé dans un boîtier résistant à l’environnement de fonctionnement usuel\n(chaleur, vibrations, ambiance corrosive, etc.).\nBeaucoup d’applications de contrôle-commande s’exécutent sur des plateformes PC\nclassiques. En revanche, il est toujours nécessaire de disposer de cartes d’entrées/\nsorties qui doivent souvent être synchronisées (acquisition et commande effectuées à\ndes instants précis). Ainsi, dans ce domaine d’applications informatiques, des matériels\nspécifiques existent et permettent ce fonctionnement temporel : c’est par exemple\nle cas de la plateforme PXI concaténation d’une plateforme classique PC et de cartes\nEnfin, dans de nombreux cas, les applications de contrôle-commande sont de type\ndistribué, c’est-à-dire qu’elles sont composées de plusieurs sites ou processeurs, sur\nlesquels s’exécutent un environnement multitâche, reliés par un ou des réseaux\ninformatiques (Ethernet, CAN, FIP…).\nL’ensemble de ces aspects matériels est traité en détail dans le chapitre 4.\nFigure 1.13 – Matériel dédié utilisé pour implémenter\nune application de contrôle-commande du domaine de l’automobile.\nAlimente le calculateur en électricité\nen diminuant la tension en provenance\nMicrocontrôleur de sécurité\nCertains calculateurs (injection, ABS,\netc.) disposent d’un microcontrôleur\nde secours (redondance).\nDétermine la vitesse\nd’exécution des opérations.\nElle se mesure en mégahertz.\nStocke les tâches utilisant\nExécute les différentes tâches\nLes calculateurs situés dans des parties\nexposées sont placés dans des boîtiers\nmétalliques étanches et blindés.\nCeux de l’habitacle sont en plastique.\nUn ASIC (Application Specific\nIntegrated Circuit) est une puce\ndédiée à une application qu’elle\ndes informations d’entrée.\n1.3 Développement des applications\nLe développement des applications informatiques demande de plus en plus de\nrigueur dans le suivi des différentes étapes de spécification, de conception et de\ncodage. Ce cycle de développement permet ainsi d’obtenir des applications de très\nbonne qualité d’un point de vue architecture logicielle, d’augmenter la maintenabilité et l’évolutivité. En particulier, cette rigueur de développement accroît de façon\nsignificative la correction des programmes en suivant une démarche de tests unitaires\net d’intégration. Si ces tests, qui sont un point primordial dans l’obtention d’une\nqualité logicielle, sont aisés à réaliser dans le cas d’applications informatique classiques, en revanche, dans le cas des applications de contrôle-commande, les tests\nopérationnels en exécution réelle sont souvent difficiles à produire à cause de diverses\n– exécution unique : satellite d’exploration ;\n– coût très élevé : fusée… ;\n– risques humains : avion…\nAinsi, malgré des phases de tests souvent coûteuses et conséquentes, de nombreuses\napplications de contrôle-commande n’ont pas rempli les objectifs fixés. Nous pouvons citer quelques exemples connus :\n– Mission Vénus : le satellite d’exploration est passé à plus de 500 000 km de la\nplanète Venus au lieu de 5 000 km, prévu initialement. Cet échec a été attribué à\nun simple remplacement d’une virgule par un point dans un programme Fortran\n(« DO 20 I = 1. 5 » au lieu de « DO 20 I = 1, 5 »).\n– Avion militaire américain F16 : lors des premiers essais en vol, l’avion était déclaré\nsur le « dos » au passage de l’équateur à la très grande surprise du pilote. Cela\nétait simplement dû à une erreur de signe dans le programme.\n– Navette spatiale américaine : lors du premier lancement de la navette, le départ\na été annulé et la mission reculée de trois jours (coût très important). Ce faux\ndépart était dû à une erreur de synchronisation entre les deux ordinateurs de\nconduite de vol. Le fonctionnement en redondance de ces ordinateurs conduisait\nà un test de cohérence de certaines grandeurs physiques. Étant donné une désynchronisation des deux ordinateurs, ce test a été négatif simplement à cause de la\nmesure du même paramètre effectuée à des instants différents.\n– Mission sur Mars : lors de la mission d’exploration de la planète Mars par le robot\nPathfinder, une remise à zéro périodique des données acquises a fortement perturbé la mission. Ce problème était lié à un blocage d’une tâche très prioritaire\npar une tâche moins prioritaire mais détenant une ressource critique (réseau de\ncommunication vers la terre). En particulier les données météorologiques mesurées\nétaient très spécifiques d’un point de vue « durée et taille » du fait des caractéristiques martiennes.\n– Fusée Ariane V : lors du premier lancement, la fusée a dû être détruite à cause\nd’une trajectoire non correcte. Cette erreur était liée à la réutilisation de certains\nmodules logiciels utilisés dans le contexte d’Ariane IV. Les spécifications, attachées\nà l’accélération, auraient dû être différentes en termes de limites afin d’éviter ce\nCette liste d’exemples de problèmes au niveau de l’exécution d’applications de\ncontrôle-commande montre la nécessité de mettre en place un cycle de développement encore plus rigoureux pour ces applications de gestion de procédé physique\ndont les tests en exécution réelle ne sont pas toujours facilement accessibles.\n1.3.1 Cycle de développement des applications informatiques\nLe cycle de développement des applications informatiques suit les trois étapes classiques que sont la spécification, la conception et la programmation. L’analyse des\nbesoins permet d’écrire le cahier des charges de l’application. À partir de ce cahier\ndes charges, le déroulement des trois étapes conduit successivement aux descriptions\nsuivantes de l’application (figure 1.14) :\n– spécification globale : description de « ce que l’on a à faire » ou le « quoi »,\nc’est-à-dire une mise en forme plus ou moins formelle du « cahier des charges » ;\n– conceptions préliminaire et détaillée : description du « comment », c’est-à-dire\nune modélisation de l’architecture logicielle de l’application (modules, tâches,\nobjets…). Il peut être nécessaire d’employer différents niveaux de raffinement\nselon la taille de l’application ;\n– programmation : traduction dans un langage exécutable de l’architecture logicielle de l’application décrite précédemment. Suivant la méthode de conception\nemployée et le niveau de raffinement, la traduction dans un langage de programmation peut être plus ou moins automatisée.\nCes différentes étapes peuvent être plus ou moins formelles selon les méthodes\nemployées. Aussi, à chaque étape, il est primordial de vérifier la cohérence de la\ndescription ou de la traduction réalisée à partir de l’étape précédente. Ce travail\nconcerne la validation. Celle-ci constitue une preuve si la méthode est formelle ou\nun test si elle ne l’est pas.\nFigure 1.14 – Cycle de développement d’une application informatique classique.\nUne présentation généralement plus adaptée est celle du cycle en « V » (figure 1.15).\nDans cette représentation, à chaque niveau d’analyse ou de conception correspond\nun niveau de validation ; ainsi, nous avons :\n– conception détaillée et tests unitaires ;\n– conception préliminaire et tests d’intégration ;\n– spécification et validation globale.\nIl est évident que cette formalisation méthodologique du développement des applications informatiques a pour principaux objectifs : éviter les fautes logicielles, accroître\nla maintenabilité, faciliter l’évolutivité… À chaque étape ou ensemble d’étapes correspond une méthode qui est généralement supportée par un outil informatique\npour aider à sa mise en œuvre plus ou moins automatisée (CASE Tools : Computer\nAided Software Engineering Tools).\nFigure 1.15 – Cycle de développement en « V »\nd’une application informatique classique.\nL’expérience du développement de logiciels prouve que l’élaboration complète de\nl’application ne se fait pas en une seule fois : évolution du cahier des charges, modifications du découpage modulaire, correction de programmes, etc. Cela a induit de\nnouveaux schémas de développement, appelés itératifs ou en spirale, qui consistent\nà prendre en compte les passages successifs dans les différentes étapes du développement. L’idée forte à retenir est que, lors de toutes modifications apportées à l’application à quelque niveau que ce soit, il est nécessaire de décliner à nouveau toutes\n1.3.2 Développement couplé matériel et logiciel\nAvant de décrire les différentes méthodes utilisées dans le cadre des applications de\ncontrôle-commande et leurs spécificités, il est important de remarquer la particularité du développement de ces applications quant au caractère du couplage fort entre\nEn effet, le cahier des charges d’une application de contrôle-commande d’un procédé va intégrer dans la grande majorité des cas à la fois la description du matériel et\nles fonctions à remplir par ce procédé (figure 1.16). Ainsi, la spécification de l’application commence par une spécification système (matériel et logiciel). Une partie de\nla conception préliminaire peut aussi intégrer les deux aspects puisque la réalisation\nd’un module fonctionnelle peut être réalisée soit de manière matérielle (circuit\nintégré spécifique – FPLA : Field Programmable Logic Array ou FPGA : Field Programmable Gate Array) soit d’une manière logicielle. Ensuite, le développement des\ndeux parties peut continuer de façon différenciée et classique avec la conception\ndétaillée, l’implémentation (réalisation ou codage) et les tests. À nouveau, les deux\naspects de l’application doivent se rejoindre pour passer à la phase d’intégration et\nde validation de l’ensemble. La phase d’intégration est certainement l’étape la plus\nimportante et la plus difficile. En effet, une partie logicielle va être insérée dans un\nenvironnement matériel très spécifique.\nBien que ce ne soit pas le propos de cet ouvrage, l’aspect matériel est abordé de façon\nsuccincte dans le chapitre 4. Au niveau de la conception, il existe aussi de nombreuses méthodes permettant d’avoir des développements de qualité. Ainsi, le langage VHDL (VHSIC Hardware Description Language – VHSIC : Very High Speed\nIntegrated Circuit) de description des fonctions à réaliser d’un point de vue matériel\nconduit à une conception formelle des circuits, c’est-à-dire autorisant une preuve\nde la conception établie.\nPrenons un exemple très répandu comme les consoles de jeux portables. Ces matériels\npossèdent une interface utilisateur très spécifique comportant un ensemble de\nS P ÉCIFICATION\nP R É LIMINAIRE\nI N T ÉGRATION\nFigure 1.16 – Cycle de développement matériel et logiciel\nd’une application de contrôle-commande de procédé.\nboutons, un haut-parleur et un écran couleur. De plus, ces consoles intègrent généralement une liaison vers l’extérieur de type infrarouge ou filaire pour une connexion\navec une autre console de la même gamme. À ces entrées/sorties très dédiées, s’ajoutent\ndes contraintes de réalisation liées à la caractéristique embarquée de l’application :\nalimentation sur batterie, autonomie importante, encombrement réduit, ergonomie,\ndesign du boîtier, réalisation en très grande quantité, coût le plus bas possible…\nToutes ces contraintes vont avoir un impact important sur le développement aussi\nbien matériel que logiciel. Ainsi, le processeur est de type microcontrôleur à faible\nconsommation intégrant des entrées/sorties multiples auquel s’ajoute un processeur\ngraphique pour gérer l’écran couleur. Le noyau temps réel implanté doit posséder les\ncaractéristiques suivantes : petite taille (taille mémoire limitée), rapidité d’exécution\n(ensembles de primitives simples), coût faible (réalisation en très grande quantité)…\nCes différentes spécifications, qui lient la réalisation matérielle à l’implémentation\nlogicielle, doivent être prises en compte au début de l’analyse de l’application.\nAussi, nous pouvons résumer l’environnement de développement d’une application\nde contrôle-commande par le schéma de la figure 1.17. Les spécifications du système\nsont donc élargies ; en plus des aspects fonctionnels et comportementaux classiques\npour ce type d’application, nous devons ajouter les contraintes de développement\névoquées précédemment, soit :\n– contraintes matérielles : type de processeur, architecture (distribué, multiprocesseur…), taille mémoire, dimension physique, consommation, environnement\n(température, pression, corrosion…) ;\n– noyau temps réel : primitives, taille (micronoyau…), certifié…\n• Aspect fonctionnel et aspect comportemental\n• Autres contraintes de développement :\n– matériel (processeur, architecture, taille, consommation…)\n– noyau temps réel\n– langage de développement\nFigure 1.17 – Environnement spécifique du développement\n– langages de développement : assembleurs, langage de haut niveau, langage\nEnsuite, il est important de noter que le développement de la partie logicielle d’une\napplication de contrôle-commande va être réalisé sur une plate-forme dite « hôte »\nqui n’a aucun rapport avec l’environnement d’exécution ou environnement « cible »\nen termes de processeur, mémoire, système d’exploitation, etc. Lorsque le logiciel\napplicatif est réalisé et testé autant que faire se peut sur cette plate-forme « hôte »,\nle programme est compilé dans le code du processeur « cible » par un compilateur\ncroisé ; puis il est téléchargé avec le noyau temps réel choisi vers l’architecture matérielle « cible ». De nouveau, des tests doivent être réalisés dans cet environnement\nd’exécution. En effet, le comportement du programme dans cette architecture\n« cible » de l’application peut être différent et amener à des modifications conséquentes du programme. Ce processus conduit à modifier le cycle en « V » de développement des applications informatiques classiques par un cycle en « W » où la\ndeuxième partie du cycle correspond à la reprise de la première partie du cycle mais\ndans l’environnement « cible » (figure 1.18). Nous trouvons en particulier dans ce\ncycle en « W » un codage croisé et l’intégration avec le noyau.\nCe constat de la dualité de développement des applications de contrôle-commande\nde procédé amène à plusieurs remarques concernant les environnements permettant\nd’élaborer ce type d’application :\n– le noyau temps réel choisi doit être adapté à l’architecture « cible » de l’application en termes de codage, de taille et de fonctionnalités (primitives, gestion des\nentrées, gestion du temps…) ;\n– l’environnement de développement sur la plate-forme « hôte » doit posséder un\némulateur du noyau temps réel afin de pouvoir faire les premiers tests du logiciel\nmultitâche réalisé ;\nen environnement « hôte »\nCODAGE - Croisé\nen environnement « cible »\nFigure 1.18 – Cycle de développement en « W »\n– l’environnement de développement sur la plate-forme « hôte » doit pouvoir\nfaire une compilation croisée dans le code du processeur de l’architecture « cible » ;\n– l’environnement de développement sur la plate-forme « hôte » doit permettre\nun « debug » de l’application lors de son exécution sur l’architecture « cible ».\nCette observation de l’exécution se fait à distance par une liaison réseau quelconque (Ethernet…). De nombreux environnements proposent une représentation graphique de l’exécution des tâches. La plus grande difficulté réside dans le\nfait de ne pas modifier l’exécution de l’application par cette observation.\nToutes ces remarques impliquent dans le choix d’un environnement de développement de ces applications de prendre en compte l’ensemble des caractéristiques\n– environnement « cible » (microprocesseurs, architecture…) ;\n– environnement « hôte » (type de système d’exploitation) ;\n– conformité à une norme ou pseudo-norme (POSIX, projet Sceptre) ;\n– compacité (pour les applications embarquées) ;\n– outils d’aide au développement (« debug », analyse en ligne…) ;\n– primitives temps réel (liste de tous les services fournis) ;\n– caractéristiques de l’ordonnanceur (politiques d’ordonnancement) ;\n– caractéristiques temporelles :\n• temps de masquage des interruptions (interrupt latency), temps pendant lequel\nles interruptions sont masquées et ne peuvent donc pas être prises en compte,\n• temps de réponse (task response time) : temps entre l’occurrence d’une interruption et l’exécution de la tâche réveillée.\nL’ensemble de ces notions concernant le noyau temps réel et son choix pour une\napplication donnée est abordé dans le chapitre 5.\n1.3.3 Cycle de développement des applications de contrôle-commande\nIl existe de nombreuses méthodes appliquées au développement logiciel des applications de contrôle-commande de procédé. Ces méthodes couvrent une ou plusieurs\nétapes du cycle de développement selon les niveaux de raffinement où elles sont\nutilisées. Sans vouloir faire un exposé exhaustif de l’existant, il est intéressant de\nciter quelques méthodes en les différenciant par leur concept de base. Nous trouvons\nainsi des méthodes fonctionnelles et structurées, dites aussi à flots de données, qui\nsont fondées sur le principe du découpage fonctionnel de l’application. Ces éléments\nou modules fonctionnels sont appliqués aux données qui se propagent de fonction\nen fonction. Le deuxième ensemble de méthodes est celui des méthodes basées sur\ndes modèles de machines à états. Ces méthodes reposent sur des bases formelles et\npermettent en général des vérifications plus avancées que les précédentes. La troisième catégorie, plus récente, de méthodes est dite orientée objets ou objets. Nous\npouvons résumer ces dernières en disant que ces méthodes mettent en avant les\ndonnées et leur structuration. Nous pouvons donner les exemples suivants dans\nchacun de ces ensembles :\n• SA_RT : Structured Analysis Real Time (Ward-Mellor, 1984 ; Pirbhaï-Hatley,\n• Langages réactifs synchrones : Lustre (Caspi, 1991), Esterel (Berry, 1991),\nSignal (le Guernic, 1991)\nLa figure 1.19 reprend le cycle en « V » de développement avec le positionnement\nde quelques-unes de ces méthodes dans ce cycle.\nFigure 1.19 – Quelques méthodes de développement\nComme cela a été justifié et expliqué dans l’avant-propos, les méthodes SA-RT et\nDARTS, qui permettent de décrire complètement le cycle dans ses phases de spécification et de conception, sont celles qui sont étudiées de façon détaillée dans cet\nouvrage. En effet, dans le cas d’applications embarquées de taille petite ou moyenne\nqui sont implémentées dans une architecture multitâche, il semble plus pertinent\nd’utiliser une analyse et une conception de type fonctionnel et structuré.\n1.3.4 Quelques exemples industriels d’applications de contrôle-commande\nAfin d’illustrer les différents environnements de développements des applications de\ncontrôle-commande, nous présentons des exemples industriels issus de programmes\nde taille importante des années 1990-2000. Ces exemples sont caractérisés par le\nnom du programme, la ou les sociétés en charge du programme et les méthodes et\nlangages utilisés, soit :\n– Programme Spot 4 (Matra Marconi Space/CNES) : satellite destiné à une observation de la terre (météorologie, environnement, agriculture…)\n• Spécifications et conceptions : HOOD\n• Langages : Ada, Assembleur\n– Programme Ariane 5 (Aérospatiale/CNES) : lanceur\n• Langages : Ada, noyau temps réel ARTK, Assembleur (Motorola 68020)\n– Programme ISO – lnfrared Space Observatory (Aérospatiale/ESA) : ensemble de\nsatellites destinés à une observation de l’espace dans un domaine infrarouge\n– Programme SENIT8 (Dassault Électronique & DCN-Ingénierie) : équipements\nde gestion et de contrôle-commande du porte-avions Charles de Gaulle\n• Spécifications et conceptions : SART et Ada-Buhr (proche de la méthode\nNous pouvons remarquer que les environnements de développement intègrent une\nanalyse fonctionnelle et structurée avec SA-RT et une conception orientée objet.\nCela est dû essentiellement soit à des obligations du cahier des charges (applications\nspatiales) soit à la taille de l’application qui justifie une méthode orientée objet.\n2 • SPÉCIFICATION\nSELON LA MÉTHODE SA-RT\n2.1 Introduction générale à la méthode SA-RT\nLa méthode SA-RT est une méthode d’analyse fonctionnelle et opérationnelle des\napplications de contrôle-commande. Cette méthode permet de réaliser une description graphique et textuelle de l’application en termes de besoins, c’est-à-dire\nde « ce que l’on a à faire » ou le « quoi » (What ?). Cette mise en forme du « cahier\ndes charges » de l’application est formelle dans le sens où la méthodologie (ensemble\ndes documents à élaborer) et l’expression (syntaxe graphique) sont définies. En\nrevanche, elle ne permet pas d’effectuer une vérification de propriétés de l’application\nà partir des seules descriptions SA-RT. Des études ont été menées pour associer à la\nméthode SA-RT des méthodes formelles afin d’apporter des possibilités de simulation\net de vérification. Une de ces méthodes est présentée à la fin du chapitre. Aucune\nrègle officielle ou normalisation n’a été mise en place pour la méthode SA-RT et son\nutilisation. Par conséquent, il existe de nombreuses mises en œuvre de la méthode\nSA-RT avec des différences plus ou moins importantes et aussi des extensions spécifiques de la méthode. Ceci fera l’objet du dernier point traité dans ce chapitre.\nNous allons nous attacher à décrire la méthode SA-RT la plus générale et la plus\nusitée, et correspondant à la méthodologie de développement d’une application de\ncontrôle-commande qui est l’objectif de cet ouvrage.\nL’accroissement très important de la taille des logiciels développés dans les années 70\na conduit à mettre en place des méthodes d’analyse et de conception permettant\nune meilleure réalisation et aussi une maintenance plus efficace dans l’exploitation\ndes logiciels. Le mot essentiel de ces méthodes est « structuration » dans le sens d’une\ndécomposition en éléments ou blocs fonctionnels pour un niveau d’analyse donné\net d’une décomposition hiérarchique cohérente entre les différents niveaux d’analyse.\nCes méthodes d’analyse ou de conception structurées conduisent naturellement à\nla programmation structurée. La deuxième particularité commune à ces méthodes est\nla description sous forme de flux ou flots de données, de contrôle ou autres. L’aspect\nopérationnel de la description est alors visualisé par la propagation de ces flux.\nAinsi, nous trouvons la méthode SA-DT (Structured Analysis Design Technics) de\nspécification d’un système qui permet d’exprimer un bloc représentant soit les\nactivités (fonctions) soit les données. Les flots entrants sont les données, un contrôle\nou des mécanismes (méthodes) et les flots sortants correspondent aux sorties de\nà la méthode SA-RT\ndonnées. Cette méthode très générale de description d’un système a été adaptée à\nla spécification de logiciels avec la méthode très connue SA (Structured Analysis)\n(D.T. Ross, 1976)\n(E. Yourdon, T. Demarco, 1979)\nStructured Analysis Real Time\n(Ward/Mellor, 1985 ; Hatley/Pirbhai, 1986)\n(W. Bruyn, R. Jensen, D. Keskar,\nP. Ward-Boeïng, Hugues Aircraft, 1987)\nFigure 2.1 – Positionnement chronologique de la méthode SA-RT.\nL’analyse structurée SA, définie par E. Yourdon et T. Demarco, est une méthode\ndescendante par affinages successifs des traitements, appelés « process ». Les différents\ndiagrammes sont donc ordonnés hiérarchiquement en faisant apparaître pour les\nderniers niveaux des fonctions élémentaires, appelées primitives élémentaires ou\n« process » primitifs. Les différents outils composant cette méthode sont :\n– diagrammes de transformations de données ou diagramme de flots de données\n– dictionnaire de données ;\n– spécifications des « process » primitifs.\nLes diagrammes de flots de données sont construits à partir de quatre éléments\ngraphiques : traitement (cercle), flot de données (flèche), unité de stockage (traits\nparallèles) et entité externe (rectangle) (tableau 2.1). À partir de ces éléments de base,\nil est possible de décrire l’aspect fonctionnel d’une application par un diagramme flots\nde données. Un exemple, présenté sur la figure 2.2, montre l’analyse d’une application très simple de régulation de température avec trois entités externes, deux process\net une unité de stockage.\nIl est intéressant de noter que cette description graphique fonctionnelle d’une application à l’aide\nde la méthode SA sera presque entièrement reprise dans la méthode SA-RT, montrant bien ainsi sa\nPour exprimer complètement le comportement de l’application, le diagramme flots\nde données de SA manquait d’un moyen permettant de spécifier l’aspect opérationnel,\nTableau 2.1 – Les différents éléments graphiques de la méthode SA.\nTraitement ou process\nUnité de travail qui\nréalise la transformation\nen données de sortie\n– Cercle ou bulle\n– Action décrite par :\nVecteur nommé reliant\ndeux process, sur lequel\ncircule un ensemble de\ndonnées de même nature\n– Flèche en trait plein\n– Donnée nommée\nEntité ou zone de\nrangement de données\n– Deux traits parallèles\n– Entité nommée\nProvenance, source ou\nFigure 2.2 – Exemple simple du diagramme flot de données de la méthode SA\ncorrespondant à une application de régulation de température.\nc’est-à-dire la description de l’enchaînement des différents process. Cette lacune\nfut comblée par la création de méthode SA-RT (Structured Analysis-Real Time).\nDeux groupes élaborèrent la méthode SA-RT avec des différences notables en termes\nde représentation : d’une part, la méthode établie par Ward et Mellor en 1985 qui\nassocie le fonctionnel et le contrôle dans un même diagramme et, d’autre part, la\nméthode proposée par Hatley et Pirbhai en 1986 qui sépare le fonctionnel et le\ncontrôle. Mais ces deux vues de la même méthode restent très similaires en termes de\ncapacité d’expression de la spécification. Nous présentons dans cet ouvrage la\nméthode SA-RT établie par Ward et Mellor en 1985.\nComme le montre la figure 2.1, la méthode SA-RT a continué à évoluer au sein\ndes entreprises en intégrant des besoins spécifiques à un domaine d’applications.\nAinsi, nous trouvons une méthode SA-RT, appelée ESML et utilisée dans l’avionique,\nqui a été enrichie d’un point de vue flot de contrôle.\n2.2 Présentation de la syntaxe graphique\nde la méthode SA-RT\nLa méthode SA-RT intègre les trois aspects fondamentaux d’une méthode de spécification en mettant l’accent sur les deux premiers qui sont des points essentiels dans\nles applications de contrôle-commande :\n– 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\ntransforment les données ;\n– aspect événementiel (piloté par les événements) : représentation des événements\nqui conditionnent l’évolution d’un système et spécification de la logique de\ncontrôle qui produit des actions et des événements en fonction d’événements en\nentrée et fait changer le système d’état ;\n– aspect informationnel (données) : spécification des données sur les flots ou dans\nles stockages. Ce dernier aspect qui est en général assez négligé dans ce type d’application peut faire l’objet d’une description spécifique choisie au sein d’une entreprise.\nNous allons présenter la syntaxe graphique complète de SA-RT permettant d’élaborer\nles différents diagrammes de la méthode. Cette syntaxe graphique très simple peut\nêtre scindée en deux parties : la syntaxe graphique afférente à l’aspect fonctionnel\net la syntaxe dédiée à l’aspect contrôle ou événementiel.\n2.2.1 Syntaxe graphique pour l’aspect fonctionnel\nm Syntaxe graphique du processus fonctionnel\nEn premier lieu, nous trouvons le Processus fonctionnel ou Processus qui représente une transformation de données. Un ou plusieurs flux de données en entrées\nsont traités pour donner un ou plusieurs flux de données en sortie (figure 2.3). Le\nProcessus est représenté par un cercle avec une étiquette ou label explicite formé de :\nÉtiquette_Processus = verbe (+ un ou plusieurs compléments d’objets) + numéro\nm Syntaxe graphique du flot de données\nPuis, nous avons le Flot de Données qui supporte ou transporte les valeurs d’une\ncertaine information à différents instants. Ce concept représente le cheminement\ndes données. Le flot de données est représenté par un arc orienté avec une étiquette\nou label explicite formé de (figure 2.4) :\nÉtiquette_Flot_de_Données = nom (+ qualifiant)\nLes valeurs de ce flot de données sont supposées disponibles pendant tout le temps\noù le processus producteur de ce flot est en mesure de les générer.\nLe flot de données peut représenter aussi bien une donnée de type continu, codée par\nun entier ou un réel (Température) qu’une donnée discrète codée par un booléen,\nFigure 2.3 – Processus fonctionnel de la méthode SA-RT.\nFigure 2.4 – Exemples simples de flots de données de la méthode SA-RT.\nexemple « Position_interrupteur ». Un flot de données peut décrire aussi bien une\ndonnée élémentaire ou unique, exemple « Température » qu’une donnée structurée\nintégrant plusieurs données élémentaires, exemple la donnée « Pressions » qui est\ncomposée de « Pression_huile » et « Pression_air ». Il est alors possible de faire apparaître l’étiquette du flot de données sous la forme suivante :\nÉtiquette_Donnée_Structurée = Étiquette_Donnée_1, Étiquette_Donnée_2\nUne spécification détaillée de cette donnée, véhiculée par le flot de données, est faite\ndans le Dictionnaire de données (voir ci-après).\nDonné e est envoy é\nsur les deux flots\nDonné e _ 1 et Donné e _ 2 sont\nextraits de Donné e\nDonné e _ 1 est extrait de Donné e\nCréation alternative de Donné e\nLe flot Donné e s ’est enrichi\nde Donné e _ 1\nLe flot Donné e est construit avec\nles flots Donn é e _ 1 et Donné e _ 2\nFigure 2.5 – Décomposition et regroupement des flots de données de la méthode SA-RT.\nCes flots de données peuvent se décomposer ou au contraire se regrouper lors des liaisons entre les processus fonctionnels dans le diagramme flot de données (figure 2.5).\nm Syntaxe graphique du stockage de données\nLe troisième élément graphique est le Stockage de Données qui modélise le besoin\nde mémorisation d’une donnée de telle façon que sa valeur puisse être relue plusieurs fois. Comme le flot de données auquel il est étroitement associé, il est nommé\npar une étiquette ou label explicite formé de :\nÉtiquette_Stockage_de_Données = nom (+ qualifiant)\nLe stockage de données est représenté par deux traits horizontaux encadrant l’étiquette définie ci-avant (figure 2.6). Les arcs « flots de données » arrivant ou partant\nde l’unité de stockage ne sont pas étiquetés s’ils transportent les données mémorisées\ncomplètes. Si une partie de la donnée est écrite ou lue, l’arc transportant de façon\npartielle la donnée doit être étiqueté avec le nom de cette donnée.\nFigure 2.6 – Unité de stockage de la méthode SA-RT.\nUn exemple de diagramme flot de données intégrant ces trois éléments graphiques\nde la méthode SA-RT (processus fonctionnel, flot de données et unité de stockage)\nest présenté sur la figure 2.7.\nFigure 2.7 – Exemple d’un diagramme flot de données de la méthode SA-RT.\nPour des besoins de clarté graphique, un stockage de données peut être visualisé plusieurs fois sur\nun diagramme flot de données en notant cette duplication par une « * ».\nIl est important de noter que l’utilisation de l’élément « stockage de données » peut\ncorrespondre à deux cas :\n– mémorisation ou représentation des constantes du système ;\n– mémorisation de valeurs de données partagées entre deux ou plusieurs processus\ndésynchronisés (consommation et production des données à des instants ou des\nm Syntaxe graphique de la Terminaison\nEnfin, le dernier élément graphique, utilisé dans cet aspect fonctionnel, est la Terminaison, ou encore appelée « bord de modèle », qui représente une entité extérieure\néchangeant des données avec le système modélisé. Une terminaison peut donc être\nune entité logicielle (programme, base de données…) ou matérielle (capteurs,\nactionneurs, console opérateur…). Représentée par un rectangle, elle est nommée\npar une étiquette ou label explicite formé de (figure 2.8) :\nÉtiquette_Terminaison = nom (+ qualifiant)\nFigure 2.8 – Terminaison ou « bord de modèle » de la méthode SA-RT.\n2.2.2 Syntaxe graphique pour l’aspect contrôle\nDans les diagrammes flot de données, le déclenchement de l’exécution des processus\nde transformation de données peut être lié au rythme d’apparition des données\nentrantes (diagramme piloté par les données : data-driven). Mais, dans le cas de la\nspécification des applications temps réel, il est préférable d’avoir un contrôle de ces\ntransformations de données piloté par des conditions externes comme l’occurrence\nd’événements (event-driven) (figure 2.9). Cette vue dynamique du modèle impose\nla mise en place de la partie contrôle : processus de contrôle et flot de contrôle\nFigure 2.9 – Pilotage de l’exécution d’un processus fonctionnel :\n(a) piloté par les données et (b) piloté par les événements.\nm Syntaxe graphique du processus de contrôle\nLe Processus de contrôle représente la logique du pilotage des processus fonctionnels.\nIl génère l’ensemble des événements qui vont activer ou désactiver les processus fonctionnels. En retour, les processus fonctionnels fournissent au processus de contrôle\ntous les événements nécessaires aux prises de décision. Le processus de contrôle ne\npeut en aucun cas gérer des données.\nLe Processus de contrôle est représenté par un cercle en pointillé avec une étiquette\nou label explicite formé de (figure 2.10) :\nÉtiquette_Processus_Contrôle = verbe (+ un ou plusieurs compléments) + numéro\nFigure 2.10 – Processus de contrôle de la méthode SA-RT.\nm Syntaxe graphique du Flot de contrôle\nLe Flot de Contrôle transporte les événements ou informations qui conditionnent\ndirectement ou indirectement l’exécution des processus de transformations de\ndonnées. Le flot de contrôle est représenté par un arc orienté pointillé avec une étiquette ou label explicite formé de (figure 2.11) :\nÉtiquette_Flot_de_Contrôle = nom (+ qualifiant)\nFigure 2.11 – Exemple simple d’une partie contrôle\nliée à une partie fonctionnelle de la méthode SA-RT.\nLes événements, fournis par le processus de contrôle, sont généralement liés à\nl’activation ou à la désactivation des processus fonctionnels. Aussi, ces événements\nspécifiques ont été formalisés et prédéfinis :\n– E pour Enable (activation) ;\n– D pour Disable (désactivation) ;\n– T pour Trigger (déclenchement).\nLes deux premiers événements sont utilisés ensemble « E/D » pour piloter un processus\nfonctionnel de type « boucle sans fin » ou périodique, c’est-à-dire que le processus\nde contrôle doit lancer l’exécution de ce processus avec l’événement « E » et ensuite\npeut l’arrêter avec l’événement « D ». L’événement « T » est utilisé pour activer un\nprocessus fonctionnel de type « début-fin » ou sporadique, c’est-à-dire que le processus de contrôle doit lancer l’exécution de ce processus avec l’événement « T » et\nensuite le processus s’arrête à la fin de son exécution sans intervention du contrôle.\n2.3 Les diagrammes flot de données\n2.3.1 Présentation d’un exemple simple d’application de contrôle-commande\nAfin d’illustrer la méthodologie au fur et à mesure de la présentation, nous allons\nprésenter un exemple simple qui va être décliné en détail au cours de cet ouvrage.\nConsidérons un système de freinage automobile qui est constitué d’une part d’un\nensemble classique composé d’une pédale de frein (demande de freinage) et d’un frein\n(actionneur de freinage) et d’autre part d’un système ABS (Anti-blocking Brake System).\nUn capteur de glissement de roues est associé à ce système ABS. Pour simplifier, le\nfonctionnement de l’ABS est basé sur un arrêt du freinage dès qu’un glissement est\ndétecté sur les roues, et cela même si la demande du conducteur est toujours effective.\nLe conducteur a la possibilité d’activer ou non ce système ABS à l’aide d’un bouton\nspécifique (bouton à deux positions stables : interrupteur). Un voyant permet de lui\nindiquer l’activation du système ABS. En revanche, il n’est pas possible de désactiver\nle système ABS en cours de freinage, c’est-à-dire pendant l’appui sur la pédale de frein.\nLa spécification fonctionnelle de cette application à l’aide de la méthode SA-RT va\ns’effectuer en plusieurs étapes :\n– diagramme de contexte ;\n– diagramme préliminaire ;\n– diagrammes de décomposition.\n2.3.2 Diagramme de contexte d’une application\nLe diagramme de contexte est une première étape extrêmement importante puisqu’elle va définir le contexte et l’environnement extérieur du système piloté. Nous\npouvons la considérer comme le contrat de réalisation entre le concepteur et son\nclient. Les bords de modèle ou terminaisons vont apparaître uniquement dans ce\ndiagramme. Les descriptions précises de ces terminaisons, ainsi que des données\nou éventuellement des événements entrants ou sortants de ceux-ci, sont à la charge\ndu donneur d’ordre. Un exemple générique d’un diagramme de contexte est donné\nsur la figure 2.12.\nNous trouvons un et un seul processus fonctionnel, numéroté « 0 », qui traduit\nl’application à réaliser effectivement par le concepteur. Autour de ce processus fonctionnel, un ensemble de bords de modèles fournit ou consomme les données ou\névénements de cette application. Ces bords de modèles peuvent donc être les éléments\nphysiques suivants :\n– capteurs (thermocouples, dynamomètres, etc.) ;\n– actionneurs (résistances chauffantes, vannes, etc.) ;\n– opérateur(s) lié(s) à des capteurs (interrupteurs, potentiomètres, etc.) ;\n– systèmes d’affichage (lampes, diodes, écran d’ordinateur, etc.) ;\n– système de stockage ou de sauvegarde externe (disque, bande magnétique, etc.) ;\n– système d’impression (imprimante, dérouleur papier, etc.) ;\nFigure 2.12 – Diagramme de contexte générique de la méthode de spécification SA-RT.\nL’ensemble des données ou événements échangés avec l’extérieur du « processus fonctionnel », qui représente l’application, constitue les spécifications d’entrées et de\nsorties de l’application. La description de ces entrées/sorties sera faite dans le dictionnaire de données (§ 2.5).\nDans l’exemple simple d’un système de freinage automobile (§ 2.3.1), le diagramme\nde contexte est constitué du processus fonctionnel « Contrôler système freinage 0 »\net de cinq bords de modèles (figure 2.13) :\n– terminaison « Pédale de frein » fournissant la donnée « Demande_freinage » ;\n– terminaison « Bouton d’activation de l’ABS » fournissant la donnée « Activation_\nABS » ;\n– terminaison « Capteur de glissement » fournissant la donnée « Glissement_roue » ;\n– terminaison « Système de freinage » consommant la donnée « Commande_\nfreinage » ;\n– terminaison « Voyant ABS » consommant la donnée « Affichage_ABS ».\nCe diagramme de contexte définit parfaitement l’interface entre le concepteur et le\nclient, c’est-à-dire les données à fournir ou à générer. La suite du travail d’analyse\nBouton activation ABS\nFigure 2.13 – Diagramme de contexte de l’application « système de freinage automobile ».\nva donc se situer dans l’expression du processus fonctionnel à réaliser : « Contrôler\nsystème freinage 0 ».\n2.3.3 Diagramme préliminaire et diagrammes de décomposition\nLe premier niveau d’analyse est représenté par le diagramme préliminaire. Ce\ndiagramme préliminaire est la première décomposition du processus à réaliser présenté dans le diagramme de contexte. À ce niveau, le diagramme représente la liste\n« graphique » des processus fonctionnels nécessaires à l’application sans se soucier\nde l’enchaînement (séquence d’exécution).\nLe nombre de processus fonctionnels, composant ce diagramme préliminaire, doit\nêtre limité pour avoir une meilleure lisibilité : 5 à 9 maximum.\nDans ce cadre, nous pouvons aussi trouver un motif générique permettant de décrire\nune fonction simple ou complexe de contrôle-commande en la divisant selon les\ntrois éléments de base, soit :\n– un processus d’acquisition ;\n– un processus de traitement (loi de régulation) ;\n– un processus de commande.\nSelon l’application, tout ou partie de ce diagramme flot de données générique peut\nêtre présent pour chaque chaîne de contrôle-commande impliquée dans le niveau\nd’analyse en cours d’élaboration. Ce diagramme flot de données générique peut être\nutilisé au niveau du diagramme préliminaire ainsi que dans les niveaux d’analyse\nsuivant des diagrammes de décomposition.\nFigure 2.14 – Décomposition fonctionnelle générique.\nLe passage des données entre les processus fonctionnels peut être réalisé selon les\nbesoins avec les deux méthodes de base : flots de données direct (exemple entre les\nprocessus 2 et 3) ou unité de stockage (cas des processus 1 et 2).\nAinsi, dans l’exemple simple d’un système de freinage automobile (§ 2.3.1), le diagramme préliminaire est constitué de cinq processus fonctionnels (figure 2.15). Au\nniveau de cet exemple simple, nous n’avons pas une décomposition fonctionnelle\naussi complexe que l’exemple générique présenté précédemment : seules les parties\nFigure 2.15 – Diagramme flot de données préliminaire de l’application\n« système de freinage automobile ».\nacquisition et commande sont présentes dans le cas du contrôle-commande du\nfreinage et du bouton ABS.\nNous pouvons souligner immédiatement la cohérence obligatoire entre le diagramme\nde contexte (figure 2.13) et ce diagramme préliminaire au niveau des flots de données\nLe passage des données entre les processus fonctionnels est effectué de façon directe.\nIl est important de noter que la donnée « Niveau_freinage » est de type entier ou\nréel alors que les données « Etat_glissement » et « Etat_bouton_ABS » sont de type\nbooléen. Cela va entraîner dans la suite de cette analyse une modification de ce\nCette décomposition fonctionnelle en diagrammes flots de données peut se poursuivre en raffinant de plus en plus la description des processus fonctionnels\n(figure 2.16). Chaque diagramme de décomposition, associé à un processus fonctionnel – numéroté « N » – du diagramme hiérarchiquement supérieur, est référencé au niveau des processus fonctionnels par des numéros « N.x ».\nL’exemple simple « système de freinage automobile » choisi pour illustrer la méthodologie n’est pas assez complexe pour justifier la décomposition d’un des processus\nfonctionnels. Donc tous les processus fonctionnels du diagramme préliminaire de\nla figure 2.15 sont des processus primitifs.\nLorsqu’il n’y a plus d’intérêt à décomposer un processus, celui-ci est appelé processus primitif et doit être décrit par une spécification sous forme textuelle, tabulaire\nou graphique (voir ci-après).\nNous pouvons énoncer les deux premières règles de cohérence de cette décomposition hiérarchique :\n– l’ensemble des flots entrants et sortants du processus décomposé doit se retrouver\ndans le diagramme de décomposition de ce processus avec les mêmes typages\n(données ou événements) ;\nFigure 2.16 – Décomposition hiérarchique en diagramme flots de données\nde la méthode d’analyse SA_RT.\n– la numérotation des différents processus fonctionnels doit intégrer le numéro du\nprocessus fonctionnel analysé « N » sous la forme « N.x » ;\n– les stockages doivent apparaître dans tous les diagrammes où les processus les utilisent.\nLa décomposition hiérarchique fonctionnelle, explicitée dans ce paragraphe, est la\nbase de la méthode d’analyse SA-RT. Mais l’aspect temporel ou plus exactement le\ncontrôle de l’enchaînement dans l’exécution de ces différents processus fonctionnels\nn’est pas décrit au travers de ces diagrammes flots de données. Ceci va donc faire\nl’objet d’un complément au niveau de ces diagrammes par l’aspect « contrôle ».\n2.4 L’aspect contrôle de la méthode SA-RT\n2.4.1 Mise en place du processus de contrôle\nLe processus de contrôle, tel


Fin de la loi des 100ch pour 2016 !\nEn votant le nouveau règlement sur l’homologation des véhicules, le Parlement européen va mettre fin à la « loi des 100 chevaux ».\nMardi 20 novembre 2012, le Parlement européen a voté un nouveau règlement visant à harmoniser l’homologation des deux-roues motorisés.\nAu cœur des nombreux paragraphes, la fin de limitation de la puissance à 74 kW pour les motos – l’exception française – est clairement stipulée.\nPar un décret du 3 janvier 2012, et à compter du 1er janvier 2013, tout conducteur d’un véhicule deux roues de plus de 50cc est dans l’obligation de porter une surface réfléchissante d’au moins 150 cm².\nLa FFMC, qui a déjà déposé un recours auprès du Conseil d’Etat, dénonce ce décret issu de la précédente mandature et interpelle le nouveau gouvernement élu sur une promesse de « changement ». Les conducteurs de deux roues motorisés et leur passager ont déjà (...)\nVéritable feuille de route d’une sécurité routière universelle, notre Manifeste s’adresse à tous les conducteurs quels que soient leur véhicule, aux familles, (...)