jkjljljljl

Conservatoire National des Arts et Métiers

Chaire d ’automatisme industr iel

UE mixte Automatisme C1 (code AUT209)

Conception et mise en œuvre de commandes

distribuées temps réel

Année 2008 - 2009

******************

Architecture logicielle type

pour les

applications de contrôle-commande

******************

Pierre BLANDIN

Conservatoire National des Arts et Métiers

Chaire d ’automatisme industr iel

UE mixte Automatisme C1 (code AUT209)

Conception et mise en œuvre de commandes

distribuées temps réel

Année 2008 - 2009

*******************

Architecture logicielle type

pour les

applications de contrôle-commande

******

1. Les applications de contrôle/commande

2. Élaboration d’une architecture logicielle type

3. Caractéristiques générales des fonctionnalités à implémenter

4. Choix structurels découlant du type de fonctionnalités à implémenter

5. Communication entre IHM et tâches permanentes de supervision

6. Synchronisation et communication entre les 2 processus

7. Le processus Win32 RTX : implémentation de l’IHM

8. Le processus Win32 RTX : implémentation du niveau Supervision

9. Le processus RTSS : structuration du niveau Contrôle/commande

10. Le processus RTSS : description des threads

*******************

Pierre BLANDIN

Laboratoire d’Automatique 21 rue Pinel 75013 PARIS

Tél. : 01 42 16 88 44 Fax : 01 45 86 21 18 Site web : http://automatique.cnam.fr/

http://automatique.cnam.fr/

Références

COTTET F., RENARD P. : Programmation graphique des applications de contrôle/commande,

Techniques de l’Ingénieur, traité « Informatique industrielle ».

CALVEZ J. P. : Spécification et conception des systèmes. Une méthodologie, Masson, 1992

CONDEMINE M. : OPC, Le Livre. Votre guide dans l’univers d’OPC, 4CE Industry, 2004,

(www.4ce-industry.com)

BLANDIN P. : Support de cours sur les Systèmes temps réel multitâches, Laboratoire

d’Automatique, CNAM Paris, 2008-2009

BLANDIN P. : Support de formation à RTX 8.1, Laboratoire d’Automatique, CNAM Paris,

2008

Sur le site web du Laboratoire http://automatique.cnam.fr/ on accède aux deux

derniers documents pédagogiques en suivant le chemin suivant :

Formations et diplômes -> Les unités d'enseignement -> AUT107

********

http://www.4ce-industry.com/

http://automatique.cnam.fr/

SOMMAIRE

1. LES APPLICATIONS DE CONTROLE/COMMANDE ................................................................................... 7

1.1 CARACTERISTIQUES DES APPLICATIONS DE CONTROLE/COMMANDE ..................................................... 7 1.2 DEVELOPPEMENT DES APPLICATIONS DE CONTROLE/COMMANDE ......................................................... 8 1.3 PROGRAMMATION DES APPLICATIONS DE CONTROLE/COMMANDE ........................................................ 9

2. ÉLABORATION D’UNE ARCHITECTURE LOGICIELLE TYPE.......................................................... 11

2.1 DECOMPOSITION FONCTIONNELLE DE LA COMMANDE ........................................................................... 11 2.2 REPARTITION JUDICIEUSE DES TRAITEMENTS INFORMATIQUES ............................................................ 14 2.3 CHOIX D’UNE ARCHITECTURE LOGICIELLE TYPE..................................................................................... 14

3. CARACTERIS TIQUES GENERALES DES FONCTIONNALITES A IMPLEMENTER ...................... 17

3.1 LES DIFFERENTES CATEGORIES D’OPERATIONS....................................................................................... 17 3.1.1 La notion d’opération dans une application de contrôle/commande ........................................ 17 3.1.2 Critères de classement des opérations d’une application de contrôle/commande ................. 18 3.1.3 Typologie des opérations d’une application de contrôle/commande ........................................ 19 3.1.4 Opérations spécifiques et opérations non spécifiques à une application ................................. 19

3.2 IMPLEMENTATION, EN FONCTION DE LEUR CATEGORIE, DES OPERATIONS SPECIFIQUES................................. 19 3.2.1 La tâche dite superviseur .................................................................................................................. 19 3.2.2 Le traitement des opérations relevant du niveau Supervision .................................................... 20 3.2.3 Répartition des traitements à effectuer en fonction de la catégorie de l’opération................ 20

3.3 ORDRES DE L’OPERATEUR NON SPECIFIQUES A UNE APPLICATION....................................................... 21 3.3.1 Demande d’affichage de l’état du système de commande et de la partie opérative ............... 21 3.3.2 Demande d’interruption de l’opération non immédiate en cours.............................................. 21 3.3.3 Acquittement de l’alarme signalée .................................................................................................. 21

4. CHOIX STRUCTURELS DECOULANT DU TYPE DE FONCTIONNALITES A IMPLEMENTER............. 23

4.1 ARCHITECTURE GENERALE DU NIVEAU SUPERVISION............................................................................ 23 4.1.1 Les tâches permanentes : la tâche superviseur et la tâche afficheObs ..................................... 23 4.1.2 La tâche temporaire realiseOpSvisionNI ....................................................................................... 23 4.1.3 Schéma récapitulatif de l’architecture du niveau Supervision................................................... 24 4.1.4 Partie logicielle du système de commande .................................................................................... 25

4.2 CHOIX DE BASE RELATIFS AUX IHM ET A LEUR MISE EN OEUVRE........................................................ 25 4.3 DEMARRAGE ET TERMINAISON DE L’APPLICATION DE CONTROLE-COMMANDE................................. 26

4.3.1 Lancement et démarrage de l’application ..................................................................................... 26 4.3.2 Arrêt du système de commande et terminaison de l’application................................................ 26

4.4 NIVEAU DE PRIORITE DES THREADS DU PROCESSUS WIN32 RTX ........................................................ 27 CONCLUSION........................................................................................................................................................ 28 ANNEXE : A PROPOS DU DEVELOPPEMENT ET DU DEPLOIEMENT D’UNE APPLICATION............................ 29

5. SYNCHRONISATION ET COMMUNICATION ENTRE L’IHM ET LE CŒUR DE L’APPLICATION .. 31

5.1 MODES DE SYNCHRONISATION ET NATURE DES INFORMATIONS ECHANGEES .................................... 32 5.1.1 Procédure de traitement d’une demande de service .................................................................... 32 5.1.2 Procédure de traitement d’une demande de préparation de l’affichage .................................. 33

5.2 COMMUNICATION ENTRE IHM, TACHE SUPERVISEUR ET TACHE AFFICHEOBS................................... 33 5.2.1 Synchronisation et communication entre l’IHM et la tâche superviseur.................................. 33 5.2.2 Synchronisation et communication entre la tâche superviseur et la tâche afficheObs .......... 34 5.2.3 Synchronisation et communication entre l’IHM et la tâche afficheObs ................................... 35

5.3 STRUCTURE DE L’INTERFACE ENTRE L’IHM ET LE CŒUR DE L’APPLICATION .................................... 36 5.4 LES FONCTIONS D’INTERFACE APPELEES PAR L’IHM............................................................................. 38

5.4.1 Description des 6 fonctions .............................................................................................................. 38 5.4.2 Liens entre les 6 fonctions et le serveur OPC (cas d’une IHM de type OPC) ........................ 40

CONCLUSION........................................................................................................................................................ 41

6. S YNCHRONISATION ET COMMUNICATION ENTRE LES 2 PROCESS US .................................. 43

6.1 CANAL 1 : PARAMETRES ET COMPTE-RENDU DE CONFIGURATION DU NIVEAU CCDE ..................... 44 6.2 CANAL 2 : ORDRES ET COMPTE RENDUS RELATIFS AUX OPERATIONS DE CCDE ............................... 46

6.2.1 A propos des messages de demande de service............................................................................. 47 6.2.2 Informations nécessaires à la réalisation d’une opération non immédiate ouverte ............... 47

6.2.3 Interruption d’une opération non immédiate de contrôle-commande....................................... 47 6.2.4 Les messages de prise en compte et de compte-rendu ................................................................. 48

6.3 CANAL 3 : DONNEES E/S ACQUISES LORS D’UNE OPERATION DE CCDE............................................. 50 6.4 CANAL 4 : OBSERVATIONS SUR L’ETAT DE L’AUTOMATE ET DE LA PO ............................................. 52

6.4.1 Les variables images des variables d’état du système de contrôle/commande........................ 52 6.4.2 Les variables images non spécifiques à une application particulière ....................................... 53 6.4.3 Mise à jour périodique des variables images ................................................................................ 53 6.4.4 L’acquittement de l’alarme signalée ............................................................................................... 53

6.5 RECAPITULATIF DES OBJETS IPC ............................................................................................................... 54

7. LE PROCESS US WIN32 RTX : IMPLEMENTATION DE L’IHM ........................................................... 57

7.1 STRUCTURE DU THREAD PRIMAIRE DU PROCESSUS WIN32 RTX .......................................................... 57 7.1.1 Programme principal du thread primaire ...................................................................................... 57 7.1.2 Les fonctions creerCanauxVersCcde() et detuireCanauxVersCcde() ....................................... 58 7.1.3 Les fonctions creerNiveauSupervision() et detruireNiveauSupervision() ..................................... 58 7.1.4 Les fonctions de gestion du dialogue avec l’application depuis la console ............................. 59

7.2 CONFIGURATION DE L’APPLICATION ET DU SERVEUR OPC ................................................................... 59 7.2.1 Les différents niveaux de configuration d’une application ......................................................... 59 7.2.2 La fonction configureCcde() ............................................................................................................. 60

7.3 GESTION DE L’IHM CONSOLE .................................................................................................................... 61 7.3.1 La fonction gestionIHMconsole() .................................................................................................... 61 7.3.2 La fonction opIHMconsole()............................................................................................................. 62

7.4 GESTION DE L’IHM DE TYPE OPC............................................................................................................. 64 7.4.1 La fonction gestionIHMopc() ........................................................................................................... 64 7.4.2 La description de la base de données exposée par le serveur OPC .......................................... 65 7.4.3 Les fonctions de l’API avec l’application appServeurOPC ........................................................ 67 7.4.4 Exemple de fonction gestionIHMopc()............................................................................................ 68

ANNEXE : EXEMPLE DE DESCRIPTION DE LA BASE DE DONNEES EXPOSEE................................................. 69

8. LE PROCESS US WIN32 RTX : IMPLEMENTATION DU NIVEAU SUPERVISION .............................. 73

8.1 LA TACHE SUPERVISEUR ............................................................................................................................. 73 8.1.1 Fonctionnalités assurées par la tâche superviseur....................................................................... 73 8.1.2 Organigramme général de la tâche superviseur ........................................................................... 74 8.1.3 La fonction superviseOpCcde()....................................................................................................... 74

8.2 LA TACHE REALISEOPSVISIONNI .............................................................................................................. 76 8.2 1 Caractéristiques générales de la tâche realiseOpSvivion ........................................................... 76 8.2.2 Organigramme général de la fonction de thread traiteDataES ................................................. 76

8.3 LA TACHE AFFICHEOBS ............................................................................................................................... 77

9. LE PROCESS US RTSS : STRUCTURATION DU NIVEAU CONTROLE/COMMANDE ..................... 79

9.1 STRUCTURE DU PROCESSUS RTSS............................................................................................................. 79 9.1.1 La raison d’être des différents threads du processus RTSS ........................................................ 79 9.1.2 Niveau de priorité des threads du processus RTSS....................................................................... 81

9.2 SYNCHRONISATION ET COMMUNICATION ENTRE LES TACHES............................................................... 81 9.2.1 Choix relatifs à l’organisation de l’activité des tâches................................................................ 81 9.2.2 Mécanisme de terminaison des tâches ............................................................................................ 82 9.2.3 Communication entre les tâches du niveau Contrôle/commande .............................................. 83

9.3 COMMUNICATION ENTRE LA TACHE AUTOMATE ET LE NIVEAU SUPERVISION.................................... 83 9.3.1 Communication entre la tâche automate et la tâche superviseur .............................................. 83 9.3.2 Transmission de données E/S au niveau Supervision................................................................... 84

9.4 GESTION DES ALARMES ............................................................................................................................... 84

10. LE PROCESS US RTSS : DESCRIPTION DES THREADS............................................................................ 87

10.1 LE THREAD PRIMAIRE ET LA FONCTION METTREENSERVICEINTERFACEPO() ................................. 87 10.1.1 Déroulement du thread primaire ................................................................................................... 87 10.1.2 La fonction spécifique mettreEnServiceInterfacePO() ............................................................. 88 10.1.3 Algorithme général du thread primaire........................................................................................ 89

10.2 LA TACHE DE COLLECTE DES OBSERVATIONS........................................................................................ 90 10.3 LA TACHE AUTOMATE ............................................................................................................................... 91

UE Automatisme C1 (AUT209) 1. Les applications de contrôle/commande

Pierre BLANDIN, Laboratoire d’Automatique, CNAM Paris 7

1. Les applications de contrôle/commande

Le contenu de ce chapitre est extrait de l’article Programmation graphique des

applications de contrôle/commande1.

Une application de contrôle/commande peut être définie comme un système informatique qui réalise l’acquisition de données par l’intermédiaire de capteurs et élabore

des commandes envoyées au procédé physique grâce à des actionneurs. Présentes dans tous les secteurs industriels, ces applications nécessitent un développement rapide, de qualité et fiable. Habituellement réalisées à partir de langages de bas niveau (assembleurs) ou classiques (langage C, etc.), la programmation des systèmes informatiques destinés au

pilotage de procédés physiques a été bouleversée par l’arrivée de langages graphiques…

1.1 Caractéristiques des applications de contrôle/commande

Les applications de contrôle/commande concernent les systèmes informatiques destinés au pilotage de procédés physiques. Ces systèmes fonctionnent souvent en ligne (on line) avec le procédé contrôlé. Dans ce contexte particulier d’interaction avec le monde extérieur, l’informatique

de contrôle-commande de procédé doit satisfaire à des exigences nouvelles comme :

le respect de contraintes temporelles adaptées au procédé piloté ;

la gestion d’une grande diversité de dispositifs d’entrées/sorties : procédés continus (entrées/sorties de type continu ou analogique),

procédés discrets (entrées/sorties de type numérique) : systèmes à

événements discrets, procédés mixtes ;

le respect des propriétés de la sûreté de fonctionnement, en particulier : fiabilité (continuité de service),

sécurité (garantie de la non occurrence de défaillances) ;

la prise en compte de comportements concurrents (parallélisme de l’environnement).

Une définition de ces systèmes de contrôle-commande pourrait être la suivante : « un

système informatique de contrôle/commande reçoit des informations sur l’état du procédé

extérieur, traite ces données et, en fonction du résultat, évalue une décision qui agit sur cet environnement extérieur dans de sévères contraintes de temps afin d’assurer un état stable ».

La notion d’état stable est liée à la vitesse de réaction du procédé contrôlé. Selon les applications, la dynamique du procédé peut être très différente :

de l’ordre de la milliseconde ou inférieure : systèmes radar, systèmes vocaux,

systèmes de mesures physiques ;

de l’ordre de la seconde : systèmes de visualisation (interface homme-machine) ;

de l’ordre de la minute : chaîne de fabrication ;

de l’ordre de l’heure : contrôle de réactions chimiques.

1 Programmation graphique des applications de contrôle/commande , par Francis COTTET et Patrick RENARD, Techniques de l’Ingénieur, traité Informatique industrielle.

1. Les applications de contrôle/commande UE Automatisme C1

8 Pierre BLANDIN, CNAM Paris

1.2 Développement des applications de contrôle/commande

L’informatique de contrôle de procédés diffère fondamentalement des systèmes

informatiques classiques et conduit à la mise en œuvre de méthodes et de techniques appropriées. En particulier, la réalisation de telles applications nécessite de conduire simultanément le développement de la partie matérielle (ordinateur, cartes d’entrées/sorties, etc.) et de la partie logicielle (gestionnaire de cartes, logiciel de pilotage, interface homme-

machine, etc.).

Le matériel, utilisé dans ce type d’applications, peut être très divers selon les caractéristiques opérationnelles de l’application. Ce matériel peut être une simple carte, construite autour d’un micro-contrôleur, pour gérer des applications de petite taille : compteur électrique industriel, caméra vidéo, radiotéléphone, appareils électroménager, etc.

Mais il peut être constitué aussi de plusieurs micro-ordinateurs reliés par un réseau de type bus de terrain pour des applications de grande taille ou, plus classiquement, par un simple micro-ordinateur pour toutes les autres applications. Nous pouvons noter que les systèmes, constitués de plusieurs micro-ordinateurs en réseau, le sont pour les trois principales raisons

suivantes :

application formée de multiples équipements (exemple : chaîne de fabrication) ;

applications nécessitant un haut niveau de sûreté de fonctionnement en utilisant de la redondance matérielle ;

application requérant une capacité de traitement importante (traitement de signaux).

Il est aussi important de noter que beaucoup d’applications de contrôle-commande ont été et sont encore réalisées à l’aide d’automates programmables industriels (API). Ces API présentent de nombreux avantages dans le contexte industriel, en particulier celui de la

sûreté de fonctionnement avec la notion d’arrêt d’urgence et reprise après arrêt. Mais l’amélioration constante des micro-ordinateurs de type industriel, associés à des langages de programmation spécifiques, amène à les utiliser pour des applications identiques avec les multiples avantages qu’ils offrent au niveau de la conception et de la réalisation du logiciel

de pilotage (facilité, réutilisabilité, lisibilité, etc.).

Au niveau de l’architecture logicielle d’applications de contrôle-commande, nous pouvons distinguer cinq grandes parties (cf. figure 1) :

1. le traitement des données internes à l’application : analyse spectrale, loi de commande, etc. ;

2. les relations avec le procédé à piloter au travers des capteurs/actionneurs et des cartes d’entrées/sorties : mesures dans le sens procédé système de pilotage, et commandes dans sens système de pilotage procédé ;

3. la gestion de l’interface vers l’opérateur avec la visualisation des données et l’entrée des consignes ;

4. la relation avec le réseau : réseau local ou bus de terrain ;

5. la liaison vers une unité de stockage de masse pour la sauvegarde des données.

Ainsi, dans le cas général, le logiciel d’une application de contrôle-commande remplit successivement les trois fonctionnalités notées sur la figure 2, à savoir :

1. Acquisition de données ;

2. Analyse et traitement de données ;

3. Restitution de données.

UE Automatisme C1 (AUT209) 1. Les applications de contrôle/commande


1.3 Programmation des applications de contrôle/commande

Comme pour tous les systèmes informatiques, le choix du langage de programmation va dépendre de la taille et de la complexité de l’application mais aussi des matériels et capacités internes à l’entreprise. Étant donné les fonctionnalités requises par ce type d’applications, le langage doit supporter les différents services suivants :

1. Acquisition et restitution de données :

contrôle de cartes d’entrées/sorties analogiques ou numériques,

contrôle d’instruments par l’intermédiaire de liaisons normalisées : GPIB, RS-

232, VXI, etc.,

liaison réseau (par exemple TCP/IP), base de données… ;

2. Traitement de données :

traitement numériques des signaux (FFT, corrélation, filtrage, fenêtrage…),

traitement statistique des signaux (moyenne, écart type ; régression,

lissage…),

1. Les applications de contrôle/commande UE Automatisme C1


traitement d’images (extraction de contour…),

élaboration de lois de commande (par exemple, régulation PID),

maîtrise statistique du procédé (par exemple, analyse de Pareto) ;

3. Présentation des données :

interface graphique et interactive,

représentation de courbes 2D et 3D, représentation d’images,

stockage des données (impression, archivage…), génération de documents…,

distribution sur réseau (Internet, Intranet…).

Étant donné l’ensemble de ces fonctions, il est très difficile de trouver un langage qui

offre toutes ces composantes à la fois. Aussi, ce type d’applications est réalisé grâce à l’association de plusieurs langages et/ou bibliothèques de programmes spécialisées (traitement de signaux, traitement d’images, lois de commande, etc.) (figure 3). Il est très courant par exemple de réaliser les gestionnaires d’interfaces (drivers) à l’aide d’un langage de bas niveau comme un assembleur, de concevoir des interfaces homme-machine avec des

langages ou bibliothèques appropriés (Visual Basic, Visual C++, Tcl-Tk, Motif…). A l’heure actuelle, une grande majorité de ces applications sont réalisées à l’aide des langages C ou

C++ qui sont associés à des bibliothèques spécifiques. Toutefois, pour des applications de grande taille, il est souvent préféré un langage plus structuré et plus « propre » comme Ada.

En 1998, plus de 700 projets d’applications de contrôle-commande, implémentés en Ada sont en cours. D’autre langages sont également disponibles pour ces applications comme LabVIEW (National Instruments), MatLab/Simulink (The Mathworks). Leur essor est lié à l’environnement de programmation offert avec un ensemble de fonctionnalités adapté à ce

domaine ou à des domaines connexes comme celui de la mesure. Le langage LabVIEW, qui est détaillé dans la suite de cet article, doit en particulier son développement à une programmation naturelle de type blocs fonctionnels très utilisé dans ce domaine.

Il est intéressant de noter que la normalisation internationale (CEI/IEC 1131-3), concernant les langages de programmation des automates programmables industriels,

définit un langage de conception, le GRAFCET (SFC : Sequential Function Chart aux États-Unis), et quatre langages d’implémentation dont deux graphiques : les diagrammes à relais (LD : Ladder Diagram) et les blocs fonctionnels (FDB : Function Block Diagram).

UE Automatisme C1 (AUT209) 2. Élaboration d’une architecture logicielle type


2. Élaboration d’une architecture logicielle type

Nous allons essayer d’élaborer une architecture type pour le logiciel d’un système temps réel de contrôle/commande ayant pour support d’exécution un micro-ordinateur équipé de Windows 2000, Windows XP ou Windows Vista, et de l’extension temps réel RTX de

la société IntervalZero (anciennement Ardence et Venturcom).

Sous le terme de Windows nous désignerons désormais le système d’exploitation

effectivement installé sur le micro-ordinateur de notre application temps réel type,

et qui donc peut être Windows 2000, Windows XP ou Windows Vista.

Pour notre projet de définition d’une architecture type pour le logiciel de différents systèmes temps réel, nous allons nous intéresser à la classe des applications de faible et moyenne complexité dans le domaine du contrôle/commande de procédés physiques.

Une telle application de contrôle/commande peut ainsi être globalement

schématisée :

2.1 Décomposition fonctionnelle de la commande

Dans un premier temps, nous allons examiner comment le système de commande peut

être structuré en procédant à une décomposition fonctionnelle de la loi de commande à implémenter.

Pour définir donc l’architecture fonctionnelle générale du logiciel de notre système temps réel type, nous allons faire appel à un modèle générique de solution, c’est-à-dire à une

esquisse de solution bien adaptée à la classe des applications auxquelles nous nous intéressons. Ce modèle, c’est le modèle supervision / contrôle-commande.

Ce modèle est décrit dans l’encart ci-dessous.

Système temps réel

Micro-ordinateur équipé de

Windows et RTX

Opérateur

Procédé physique

observations actions

2. Élaboration d’une architecture logicielle type UE Automatisme C1


²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

Le modèle Supervision / contrôle-commande

Pour le développement d’applications industrielles de commande de procédés, une

approche hiérarchique est souhaitable lorsqu’il s’agit d’applications complètes et

relativement complexes (complexité qui se mesure par l’importance des fonctions et le

nombre d’entrées/sorties du système).

L’idée est que la conduite d’une installation plutôt complexe est globalement prise en

charge par le système. L’utilisateur ou exploitant se contente de fournir les objectifs à

atteindre et observe à un niveau macroscopique le comportement de l’installation. La

conduite par l’exploitant est une fonctionnalité de niveau supérieur par rapport à la conduite

de chaque entité de l’installation.

De tels systèmes se structurent en au moins deux niveaux :

un niveau supervision qui assure l’interface avec l’exploitant pour la conduite

globale de l’application ;

un niveau contrôle-commande chargé de gérer les entités physiques de

l’application pour qu’elles contribuent à satisfaire l’objectif du niveau supérieur.

Les deux niveaux sont donc couplés entre eux : dans le sens descendant pour l’assignation

d’objectifs, dans le sens ascendant pour rendre compte de l’avancement vers les objectifs.

Le modèle proposé découle de ce principe de structuration : décomposition

hiérarchique en un niveau supervision et un niveau contrôle-commande. Pour spécifier le

modèle, il faut détailler le couplage général existant entre les deux catégories de fonctions.



La mise à œuvre du modèle supervision / contrôle-commande pour structurer le logiciel de notre application temps réel type conduit à définir deux processus d’exécution :

un processus où seront implémentées les fonctions du niveau Supervision,

un processus où seront implémentées les fonctions du niveau Contrôle/commande.

Le modèle Supervision / contrôle–commande (suite)

Le couplage descendant, de supervision vers contrôle-commande, nécessite deux

catégories d’informations :

des paramètres, qui vont qualifier les objectifs à atteindre pour la partie

opérative : température de consigne, temps de réponse…

des ordres, qui sont des événements avec association ou non d’informations, pour

désigner les opérations que doit entreprendre la partie contrôle-commande.

Le couplage ascendant, de contrôle–commande vers supervision, nécessite aussi deux

catégories d’informations :

des observations qui, synthétisées par la partie contrôle–commande,

permettront de suivre le déroulement des opérations,

des réactions, pour signaler au niveau supérieur des situations particulières à

prendre en compte.

Les entrées et sorties pour l’exploitation sont associées à la supervision. Les autres

entrées et sorties sont associée à la partie commande.

Méthode à suivre pour l’emploi de ce modèle

De nombreuses applications, tout particulièrement celles comportant une partie

opérative et faisant intervenir une exploitation sous toutes ses formes, peuvent être

développées sur la base de ce modèle.

Le choix de ce modèle étant fait, la démarche pour sa mise en œuvre est la suivante :

Identifier les entités liées à chacun des deux niveaux.

Rechercher par analyse des spécifications, les variables de couplage

nécessaires : paramètres dans un sens, observations dans l’autre.

Rechercher ensuite les événements de couplage, c’est-à-dire les ordres

dans un sens, les réactions dans l’autre.

Représenter graphiquement la structure fonctionnelle en la complétant

par les entrées et sorties à chacun des deux niveaux, et par les relations

de couplage entre eux.

Vérifier la solution pour s’assurer que toutes les spécifications sont

prises en compte.

D’après J.L. CALVEZ : Spécification et conception des systèmes, une méthodologie, p. 334

2. Élaboration d’une architecture logicielle type UE Automatisme C1


2.2 Répartition judicieuse des traitements informatiques

Pour mener avec succès le développement d’une application temps réel avec RTX, il

est nécessaire de répartir correctement l’implémentation des fonctionnalités de l’application entre d’une part les processus non temps réel (les processus Win32) et d’autre part les processus temps réel (les processus RTSS), et ensuite de définir l’interface de synchronisation et de communication entre ces processus.

Si, par exemple, il y a trop de traitements à contraintes temporelles strictes dans

les processus Win32, trop de traitements à contraintes temporelles relatives dans

les processus RTSS et trop de mécanismes de synchronisation et de flux de données

entre les divers processus, les performances globales de l’application risquent d’être

catastrophiques (dans l’hypothèse où l’on soit malgré tout arrivé à faire fonctionner

une application si mal structurée !).

Ces considérations sur la répartition des traitements informatiques d’une application temps réel, conduit à une structuration du logiciel qui rejoint celle qui a été précédemment

préconisée pour une application de contrôle/commande en se situant du seul point de vue de la décomposition fonctionnelle de la loi de commande.

Ainsi dans le Support de formation à RTX 8.1, étaient données les directives suivantes en ce qui concerne la structuration d’une application temps réel utilisant RTX (cf. § 2.2.1 Structure d’une application temps réel utilisant RTX, p. 15).

2.3 Choix d’une architecture logicielle type

Voici en définitive l’architecture logicielle type du logiciel des applications de

contrôle/commande auxquels nous nous intéressons et dont le support d’exécution est un micro-ordinateur équipé de Windows et de RTX :

1. Un processus Win32 où est implémenté le niveau Supervision : il assure toutes les fonctions non temps réel ou temps réel non critique de l’application ; il peut gérer une interface de type GUI (Graphic User Interface) avec l’opérateur.

2. Un processus RTSS où est implémenté le niveau Contrôle/commande : il assure toutes les fonctions temps réel à contraintes strictes de l'application ; c’est donc la partie déterministe du système de commande.

Structure d’une application temps réel utilisant RTX

Une application temps réel faisant appel à l’extension temps réel RTX comportera généralement au moins deux processus travaillant de concert :

un processus Win32 dans lequel sont implémentées les fonctionnalités non

temps réel ou temps réel non critique de l’application ; ce processus peut tirer avantage des fonctions spécifiques au sous système Win32, comme par exemple les fonctions graphiques de gestion de l’interface opérateur (GUI = Graphic User Interface),

un processus RTSS dans lequel sont implémentées les fonctionnalités temps

réel (déterministes) de l’application.

Il est important de noter que toutes les fonctions qui comportent une allocation

de mémoire, une écriture à l’écran ou une opération d’entrée/sortie de fichier

n’ont pas un comportement déterministe .



Deux points de vue sont donc à l’origine de cette architecture type, et de ce fait la justifient :

1. La décomposition fonctionnelle hiérarchique de la commande fait apparaître :

un niveau supervision qui assure l’interface avec l’exploitant pour la conduite

globale de l’application,

un niveau contrôle/commande chargé de gérer les entités physiques de

l’application.

2. Une application temps réel faisant appel à l’extension RTX de IntervalZero comporte

nécessairement au moins deux processus travaillant de concert :

un processus Win32 dans lequel sont implémentées les fonctionnalités non temps

réel ou temps réel non critique de l’application ; ce processus peut tirer avantage des fonctions spécifiques au sous système Win32, comme par exemple les

fonctions graphiques de gestion de l’interface opérateur ;

un processus RTSS dans lequel sont implémentées les fonctionnalités temps réel

(déterministes) de l’application.

Ainsi, d’une part la décomposition fonctionnelle de la commande et d’autre part la nécessaire répartition judicieuse des traitements entre processus Win32 et processus RTSS ont conduit à définir cette architecture type pour le logiciel des applications de

contrôle/commande.

Opérateur

Processus Win32 RTX

Supervision Fonctions non déterministes

Gestion d’une interface graphique avec l’utilisateur (GUI)

Processus RTSS

Contrôle - commande Fonctions déterministes

Gestion des E/S avec le procédé physique

Procédé physique

Réactions

Observations Ordres

Paramètres

Actions Observations

UE Automatisme C1 (AUT209) 3. Caractéristiques des fonctionnalités


3. Caractéristiques générales des fonctionnalités à implémenter

Pour une application particulière de contrôle/commande, l’ensemble des opérations dont l’opérateur humain est susceptible de demander l’exécution découle du cahier des charges et plus précisément des spécifications fonctionnelles du système de commande.

Dans ce chapitre, nous allons dégager les caractéristiques générales des opérations implémentées dans les applications temps réel de la classe à laquelle nous nous intéressons, à savoir la classe des applications de faible et moyenne complexité dans le domaine du contrôle/commande de procédés physiques. Ceci va nous guider dans les choix relatifs :

d’une part, au nombre et à la raison d’être des threads (ou tâches) qui vont composer le processus Win32 RTX et le processus RTSS ;

et d’autre part, aux mécanismes de synchronisation et de communication à mettre en place entre ces différentes tâches.

La structuration générale qui va ainsi être élaborée pour le processus Win32 RTX et le

processus RTSS facilitera ensuite l’implémentation des fonctionnalités d’une application particulière de contrôle/commande.

3.1 Les différentes catégories d’opérations

Avant de décrire les critères qui ont présidé à l’élaboration de la typologie des

opérations réalisées par les applications de contrôle/commande à la suite d’ordres ou demandes de service émanant de l’opérateur, il est nécessaire de préciser la notion d’opération.

3.1.1 La notion d’opération dans une application de contrôle/commande

Une opération est ce dont l’utilisateur humain est susceptible de demander la réalisation à l’application de contrôle/commande. Une opération a un début et une fin, et

aucune hypothèse n’est faite a priori sur sa complexité.

Compte tenu de la classe des applications auxquelles nous nous intéressons, nous considérons qu’à un instant donné l’application ne peut exécuter qu’une seule opération.

Une opération ne peut cependant être confondue avec un mode de fonctionnement particulier de l’application En effet, si pour cette dernière, une opération est exclusive d’une

autre opération, un mode de fonctionnement n’est pas exclusif d’une opération.

Ainsi la commande en boucle ouverte (BO) et la commande en boucle fermée (BF) d’un

axe machine sont des modes distincts de fonctionnement (de commande) de la partie

opérative. Dans l’un ou l’autre de ces modes de fonctionnement peuvent être

réalisées différentes opérations sur l’axe machine : commande « manuelle » de l’axe

(à l’aide d’un joystick par exemple), mouvement de l’axe sur une certaine distance,

opération d’acquisition de données E/S lors de mouvements de l’axe, etc. Cependant,

à un instant donné, une seule de ces opérations peut être réalisée et donc demandée

par l’opérateur.

Le fait qu’à un instant donné l’application ne puisse traiter qu’une seule opération ne

constitue pas en réalité une contrainte limitative étant donné qu’aucune hypothèse

n’est faite sur la complexité des opérations. Il sera en effet toujours possible de

définir une ou plusieurs macro opérations correspondant chacune à l’exécution

simultanée ou coordonnée de plusieurs opérations élémentaires.

3. Caractéristiques des fonctionnalités UE Automatisme C1


3.1.2 Critères de classement des opérations d’une application de contrôle/commande

La typologie des opérations d’une application de contrôle/commande a été faite à

partir des trois critères suivants de classement des opérations :

1. Opération de supervision et/ou opération de contrôle/commande

Ceci signifie que l ’opération demandée par l’utilisateur sera réalisée :

soit par le niveau Supervision (processus Win32 RTX),

soit par le niveau Contrôle/commande (processus RTSS),

soit conjointement par le niveau Supervision et le niveau Contrôle/commande.

2. Opération immédiate ou opération non immédiate

La durée d’exécution d’une opération s’apprécie essentiellement au regard de

l’opérateur humain.

Une opération immédiate est une opération dont l’exécution est quasi instantanée, et

qui, de ce fait, ne peut être interrompue par l’opérateur. Par exemple, le passage

dans un certain mode de fonctionnement correspond à une opération immédiate.

Une opération est considérée comme non immédiate si, prenant un certain temps

pour s’exécuter, elle est susceptible d’être interrompue par l’opérateur. Ceci suppose

que l’interruption de l’opération en cours ait un sens pour l’application, et que donc

cette dernière puisse à tout moment prendre en compte et traiter l’ordre de

l’opérateur d’interrompre et d’annuler l’opération en cours.

3. Opération non immédiate fermée ou opération non immédiate ouverte

On désigne sous le terme d’opération fermée une opération non immédiate pour

laquelle au moment de la demande de service l’application dispose de toutes les

informations nécessaires à la réalisation de l’opération demandée, y compris les

informations donnant le critère de fin ou d’arrêt de celle-ci.

Exemple : Le mouvement d’un axe de la position courante à une certaine position avec

une vitesse maximale donnée de déplacement constitue une opération non immédiate

fermée.

Le terme d’opération ouverte désigne par contre une opération non immédiate pour

laquelle toutes les informations nécessaires à sa réalisation par l’application ne sont

pas disponibles au moment de la demande de service, une partie de ces informations

(y compris le critère d’arrêt de l’opération) devant être communiquées à l’application

au cours de l’opération elle-même. De ce fait, au moment où elle déclenche la

réalisation de l’opération, l’application ne peut savoir quand celle-ci va se terminer ;

d’où le terme d’opération ouverte pour désigner un tel type d’opération.

Exemple : La commande « manuelle » du mouvement d’un axe à partir de la position

d’un joystick constitue une opération non immédiate ouverte. En effet, au cours de

cette opération est transmise périodiquement au niveau Contrôle/commande la

position courante du joystick, position à partir de laquelle est élaborée la commande

de l’axe.

Une opération non immédiate fermée se termine d’elle-même. Elle peut cependant être, à tout moment, interrompue par l’opérateur. Mais une telle interruption est alors considérée comme une situation anormale ; elle donne donc lieu au déclenchement d’une alarme.

L’exécution d’une opération non immédiate ouverte se poursuit par contre jusqu’à ce que le l’opérateur commande explicitement la fin de l’opération. Il faudra donc prévoir un ordre d’arrêt de l’opération non immédiate ouverte en cours.



3.1.3 Typologie des opérations d’une application de contrôle/commande

A partir des 3 critères décrits précédemment, nous pouvons établir la liste des différents

types d’opérations qu’une application de contrôle/commande est susceptible de réaliser :

1. opération immédiate relevant du niveau Supervision

2. opération immédiate relevant du niveau Contrôle/commande

3. opération non immédiate (ouverte ou fermée) relevant du niveau Supervision

4. opération non immédiate (ouverte ou fermée) relevant du niveau Contrôle/commande

5. opération non immédiate (ouverte ou fermée) relevant conjointement du niveau

Supervision et du niveau Contrôle/commande.

Une opération non immédiate fermée conjointe de supervision et de contrôle-

commande est par exemple :

une opération de mouvement d’un axe de la position courante à une position

donnée avec acquisition à chaque période d’échantillonnage de données E/S

(traitements assurés par le niveau Contrôle/commande),

ces données E/S étant, au fur et mesure de leur acquisition, exploitées puis

enregistrées dans un fichier sur disque ( traitements assurés par le niveau

Supervision).

3.1.4 Opérations spécifiques et opérations non spécifiques à une application

Au regard des choix d’implémentation des opérations d’une application de contrôle/commande et donc de l’élaboration de notre architecture logicielle type, il est

judicieux de distinguer :

d’une part, les opérations spécifiques à une application de contrôle/commande particulière ;

d’autre part, les ordres ou les opérations d’usage général que l’on retrouve dans toutes les applications de contrôle/commande.

3.2 Implémentation, en fonction de leur catégorie, des opérations spécifiques

Considérant les opérations spécifiques à une application de contrôle-commande particulière, nous allons décrire et justifier les choix d’implémentation de ces opérations en fonction de leur catégorie.

3.2.1 La tâche dite superviseur

Une tâche du niveau Supervision, la tâche dite superviseur, prend en compte toutes les

demandes de service adressées par l’opérateur à l’application qui donnent lieu à l’exécution par cette dernière d’une opération spécifique de supervision et/ou de contrôle-commande.

La tâche superviseur reçoit donc de l’Interface Homme Machine (IHM) tous les ordres ou demandes de service correspondant à des opérations spécifiques que l’application doit réaliser. Et nous verrons ultérieurement que cette tâche ne reçoit que ceux-là, et que donc elle

ne reçoit pas les ordres d’usage général.

L’exécution des traitements correspondant à l’opération demandée sera ensuite assurée par la tâche la plus appropriée compte tenu de la catégorie à laquelle appartient l’opération demandée.

3. Caractéristiques des fonctionnalités UE Automatisme C1


3.2.2 Le traitement des opérations relevant du niveau Supervision

C’est la tâche superviseur, qui en fonction de la catégorie de l’opération activera les

traitements à effectuer. Elle assurera ainsi la supervision de l’exécution de l’opération.

La tâche superviseur effectue elle-même les traitements relatifs aux opérations immédiates relevant du niveau Supervision.

Par contre, il semble préférable qu’une tâche du niveau Supervision, distincte de la

tâche superviseur, assure les traitement relatifs aux :

opérations non immédiates du niveau Supervision,

opérations non immédiates relevant conjointement du niveau Supervision et du niveau Commande/commande.

Cette tâche, appelée realiseOpSvisionNI, assurera ponctuellement les traitements

relatifs à ces catégorie d’opérations spécifiques.

3.2.3 Répartition des traitements à effectuer en fonction de la catégorie de l’opération

En définitive, suivant la nature de l’opération demandée, celle-ci est réalisée par :

la tâche superviseur elle-même s’il s’agit d’une opération immédiate du niveau Supervision ;

la tâche realiseOpSvisionNI s’il s’agit d’une opération non immédiate du niveau Supervision ;

le niveau Contrôle/commande s’il s’agit d’une opération de contrôle/commande (immédiate ou non immédiate).

Une opération non immédiate relevant conjointement du niveau Supervision et du niveau Contrôle/commande est réalisée par le niveau Contrôle/commande et par la tâche realiseOpSvisionNI du niveau Supervision.

Le tableau ci-dessous récapitule la répartition des traitements relatifs aux différentes opérations spécifiques d’une application de contrôle/commande :

Catégorie de l’opération… Opération réalisée par …

immédiate du niveau Supervision … la tâche superviseur

immédiate du niveau Contrôle/commande … le niveau Contrôle/commande

non immédiate du niveau Supervision … la tâche realiseOpSvisionNI

non immédiate du niveau Contrôle/commande … le niveau Contrôle/commande

non immédiate conjointe … le niveau Contrôle/commande et la tâche

realiseOpSvisionNI



3.3 Ordres de l’opérateur non spécifiques à une application

Parmi les ordres d’usage général que l’on retrouve dans toutes les applications de

contrôle-commande, nous avons identifié les 3 suivants :

1. Demande d’affichage de l’état du système de commande et de la partie opérative

2. Demande d’interruption de l’opération non immédiate en cours

3. Acquittement de l’alarme signalée à l’opérateur.

Ces ordres vont être pris en compte dans notre architecture logicielle type. Leur implémentation a comme caractéristique qu’ils ne sont ni reçus ni traités par la tâche superviseur, mais directement par les tâches concernées.

3.3.1 Demande d’affichage de l’état du système de commande et de la partie opérative

Lorsque le type d’interface homme machine (IHM) mis en œuvre ne permet pas un affichage périodique automatique de l’état du système de commande et de la partie

opérative, il est nécessaire de prévoir un ordre qui donne la possibilité à l’opérateur de demander ponctuellement l’affichage de telles informations. Cette demande devra pouvoir être prise en compte par l’application même lorsqu’une opération est en cours d’exécution ou qu’une alarme signalée à l’opérateur n’a pas encore été acquittée par lui.

Cet ordre sera directement reçu et traité par la tâche du niveau Supervision qui assure

la préparation des messages textuels à destination de l’opérateur : la tâche afficheObs.

3.3.2 Demande d’interruption de l’opération non immédiate en cours

L’ordre d’interruption et d’annulation de l’opération non immédiate (fermée ou ouverte) en cours est reçu directement par la tâche qui traite cette opération, que cette tâche soit une tâche du niveau Supervision ou une tâche du niveau Contrôle/commande.

Ainsi, suivant la catégorie de l’opération non immédiate en cours, la demande

d’interruption faite par l’opérateur sera reçue et prise en compte comme indiqué ci-après.

Catégorie de l’opération non immédiate en

cours

La demande d’interruption sera prise en

compte par …

non immédiate du niveau Supervision … la tâche realiseOpSvisionNI

non immédiate du niveau Contrôle/commande … le niveau Contrôle/commande

non immédiate conjointe … le niveau Contrôle/commande

3.3.3 Acquittement de l’alarme signalée

Chaque alarme déclenchée par le niveau Contrôle/commande est signalée à l’opérateur par l’intermédiaire du niveau Supervision. Toute alarme signalée à l’opérateur doit être

acquittée par ce dernier. S’il ne le fait pas, toute demande d’exécution d’une opération de contrôle-commande sera refusée.

Cet ordre d’acquittement de l’alarme signalée sera directement reçu et traité par la tâche du niveau Contrôle/commande qui gère la signalisation, en direction du niveau

Supervision, des alarmes déclenchées par le niveau Contrôle/commande.

Si une opération de contrôle-commande (immédiate ou non immédiate) est en cours au moment d’une déclenchement d’une alarme, cette opération est interrompue et annulée.

UE Automatisme C1 (AUT209) 4. Choix structurels


4. Choix structurels découlant du type de fonctionnalités à implémenter

4.1 Architecture générale du niveau Supervision

Des fonctionnalités à implémenter, il découle donc que le niveau Supervision va comprendre 3 taches : la tâche superviseur, la tâche afficheObs et la tâche realiseOpSvisionNI.

Les 2 premières tâches sont des tâches permanentes : elles sont créées par le thread primaire du processus Win32 RTX lors de la mise en service du système de commande, et

détruites lors de sa mise hors service.

La dernière tâche est une tâche temporaire : son existence est liée à l’exécution d’une opération non immédiate du niveau Supervision ou d’une opération non immédiate conjointe.

4.1.1 Les tâches permanentes : la tâche superviseur et la tâche afficheObs

Suivant le type d’opération qui doit être exécutée, la tâche superviseur gère différemment chaque demande de service qu’elle reçoit de l’IHM :

S’il s’agit d’une opération immédiate du niveau Supervision, elle exécute elle-

même cette opération.

S’il s’agit d’une opération non immédiate du niveau Supervision, elle crée la tâche

realiseOpSvisionNI avec comme fonction de thread celle qui correspond au traitement de l’opération demandée, puis démarre l’activité de cette tâche.

S’il s’agit d’une opération du niveau Contrôle/commande, elle transmet la demande

de service au niveau Contrôle/commande.

S’il s’agit d’une opération non immédiate conjointe, elle transmet la demande de

service au niveau Contrôle/commande, puis, lorsque ce dernier a retourné un accusé positif de prise en compte de la demande, elle crée la tâche realiseOpSvisionNI

avec comme fonction de thread celle qui correspond au traitement de l’opération demandée, et enfin démarre l’activité de cette tâche.

Quant à la tâche afficheObs, elle prépare l’affichage d’une part des observations que lui transmet périodiquement le niveau Contrôle/commande, et d’autre part des messages de

service émis par la tâche superviseur.

4.1.2 La tâche temporaire realiseOpSvisionNI

Créée et démarrée par la tâche superviseur lorsque doit être réalisée une opération non immédiate du niveau Supervision ou une opération non immédiate conjointe, la tâche realiseOpSvisionNI se termine et est détruite à la fin de l’exécution de l’opération.

Lors d’une opération non immédiate conjointe, la tâche realiseOpSvisionNI aura le

plus souvent à traiter, et éventuellement à enregistrer, des données E/S transmises

par le niveau Contrôle/commande. Elle se terminera et sera détruite après que ce

dernier lui aura indiqué la fin de la partie contrôle-commande de l’opération.

La tâche realiseOpSvisionNI est donc créée par la tâche superviseur au fur et à mesure des besoins. La fonction de thread correspondant au code de la tâche realiseOpSvisionNI pourra être différente pour chaque opération ou bien commune à plusieurs opérations d’une même catégorie.

Il est en effet déconseillé qu’une même fonction de thread implémente les

traitements relatifs à des opérations de catégorie différente.

4. Choix structurels UE Automatisme C1


4.1.3 Schéma récapitulatif de l’architecture du niveau Supervision

Processus Win32 RTX

niveau Supervision

Interface Homme – Machine (IHM)

Processus RTSS

niveau Contrôle/commande

Tâche afficheObs Elle prépare pour l’IHM l’affichage :

de l’état du système et de la PO,

des messages de service émis par

la tâche superviseur

Tâche superviseur Elle reçoit toutes les demandes de service

spécifiques à l’application. Elle n’exécute que les

opérations immédiates du niveau Supervision mais

supervise l’exécution de toutes les autres.

Demandes de service spécifiques à l’application

Demande

d’acquittement de

l’alarme signalée

Demandes de service conduisant à des opérations de contrôle-commande

Demande d’interruption de l’opération non

immédiate en cours

Demande de préparation de

l’affichage de l’état du

du système et de la PO

Observations sur l’état de la PO et de l’automate.

Alarme à signaler à l‘opérateur

Tâche

realiseOpSvisionNI

Traitements relatifs à une opération non

immédiate du niveau Supervision

Traitements relatifs à la partie supervision

d’une opération non immédiate conjointe



4.1.4 Partie logicielle du système de commande

Dans notre architecture type, la partie logicielle du système de commande de la

partie opérative est constituée des éléments suivants :

le processus RTSS,

toutes les tâches (ou threads) du processus Win32 RTX, autre que le programme principal du thread primaire.

Le système de commande est en service ou en fonctionnement lorsque existent - et sont donc actifs - le processus RTSS ainsi que les tâches superviseur et afficheObs du processus Win32 RTX.

Il est à l’arrêt ou hors service lorsque sont inexistants le processus RTSS et les tâches superviseur et afficheObs. Quand le système de commande est hors service, seul donc existe

et est actif le thread primaire du processus Win32 RTX.

4.2 Choix de base relatifs aux IHM et à leur mise en oeuvre

L’architecture proposée pour les applications de contrôle-commande permet la mise en œuvre de différents types d’Interface Homme-Machine (IHM). Pourront notamment être mis en œuvre les 2 types suivants d’interaction entre l’utilisateur et l’application de contrôle-

commande :

1. Une IHM de type caractères (ou texte ou console).

L’utilisateur interagit avec l’application depuis la console, celle qui est active durant

l’exécution du fichier .exe du processus Win32 RTX.

2. Une IHM de type OPC.

L’utilisateur interagit avec l’application depuis un client OPC (développé par exemple

avec le langage graphique LabVIEW), l’application de contrôle-commande se

comportant alors comme un serveur OPC.

Le thread primaire du processus Win32 RTX et les différentes tâches du niveau

Supervision vont être structurés, et donc vont pouvoir fonctionner, de façon à permettre une interaction avec l’utilisateur à travers aussi bien une IHM de type caractères qu’une IHM de type OPC.

Dans la suite de ce document, nous allons donc considérer que pour une même application de contrôle-commande l’un ou l’autre de ces 2 types d’IHM pourra être mis en

œuvre. Le basculement d’une IHM à l’autre pourra être fait à tout moment en cours de fonctionnement de l’application, à la condition toutefois qu’aucune opération de contrôle/commande ne soit alors en cours d’exécution.

Pour l’élaboration de l’architecture logicielle type, les choix suivants ont été faits en ce

qui concerne l’IHM :

La modification du fichier texte contenant les paramètres de configuration de l’application sera toujours faite depuis la console, celle qui est active durant l’exécution du fichier .exe du processus Win32 RTX.

Après la création réussie de la partie logicielle du système de commande,

l’opérateur peut, depuis la console, choisir le type d’IHM à mettre en service : IHM de type caractères ou IHM de type OPC. L’IHM en service pourra ensuite être désactivée, et un nouveau type d’IHM choisi ; tout ceci pourra être fait sans qu’il soit nécessaire de mettre hors service le système de commande.



L’arrêt du système de commande est toujours demandée depuis la console, celle qui est active durant l’exécution du fichier .exe du processus Win32 RTX..

Une variable globale typeIHM indiquera si une IHM est effectivement en service et quel est son type :

typeIHM = AUCUNE_IHM aucune IHM n’est en service

typeIHM = IHM_CONSOLE mise en œuvre d’une IHM de type caractères

typeIHM = IHM_OPC mise en œuvre d’une IHM de type OPC

4.3 Démarrage et terminaison de l’application de contrôle-commande

4.3.1 Lancement et démarrage de l’application

Le lancement de l’application se fait depuis l’ordinateur support du système de commande en ouvrant le fichier .exe du processus Win32 RTX.

Avant la création du processus RTSS, et donc du niveau Contrôle/commande, l’opérateur a la possibilité de modifier certains paramètres de configuration de l’application. Ceci sera assuré par la fonction configureCcde() appelée par le programme principal du thread primaire. Après éventuellement avoir modifié certains paramètres de configuration,

l’opérateur demandera la création du système de commande ou la fin de l’application.

Le processus RTSS ayant été créé, et donc le niveau Contrôle/commande ayant été mis en service, l’opérateur ne pourra modifier à nouveau ces paramètres de configuration qu’après avoir demandé l’arrêt du système de commande, et donc la terminaison du processus RTSS et du niveau Supervision.

La possibilité pour l’opérateur de modifier certains paramètres de configuration de

l’application alors que celle-ci est en fonctionnement, ne lui est donc offerte que

lorsque le système de commande est à l’arrêt, c’est-à-dire hors service.

Après la création réussie du niveau Contrôle/commande, le thread primaire du

processus Win32 RTX crée et lance les tâches superviseur et afficheObs. Il attend ensuite la fin de la phase d’initialisation de ces tâches avant d’inviter l’opérateur à choisir le type d’IHM à mettre en service.

En ce point du déroulement de l’application, l’opérateur a en réalité le choix entre les

3 actions suivantes :

1. Mettre en service l’IHM de type console

2. Mettre en service l’IHM de type OPC

3. Commander l’arrêt du système de commande.

4.3.2 Arrêt du système de commande et terminaison de l’application

Le lancement de l’application se fait donc depuis l’ordinateur support d’exécution

des processus Win32 RTX et RTSS constituant l’application de contrôle-commande. Non seulement la fermeture de l’application mais également l’arrêt du système de commande seront également demandés depuis cet ordinateur à travers la fenêtre de type console qui s’est ouverte lorsque a été lancé le processus Win32 RTX, et cela quel que soit le type d’IHM effectivement mis en service.

La mise hors service du système de commande ne pourra donc jamais se faire depuis

le client OPC pilote de l’application ; elle se fera toujours depuis la console.



Comme elle se situe au même niveau que la mise en service de l’IHM, la demande d’arrêt du système de commande ne peut être faite en pratique que si aucune IHM n’est en service. Comme la désactivation de l’IHM en service ne peut intervenir tant qu’une opération est en cours, il en découle que lorsque l’opérateur a la possibilité de demander l’arrêt du système de commande, aucune opération de contrôle/commande n’est en cours d’exécution.

A la suite d’une demande d’arrêt du système de commande, le thread primaire du processus Win32 RTX :

1. Émet d’abord le signal de demande de fin du niveau Supervision en utilisant l’objet evCdeFinSvision de type event à reset manuel ; lorsqu’elles reçoivent ce

signal, les tâches superviseur et afficheObs se terminent.

2. Demande ensuite au processus RTSS de se terminer ; pour cela, il utilise l’objet evCdeFinProcessCcde de type event à reset automatique ; le processus RTSS peut effectivement se terminer car le niveau Contrôle/commande est parfaitement au repos lorsque la demande lui est adressée.

La mise hors service du système de commande se traduit donc par la fin et la destruction du processus RTSS et des tâches du niveau Supervision. Le système de commande étant hors service, l’opérateur peut ensuite, depuis la console, demander la terminaison et la fermeture de l’application, ou bien une nouvelle création du système de

commande.

4.4 Niveau de priorité des threads du processus Win32 RTX

Étant donné qu’il s’agit d’un processus Win32 RTX, ce dernier va s’exécuter dans la classe de priorité REALTIME_PRIORITY_CLASS de Windows dès qu’une fonction de la RTAPI de RTX est appelée (cf. Support de formation à RTX 8.1, § 3.3.2, p. 26).

A l’intérieur de cette classe de priorité, sont donnés aux tâches du processus Win32 RTX les indices de priorité suivants par ordre décroissant :

tâche superviseur (prioriteThreadPrimaire + 3)

tâche realiseOpSvisionNI (lors d’une opération conjointe) (prioriteThreadPrimaire + 2)

tâche afficheObs (prioriteThreadPrimaire + 1)

Le thread primaire (prioriteThreadPrimaire)

tâche realiseOpSvisionNI (lors opération de supervision) (prioriteThreadPrimaire - 1)

avec prioriteThreadPrimaire = THREAD_PRIORITY_LOWEST (= RT_PRIORITY_MIN + 1).

Le niveau de priorité donné à la tâche realiseOpSvisionNI lors de sa création dépend de la catégorie à laquelle appartient l’opération qu’elle doit traiter :

Lorsqu’il s’agit d’une opération non immédiate conjointe, la tâche realiseOpSvisionNI traite les données que le niveau Contrôle/commande lui adresse, à chaque période d’échantillonnage, au fur et à mesure du déroulement de l’opération. De ce fait, il est préférable que cette tâche ait une priorité élevée.

En pratique, son niveau de priorité sera celui immédiatement inférieur à celui de la

tâche superviseur ou bien le même puisque, alors, cette dernière ne fait qu’attendre

la fin de la tâche realiseOpSvisionNI.

Lorsqu’elle traite une opération non immédiate de niveau Supervision, il est préférable de donner à la tâche realiseOpSvisionNI, l’indice de priorité le moins

élevé de façon qu’elle ne bloque pas l’exécution des autres tâches du niveau Supervision.



Les différentes tâches du processus Win32 RTX auront donc comme indice de priorité les valeurs suivantes :

Tâches Nom de priorité symbolique Windows Nom de priorité

symbolique RTSS

superviseur THREAD_PRIORITY_ABOVE_NORMAL RT_PRIORITY_MIN + 4

realiseOpSvisionNI THREAD_PRIORITY_NORMAL RT_PRIORITY_MIN + 3

afficheObs THREAD_PRIORITY_BELOW_NORMAL RT_PRIORITY_MIN + 2

Thread primaire THREAD_PRIORITY_LOWEST RT_PRIORITY_MIN + 1

realiseOpSvisionNI THREAD_PRIORITY_IDLE RT_PRIORITY_MIN

Les niveaux de priorité à donner aux tâches du processus RTSS devront être

strictement supérieurs à RT_PRIORITY_MIN + 4.

Conclusion

Partant de l’architecture logicielle très générale donnée dans le chapitre 2 (cf. § 2.3 Choix d’une architecture logicielle type), nous avons, dans ce chapitre, précisé les choix structurels de cette architecture logicielle type, notamment en ce qui concerne le niveau Supervision.

Ceci a été fait en prenant tout particulièrement en compte :

1. les différentes catégories d’opérations susceptibles d’être implémentées dans une application de contrôle-commande ;

2. les ordres de l’opérateur que l’on retrouve dans toute application de contrôle-

commande ;

3. l’implémentation d’une IHM de type caractères et d’une IHM de type OPC, avec possibilité de mise en service de l’une ou de l’autre et même de basculement de l’une à l’autre lorsque aucune opération de contrôle/commande est en cours d’exécution.

Dans les chapitres suivants, nous allons de plus en plus détailler la mise en œuvre de cette architecture logicielle type.



Annexe : A propos du développement et du déploiement d’une application

En ce qui concerne le développement d’une application de contrôle-commande et ensuite son déploiement sur l’ordinateur support de son exécution, un certain nombre de

choix pratiques ont également été faits.

Développement d’une application de contrôle/commande

Un projet Visual Studio C++ distinct sera créé pour chacun des processus Win32 RTX et RTSS.

Ceci est impératif puisque pour le processus Win32 RTX, il s’agit d’une

application Win32 de type console (Win32 Console Application), et pour le

processus RTSS, d’une application RTSS créée en utilisant le RTX Application Wizard (cf. Support de formation à RTX 8.1, § 2.3.2, p. 16) .

Le nom donné à ces 2 projets Visual Studio C++ sera ainsi formé :

pour le processus Win32 RTX : nomApplication_win32

pour le processus RTSS : nomApplication_rtss

Il a été fait choix que pour chaque processus ne serait créé qu’un seul fichier source : un fichier .c contiendrait l’ensemble des déclarations et du code programme.

Pour en faciliter la lecture, ce fichier sera cependant découpé en sections. Ainsi la première section du fichier source de chacun des 2 processus comportera toutes les

déclarations relatives aux objets IPC communs au processus Win32 RTX et au processus RTSS.

Il est important de noter que dans les 2 fichiers source ces déclarations

relatives aux objets IPC communs aux 2 processus seront strictement

identiques ; la section 1 du fichier source du processus RTSS sera donc une

simple copie de la section 1 du fichier source du processus Win32 RTX.

Déploiement d’une application de contrôle/commande

Tous les fichiers relatifs à l’application seront rangés dans un dossier portant le

nom de l’application.

Ce dossier contiendra :

1. le fichier exécutable correspondant au processus Win32 RTX, c’est-à-dire le fichier portant le nom : nomApplication_win32.exe

2. le fichier exécutable correspondant au processus RTSS, c’est-à-dire le fichier portant le nom : nomApplication_rtss.rtss

3. un sous dossier intitulé configuration contenant tous les fichiers de configuration de l’application

4. un sous dossier intitulé enregistrement dans lequel seront créés tous les fichiers des données E/S acquises lors d’opérations de contrôle-commande.

UE Automatisme C1 (AUT209) 5. Communication entre IHM et tâches de supervision


5. Synchronisation et communication entre l’IHM et le cœur de l’application

Nous devons apporter un soin tout particulier à la définition de la synchronisation et de la communication entre l’IHM et le cœur de l’application. En effet, suite aux choix structurels qui ont été faits, nous voulons qu’à l’intérieur de la même application soit

implémentée une IHM de type caractères et une IHM de type OPC.

Pour éviter que les différentes tâches du niveau Supervision et du niveau Contrôle/commande aient à tenir compte dans leurs échanges avec l’opérateur du type d’IHM effectivement en service à ce moment-là, il est nécessaire de définir entre l’IHM et le coeur de

l’application une interface qui masque vis-à-vis du cœur de l’application les caractéristiques de ces 2 types d’IHM, et donc qui permette au cœur de l’application d’ignorer quel est le type d’IHM effectivement en service.

Notons cependant dès maintenant que cet objectif ne sera pas totalement atteint :

la tâche afficheObs devra en effet à un moment donné tester la variable typeIHM

pour savoir si c’est l’IHM de type console qui est en service.

La structuration des échanges entre l’IHM et le cœur de l’application de contrôle-

commande a été faite de façon que l’interaction avec l’utilisateur puisse se faire à travers aussi bien une IHM de type caractères qu’une IHM de type OPC (cf. § 4.2 Choix de base relatifs aux IHM et à leur mise en œuvre). Ceci a conduit à la définition suivante de l’interface entre l’IHM et le cœur de l’application.

Mais avant de décrire cette interface, nous allons d’abord préciser les modes de synchronisation et la nature des informations échangées entre les 3 entités suivantes : l’IHM, la tâche superviseur et la tâche afficheObs, puis présenter les mécanismes mis en œuvre pour assurer cette synchronisation et cette communication.

IHM de type console IHM de type OPC

Interface entre

les différents types d’IHM et le cœur de l’application

Cœur de l’application

5. Communication entre IHM et tâches de supervision UE Automatisme C1


5.1 Modes de synchronisation et nature des informations échangées

La tâche superviseur reçoit toutes les demandes de service spécifiques à l’application.

Elle ne peut recevoir et donc traiter une nouvelle demande de service tant qu’elle n’a pas adressé à l’IHM (via la tâche afficheObs) un compte-rendu de fin d’exécution de la précédente demande de service qui lui a été adressée.

La tâche afficheObs transmet à l’IHM sous une forme appropriée, exploitable par

cette dernière, c’est-à-dire le plus souvent sous forme de messages textuels (chaînes de caractères) :

d’une part, les messages de service générés à l’intention de l’IHM par la tâche superviseur,

d’autre part, l’état de l’automate et de la partie opérative (informations transmises

périodiquement à la tâche afficheObs par le niveau Contrôle/commande).

La communication entre l’IHM, la tâche superviseur et la tâche afficheObs peut être ainsi schématisée :

5.1.1 Procédure de traitement d’une demande de service

Pour toute demande de service adressée à la tâche superviseur, la procédure de traitement suivante a été adoptée :

1. Si la demande de service est acceptée, la tâche superviseur transmet à la tâche

afficheObs le code de l’opération déclenchée à la suite de cette demande.

2. A partir de la valeur de ce code, la tâche afficheObs génère un message textuel et transmet ce dernier à l’IHM sous une forme appropriée au type d’IHM en service.

3. En cas de refus de la demande de service ou à la fin normale ou avortée de

l’opération déclenchée, la tâche superviseur génère un code de compte rendu et le transmet à la tâche afficheObs.

4. A partir de la valeur de ce code, la tâche afficheObs prépare un message textuel et transmet ce dernier à l’IHM sous une forme appropriée au type d’IHM en service.

5. Après avoir affiché le texte de ce message de compte-rendu, l’IHM adresse à la

tâche superviseur, soit automatiquement soit sur ordre de l’opérateur, un signal d’acquittement.

Interface Homme machine (IHM)

tâche superviseur tâche afficheObs

Messages textuels prêts

à être affichés par l’IHM

Demandes de service spécifiques à l’application

Demande de préparation de l’affichage de l’état

du système et de la PO

Demandes de préparation de messages destinés à

l’opérateur



6. C’est seulement après avoir émis ce signal d’acquittement du message de compte rendu que l’IHM pourra adresser une nouvelle demande de service à la tâche superviseur.

Lorsqu’une opération a été interrompue à la suite d’une alarme ou d’une erreur quelconque détectée lors de l’exécution de l’opération, la tâche superviseur précise le code de

cette alarme à la tâche afficheObs de façon que celle-ci puisse générer le texte descriptif de l’alarme en même temps que le message textuel de compte rendu de l’opération interrompue.

5.1.2 Procédure de traitement d’une demande de préparation de l’affichage

Lorsque l’IHM n’est pas en mesure d’afficher en permanence l’état de la partie

opérative et du système de commande, elle donne la possibilité à l’opérateur de demander ponctuellement l’affichage de telles informations, et ce, même lorsqu’une opération non immédiate est en cours d’exécution.

Lorsque l’opérateur demande l’affichage de l’état de la partie opérative et du système

de commande, la procédure suivante est déclenchée :

1. L’IHM transmet la demande à la tâche afficheObs puis attend le message contenant le texte à afficher.

2. A la réception de cette demande, la tâche afficheObs prépare le message textuel (la chaîne de caractères) qui contiendra la valeur des variables d’état de la partie

opérative et du système de commande, informations que le niveau Contrôle/commande lui transmet périodiquement.

3. La tâche afficheObs transmet ensuite à l’IHM un message contenant le texte à afficher.

5.2 Communication entre IHM, tâche superviseur et tâche afficheObs

5.2.1 Synchronisation et communication entre l’IHM et la tâche superviseur

De la procédure décrite précédemment (cf. § 5.1.1), on en déduit la mise en œuvre suivante pour ce qui concerne la communication entre l’IHM et la tâche superviseur.

Interface Homme machine (IHM)

tâche superviseur

Code de la demande de service :

int codeDdeService ;

Paramètres des demandes de service :

…

declencherDdeService()

acquitterCRddeService()



Après avoir rangé le code et les paramètres de la demande de service dans des variables globales partagées, l’IHM signale à la tâche superviseur une nouvelle demande de service à traiter. Pour cela, elle appelle la fonction declencherDdeService().

En raison de la synchronisation des opérations de lecture et d’écriture, et plus

généralement de la procédure précédemment décrite de traitement d’une demande

de service, il n’est pas nécessaire de protéger l’accès à ces variables partagées par

un objet de type sémaphore d’exclusion mutuelle.

L’IHM émet le signal d’acquittement en direction de la tâche superviseur en appelant la fonction acquitterCRddeService() :

soit, immédiatement après avoir reçu le message textuel de compte rendu à sa demande de service (il s’agit alors d’un acquittement automatique) ;

soit, après que l’opérateur a acquitté ce message textuel de compte rendu (il s’agit

alors d’un acquittement manuel, c’est-à-dire sur ordre explicite de l’opérateur).

5.2.2 Synchronisation et communication entre la tâche superviseur et la tâche afficheObs

De la procédure décrite précédemment (cf. § 5.1.2), il ressort que la tâche superviseur doit transmettre à la tâche afficheObs tout changement de valeur de l’une ou l’autre des trois variables d’état suivantes :

1. codeOpEnCours : code de l’opération en cours

2. codeCRddeService : code du compte rendu à une demande de service

3. causeItOpEnCours : code de la cause de l’éventuelle interruption de l’opération en cours.

Il est à noter que c’est la tâche afficheObs, et non la tâche superviseur, qui

modifiera la valeur de ces variables.

Lorsque l’opération en cours a été interrompue puis annulée à la suite de l’apparition

d’une alarme, est associé au code du compte-rendu à la demande de service celui de

la cause de cette interruption.

Le mécanisme le plus approprié pour cette communication d’informations entre la

tâche superviseur et la tâche afficheObs est celui d’une communication par messages. Un message est envoyé à la tâche afficheObs chaque fois que l’une ou l’autre de ces variables doit faire l’objet d’un changement de valeur, y compris lorsqu’il s’agit d’une remise à zéro.

Comme les changements de valeur des variables codeCRddeService et

causeItOpEnCours ont toujours lieu au même instant, il suffit de définir les 2 structures de message suivantes :

Code du message Paramètre 1 Paramètre 2

CODE_OpEnCours Valeur à donner à

codeOpEnCours 0

CODE_CRddeService Valeur à donner à

codeCRddeService Valeur à donner à

causeItOpEnCours

La valeur à donner à causeItOpEnCours est celle qui été transmise à la tâche

superviseur par le niveau Contrôle/commande ou par la tâche realiseOpSvisionNI.

Chaque message généré par la tâche superviseur est rangé dans une boite aux lettres à laquelle est associée de façon permanente et exclusive la tâche afficheObs. Il s’agit donc d’une porte de la tâche afficheObs ; d’où son nom : BALafficheObs.



La lecture de cette boite aux lettres sera effectuée périodiquement par la tâche afficheObs. Ainsi, jamais cette dernière ne se mettra en attente de l’arrivée d’un message. L’implémentation de cette boite aux lettres sera donc celle décrite au § 8.2.4 du support de cours de l’UE AUT107 sur les Systèmes temps réel multitâches (année 2008-2009).

5.2.3 Synchronisation et communication entre l’IHM et la tâche afficheObs

Communication dans le sens IHM vers tâche afficheObs

Si l’on considère la communication dans le sens IHM vers tâche afficheObs, cette dernière ne reçoit de l’IHM qu’un seul ordre, celui de préparer l’affichage de l’état de la partie opérative et du système de commande.

Pour transmettre cet ordre à la tâche afficheObs, le plus simple pour l’IHM est de générer un message qu’elle rangera ensuite dans la boite aux lettres BALafficheObs. Ce message aura la structure suivante :

Code du message Paramètre 1 Paramètre 2

DDE_IHM_EtatCcde noEnsemble 0

Le paramètre noEnsemble correspond au numéro du sous ensemble de variables

d’état pour lesquelles l’IHM souhaite la préparation de l’affichage.

Le paramètre 2 pourra éventuellement être utilisé pour indiquer le type de format

désiré pour cet affichage.

Communication dans le sens tâche afficheObs vers IHM

En ce qui concerne la communication dans le sens tâche afficheObs vers IHM, il est nécessaire de prendre en compte le type d’IHM en service.

Cas d’une IHM de type console

S’il s’agit d’une IHM de type console, la communication dans le sens tâche afficheObs vers IHM se fera également par messages en utilisant une boite aux lettres comme objet

intermédiaire. Cette boite aux lettres sera une porte de la tâche implémentant l’IHM de type console, c’est-à-dire le thread primaire, BALconsole étant le nom donné à cette porte. La tâche afficheObs envoie un message à l’IHM uniquement lorsqu’un message textuel (c’est-à-dire une chaîne de caractères) doit être affiché sur la console.

Lors de l’exécution d’une opération, l’IHM de type console testera la présence de

messages dans la boite aux lettres. L’implémentation de cette boite aux lettres sera celle correspondant à la variante 1 décrite aux § 8.2.4 du support de cours sur les Systèmes temps réel multitâches (année 2008-2009).

On définit les 5 structures de message suivantes :

Code du message Paramètre

AFF_TEXTE_OpEnCours Adresse de texteOpEnCours

AFF_TEXTE_CRddeServiceOK Adresse de texteCRddeService

AFF_TEXTE_CRddeServiceERR Adresse de texteCRddeService

AFF_TEXTE_EtatCcde Adresse de texteEtatCcde

AFF_TEXTE_AlarmeCcde Adresse de texteAlarmeCcde



Le tableau ci-après précise la signification des 4 variables de type chaine de

caractères.

Variable Signification de la variable

texteOpEnCours Texte décrivant l’opération en cours d’exécution

texteCRddeService Texte donnant le compte rendu à la demande de service faite par l’opérateur, avec éventuellement la description de l’alarme à l’origine de l’interruption de l’opération

texteEtatCcde Texte décrivant l’état actuel de la partie opérative et du système de commande

texteAlarmeCcde Texte décrivant la nature de l’alarme signalée

Cas d’une IHM de type OPC

Aucun mécanisme particulier de communication autre que la communication par variables communes ne sera mis en place entre la tâche afficheObs() et l’IHM de type OPC.

La mise à jour des items en lecture sera faite par la fonction gestionIHMopc() à partir de la valeurs des variables donnant l’état de la partie opérative et du système de commande.

Synchronisation entre la tâche afficheObs et l’IHM

A la fin de chacune de ses exécutions périodiques, la tâche afficheObs émet un signal

en direction de l’IHM en service. L’implémentation de ce signal sera faite à l’aide de l’objet evReveilIHM de type event à reset automatique. Cet objet sera donc mis dans l’état signalé à la fin de chacune des exécutions périodiques de la tâche afficheObs.

Dans le cas d’une IHM de type console, la fonction gestionIHMconsole() utilise ce signal pour synchroniser la lecture qu’elle doit faire de la boite aux lettres BALconsole.

Dans le cas d’une IHM de type OPC, ce signal informe la fonction gestionIHMopc() qu’une mise à jour des variables d’état vient d’être faite, et que donc les items en lecture qui leur correspondent doivent aussi voir leur valeur mise à jour.

5.3 Structure de l’interface entre l’IHM et le cœur de l’application

L’interface entre les différents types d’IHM et le cœur de l’application se compose des

éléments suivants :

une variable indiquant, notamment à la tâche afficheObs, le type d’IHM effectivement en service (typeIHM).

3 structures de données : la 1ère constituée des données mises à jour par l’IHM, la

2ème constituée de celles mises à jour par la tâche afficheObs et la 3ème constituée des autres variables requises pour la gestion de cette interface.

un ensemble de 6 fonctions appelées par l’IHM, qu’il s’agisse d’une IHM de type console ou d’une IHM de type OPC (cf. § 5.4 Les fonctions d’interface appelées par l’IHM).

Le schéma de la page suivante représente les différents éléments constituant cette interface entre l’IHM et le cœur de l’application.

Il apparaît que la tâche afficheObs transmet sous des formes différentes à l’IHM les informations qu’elle doit lui communiquer, suivant qu’il s’agit d’une IHM de type console ou d’une IHM de type OPC.



IHM de type OPC

Code de la demande de service :

int codeDdeService ;

Paramètres des demandes de service :

…

Autres variables de l’interface entre IHM et les tâches superviseur et afficheObs :

Type de l’IHM en service : int typeIHM

Type de l’opération en cours : int typeOpEnCours ;

Pointeur sur les données à MAJ (cas d’une opération NIO) : int *pDataOpNIO ;

Indicateur de mise à jour des VE textuelles : signed char iMAJtexte[6] ;

Période en ms de màj des variables associéex aux items L : int periodeMajVarEnL ;

Variables donnant l'état de la PO et du système de commande :

1) Variables non spécifiques à l'application :

byte etatPO; char texteEtatPO[ ];

byte ssEtatPO; char texteSsEtatPO[ ];

byte alarmeCcde; char texteAlarmeCcde[ ]; byte codeOpEnCours; char texteOpEnCours[ ];

byte codeCRddeService; char texteCRddeService[ ];

byte causeItOpEnCours;

char texteEtatCcde[ ];

2) variables spécifiques à l'application :

…

BALconsole

tâche superviseur tâche afficheObs

BALafficheObs

declencherDdeService()

acquitterCRddeService()

preparerAffichageEtat() arreterOpNIenCours()

acquitterAlarme() mettreAJourDataOpNIO()

Messages envoyés par

la tâche afficheObs

Messages envoyés par l’IHM

et par la tâche superviseur

Mise à jour

Mise à jour

IHM de type console

evReveilIHM



5.4 Les fonctions d’interface appelées par l’IHM

Au nombre de six, ces fonctions qui permettent la communication entre l’IHM et

l’application proprement dite présentent les caractéristiques communes suivantes :

à l’exception de la fonction mettreAJourDataOpNIO(), elles sont appelées à la suite d’un ordre de l’opérateur ;

l’exécution de chacune d’elles donne lieu à l’émission d’un signal en direction du

cœur de l’application ;

la fonction retourne la valeur TRUE si l’opération indiquée dans le nom même de la fonction a pu être réalisée ; dans le cas contraire la fonction retourne FALSE.

Pour éviter l’émission intempestive de signaux en direction du cœur de l’application, l’exécution de l’opération indiquée par le nom même de la fonction n’est exécutée que si

cette opération est attendue, ou du moins que si le système de commande est dans un état tel que l’exécution de l’opération ait un sens pour l’application.

5.4.1 Description des 6 fonctions

La fonction declencherDdeService()

Cette fonction est appelée par l’IHM lorsque, l’opérateur déclenche une demande de service spécifique à l’application.

Comme d’une demande de service à l’autre la valeur de ces paramètres est conservée,

l’opérateur peut déclencher une nouvelle demande de service sans avoir à renseigner

tous les paramètres de la demande, mais seulement ceux dont la valeur a changé.

La fonction declencherDdeService() utilise l’objet evDdeService de type event à reset manuel pour signaler à la tâche superviseur la demande, de la part de l’opérateur, d’une nouvelle demande de service.

Organigramme général de la fonction declencherDdeService()

Si état de l’objet evDdeService = non signalé alors :

Mettre l’objet evDdeService dans l’état signalé

Retourner TRUE

sinon

Retourner FALSE

finSi

A la fin du traitement d’une demande de service, l’objet evDdeService est remis dans l’état non signalé par la tâche superviseur.

Ainsi, durant tout le traitement d’une demande de service, l’objet evDdeService

reste dans l’état signalé, bloquant ainsi toute transmission d’une nouvelle demande de

service à la tâche superviseur.

La fonction mettreAJourDataOpNIO()

Lors de l’exécution d’une opération non immédiate ouverte, périodiquement des paramètres de l’opération doivent être mis à jour. Lorsque cette mise à jour est assurée par l’IHM, cette fonction lui permet de signaler à l’application chacune de ces mises à jour.

Chaque mise à jour effective de ces paramètres est signalée au cœur de l’application en utilisant l’objet evMAJOpNIO de type event à reset automatique.



Organigramme général de la fonction mettreAJourDataOpNIO()

Si typeOpEnCours = OP_NIO alors :

*pDataOpNIO := pcVmanu (par exemple)

Mettre l’objet evMAJOpNIO dans l’état signalé

Retourner TRUE

sinon

Retourner FALSE

finSi

La fonction arreterOpNIenCours()

Une opération non immédiate peut être arrêtée par l’opérateur. Lorsque l’opérateur

commande l’arrêt de l’opération non immédiate en cours, l’IHM appelle cette fonction pour transmettre l’ordre au cœur de l’application en utilisant l’objet evDdeItOpNI de type event à reset automatique.

Organigramme général de la fonction arreterOpNIenCours()

Si typeOpEnCours = OP_NIF OU typeOpEnCours = OP_NIO alors :

Mettre l’objet evDdeItOpNI dans l’état signalé

Retourner TRUE

sinon

Retourner FALSE

finSi

La fonction acquitterCRddeService()

Après que la tâche superviseur (via la tâche afficheObs) a transmis à l’IHM un compte-rendu à la demande de service qui lui a été adressée, la tâche superviseur attend, de

la part de l’IHM, un acquittement de ce compte-rendu pour considérer que cette demande de service a été définitivement traitée.

L’IHM émet le signal d’acquittement en direction de la tâche superviseur en utilisant l’objet evAcquitCRddeService de type event à reset automatique. Ce signal n’est émis que si

la tâche superviseur a transmis un message de compte-rendu (codeCRddeService <> 0).

Organigramme général de la fonction acquitterCRddeService()

Si codeCRddeService <> 0 alors :

Mettre l’objet evAcquitCRddeService dans l’état signalé

Retourner TRUE

sinon

Retourner FALSE

finSi

La fonction preparerAffichageEtat()

Si, périodiquement ou ponctuellement à la demande de l’opérateur, l’IHM désire afficher tout ou partie de l’état de la partie opérative et du système de commande, elle

demande à l’application la préparation de la chaîne de caractères à afficher en appelant la fonction preparerAffichageEtat().



Comme décrit au § 5.2.3, cette demande se fait en envoyant à la tâche afficheObs un message DDE_IHM_EtatCcde avec, pour le paramètre 1, le numéro du sous ensemble de variables d’état considéré.

Pour éviter une émission intempestive de ce message – ce qui pourrait avoir pour conséquence de saturer la boite aux lettres BALafficheObs - est mis en œuvre un mécanisme

qui empêche qu’un nouveau message DDE_IHM_EtatCcde ne soit rangé dans la boite aux lettres si le précédent message DDE_IHM_EtatCcde s’y trouve encore. Ce mécanisme de régulation d’envoi des messages DDE_IHM_EtatCcde est inclus dans la gestion même de la boite aux lettres BALafficheObs.

Voir au sujet de cette variante de gestion d’une boite aux lettres, le § 8.2.4 du

support de cours sur les Systèmes temps réel multitâches (année 2008-2009).

Organigramme général de la fonction preparerAffichageEtat()

Si envoyerMessageBALafficheObs (DDE_IHM_EtatCcde, noEnsemble, 0) = TRUE alors :

Retourner TRUE

sinon

Retourner FALSE

finSi

La fonction acquitterAlarme()

Toute alarme qui lui est signalée doit être acquittée par l’opérateur. Lorsque

l’opérateur demande l’acquittement de l’alarme qui vient de lui être signalée (alarmeCcde

<> 0), l’IHM appelle cette fonction pour transmettre l’acquittement au cœur de l’application.

Cet acquittement est transmis en utilisant l’objet evAcquitAlarme de type event à reset automatique.

Organigramme général de la fonction acquitterAlarme()

Si alarmeCcde <> 0 alors :

Mettre l’objet evAcquitAlarme dans l’état signalé

Retourner TRUE

sinon

Retourner FALSE

finSi

5.4.2 Liens entre les 6 fonctions et le serveur OPC (cas d’une IHM de type OPC)

Le tableau ci-après précise les liens entre les 6 fonctions décrites précédemment et la base de données exposée par le serveur OPC lorsque une IHM de type OPC est en service. Il indique dans quelles circonstances est appelée chacune de ces 6 fonctions.

Il ressort de ce tableau que :

3 fonctions sont appelées à la suite de la réception d’un signal de commande ; il

s’agit des fonctions : arreterOpNIenCours(), acquitterCRddeService() et

acquitterAlarme()

3 fonctions sont appelées lorsque tous les items d’une branche ou seulement certains d’entre eux ont été mis à jour par le client OPC pilote de l’application ou

par un client OPC quelconque ; il s’agit des fonctions : declencherDdeService(),

mettreAJourDataOpNIO() et preparerAffichageEtat().



Fonction IHM de type OPC

declencherDdeService () Fonction appelée lorsque tous les items en écriture

correspondant aux paramètres d’une demande de service ont

été mis à jour par le client OPC pilote de l’application.

mettreAJourDataOpNIO () Fonction appelée lorsque ont été mis à jour les items

correspondant aux données nécessaires à l’exécution de

l’opération non immédiate ouverte en cours.

arreterOpNIenCours () Fonction appelée lorsque le signal de commande

arreterOpNIenCours a été émis par le client OPC pilote de

l’application.

acquitterCRddeService () Fonction appelée lorsque le signal de commande

acquitterCRddeService a été émis par le client OPC pilote de

l’application.

preparerAffichageEtat () Fonction appelée lorsque a été mis à jour par un client OPC

quelconque l’item correspondant à la variable noEnsemble.

acquitterAlarme () Fonction appelée lorsque le signal de commande

acquitterAlarme a été émis par le client OPC pilote de

l’application.

Conclusion

Pour ce qui concerne la synchronisation et la communication dans le sens IHM vers le cœur de l’application, les 6 fonctions décrites au § 5.4 et la 1ère structure de données (celle des données mises à jour par l’IHM) permettent de masquer totalement vis-à-vis du coeur de application les caractéristiques de différents types d’IHM. Ainsi la tâche superviseur ne sait

pas à partir de quel type d’IHM l’opérateur lui adresse les demandes de service.

Par contre, pour ce qui concerne la communication dans le sens cœur de l’application vers IHM, la tâche afficheObs doit savoir si c’est l’IHM de type console qui est effectivement en service pour lui envoyer les messages textuels qui doivent être affichés.

****************

UE Automatisme C1 (AUT209) 6. Synchronisation et communication entre les 2 processus


6. Synchronisation et communication entre les 2 processus

Nous allons décrire en détail dans ce chapitre les mécanismes de synchronisation et de communication à mettre en place entre le processus Win32 et le processus RTSS.

Il est important de rappeler que ces deux processus ne peuvent synchroniser leur

activité et échanger de l’information qu’en utilisant les types d’objets IPC1 que propose RTX, à savoir des objets RTSS de type shared memory, semaphore, mutex ou event. Ces objets utilisés pour la synchronisation et la communication entre les 2 processus seront donc des objets RTSS et non des objets Win32. De ce fait, le processus Win32 sera nécessairement un

processus Win32 RTX, c’est-à-dire un processus qui s’exécute dans l’environnement Win32 mais qui fait appel à l’API temps réel (RTAPI) de RTX.

Les mécanismes nécessaires à la synchronisation et communication entre le processus Win32 RTX et le processus RTSS peuvent être décrits en considérant qu’il y a 4 canaux de communication à créer et à gérer entre ces 2 processus :

1. Canal 1 : Paramètres de configuration et compte-rendu de mise en service du niveau Contrôle/commande

Lorsque le processus Win32 RTX crée et démarre le processus RTSS, il doit transmettre à ce dernier les paramètres de configuration du niveau Contrôle/commande. En retour, à la fin de la phase de création et de mise en service de ce niveau Contrôle/commande, le processus RTSS envoie un message de compte-rendu

au processus Win32 RTX.

La demande faite au processus RTSS de se terminer après avoir mis hors service le niveau Contrôle/commande transitera également par ce canal.

2. Canal 2 : Ordres donnés par le niveau Supervision au niveau Contrôle/commande et compte-rendu des opérations de contrôle-commande réalisées

Lorsque le niveau Contrôle/commande est en service, le processus Win32 RTX doit transmettre au processus RTSS les ordres donnés par le niveau Supervision (ordres dont en définitive l’opérateur est à l’origine), et en retour recevoir du processus RTSS les messages de compte-rendu pour les opérations de contrôle-commande réalisées.

3. Canal 3 : Données E/S acquises lors d’une opération de contrôle-commande

Lors d’opérations non immédiates conjointes, le niveau Contrôle/commande doit transmettre au niveau Supervision des données E/S acquises au cours de l’opération.

4. Canal 4 : Observations de la partie opérative et état de l’automate de commande

Durant tout le temps où il est en service, le niveau Contrôle/commande doit transmettre

périodiquement au niveau Supervision l’état de la partie opérative et de l’automate de commande.

La mise en œuvre de chacun de ces 4 canaux d’échanges entre le processus Win32 RTX et le processus RTSS va être décrite en détail dans la suite de ce chapitre.

1 IPC = interprocessus communication

6. Synchronisation et communication entre les 2 processus UE Automatisme C1


6.1 Canal 1 : Paramètres et compte-rendu de configuration du niveau Ccde

Sur ce canal d’échanges, les échanges d’informations se font par modification et

consultation de variables communes. Pour chacune de ces variables, le thread primaire du processus Win32 RTX et le thread primaire du processus RTSS sont successivement le rédacteur et le lecteur.

(cf. § 8.1.2 Communication par variables communes : exemple 2 du Support de

cours sur les Systèmes temps réel multitâches (année 2008 – 2009), pp. 82 – 84)

Processus Win32 RTX Thread primaire Rédacteur des paramètres de configuration

Lecteur du message de compte-rendu

Processus RTSS : Thread primaire Lecteur des paramètres de configuration Rédacteur du message de compte-rendu

evCRprocessCcde

evCdeFinProcessCcde

MPprocessCcde

(objet SharedMemory)

Paramètres de configuration du niveau

contrôle/commande :

(spécifiques à chaque application)

Compte-rendu de l’opération de configuration et

initialisation du niveau contrôle/commande :

int codeCRConfigCcde ; char texteCRConfigCcde [160] ;

Identification du processus RTSS implémentant

le niveau contrôle/commande :

char versionLogiciel [80] ;



Avant de créer et démarrer le processus RTSS, le processus Win32 RTX définit les paramètres de configuration du niveau Contrôle/commande. C’est à partir de la valeur de ces paramètres que le thread primaire du processus RTSS va réaliser la création et la mise en service du niveau Contrôle/commande.

Le thread primaire du processus RTSS signale la fin normale ou avortée de

l’opération de configuration et mise en service du niveau Contrôle/commande après avoir renseigné les variables de compte–rendu de cette opération. Pour effectuer cette signalisation il utilise l’objet evCRprocessCcde de type event à reset automatique.

La variable codeCRConfigCcde peut prendre les 2 valeurs suivantes :

CONFIG_CCDE_OK

CONFIG_CCDE_ERR

L’objet evCdeFinProcessCcde de type event à reset automatique est utilisé par le thread primaire du processus Win32 RTX pour demander au processus RTSS de mettre hors service le niveau Contrôle/commande puis de se terminer.

Comme cela a été précisé dans le paragraphe 4.3.2 Arrêt du système de commande et

terminaison de l ’application, la demande faite au processus RTSS de mettre hors service le niveau Contrôle/commande puis de se terminer ne peut intervenir que lorsque aucune opération de contrôle/commande n’est en cours. Il n’est donc pas nécessaire au niveau du processus RTSS de prévoir le cas où l’état du système de commande interdirait sa mise hors

service.



6.2 Canal 2 : Ordres et compte rendus relatifs aux opérations de Ccde

Sur ce canal, les échanges d’informations se font selon le schéma de communication

client/serveur. Nous avons un client : la tâche superviseur, et un serveur : la tâche automate.

(cf. § 8.4 Communication entre plusieurs clients et un serveur du Support de cours

sur les Systèmes temps réel multitâches (année 2008 – 2009) : § 8.4.1 à § 8.4.4)

Processus Win32 RTX Tâche superviseur Client de la tâche automate

Processus RTSS : Tâche automate Serveur de la tâche superviseur

semaPCRCcde

MP_SupervisionCcde


Code de la demande de service adressée au niveau

Contrôle/commande :

int codeOrdreCcde ;

Paramètres de chaque demande de service : (spécifiques à chaque application)

Message de compte-rendu de l’opération réalisée :

int codeCRCcde ; int causeItOp ; int vCR_etatPO ; int vCR_ssEtatPO ;

evOrdreCcde

evMAJOpNIO

evDdeItOpNI

IHM

Message d’acceptation ou de refus de la demande

de service : int codePCcde ; int typeOpCcde;

int causeRefus ; int vPC_etatPO ; int vPC_ssEtatPO ;



6.2.1 A propos des messages de demande de service

Le code de l’ordre adressé par la tâche superviseur à la tâche automate est rangé dans

la variable codeOrdreCcde de la mémoire partagée MP_SupervisionCcde. Le code des opérations de contrôle-commande reconnues et traitées par l’automate est propre à chaque application. Cependant, chaque demande de service adressée à l’automate donne lieu à l’exécution d’une opération appartenant nécessairement à l’un des 3 types suivants :

1. opération immédiate de contrôle-commande

2. opération non immédiate (ouverte ou fermée) de contrôle-commande

3. opération non immédiate (ouverte ou fermée) conjointe

Découlant des choix structurels initiaux que l’application ne peut, à un instant donné, traiter qu’une seule opération, la tâche automate ne peut recevoir une nouvelle demande de

service de la part de la tâche superviseur qu’après lui avoir adressé le message de compte-rendu indiquant la fin de l’opération relative à la précédente demande de service.

6.2.2 Informations nécessaires à la réalisation d’une opération non immédiate ouverte

Pour la réalisation d’une opération non immédiate ouverte, certaines informations doivent être transmises au niveau Contrôle/commande tout au long du déroulement de

l’opération. Ces informations pourront provenir du niveau Supervision ou bien seront directement acquises par le niveau Contrôle/commande à travers une interface d’entrée/sortie (donc sans intervention du niveau Supervision).

Par exemple, dans le cas d’une opération de commande « manuelle » d’un axe, la

position du joystick pourra être transmise au niveau Contrôle/commande par la

processus Win32 RTX ou bien être directement acquise par lui, par exemple, à

travers une liaison série, sans intervention du niveau Supervision.

Pour le cas où ces informations doivent être transmises au niveau Contrôle/commande par le niveau Supervision, il est nécessaire de disposer pour cela d’un mécanisme de transmission. A cette fin, on met en oeuvre une communication par variables partagées, mais avec synchronisation des opérations de mise à jour et de lecture de façon à s’affranchir des

problèmes de conflit d’accès aux variables partagées. On prévoit donc un objet de type event à reset automatique : l’objet evMAJOpNIO. Le processus Win32 RTX utilisera cet objet pour signaler au niveau Contrôle/commande chaque mise à jour de variables implantées dans la zone de mémoire partagée MP_SupervisionCcde, ces variables contenant les informations dont a besoin le niveau Contrôle/commande lors du déroulement de l’opération non

immédiate ouverte en cours.

La mise à jour de ces informations ainsi que sa signalisation avec l’objet

evMAJOpNIO ne sont pas assurées par la tâche superviseur mais par l’IHM.

6.2.3 Interruption d’une opération non immédiate de contrôle-commande

Une opération non immédiate de contrôle-commande est une opération qui, du fait qu’elle demande un certain temps pour être réalisée, peut être interrompue par l’opérateur. Qu’il s’agisse d’une opération non immédiate fermée ou d’une opération non immédiate ouverte, l’interface homme machine demande l’interruption de l’opération non immédiate en cours en envoyant un signal ; pour cela elle utilise un objet spécifique de type event à reset

automatique : l’objet evDdeItOpNI.



La réception de ce signal est interprétée de la façon suivante par la tâche automate :

Si l’opération non immédiate en cours est une opération fermée, on considère qu’une situation anormale du point de vue de l’opérateur a conduit celui-ci à demander l’interruption de l’opération : l’automate déclenche alors une alarme, l’alarme AL_ordreItOpNIF, dont le traitement va effectivement conduire à l’arrêt

et à l’annulation de l’opération en cours, et qui, comme toute alarme, devra ensuite être acquittée par l’opérateur.

Si l’opération non immédiate en cours est une opération ouverte, on considère que l’opérateur demande simplement l’arrêt de l’opération ; l’automate, dans ce

cas, ne déclenche pas d’alarme.

La demande d’interruption de l’opération non immédiate en cours est implémentée

simplement à l’aide d’un objet spécifique de type event puisque d’une part aucune

information n’est à transmettre à cette occasion au niveau Contrôle/commande, et que

d’autre part ce dernier n’a pas de message de compte-rendu à donner au sujet de la prise

en compte ou non de cette demande d’interruption (une telle demande est ignorée s’il n’y a

aucune opération non immédiate en cours).

6.2.4 Les messages de prise en compte et de compte-rendu

Pour toutes les demandes de service qu’elle reçoit, que celles-ci donnent lieu à l’exécution d’une opération immédiate ou d’une opération non immédiate, la tâche automate envoie d’abord un message de prise en compte ou non de la demande de service puis, à la fin de l’exécution de l’opération, un message de compte-rendu.

Après l’envoi d’une demande de service au niveau Contrôle/commande, la tâche superviseur va donc recevoir :

d’abord, un message de prise en compte ou non de la demande de service, c’est-à-dire un message avec le code PC_INCONNU, PC_REFUSE ou PC_ACCEPTE ;

ensuite, si la demande de service a été acceptée, un message de compte rendu avec le code CR_OP_OK ou CR_OP_IT indiquant la réalisation ou non de l’opération demandée.

Lorsque l’automate accepte une demande de service, dans le message de prise en compte de cette dernière, il indique à la tâche superviseur la catégorie à laquelle appartient

l’opération qui va être réalisée par la tâche automate :

opération immédiate : typeOpCcde = OP_IM

opération non immédiate fermée : typeOpCcde = OP_NIF

opération non immédiate ouverte : typeOpCcde = OP_NIO

Les causes de refus par la tâche automate d’une demande de service sont les suivantes :

causeRefus Signification du code de refus

AL_NON_ACQUIT Les alarmes du niveau Contrôle/commande n’ont pas

toutes été acquittées

INCOMPATIBLE L’opération demandée est incompatible avec l’état de

l’automate et de la partie opérative



Si le code de la demande de service ne correspond à aucun des ordres susceptibles d’être reçu par le niveau Contrôle/commande, la tâche automate envoie un message de non prise en compte avec l’indication PC_INCONNU.

Que l’opération exécutée à la suite d’une demande de service acceptée soit une opération immédiate ou une opération non immédiate, le code du message final de compte rendu sera l’un des 2 codes suivants :

codeCRCcde Signification du code de compte-rendu

CR_OP_OK L’opération a pu s’exécuter normalement

CR_OP_IT L’opération n’a pas pu s’exécuter normalement : elle a été interrompue :

soit, par le niveau Contrôle/commande à la suite d’une alarme ;

soit, par le niveau Supervision (cas d’une opération non immédiate

fermée).

Bien que ne pouvant être interrompue par l’opérateur (ou le niveau Supervision), une

opération immédiate du niveau Contrôle/commande peut ne pas aboutir en raison de

l’apparition d’une erreur ou d’une alarme au moment même de son exécution.

Lorsque le code du message de compte rendu est CR_OP_IT, le paramètre causeItOp

précise la cause de l’interruption et de l’annulation de l’opération. Il s’agit en fait du code de

l’alarme qui a conduit à l’arrêt prématuré de l’opération ou à sa non exécution.

Les codes d’alarme sont spécifiques à chaque application. Cependant, toutes les applications géreront le code AL_ordreItOpNIF qui correspond à l’alarme générée par l’automate lorsque celui-ci reçoit du niveau Supervision l’ordre d’interrompre l’opération non immédiate fermée en cours.

Rappel ! La demande faite par le niveau Supervision d’interrompre l’opération non

immédiate fermée en cours est en effet considérée par le niveau Contrôle-commande

comme une situation devant déclencher une alarme. De ce fait, cette dernière devra,

comme toutes les autres alarmes, être acquittée par l’opérateur.



6.3 Canal 3 : Données E/S acquises lors d’une opération de Ccde

Sur ce canal, les échanges d’informations se font selon le schéma de communication

producteur/consommateur. Nous avons un producteur : le niveau Contrôle/commande (la tâche automate), et un consommateur : le niveau Supervision (la tâche realiseOpSvisionNI).

(cf. § 8.3 Communication entre plusieurs producteurs et un consommateur du

Support de cours sur les Systèmes temps réel multitâches (année 2008 – 2009), pp.

90 – 93)

Mise en œuvre de ce schéma de communication avec les 4 variantes décrites, à

savoir :

1. Communication entre un producteur et un consommateur ;

2. Non blocage du producteur lorsque ce dernier trouve la boite aux lettres pleine ;

3. Non blocage du producteur lorsque ce dernier trouve le mutex

mutexBALdataES occupé ;

4. Indication au consommateur de la fin de la production des données.

Processus Win32 RTX Tâche realiseOpSvisionNI Consomme les données produites par la tâche automate

Processus RTSS : Tâche automate Produit les données qui seront consommées par la tâche realiseOpSvisionNI

evBALdataES

MP_BALdataES


TAMPON Tableaux de données dont la taille et le type sont

spécifiques à chaque opération de Ccde.

int sqU [TAILLE_BALdataES] ;

long sqY [TAILLE_BALdataES] ;

Attributs de la file FIFO : int tete ;

int queue ; int compteur ; BOOL iMessageStocke ; int mem_ui ; long mem_yi ; BOOL iFinProduction ; int causeItProduction ;

semaBALdataES

mutexBALdataES

Exemple

Exemple



Il s’agit pour la tâche automate (processus RTSS) de transmettre à la tâche realiseOpSvisionNI (processus Win32 RTX) l’intégralité d’un ensemble de données acquises à chaque période d’échantillonnage (ou selon une périodicité multiple de celle-ci) au cours de la réalisation d’une opération non immédiate de contrôle-commande. Le type et le nombre des données constituant chacun des échantillons transmis à la tâche realiseOpSvisionNI

peuvent être différents d’une opération de contrôle-commande à l’autre.

A la fermeture du canal, le producteur (la tâche automate) donne la valeur TRUE à l’attribut iFinProduction, indiquant ainsi au consommateur que la production des données est terminée.

Durant tout le temps où le canal de communication est ouvert, cet attribut

iFinProduction aura bien évidemment la valeur FALSE.

L’attribut causeItProduction permet au producteur de préciser au consommateur s’il s’agit d’une fin de production normale (causeItProduction = 0) ou consécutive à une interruption prématurée de l’opération (causeItProduction <> 0).

causeItProduction Signification de la valeur de l’attribut

0 La fin de la production des données E/S est consécutive

à la fin normale de l’opération de contrôle-commande

<> 0

La fin de la production est consécutive à l’ interruption

et annulation de l’opération de contrôle-commande.

causeItProduction donne le code de l’alarme à l’origine

de l’interruption et annulation de l’opération.

Lorsqu’elle a à transmettre à la tâche realiseOpSvisionNI un échantillon de données,

la tâche automate peut détecter l’une ou l’autre des 2 situations d’erreur suivantes :

1. La boite aux lettres est pleine ;

2. deux fois de suite la tâche automate trouve le mutex mutexBALdataES occupé.

Lorsque c’est le cas, ceci donne lieu, de la part de la tâche automate, au

déclenchement d’une alarme :

AL_BALdataES_pleine ou AL_mutexBALdataES_occupe.

Dans l’annexe 3.2 du chapitre 8 du Support de cours sur les Systèmes temps réel

multitâches (année 2008 – 2009), est donné le code source en langage C des

primitives de gestion de la boite aux lettres utilisée pour la communication entre la

tâche automate et la tâche realiseOpSvisionNI (cf. pp. 115 – 119).



6.4 Canal 4 : Observations sur l’état de l’automate et de la PO

Sur ce canal, les échanges d’informations se font par modification et consultation de

variables communes. Pour ces variables, la tâche collecteObs (processus RTSS) est le rédacteur tandis que la tâche afficheObs (processus Win32 RTX) est le lecteur.

(cf. § 8.1.3 Communication par variables communes : exemple 3 du Support de

cours sur les Systèmes temps réel multitâches (année 2008 – 2009), pp. 85)

6.4.1 Les variables images des variables d’état du système de contrôle/commande

Pour chaque application, sont créées dans la zone de mémoire partagée

MP_Observations, un certain nombre de variables qui donnent, à un instant donné, l’image de l’état du système de commande. Chaque variable d’état interne du système de commande n’a pas nécessairement une variable image dans cette zone de mémoire MP_Observations. N’ont une variable image dans cette zone que les variables d’état dont le niveau Supervision et l’opérateur ont besoin de connaître la valeur et d’en suivre l’évolution.

Le nom donné à ces variables sera identique à celui de la « vraie » variable d’état (celle interne au système de commande) ; mais pour bien indiquer qu’il s’agit d’une image qui n’est mise à jour que périodiquement à partir de la valeur réelle de la variable d’état interne, ce nom sera précédée de iVE_.

Processus Win32 RTX Tâche afficheObs Lecteur de l’image des variables d’état du niveau Contrôle/commande

Processus RTSS : Tâche collecteObs Rédacteur de l’image des variables d’état du niveau Contrôle/commande

evMAJObs

MP_Observations


Image des variables d’état

du niveau Contrôle/commande :

// Variables non spécifiques à l’application

int iVE_etatPO ; int iVE_ssEtatPO ; int iVE_alarmeSignalee ;

// Variables spécifiques à l’application

…

evAcquitAlarme

IHM



6.4.2 Les variables images non spécifiques à une application particulière

Nom Type Propriétés Description

iVE_etatPO int Code de l’état de l’ensemble Système de

commande + partie opérative

iVE_ssEtatPO int Code du sous état de l’ensemble Système

de commande + partie opérative

iVE_alarmeSignalee int Les codes des alarmes

sont <> 0

Code de l’alarme à signaler à l’opérateur

et que ce dernier doit acquitter

6.4.3 Mise à jour périodique des variables images

Périodiquement, selon une périodicité spécifiée par un paramètre de configuration du processus RTSS, la tâche collecteObs met donc à jour dans la zone de mémoire partagée

MP_Observations l’image des variables d’état du niveau Contrôle/commande qui doivent être visibles pour le niveau Supervision.

Comme c’est à partir de la valeur de ces images de variables d’état que vont être, au niveau de l’IHM, rafraîchis et mis à jour les diagrammes, les courbes ou les valeurs numériques affichées, cette périodicité n’a pas à être inférieure à 200 ms ; elle doit se situer

aux environs de 300 ms.

Chaque mise à jour de ces images de variables d’état du niveau Contrôle/commande est signalée à la tâche afficheObs à l’aide de l’objet evMAJObs de type event à reset automatique.

Si l’on suppose, d’une part que la tâche afficheObs ne lit la valeur de ces variables

que suite à la réception de ce signal, et d’autre part que cette lecture est terminée lorsque la tâche collecteObs procédera à une nouvelle mise à jour, il n’est pas nécessaire de protéger par un mutex l’accès à cette zone de mémoire partagée.

6.4.4 L’acquittement de l’alarme signalée

Toute alarme signalée à l’opérateur par l’intermédiaire de la tâche afficheObs doit

être acquittée par ce dernier.

Lorsque l’opérateur acquitte l’alarme qui lui est signalée, l’IHM génère à l’intention de la tâche collecteObs un signal en utilisant l’objet evAcquitAlarme de type event à reset automatique.



6.5 Récapitulatif des objets IPC

Le schéma ci-après donne un vue d’ensemble des 4 canaux de communication entre

le processus Win32 RTX et le processus RTSS.

Les objets nécessaires à l’implémentation des 4 canaux de communication entre le

processus RTSS et le processus Win32 RTX sont récapitulés dans le tableau suivant :

CANAL Nom de l’objet Type de l’objet

1 MPprocessCcde Objet shared memory

evCRprocessCcde Objet event à reset automatique

evCdeFinProcessCcde Objet event à reset automatique

2 MP_SupervisionCcde Objet shared memory

evOrdreCcde Objet event à reset automatique

semaPCRCcde Objet semaphore à compte privé

evMAJOpNIO Objet event à reset automatique

evDdeItOpNI Objet event à reset automatique

3 MP_BALdataES Objet shared memory

semaBALdataES Objet semaphore

mutexBALdataES Objet mutex

evBALdataES Objet event à reset manuel

Processus Win32 RTX

thread primaire

superviseur

realiseOpSvisionNI

afficheObs

Processus RTSS

thread primaire

automate

automate

collecteObs

ca

na

l 2

ca

na

l 1

ca

na

l 3

ca

na

l 4



4 MP_Observations Objet shared memory

evMAJObs Objet event à reset automatique

evAcquitAlarme Objet event à reset automatique

Les objets RTSS utilisés pour la synchronisation et la communication entre les 2 processus seront créés par le processus Win32 RTX. En effet, le démarrage de l’application de

contrôle-commande se fera par le démarrage du processus Win32, celui dans lequel est implémenté le niveau Supervision. Il est donc logique que le processus Win32 RTX crée les objets RTSS nécessaires à la synchronisation et à la communication avec le processus RTSS avant de créer et démarrer ce dernier à l’aide de la fonction RtCreateProcess ().

Ceci est d’autre part absolument nécessaire pour l’objet MPprocessCcde puisque c’est par des variables créées dans cette zone mémoire que le processus Win32 RTX transmettra au processus RTSS les paramètres de configuration du niveau Contrôle/commande.

Lors de la création de tous ces objets IPC, le processus Win32 RTX devra

nécessairement donner à chacun d’eux un nom sous la forme d’une chaîne de caractères ASCII. En effet, c’est par ce nom que le processus RTSS pourra ensuite, lorsqu’il appellera la fonction RtOpen…, désigner l’objet vers lequel il veut ouvrir un handle (cf. Support de formation à RTX 8.1, § 5, p. 31).

*******************

UE Automatisme C1 (AUT209) 7. Processus Win32 RTX : implémentation de l’IHM


7. Le processus Win32 RTX : implémentation de l’IHM

Le thread primaire du processus Win32 RTX - le premier thread à démarrer lors du lancement de l’application de contrôle/commande et le dernier à se terminer lors de la fermeture de cette dernière – assure les traitements suivants :

Il gère les échanges qu’a l’opérateur avec l’application depuis la console (celle active durant l’exécution du fichier .exe du processus Win32 RTX).

Il met en service le niveau Supervision en créant les tâches permanentes superviseur et afficheObs, ainsi que les ressources globales nécessaires à leur

activité.

Il crée le processus RTSS à l’intérieur duquel est implémenté le niveau Contrôle/commande, et demande à ce processus de se terminer lorsque l’opérateur demande la mise hors service du système de commande.

Il gère l’IHM de type console et gère les échanges avec l’application

appServeurOPC lorsque l’IHM de type OPC a été choisie par l’opérateur.

7.1 Structure du thread primaire du processus Win32 RTX

Le code du thread primaire du processus Win32 RTX se compose :

1. d’un programme principal non spécifique à une application de contrôle-commande particulière (il peut être utilisé tel quel d’une application de contrôle/commande à l’autre) ;

2. des fonctions creerCanauxVersCcde() et detruireCanauxVersCcde(), fonctions non spécifiques à une application particulière qui assurent respectivement la création et la destruction des canaux de communication avec le processus RTSS (le niveau Contrôle/commande) ;

3. des fonctions creerNiveauSupervision() et detruireNiveauSupervision(), fonctions non spécifiques à une application particulière qui assurent respectivement la création et la destruction du niveau Supervision ;

4. d’un ensemble de 3 fonctions plus ou moins spécifiques à une application de contrôle/commande particulière :

configureCcde() elle permet à l’opérateur, depuis la console, de configurer l’application

gestionIHMconsole() elle gère l’IHM de type console

gestionIHMopc () elle gère les échanges avec l’application appServeurOPC

7.1.1 Programme principal du thread primaire

Le programme principal du thread primaire assure les opérations suivantes :

Création et démarrage d’abord du processus RTSS, puis du niveau Supervision

Mise en service de l'IHM (IHM console ou IHM de type OPC)

Commande de l’arrêt du système de commande, c’est-à-dire la fin d’abord du niveau Supervision puis du processus RTSS.

7. Processus Win32 RTX : implémentation de l’IHM UE Automatisme C1


Organigramme général du programme principal du thread primaire

Fixer et mémoriser le niveau de priorité du thread primaire

creerCanauxVersCcde ()

TantQue configureCcde () = VRAI faire :

Créer et démarrer le processus RTSS

Attendre puis afficher le message de compte-rendu envoyé par le processus RTSS

Si codeCRConfigCcde = CONFIG_CCDE_ERR alors :

Afficher le message « Échec de l’opération de création du niveau Ccde ! »

sinon

Afficher le message « Opération réussie de création du niveau Ccde ! »

creerNiveauSupervision()

Démarrer l’activité des tâches superviseur et afficheObs

Attendre la fin de la phase d’initialisation de ces tâches

typeIHM := AUCUNE_IHM

TantQue (codeOp := lireCodeOp (pListeCodes, 3, "COA")) <> 'A') faire :

Quand codeOp

= 'C': (choix de l’IHM de type console)

gestionIHMconsole ()

= 'O': (choix de l’IHM de type OPC)

gestionIHMopc ()

finQuand

finTantQue

Donner ordre de fin du niveau Supervision (evCdeFinSvision)

Attendre la fin des tâches superviseur et afficheObs detruireNiveauSupervision()

Commander la fin du processus RTSS (evCdeFinProcessCcde)

finSi

Attendre la fin du processus RTSS

Clore le handle vers le processus RTSS

finTantQue detruireCanauxVersCcde ()

Afficher le message « Fermeture de l’application ! »

7.1.2 Les fonctions creerCanauxVersCcde() et detuireCanauxVersCcde()

Ces fonctions permettent respectivement de créer et de détruire les objets IPC requis

pour l’implémentation des 4 canaux de communication entre le processus Win32 RTX et le processus RTSS, tels qu’ils ont été décrits dans le chapitre 6.

Prototype de ces 2 fonctions :

void creerCanauxVersCcde (void);

void detruireCanauxVersCcde (void);

7.1.3 Les fonctions creerNiveauSupervision() et detruireNiveauSupervision()

Ces fonctions permettent respectivement de créer et de détruire d’une part les tâches superviseur et afficheObs, et d’autre part les objets requis pour la synchronisation et la communication entre ces tâches et entre ces dernières et le thread primaire.

Prototype de ces 2 fonctions :

void creerNiveauSupervision (void);

void detruireNiveauSupervision (void);



7.1.4 Les fonctions de gestion du dialogue avec l’application depuis la console

Est donnée ci-après une description succincte des 2 fonctions appelées par le

programme principal du thread primaire pour assurer la gestion des échanges entre la console et l’application de contrôle/commande.

1. configureCcde ()

Fonction qui permet, depuis la console, de configurer l’application de

contrôle/commande.

Prototype de la fonction : BOOL configureCcde (void);

Valeur de retour de la fonction :

TRUE : demande de création du système de commande

FALSE : demande de terminaison et fermeture de l’application

2. gestionIHMconsole ()

Fonction qui gère l’IHM de type caractères ou texte

Prototype de la fonction : void gestionIHMconsole (void);

La fonction retourne lorsque l’opérateur a demandé l’arrêt du système de

commande, aucune opération à la demande de l’opérateur n’étant alors en cours d’exécution.

7.2 Configuration de l’application et du serveur OPC

Quand le système de commande est hors service, l’opérateur, depuis la console, a la possibilité d’afficher tous les paramètres de configuration de l’application et d’en modifier certains d’entre eux. Ceci est assuré par la fonction configureCcde(), fonction appelée par le programme principal du thread primaire Win32 RTX.

7.2.1 Les différents niveaux de configuration d’une application

Les paramètres de configuration de l’application pourraient être enregistrés dans un

ensemble hiérarchisé de plusieurs fichiers de configuration.

Il semble en effet judicieux de procéder à une configuration hiérarchisée d’une application de contrôle/commande, c’est-à-dire une hiérarchisation qui correspondrait aux différents niveaux ou aux différents types de contrôle/commande de la partie opérative qui

peuvent être mis en œuvre.

Ainsi dans le cas de la commande en boucle ouverte d’un axe de la machine ORION,

on pourrait définir 2 fichiers de configuration :

1. celui correspondant à la configuration du module BIM 2AX-BF (paramètres

intervenant dans la gestion des E/S) ;

2. celui correspondant à la configuration de la commande de l’axe en boucle ouverte

(commande de base de l’axe).

Dans le cas de la commande en boucle fermée d’un axe de la machine ORION, on

pourrait définir 3 fichiers de configuration :

1. celui correspondant à la configuration du module BIM 2AX-BF (paramètres

intervenant dans la gestion des E/S) ;

2. celui correspondant aux paramètres de configuration de base de la commande en

boucle fermée de l’axe ;

3. celui correspondant aux paramètres du régulateur RTS qui assure

l’asservissement en position de l’axe.



Suivant les applications, l’opérateur ne pourrait modifier que les paramètres de certains de ces fichiers, par exemple le fichier le plus élevé (le dernier) dans cette hiérarchie.

Par exemple, l’application de commande en BO ou en BF d’un axe de la machine

ORION pourrait ne pas donner la possibilité à l’opérateur de modifier le fichier des

paramètres de configuration du module BIM 2AX-BF ; ceux-ci, définis lors du

réglage et de la mise en service de la machine, seraient considérés comme figés pour

l’application de commande en BO ou en BF d’un axe machine.

7.2.2 La fonction configureCcde()

Spécifique à chaque application de contrôle/commande, cette fonction effectue les actions suivantes :

lit les fichiers de configuration de l’application de contrôle/commande ;

donne la possibilité à l’opérateur de modifier certains fichiers de configuration

(notamment celui le plus haut dans la hiérarchie des fichiers de configuration) ;

range les paramètres de configuration du niveau Contrôle/commande dans la zone

de mémoire MPprocessCcde partagée avec le processus RTSS ;

retourne au thread primaire en indiquant si l’opérateur a demandé la terminaison de l’application ou la création et mise en service du système de commande.

Prototype de la fonction : BOOL configureCcde (void);

Valeur de retour de la fonction :

TRUE : demande de création du système de commande

FALSE : demande de terminaison et fermeture de l’application

Organigramme général de la fonction configureCcde()

Il s’agit d’un organigramme type qui pourra fait l’objet d’adaptations en fonction des exigences de l’application particulière à développer.

Lire tous les fichiers de configuration de l’application de contrôle/commande

TantQue (codeOp := lireCodeOp (pListeCodes, 4, menu) <> ‘Q’) faire :

Quand codeOp

= ‘V’ : (Visualisation de tous les paramètres de configuration)

Afficher la valeur de tous les paramètres de configuration de l’application

= ‘M’ : (Modification du fichier supérieur de configuration)

Modifier le fichier supérieur de configuration de l’application

= ‘C’ : (Demande de création du système de commande)

Écrire les paramètres de configuration dans la zone MPprocessCcde

Retourner TRUE

finQuand

finTantQue

Retourner FALSE



7.3 Gestion de l’IHM console

La gestion de l’IHM de type caractères depuis la console qui est active durant

l’exécution du processus Win32 RTX est assurée par une fonction principale, la fonction gestionIHMconsole(). Cette fonction, spécifique à chaque application de contrôle-commande, peut faire appel à la fonction opIHMconsole().

Plus ou moins générale, c’est-à-dire pouvant se retrouver strictement identique d’une

application à l’autre, cette fonction opIHMconsole() assure la gestion de l’IHM de type console lorsque l’opérateur a fait une demande de service spécifique à l’application, que cette daemande donne lieu à la réalisation d’une opération immédiate (OP_IM), d’une opération non immédiate fermée (OP_NIF) ou d’une opération non immédiate ouverte (OP_NIO).

7.3.1 La fonction gestionIHMconsole()

Après avoir affiché un menu d’opérations et le code associé à chacune d’elles, la fonction invite l’utilisateur à taper le code de l’opération qu’il désire voir exécutée.

Outre le code des 3 opérations générales, celles que l’on retrouve dans toutes les applications de contrôle/commande, à savoir :

1. opération K : acquittement de l’alarme signalée

2. opération V : demande d’affichage de l’état du système et de la PO

3. opération F : désactivation de l’IHM console

le menu comprend le code d’opérations spécifiques à l’application développée.

Plusieurs menus pourront être définis et affichés à l’initiative de la fonction

gestionIHMconsole(), le menu valide à un instant donné dépendant des opérations

précédemment réalisées (cf. Module de Mise à niveau en programmation en C).

Après que l’utilisateur a indiqué le code de l’opération qu’il désire voir exécutée, la fonction l’invite à entrer la valeur des éventuels paramètres requis pour son exécution.

Ensuite, après la lecture des paramètres de l’opération demandée, la fonction gestionIHMconsole() :

appelle la fonction acquitterAlarme() s’il s’agit de l’opération K ;

appelle la fonction preparerAffichageEtat() s’il s’agit de l’opération V ;

prépare le message de demande de service à adresser à la tâche superviseur s’il

s’agit d’une opération spécifique à l’application.

Dans le cas d’une opération spécifique, après avoir préparé le message à adresser à la tâche superviseur (c’est-à-dire après avoir renseigné les paramètres de la demande de service) la fonction gestionIHMconsole() appelle une fonction particulière pour assurer la

gestion de l’IHM durant le traitement de la demande de service : il s’agit de la fonction opIHMconsole().

Cette fonction opIHMconsole() retourne avec la valeur :

TRUE si l’opération demandée a pu s’exécuter correctement,

FALSE dans le cas contraire.



Organigramme général de la fonction gestionIHMconsole()

Il s’agit d’un organigramme type qui devra nécessairement être complété en fonction

des demandes de service spécifiques à l’application à développer.

Prototype de la fonction : void gestionIHMconsole (void) ;

typeIH := IHM_CONSOLE

menu := menu1

// La fonction gestionIHMconsole() se termine lorsque l’opérateur tape comme code de

// l’opération la lettre A (opération « Arrêt du système de commande)

TantQue (codeOp := lireCodeOp (pListeCodes, NB_CODES, menu) != ‘F’) faire :

Quand (codeOp)

= ‘K’ : (Acquittement de l’alarme signalée)

Si acquitterAlarme() = VRAI alors :

Afficher le message : « L’alarme signalée a été acquittée »

finSi

= 'V' : (Affichage de l’état du système et de la PO)

Transmettre la demande : preparerAffichageEtat()

= ….

= … (Toutes les opérations spécifiques à l’application)

= …

finQuand

Effacer l’éventuel signal de réveil de l’IHM : ResetEvent (hEvReveilIHM)

Attendre la prochaine occurrence du signal de réveil de l’IHM :

WaitForSingleObject (hEvReveilIHM, INFINITE)

TantQue recevoirMessageBALconsole (&codeMessage, &pChaine) = VRAI faire :

Afficher la chaîne de caractères pChaine

finTantQue

finTantQue

typeIHM := AUCUNE_IHM

7.3.2 La fonction opIHMconsole()

Cette fonction assure la gestion de l’IHM de type console durant tout le traitement de d’une demande de service spécifique à l’application. Elle se termine immédiatement après avoir appelé la fonction acquitterCRddeService(). Grâce à la valeur retournée elle indique à la fonction gestionIHMconsole() si l’opération demandée a pu ou non s’exécuter

normalement.

D’une application à l’autre, cette fonction opIHMconsole() pourra présenter des différences. Cependant, dans tous les cas, par le premier paramètre d’appel de la fonction sera passé à celle-ci le code de la demande de service à adresser à la tâche superviseur.



Organigramme général d’une fonction opIHMconsole()

BOOL opIHMconsole (int codeDS, int valeurMAJ)

{

iServiceEnCours := VRAI

codeDdeService := codeDS

Transmettre la demande de service à la tâche superviseur : declencherDdeService()

TantQue iServiceEnCours = VRAI faire :

Attendre la prochaine occurrence du signal de réveil de l ’IHM :

WaitForSingleObject (hEvReveilIHM, INFINITE)

Si typeOpEnCours = OP_NIF ou OP_NIO alors :

pcVmanu := 0

Tester si une touche du clavier a été enfoncée

Quand (touche enfoncée)

= ‘V’ // demande d’affichage de l’état du système et de la PO

Transmettre la demande : preparerAffichageEtat()

= ‘+’ // commande de déplacement de l’axe dans le sens positif

pcVmanu := + valeurMAJ

= ‘-’ // commande de déplacement de l’axe dans le sens négatif

pcVmanu := -valeurMAJ

= touche ESPACE ou ENTREE // demande d’interruption de l’op NI

Commander arrêt de l’op. NI en cours :arreterOpNIenCours()

finQuand

Mettre à jour les données : mettreAJourDataOpNIO()

finSi

TantQue recevoirMessageBALconsole (&codeMessage, &pChaine) = VRAI faire :

Afficher la chaîne de caractères pChaine

Quand (codeMessage)

= AFF_TEXTE_CRddeServiceOK :

vRetour := TRUE

iServiceEnCours := FALSE

= AFF_TEXTE_CRddeServiceERR :

vRetour := FALSE

iServiceEnCours := FALSE

finQuand

finTantQue

finTantQue

Envoyer le signal d’acquittement du message de CR : acquitterCRddeService()

Retourner vRetour

}



7.4 Gestion de l’IHM de type OPC

La technologie OPC ainsi que les mécanismes de communication et de

synchronisation entre l’application de contrôle/commande et l’application appServeurOPC sont décrits de façon détaillée dans un document distinct de celui-ci.

Cependant, dans ce paragraphe nous allons présenter les fonctionnalités implémentées dans la fonction gestionIHMopc(), fonction qui assure la gestion de l’IHM de

type OPC pour le compte de l’application de contrôle/commande en liaison avec l’application appServeurOPC.

Pour cela, elle dispose :

d’une part, d’une description de la base de données que l’application appServeurOPC devra exposer aux clients OPC qui se connecteront au serveur ;

d’autre part, d’un ensemble de fonctions qui constitue une sorte d’API pour les échanges avec l’application appServeurOPC.

7.4.1 La fonction gestionIHMopc()

Elle est appelée par le programme principal du thread primaire lorsque l’opérateur a choisi l’IHM de type OPC.

Après avoir demandé et obtenu l’usage exclusif du serveur OPC, la fonction

gestionIHMopc() configure ce dernier à partir de la description de la base de données que l’application de contrôle/commande désire que le serveur OPC expose aux clients OPC qui se connecteront.

La configuration s’étant déroulée sans erreur, la fonction gestionIHMopc() active le

serveur en appelant la fonction OPCactiverServeur(). Si le démarrage de l’activité normale du serveur a pu se faire avec succès, la fonction gestionIHMopc() fait appel, pour gérer les échanges avec le serveur OPC, à la fonction OPCgererEchangesAvecServeur().

La fonction gestionIHMopc() se termine :

si l’application CNAMappServeurOPC n’est pas active ou si elle est déjà utilisée par une autre application de contrôle/commande ;

dès qu’apparaît une erreur lors de la phase de configuration du serveur OPC ;

lorsque se termine la fonction OPCgererEchangesAvecServeur() à la suite d’une erreur ou quand CNAMappServeurOPC() a demandé à l’application de

contrôle/commande de libérer le serveur.

Cette demande de libérer le serveur OPC intervient normalement sur ordre de

l’opérateur (ordre donné depuis l’IHM de l’application CNAMappServeurOPC)

lorsque aucun client OPC n’est connecté au serveur.

Avant de se terminer, la fonction gestionIHMopc() affiche un message indiquant la raison de la fin de son activité, et donc la mise hors service de l’IHM de type OPC.

Au paragraphe 7.4.4 est donné un exemple de réalisation de cette fonction gestionIHMopc().



7.4.2 La description de la base de données exposée par le serveur OPC

L’application de contrôle/commande elle-même doit comporter une description sous

une certaine forme de la base de données que l’application CNAMappServeurOPC devra exposer aux clients OPC qui se connecteront.

Cette description est faite avec une double finalité :

permettre la configuration du serveur OPC après que la fonction gestionIHMopc()

a obtenu, pour le compte de l’application de contrôle/commande dont elle fait partie, la propriété exclusive de ce dernier ;

faciliter la mise à jour d’une part des items en lecture, et d’autre part des variables

de l’application de contrôle/commande qui sont associées aux items en écriture.

La description de la base de données est faite à partir des 5 types suivants de structures :

1. Pour la description d’un item de catégorie C ou L : struct itemEnL { char nomItem[40]; // Nom de l’item (chaîne d’au plus 40 caractères) VARTYPE typeItem; // Type de l’item void *adVar; // Adresse de la variable correspondante HANDLE hItem; // Handle de l’item (communiqué par CNAMappServeurOPC) };

2. Pour la description d’une branche d’items de catégorie L : struct brItL {

char nomBranche[48]; // Nom réduit de la branche (au plus 48 caractères)

int nbItems; // Nombre d'items de la branche

struct itemEnL *pPremItem; // Adresse du descripteur du 1er

item de la branche

BOOL *piMajVar; // Adresse d'un tableau d'indicateurs de màj de la variable

};

3. Pour la description d’un item de catégorie S :

struct itemS {

char nomItem[40]; // Nom de l’item (chaîne d’au plus 40 caractères)

BOOL (* adFa)(void); // Adresse d'une fonction de l'application

};

4. Pour la description d’un item de catégorie E :

struct itemEnE {

char nomItem[40]; // Nom de l’item (chaîne d’au plus 40 caractères)

VARTYPE typeItem; // Type de l’item

void *pVar; // Adresse de la variable associée à l'item

DWORD ixDS; // Indicateur des demandes de service où il intervient // (cas d'un item appartenant à une branche multiDS )

};

5. Pour la description des branches E des items en écriture : struct brItE {

char nomBranche [48]; // Nom réduit de la branche (au plus 48 caractères)

int nbItems; // Nombre total d'items de la branche

struct itemEnE *pPremItem; // Adresse du descripteur du 1er

item de la branche

BYTE vCodeDSmax; // si br de type multiDS, nombre total de DS (sinon 0)

int *pCodeDS; // si br de type monoDS, adr du code de la DS (sinon NULL)

BOOL (* adFa)(void); // NULL ou adresse d'une fonction appelée lorsque tous les // items de la branche ou d’une DS ont été mis à jour

};



A ces 5 types de structures requises pour décrire la base de données, se rajoutent les 3 types de service suivants :

1. Pour décrire les données requises pour l’activation du serveur :

struct dptActivation {

BOOL iHighPriorityClass; // Indicateur que CNAMappServeurOPC doit // s'exécuter en HIGH_PRIORITY_CLASS

int *pPeriodeMajVarEnL; // Périodicité en ms de màj des variables // associées aux items de catégorie L

DWORD ixBrEaBloquer; // 0 ou indicateurs des branches d'items E dont la màj doit // être bloquée lors du traitement d’une dde de service

};

2. Pour décrire les données requises par l’exploitation du serveur :

struct dptExploitation {

HANDLE *phEvMajVarEnL; // Adr handle d'un objet Win32 type event signalant la // màj périodique des variables associées aux items L int noItemAcqCR; // Rang de l’item S acquitterCRddeService, signal débloquant // la màj des items des branches ixBrEaBloquer // Pour la gestion de la connexion/déconnexion du client OPC pilote de l'application : BOOL (*adFaITopNI)(void); // NULL ou adr de la fonction d’IT de l’opération NI // en cours, fct appelée lorsque le client se déconnecte BOOL (*adFaAcqCR)(void); // NULL ou adr fonction d’acquittement du CRddeService, // fonction appelée lorsque le client se déconnecte

struct brItL *pBrCR; // NULL ou adresse du descripteur de la branche de l'item L // texteCRddeService (texte du CR à la dde de service) int noItemCR; // Rang de cet item dans la branche };

3. Pour décrire la zone mémoire de travail requise par l’API avec CNAMappServeurOPC :

struct mtAPI {

int motDePasseOPC; // Mot de passe pour échanger avec CNAMappServeurOPC

int nbBrL; // Nombre de branches L à mettre à jour

struct brItL *pPremBrL; // Adresse du descripteur de la 1ère branche L dont // les items sont à mettre à jour

struct itemS *pPremItemS; // Adresse du descripteur du 1er item de la branche S

BOOL iPiloteConnecte; // Indicateur de connexion du client OPC pilote

int var ; // réservé // Pour la mémorisation de l'erreur détectée par l'API ou par CNAMappServeurOPC :

int codeOpIHMopc; // Code de l'opération effectuée

char catBr; // Catégorie de l'item C, L, S ou E

int noBr; // Numéro de la branche concernée

int noItem; // Numéro d'ordre (dans la br) de l'item concerné

int codeCRserveurOPC; // Code CR (≠ de CR_OPC_OK) retourné par CNAMappServeurOPC

int codeErreur; // Code d'erreur retourné par CNAMappServeurOPC ou par l'API

};

En annexe de ce chapitre est donné un exemple de définition et d’initialisation des structures de données requises pour la configuration du serveur OPC et pour les échanges d’informations entre le serveur OPC configuré et l’application de contrôle/commande.



7.4.3 Les fonctions de l’API avec l’application appServeurOPC

Pour ses échanges avec l’application appServeurOPC, la fonction gestionIHMopc()

dispose d’un ensemble de fonctions qui constitue une véritable API (Application Programming Interface) pour configurer et exploiter le serveur OPC.

Ces fonctions, au nombre de 9, permettent à la fonction gestionIHMopc() d’effectuer les opération suivantes :

OPCacquerirServeur () Demander de disposer de façon exclusive du serveur OPC

OPCcreerBrC () Créer la branche d’items de catégorie C

OPCcreerBrL () Créer les branches d’items de catégorie L

OPCcreerBrS () Créer la branche d’items de catégorie S

OPCcreerBrE () Créer les branches d’items de catégorie E

OPCactiverServeur () Clore la phase de configuration du serveur et activer ce dernier

OPCgererEchangesAvecServeur () Gérer les échanges avec le serveur configuré et activé

OPCrestituerServeur () Libérer le serveur OPC

OPCafficherMessageErreur () Élaborer et afficher un message d’erreur

Voici le prototype de chacune de ces 9 fonctions :

BOOL OPCacquerirServeur ( char *pNomApplication, // Adresse du nom de l’application struct mtAPI *pMT

) ;

BOOL OPCcreerBrC (

int nbItC, // Nombre d’items à créer struct itemEnL brC[], // Tableau de structures de type itemEnL struct mtAPI *pMT

) ;

BOOL OPCcreerBrL (

int nbBrL, // Nombre de branches L à créer struct brItL brL[], // Tableau de structures de type brItL struct mtAPI *pMT

) ;

BOOL OPCcreerBrS ( int nbItS, // Nombre d’items à créer struct itemS brS[], // Tableau de structures de type itemS struct mtAPI *pMT

) ;

BOOL OPCcreerBrE (

int nbBrE, // Nombre de branches E à créer

struct brItE brE[], // Tableau de structures de type brItE

struct mtAPI *pMT

) ;

BOOL OPCactiverServeur (

struct dptActivation *pdAct,

struct mtAPI *pMT

) ;

BOOL OPCgererEchangesAvecServeur (

struct dptExploitation *pdExp,

struct mtAPI *pMT

) ;



void OPCrestituerServeur (

struct mtAPI *pMT

) ;

void OPCafficherMessageErreur (

struct mtAPI *pMT

) ;

7.4.4 Exemple de fonction gestionIHMopc()

La fonction gestionIHMopc() ci-dessous est un exemple d’utilisation de l’API décrite dans ce chapitre. Cette utilisation est faite d’après la description de la base de données

présentée dans l’annexe Exemple de description de la base de données exposée.

Remarquez que dans cette fonction gestionIHMopc() sont utilisées toutes les

fonctions qui viennent d’être décrites, et que chacune d’elles n’est appelée qu’une

seule fois.

void gestionIHMopc (void)

{

struct mtAPI mtAPIopc;

if (OPCacquerirServeur (pNomAppCcde, &mtAPIopc))

{ // Acquisition de l'usage exclusif du serveur

printf ("\n\tAcquisition du serveur OPC !");

do {

// Phase de configuration du serveur OPC

if (! OPCcreerBrC (1, tabItemC, &mtAPIopc)) // Création de la branche C

break;

if (! OPCcreerBrL (3, tabBrL, &mtAPIopc)) // Création des branches L

break;

if (! OPCcreerBrS (3, tabItemS, &mtAPIopc)) // Création de la branche S

break;

if (! OPCcreerBrE (3, tabBrE, &mtAPIopc)) // Création des branches E

break;

if (! OPCactiverServeur (&activationServeurOPC, &mtAPIopc))

break;

printf ("\n\tConfiguration et activation du serveur OPC !");

// Phase d’exploitation du serveur OPC

OPCgererEchangesAvecServeur (&exploitationServeurOPC, &mtAPIopc);

} while (FALSE);

OPCrestituerServeur (&mtAPIopc);

}

OPCafficherMessageErreur (&mtAPIopc);

printf ("\n\tMise hors service de l'IHM de type OPC");

return;

}



Annexe : Exemple de description de la base de données exposée

1. Items en lecture

// Nom de l’application de contrôle/commande :

char *pNomAppCcde = "Contrôle/commande en BO d'un axe de la machine ORION";

/* Tableaux de structures de type itemEnE décrivant tous les items en lecture */

struct itemEnL tabItemC [1] = {

{ "nomAxe", VT_BSTR, nomAxe, 0 }

};

struct itemEnL tabItemEnL_1 [6] = {

{ "etatPO", VT_UI1, &etatPO, 0 },

{ "ssEtatPO", VT_UI1, &ssEtatPO, 0 },

{ "alarmeCcde", VT_UI1, &alarmeCcde, 0 },

{ "codeOpEnCours", VT_UI1, &codeOpEnCours, 0 },

{ "codeCRddeService", VT_UI1, &codeCRddeService, 0 },

{ "causeItOpEnCours", VT_UI1, &causeItOpEnCours, 0 },

};


{ "texteEtatPO", VT_BSTR, &texteEtatPO, 0 },

{ "texteSsEtatPO", VT_BSTR, &texteSsEtatPO, 0 },

{ "texteAlarmeCcde", VT_BSTR, &texteAlarmeCcde, 0 },

{ "texteOpEnCours", VT_BSTR, &texteOpEnCours, 0 },

{ "texteCRddeService", VT_BSTR, &texteCRddeService, 0 },

{ "texteEtatCcde", VT_BSTR, &texteEtatCcde, 0 },

};


{ "puissance", VT_UI1, &puissance, 0 },

{ "buteeBasse", VT_UI1, &buteeBasse, 0 },

{ "buteeHaute", VT_UI1, &buteeHaute, 0 },

{ "origine", VT_UI1, &origine, 0 },

{ "defautCAN", VT_UI1, &defautCAN, 0 },

{ "defautCodeur", VT_UI1, &defautCodeur, 0 },

{ "inTOR", VT_UI1, &inTOR, 0 },

{ "inANA", VT_I2, &inANA, 0 },

{ "posAxe", VT_I4, &posAxe, 0 },

{ "outTOR", VT_UI1, &outTOR, 0 },

{ "outANA", VT_I2, &outANA, 0 }

};

/* Tableau de structures brItL décrivant les branches d'items de catégorie L */

struct brItL tabBrL[3] = {

{ "Variables d'état générales (numériques)", 6, tabItemEnL_1, NULL },

{ "Variables d'état générales (textuelles)", 6, tabItemEnL_2, &iMAJtexte[0]},

{ "Variables d'état spécifiques", 11, tabItemEnL_3, NULL } };



2. Items en écriture

/* Tableau de structures itemS décrivant tous les items de catégorie S */

struct itemS tabItemS [3] = {

{ "arreterOpNIenCours", arreterOpNIenCours },

{ "acquitterCRddeService", acquitterCRddeService },

{ "acquitterAlarme", acquitterAlarme }

};

#define ARRET_OpNIenCours 0

#define ACQ_CRddeService 1

#define ACQ_Alarme 2

/* Tableaux de structures itemEnE décrivant tous les items de catégorie E */

struct itemEnE tabItemEnE_1 [12] = {

{ "codeDdeService", VT_UI1, &codeDdeService, '\x000F' },

{ "pcVmax", VT_I2, &pcVmax, '\x0002' },

{ "dTVmax", VT_UI2, &dTVmax, '\x0002' },

{ "ech_s", VT_BOOL, &ech_s, '\x0004' },

{ "ech_U", VT_UI2, &ech_U, '\x0004' },

{ "ech_T", VT_UI2, &ech_T, '\x0004' },

{ "sbpa_U", VT_UI2, &sbpa_U, '\x0008' },

{ "sbpa_n", VT_UI2, &sbpa_n, '\x0008' },

{ "sbpa_p", VT_UI2, &sbpa_p, '\x0008' },

{ "sbpa_L", VT_UI2, &sbpa_L, '\x0008' },

{ "nomFichier", VT_BSTR, &nomFichier, '\x000C' },

{ "commentaires", VT_BSTR, &commentaires, '\x000C' },

};


{ "pcVmanu", VT_I2, &pcVmanu, 0 }

};


{ "noEnsemble", VT_UI1, &noEnsemble, 0 }

};

/* Tableau de structures brItE décrivant les branches d'items de catégorie E */

struct brItE tabBrE [3] = {

{ "Paramètres des demandes de service", 12,

tabItemEnE_1, 4, NULL, declencherDdeService},

{ "Position du joystick", 1,

tabItemEnE_2, 0, NULL, mettreAJourDataOpNIO },

{ "Sous ensemble des variables à afficher", 1,

tabItemEnE_3, 0, NULL, preparerAffichageEtat }

};



3. Paramètres d’activation et d’exploitation du serveur OPC

*******************

/* Paramètres d'activation du serveur OPC */

struct dptActivation activationServeurOPC = {

FALSE, &periodeMajVarEnL, '\x0001' };

/* Conditions d'exploitation du serveur OPC */

struct dptExploitation exploitationServeurOPC = {

&hEvReveilIHM, 1,

arreterOpNIenCours, acquitterCRddeService, &tabBrL[1], 4 };

UE Automatisme C1 (AUT209) 8. Processus Win32 RTX : le niveau Supervision


8. Le processus Win32 RTX : implémentation du niveau Supervision

Le niveau Supervision comprend :

deux tâches permanentes : les tâches superviseur et afficheObs

et une tâche temporaire : la tâche realiseOpSvisionNI

8.1 La tâche superviseur

La tâche superviseur n’est créée et ne démarre son activité que lorsque le niveau Contrôle/commande a été créé et mis en service, et est donc opérationnel. Elle reçoit de l’IHM toutes les demandes de service faites par l’opérateur et qui sont spécifiques à l’application.

Quel que soit le type d’IHM mis en œuvre (IHM de type console ou IHM de type

OPC), une fonction de thread unique assure la supervision des demandes de service spécifiques adressées à l’application. Au cours de sa phase d’initialisation générale, la tâche superviseur initialise les paramètres des demandes de service

8.1.1 Fonctionnalités assurées par la tâche superviseur

Après avoir effectué l’initialisation générale de son activité et des paramètres des

demandes de service, la tâche superviseur se met en attente des 2 événements suivants :

1. Demande de service transmis par l’IHM (signal evDdeService) ;

2. Ordre de terminaison du niveau Supervision (signal evCdeFinSvision).

A un instant donné, l’opérateur pilote de l’application ne peut demander à la tâche superviseur que la réalisation d’une seule opération. Il doit attendre la fin de la précédente

opération avant de demander l’exécution d’une nouvelle opération. Si l’opération en cours est une opération non immédiate, il peut cependant, à tout moment, l’interrompre définitivement.

Rappelons que cet ordre d’interruption de l’opération non immédiate en cours ne

transite pas par la tâche superviseur ; il est transmis directement de l’IHM à la

tâche qui traite cette opération.

Les opérations que le pilote de l’application peut demander à la tâche superviseur sont spécifiques à une application particulière de contrôle/commande. Le code de la

demande de service adressée à la tâche superviseur est mémorisé dans codeDdeService.

Après avoir reçu et analysé une demande de service, la tâche superviseur :

exécute elle-même le service si celui-ci consiste à réaliser une opération immédiate du niveau Supervision ;

crée la tâche realiseOpSvisionNI pour l’exécution du service demandé si celui-ci consiste à réaliser une opération non immédiate du niveau Supervision ;

appelle la fonction superviseOpCcde() si l’exécution du service demandé conduit

à la réalisation d’une opération immédiate ou non immédiate du niveau Contrôle/commande ou d’une opération non immédiate conjointe.

Après avoir transmis à la tâche afficheObs le code du compte rendu de l’opération réalisée, la tâche superviseur se met en attente du signal d’acquittement de ce compte rendu.

Dès que ce signal a été reçu, la tâche superviseur se met en attente d’une nouvelle demande de service ou de l’ordre de terminaison du niveau Supervision.

8. Processus Win32 RTX : le niveau Supervision UE Automatisme C1


8.1.2 Organigramme général de la tâche superviseur

iSuperviseurActif := VRAI

codeDdeService := 0

Initialiser les paramètres des demandes de service

typeOpenCours := 0

Signaler au thread primaire la fin de la phase d’initialisation (semaFinInitTaches)

TantQue iSuperviseurActif = VRAI faire :

evRecu := attendre evDdeService ou evCdeFinSvision

Si evRecu = evCdeFinSvision alors :

iSuperviseurActif := FAUX

Sortir boucle TantQue

finSi

Quand codeDdeService // code de la demande de service spécifique reçue de l’IHM

= …

= …

= autre :

envoyerMessageBALafficheObs (CODE_CRddeService, CRDS_INCONNUE, 0)

finQuand

typeOpEnCours := 0

envoyerMessageBALafficheObs (CODE_OpEnCours, 0, 0)

Attendre le signal evAcquitCRddeService

envoyerMessageBALafficheObs (CODE_CRddeService, 0, 0)

RAZ du signal evDdeService

finTantQue

Terminaison de la tâche superviseur

8.1.3 La fonction superviseOpCcde()

Appelée par la tâche superviseur chaque fois qu’une demande de service entraîne la

réalisation d’une opération du niveau Contrôle/commande, la fonction superviseOpCcde(), comme son nom l’indique, supervise la réalisation d’une telle opération. Cette opération peut donc être :

soit, une opération immédiate relevant uniquement du niveau Contrôle/commande

soit, une opération non immédiate (ouverte ou fermée) relevant uniquement du niveau Contrôle/commande

soit, une opération non immédiate (ouverte ou fermée) relevant conjointement du niveau Supervision et du niveau Contrôle/commande.

Dans le cas d’une opération non immédiate conjointe, la tâche superviseur transmet à

la fonction superviseOpCcde() l’adresse de la fonction de thread avec laquelle la tâche realiseOpSvision devra être créée ainsi que l’adresse de la structure de données à transmettre à cette tâche lors de sa création.

Prototype de la fonction superviseOpCcde() :

void superviseOpCcde (

int codeOp, // code de l’opération (en fait, codeOp = codeDdeService)

DWORD (WINAPI *pFthread) (void *), // adresse d’une fonction de thread

void *pD // adresse d’une structure de données à passer au thread

) ;



Organigramme général de la fonction superviseOpCcde()

Si pFthread <> NULL alors :

Créer suspendue la tâche realiseOpSvision avec :

(*pFthread) comme fonction de thread

pD comme valeur de l’argument lpParameter d’appel de CreateThread()

finSi

Déclencher l’envoi au niveau Contrôle/commande de la demande de service

Attendre du niveau Ccde le message de prise en compte ou non de la demande de service

causeItOp := 0

Quand (codePCcde)

= PC_INCONNU :

codeCRCcde := CRDS_INCONNUE

= PC_REFUSE :

Si causeRefus = AL_NON_ACQUIT alors :

codeCRCcde := CRDS_REFUSEE_AL

finSi

Si causeRefus = INCOMPATIBLE alors :

codeCRCcde := CRDS_REFUSEE_SYS

finSi

= PC_ACCEPTE :

typeOpEnCours := typeOpCcde

envoyerMessageBALafficheObs (CODE_OpEnCours, codeOp, 0)


Démarrer la tâche realiseOpSvision

Attendre la fin de la tâche realiseOpSvision

finSi

Attendre du niveau Ccde le message de compte rendu de l’opération

Quand (codeCRCcde)

= CR_OP_OK :

codeCRCcde := CRDS_OP_OK

= CR_OP_IT :

codeCRCde := CRDS_OP_IT

causeItOp := causeItOp (du message de compte-rendu)

= autre :

coceCRCcde := CRDS_PAS_CR

finQuand

finQuand

envoyerMessageBALafficheObs (CODE_CRddeService, codeCRCcde, causeItOp)


Clore le handle vers la tâche realiseOpSvision

finSi

Retour dans la tâche superviseur

8. Processus Win32 RTX : le niveau Supervision UE Automatisme C1


8.2 La tâche realiseOpSvisionNI

8.2 1 Caractéristiques générales de la tâche realiseOpSvivion

La tâche realiseOpSvisionNI est créée par la tâche superviseur au fur et à mesure des

besoins, c’est-à-dire lorsqu’une demande de service reçue de l’IHM va donner lieu à l’exécution :

soit, d’une opération non immédiate du niveau Supervision ;

soit, d’une opération non immédiate conjointe : dans ce cas, la tâche realiseOpSvision effectue les traitements incombant au niveau Supervision, ceux

incombant au niveau Contrôle/commande étant exécutés par la tâche automate.

La tâche realiseOpSvisionNI se termine et est détruite lorsque se termine l’opération pour laquelle elle a été créée.

D’une existence à l’autre de la tâche realiseOpSvisionNI, la fonction de thread

correspondant au code programme de la tâche pourra être différente, notamment si l’opération à réaliser appartient à une catégorie différente de celle précédemment réalisée par la tâche.

Nous avons d’autre part indiqué qu’un niveau de priorité différente sera donnée à la tâche realiseOpSvision suivant qu’elle effectue les traitements relatifs à une opération non

immédiate de supervision ou une opération non immédiate conjointe (cf. § 4.4 Niveau de priorité des threads du processus Win32 RTX).

Ci-après est donné l’organigramme général d’une fonction de thread, la fonction traiteDataES(), qui implémente les traitements incombant au niveau Supervision lors d’une

opération non immédiate conjointe. Ces traitements consistent à enregistrer dans un fichier sur disque les données E/S transmises par le niveau Contrôle/commande.

8.2.2 Organigramme général de la fonction de thread traiteDataES

traiteDataESactif := VRAI

Ouvrir en écriture le fichier où vont être enregistrées les données E/S

Récupérer la date et heure données par le système d’exploitation

Enregistrer dans le fichier commentaires, date, heure, et éventuellement d’autres infos

TantQue traiteDataESactif = VRAI faire :

nbMes := recevoirMessageBALdataES ( )

Si nbMes = -1 alors :

traiteDataESactif := FAUX

sinon

Enregistrer dans le fichier les messages reçus

finSi

finTantQue

Fermer le fichier

Si causeItProduction <> 0 alors :

Supprimer le fichier

finSi

Fin de la fonction de thread



8.3 La tâche afficheObs

Quant à la tâche afficheObs, elle prépare l’affichage d’une part des observations que

lui transmet périodiquement le niveau Contrôle/commande sur l’état du système de commande et de la PO, et d’autre part des messages de service émis par la tâche superviseur à destination de l’opérateur.

Organigramme général de la tâche afficheObs

iAfficheObsActif := VRAI

Initialiser les variables d’état non spécifiques à l’application

Signaler au thread primaire la fin de la phase d’initialisation : RtReleaseSemaphore (hSemaFinInitTaches, 1, NULL) ;

TantQue iAfficheObsActif = VRAI faire :

evRecu := attendre evMAJObs ou evCdeFinSvision

Si evRecu = evCdeFinSvision alors :

iAfficheObsActif := FAUX

Sortir de la boucle TantQue

finSi

1) Lire valeur des iVE du niveau Ccde et préparer messages textuels à afficher

2) Lire les messages envoyés par l’IHM et la tâche superviseur,

et préparer les messages textuels à afficher :

TantQue lireMessageBALafficheObs (&codeMessage, &par1, &par2) = VRAI faire :

Quand (codeMessage)

= DDE_IHM_EtatCcde :

Préparer le message contenant la valeur des variables d’état

= CODE_OpEnCours :

codeOpEnCours := par1

Préparer le message donnant l’intitulé de l’opération en cours

= CODE_CRddeService :

codeCRddeService := par1

causeItOpEnCours := par2

Préparer le message textuel relatif au CR de la demande de service

finQuand

finTantQue

3) Si IHM console en service, lui transmettre les messages textuels,

puis réveiller l’IHM en service :

Si typeIHM = IHM_CONSOLE alors :

Transmettre les messages textuels à l'IHM console

finSi

Réveiller l’IHM en service : RtSetEvent (hEvReveilIHM) ;

finTantQue

Terminaison de la tâche afficheObs

Remarque

La boite aux lettres BALafficheObs est créée dans la fonction

creerNiveauSupervision() et détruite dans la fonction detruireNiveauSupervision().

*******************

UE Automatisme C1 (AUT209) 9. Le processus RTSS : structuration du niveau Ccde


9. Le processus RTSS : structuration du niveau Contrôle/commande

Dans le processus RTSS on peut distinguer :

le thread primaire, celui qui est créé et lancé lors de la création du processus,

le niveau Contrôle/commande (ou partie temps réel proprement dite) dont les

tâches (threads) et ressources sont créées par le thread primaire.

9.1 Structure du processus RTSS

Dans la version de base du niveau Contrôle/commande décrite dans ce chapitre, le processus RTSS se compose de 3 threads :

1. le thread primaire,

2. la tâche automate,

3. la tâche collecteObs de collecte des observations.

9.1.1 La raison d’être des différents threads du processus RTSS

Le thread primaire du processus RTSS assure la gestion organisationnelle de ce processus, à savoir toutes les opérations de création et de destruction des agents actifs

(tâches) et des ressources globales dont ont besoin ces derniers pour réaliser l’objectif confié à la partie temps réel (déterministe) de l’application de contrôle/commande.

Le thread primaire assure également :

d’une part, la mise en service de l’interface entre le système informatique de

commande et la partie opérative (machine ou procédé physique) ;

d’autre part, la mise hors service de cette interface.

à travers 2 fonctions spécifiques de l’application : les fonctions mettreEnServiceInterfacePO()

et mettreHorsServiceInterfacePO().

La tâche automate reçoit les demandes de service adressées au niveau

Contrôle/commande par la tâche superviseur (du processus Win32 RTX) ; elle vérifie que leur exécution est bien compatible avec son état et celui de la partie opérative, puis effectue les traitements préliminaires aux opérations demandées. La tâche automate tout à la fois gère les entrées/sorties avec le procédé physique et assure le contrôle/commande de ce dernier d’après les directives qu’il reçoit de la tâche superviseur. Au cours de certaines opérations de

contrôle/commande, elle acquiert des données E/S puis transmet ces données au niveau Supervision, plus précisément à la tâche realiseOpSvisionNI.

Comme son nom l’indique, la tâche collecteObs collecte les observations réalisées par l’automate sur l’état de la partie opérative, éventuellement les synthétise, puis les transmet

au niveau Supervision.

Ces traitements sont faits selon une périodicité très supérieure à celle d’activation

de la tâche automate. Alors que l’activation de cette dernière se situe généralement

entre 5 et 20 ms (ce qui correspond en fait à la période d’échantillonnage), celle de

la tâche collecteObs est de l’ordre de quelques centaines de ms.

Ces traitements réalisés par la tâche collecteObs sont les moins prioritaires de tous

ceux que doit assurer le niveau Contrôle/commande. Ils implémentent cependant une

fonctionnalité permanente, alors que celle d’acquérir et transmettre des données

E/S à chaque période d’échantillonnage lors de certaines opérations de

contrôle/commande constitue une fonctionnalité ponctuelle de la tâche automate.

9. Le processus RTSS : structuration du niveau Ccde UE Automatisme C1


Processus RTSS

niveau Contrôle/commande

automate

(tâche périodique :

séquence de traitement d’un timer RTX)

thread primaire

(programme principal non spécifique à l’application)

mettreEnServiceINterfacePO

(fonction spécifique à l’application)

mettreHorsServiceInterfacePO

(fonction spécifique à l’application)

collecteObs

(tâche de collecte des observations)

Zone des données partagées

(par les tâches du processus RTSS)

Variables d’état de l’automate et de la partie opérative :

1) Variables non spécifiques à l’application :

BOOL iCcdeActif; int etatPO; int ssEtatPO; int itALmax; int codeALmax; struct FIFO alarmes;

struct GeneSBPA dataGeneSBPA;

2) Variables spécifiques à l’application : ….

Autres variables globales partagées non spécifiques à l’application :

int iSynchroCcde; HANDLE hEvFinCycleAutomate;



9.1.2 Niveau de priorité des threads du processus RTSS

Les threads du processus RTSS sont ordonnancés par l’ordonnanceur RTSS en

fonction de leur seul niveau de priorité de thread. Un niveau de priorité différent est donné à chacun des threads du processus RTSS.

Parmi les threads du processus RTSS, le thread primaire a le niveau de priorité le plus faible. Cependant, il doit avoir un niveau de priorité supérieur à celui de la tâche la plus

prioritaire du processus Win32 RTX, c’est-à-dire un niveau de priorité supérieur à RT_PRIORITY_MIN + 4 (cf. § 4.4 Niveau de priorité des threads du processus Win32 RTX).

Ainsi, seront donnés les niveaux de priorité suivants aux threads du processus RTSS :

Thread primaire RT_PRIORITY_MIN + 5

Tâche collecteObs RT_PRIORITY_MIN + 6

Tâche xxxxxx RT_PRIORITY_MIN + 7

Tâche automate (thread timer) RT_PRIORITY_MIN + 8

9.2 Synchronisation et communication entre les tâches

Le thread primaire n’intervient que pour la création et l’initialisation du niveau Contrôle/commande de l’application. Lorsqu’il a pu réaliser ceci correctement, il démarre l’exécution des tâches du niveau Contrôle/commande (en l’occurrence les tâches automate et collecteObs si l’on considère la structure de base décrite précédemment), puis se met en

attente du signal de demande d’arrêt du système de contrôle/commande (signal evCdeFinProcessCcde émis par le thread primaire du processus Win32 RTX). Entre le démarrage des tâches du niveau Contrôle/commande et l’occurrence de ce signal, le thread primaire du processus RTSS est donc dans l’état en attente. De ce fait, il n’est pas concerné

par le problème de la communication et de la synchronisation entre les tâches du niveau Contrôle/commande, problème que nous allons examiner maintenant.

9.2.1 Choix relatifs à l’organisation de l’activité des tâches

Pour ce qui concerne l’organisation des traitements entre la tâche automate et les autres tâches du niveau Contrôle/commande, les choix suivants ont été faits :

1. Un niveau de priorité différent est donné à chacune des tâches, la plus prioritaire étant la tâche automate, et la moins prioritaire la tâche collecteObs.

2. La tâche automate est une tâche périodique : il s’agit plus précisément de la séquence de traitement associée à un thread timer RTX, et exécutée à chaque expiration du temporisateur ; la périodicité d’exécution de cette séquence est fixée à la valeur de la période d’échantillonnage des entrées/sorties.

Si l’échantillonnage des E/S se fait selon des périodicités différentes, la période du

timer RTX gérant la tâche automate est celle qui correspond à la plus petite période

d’échantillonnage.

3. A la fin de chacune de ses exécutions périodiques, la tâche automate réveille les autres tâches. Parmi elles, c’est la tâche la plus prioritaire qui reprendra son activité dès que la tâche automate aura effectivement terminé son exécution périodique.

4. La communication entre la tâche automate et les autres tâches du niveau Contrôle/commande se fait par variables globales.



Il découle de ceci qu’à chaque période d’échantillonnage, s’exécutent successivement la tâche automate, puis, dans l’ordre décroissant de leur niveau de priorité, chacune des autres tâches du niveau Contrôle/commande.

Le schéma suivant illustre l’activité synchronisée et périodique des tâches du niveau Contrôle/commande lorsque ces dernières sont au nombre de trois.

Un seul objet de type event à reset manuel est nécessaire pour le réveil par la tâche

automate des autres tâches du niveau Contrôle/commande. C’est l’objet evFinCycleAutomate. A la fin de chacune de ses exécutions périodiques, la tâche automate réveillera les autres tâches du niveau Contrôle/commande en faisant :

RtPulseEvent (hEvFinCycleAutomate) ;

En effet, à cet instant, toutes les tâches qu’elle est censée réveiller sont en attente de ce signal,

ayant normalement terminé leur activité périodique.

Cependant, si à cet instant, une tâche n’est pas en attente du signal (son exécution

consécutive à la précédente occurrence du signal de réveil n’est pas encore

terminée), la présente occurrence du signal de réveil sera alors perdue pour cette

tâche.

9.2.2 Mécanisme de terminaison des tâches

L’ordre d’arrêt du système de commande est donné par le thread primaire du processus RTSS aux tâches du niveau Contrôle/commande en positionnant l’indicateur

iCcdeActif à FAUX.

Cet indicateur avait été mis dans l’état VRAI par ce même thread primaire juste

avant de commander le démarrage des tâches du niveau Contrôle/commande.

Chacune des tâches autres que la tâche automate présente en effet une structure en boucle contrôlée par la variable iCcdeActif :

automate

xxxxxx

collecteObs

Niv

eau

de

pri

orit

é d

écro

issa

nte

Tâches

temps

A chaque expiration du temporisateur

période d’échantillonnage



TantQue iCcdeActif = VRAI faire :

Attendre le signal de réveil émis par l’automate

Exécuter les traitements spécifiques à la tâche

finTantQue

Après avoir donné l’ordre de mise hors service du niveau Contrôle/commande, le thread primaire se met en attente de la fin de la tâche la moins prioritaire, puis éventuellement du signal evFinCycleAutomate. En effet, suivant l’application de

contrôle/commande, il peut être préférable que la dernière tâche exécutée soit, non la tâche la moins prioritaire, mais la tâche la plus prioritaire (en l’occurrence, la tâche automate).

Avant de mettre hors service l’interface entre le système informatique et la partie opérative en appelant la fonction mettreHorsServiceInterfacePO(), le thread primaire désactive et supprime le timer RTX qui gère l’exécution périodique de la tâche automate

9.2.3 Communication entre les tâches du niveau Contrôle/commande

Bien que la communication entre les tâches du niveau Contrôle/commande se fasse par l’intermédiaire de variables globales, la synchronisation de leur exécution telle qu’elle vient d’être décrite permet de supprimer les problèmes de conflit d’accès à ces variables partagées.

Les données partagées par l’ensemble des tâches du niveau Contrôle/commande

peuvent être réparties en 2 ensembles :

1. les variables d’état de l’automate et de la partie opérative, qu’il s’agisse de variables non spécifiques à l’application ou de variables spécifiques à cette dernière.

2. les variables globales requises pour la synchronisation de l’activité de ces tâches.

9.3 Communication entre la tâche automate et le niveau Supervision

La communication entre la tâche automate et le niveau Supervision se fait par l’intermédiaire de deux canaux :

1. Le canal 2 pour ce qui concerne les demandes de service que lui adresse la tâche

superviseur.

2. Le canal 3 pour ce qui concerne les données E/S dont la tâche automate fait l’acquisition lors de certaines opérations de contrôle/commande, et qu’elle doit ensuite transmettre à la tâche realiseOpSvisionNI du niveau Supervision.

9.3.1 Communication entre la tâche automate et la tâche superviseur

A chacune de ses activations périodiques, la tâche automate vérifie si un message de demande de service lui a été adressé.

Si c’est le cas, elle envoie d’abord un message de prise en compte ou non de la demande de service puis, si la demande est acceptée, un message de compte-rendu à la fin

de l’exécution de l’opération demandée (cf. § 6.2 Canal 2 : Ordres et compte rendus relatifs

aux opérations de contrôle/commande).



9.3.2 Transmission de données E/S au niveau Supervision

Lors d’une opération d’acquisition de données E/S, la tâche automate acquiert un

ensemble de données à chaque période d’échantillonnage (ou selon une périodicité multiple de celle-ci), puis les transmet à la tâche realiseOpSvisionNI par l’intermédiaire du canal 3 de communication entre le processus Win32 RTX et le processus RTSS.

C’est la tâche automate qui assure, en tant que producteur de données, la gestion

complète de ce canal, et donc les opérations d’ouverture et de fermeture du canal. Elle le fait en faisant appel aux 3 fonctions suivantes :

1. ouvrirCanalBALdataES()

2. envoyerMessageBALdataES()

3. fermerCanalBALdataES()

Pour pouvoir ranger un message dans la boite aux lettres BALdataES, la fonction envoyerMessgeBALdataES() doit disposer :

d’une part, d’une unité du sémaphore à compte semaBALdataES et

d’autre part, du mutex mutexBALdataES.

Or, en raison de sa nature, la tâche automate ne doit en aucun cas se trouver à un

moment donné en attente sur l’un ou l’autre de ces objets. Aussi la fonction envoyerMessageBALdataES() ne fait que tester ces objets.

La valeur de retour de cette fonction a les significations suivantes :

> 0 : nombre de messages envoyés (1 ou 2)

0 : pas d'envoi de message, mais pas non plus d'alarme à déclencher

-1 : l'alarme AL_BALdataES_pleine doit être déclenchée

-2 : l'alarme AL_mutexBALdataES_occupe doit être déclenchée L’indication du déclenchement de cette dernière alarme est faite lorsque

la fonction trouve 2 fois de suite le mutex mutexBALdataES occupé.

Ainsi, lorsque la valeur de retour de la fonction envoyerMessageBALdataES() est

négative, la tâche automate déclenche une alarme.

9.4 Gestion des alarmes

Les tâches du niveau Contrôle/commande sont susceptibles, au cours de leurs diverses activités, de détecter des situations d’erreur. Chaque fois qu’une tâche détecte une situation d’erreur, elle déclenche une alarme.

Toutes les alarmes déclenchées par le niveau Contrôle/commande font l’objet d’une signalisation au niveau Supervision, et ce, dans l’ordre de leur apparition. Pour cela, on utilise une file FIFO, la file alarmes où est rangé le code de chaque situation d’erreur détectée. La signalisation des alarmes au niveau Supervision est gérée par la tâche collecteObs. C’est

également cette tâche qui après l’acquittement d’une alarme retire celle-ci de la file des alarmes.

Pour la gestion de la file FIFO des alarmes, nous ferons appel à la fonction gestionFIFO() telle qu’elle est décrite dans Pratiques de la programmation en C.

L’instruction de déclaration de cette fonction gestionFIFO est la suivante :

int gestionFIFO (int opFIFO, struct FIFO *p, int xIn, int *xOut) ;

La variable de type structure sera ainsi déclarée :



struct FIFO { int F [NB_ALARM_MAX] ; int longueur ; int tete ; int queue ; int compteur ; } ; struct FIFO alarmes ;

Les 4 valeurs que peut prendre le paramètre opFIFO sont les suivantes :

INIT Initialisation de la file

AJOUT Ajout d'un élément en queue de la file

RETRAIT Retrait de l'élément en tête de la file

LECTURE Lecture de la valeur du compteur et de l'élément en tête de la file

Les situations d’erreur ayant conduit au déclenchement d’une alarme doivent

également être prises en compte par la tâche automate. Une alarme peut provoquer non seulement l’interruption de l’éventuelle opération de contrôle/commande en cours d’exécution mais également un changement du mode de fonctionnement de l’automate.

Plusieurs types d’alarmes peuvent conduire à un même traitement effectué par

l’automate, et à un même changement d’état de ce dernier. Pour l’ensemble des alarmes, il faut donc répertorier les différents traitements et changements d’état qu’elles déclenchent au niveau de l’automate. A chacun d’eux est attribué un code qui correspond à son niveau d’importance ou d’urgence, ou encore au niveau de gravité de la situation d’erreur ayant conduit au déclenchement de l’alarme. Il est à noter que plusieurs types d’alarme peuvent

conduire, au niveau de l’automate, à un même traitement ou à un même changement d’état. Les valeurs des codes attribués aux traitements croissent en fonction de leur niveau d’urgence ou d’importance.

Cette hiérarchisation des traitements est nécessaire car au cours d’une période

d’échantillonnage plusieurs alarmes peuvent apparaître. Dans ce cas, il faut que

l’automate les prenne en compte en fonction de leur niveau d’urgence, comme le

ferait pour les interruptions matérielles l’ordonnanceur câblé.

On met donc en œuvre un mécanisme qui à chaque période d’échantillonnage mémorise la dernière alarme la plus grave (conduisant de ce fait au traitement le plus urgent ou le plus important) non encore prise en compte par l’automate.

Lorsqu’une alarme apparaît, on mémorise dans les variables globales codeALmax et

itALmax son code ainsi que celui du traitement que l’automate doit réaliser. Si une autre alarme apparaît au cours de la même période d’échantillonnage, celle-ci n’est mémorisée dans codeALmax et itALmax que si le niveau d’importance ou d’urgence du traitement à effectuer au niveau de l’automate est supérieur à celui déjà mémorisé dans itALmax.

A chaque détection d’une situation d’erreur, les tâches du niveau Contrôle/commande appelleront la fonction declencherAlarme() dont voici le code en langage C :

void declencherAlarme (int noAlarme, int nivAlarme) {

gestionFIFO (AJOUT, &alarmes, noAlarme, NULL) ; if (itALmax < nivAlarme) {

codeALmax = noAlarme ; itALmax = nivAlarme ;

} return ;

}



Ensuite, à chaque période d’échantillonnage, au moment qu’elle juge le plus approprié, la tâche automate teste la valeur de la variable itALmax :

Si itALmax = 0, aucune alarme n’est apparue ou, une alarme ayant été déclenchée, celle-ci n’impose à l’automate aucun traitement particulier ou changement d’état.

Si itALmax > 0, une alarme est apparue. La valeur de itALmax indique

l’importance ou l’urgence du traitement ou du changement d’état à effectuer. La tâche automate l’effectue puis remet à zéro les 2 variables codeALmax et itALmax.

*******************

UE Automatisme C1 (AUT209) Annexe : Mise en œuvre du canal 3


10. Le processus RTSS : description des threads

10.1 Le thread primaire et la fonction mettreEnServiceInterfacePO()

Comme indiqué dans le paragraphe 9.1.1 La raison d’être des différents threads du

processus RTSS, au démarrage du processus RTSS, le thread primaire assure :

d’une part, toutes les opérations de création des agents actifs (tâches) et des ressources dont ont besoin ces derniers pour réaliser l’objectif confié à la partie temps réel (déterministe) de l’application ;

d’autre part, la mise en service de l’interface entre le système informatique de

commande et la partie opérative (machine ou procédé physique).

Ce qui dans ces opérations de création et mise en œuvre est propre à une application particulière, notamment ce qui concerne la gestion des entrées/sorties avec la partie opérative, est réalisé par une fonction spécifique - la fonction mettreEnServiceInterfacePO() - à partir des paramètres de configuration transmis au processus RTSS par le processus Win32

RTX. Ces paramètres de configuration peuvent être communiqués au processus RTSS :

soit directement par la zone de mémoire partagée MPprocessCcde ;

soit par un fichier dont le nom et le chemin d’accès sont transmis au processus RTSS par l’intermédiaire de cette zone de mémoire partagée MPprocessCcde.

10.1.1 Déroulement du thread primaire

La création de la partie temps réel de l’application consiste, à partir des paramètres de

configuration transmis par le processus Win32 RTX, à créer toutes les tâches nécessaires au contrôle/commande du procédé physique, et toutes les ressources dont ces tâches ont besoin.

Important ! Pour tous les modes opératoires (ou de fonctionnement) de l’application

temps réel, toutes les tâches et toutes les ressources dont ces tâches peuvent avoir

besoin au cours de leur activité doivent être créées avant le démarrage effectif de

la partie contrôle/commande, c’est-à-dire avant le démarrage de la tâche automate.

En effet, la création d’un objet comporte une opération d’allocation mémoire. Or ces

opérations d’allocation mémoire, qui sont assurées par Windows, ne sont pas des

opérations déterministes ; elles doivent donc être faites avant que démarre l’activité

de la partie temps réel (donc déterministe) de l’application.

Avant toute opération de contrôle/commande demandée par le niveau Supervision, il

faut que les objets assurant les échanges avec les entités physiques aient été créés

et même que la commande de ces entités physiques a ient été initialisée, c’est-à-dire

que ces dernières aient été mises dans un certain état (état de repos). En d’autres

termes, il faut que l’automatisme ait été entièrement mis en service et soit donc

opérationnel.

D’un point de vue informatique, il faut que les tâches du niveau Contrôle/commande,

et notamment la tâche automate, n’ait, à aucun moment, à réaliser des opérations de

création d’objets (threads, etc…) et plus généralement à appeler des fonctions non

déterministes de l’API temps réel de RTX, comme par exemple, les fonctions

RtCreateTimer(), RtAttachInterruptVector(), RtGetBusDataByOffset() et

RtEnablePortIo().

Annexe : Mise en œuvre du canal 3 UE Automatisme C1


Si l’opération de mise en service de l’interface avec la partie opérative et d’initialisation de cette dernière a pu se dérouler normalement (ceci est assuré par la fonction mettreEnServiceInterfacePO()), le thread primaire crée les tâches du niveau Contrôle/commande puis démarre leur activité.

A partir de cet instant, la partie temps réel est opérationnelle quoique dans l’état

AU_REPOS ; elle est prête à recevoir et à traiter les demandes de service que la tâche superviseur est censée lui adresser.

Après avoir positionné l’indicateur iCcdeActif dans l’état VRAI, démarré les tâches du niveau Contrôle/commande et envoyé un message de compte-rendu au processus Win32 RTX,

le thread primaire se met en attente du signal de demande de terminaison du processus RTSS (signal evCdeFinProcessCcde émis par le thread primaire du processus Win32 RTX).

Quand il reçoit ce signal, le thread primaire enclenche le mécanisme de terminaison des tâches en positionnant l’indicateur iCcdeActif dans l’état FALSE, comme décrit dans le paragraphe 9.2.2 Mécanisme de terminaison des tâches.

Quand toutes les tâches du niveau Contrôle/commande se sont terminées, le thread

primaire appelle la fonction spécifique mettreHorsServiceInterfacePO() pour annuler ou détruire ce qui a été fait par la fonction mettreEnServiceInterfacePO(), puis se termine. L’arrêt de l’activité du niveau Contrôle/commande entraîne donc la terminaison du processus RTSS.

10.1.2 La fonction spécifique mettreEnServiceInterfacePO()

Puisque la fonction mettreEnServiceInterfacePO() assure la mise en service des contrôleurs d’E/S, il est nécessaire de prévoir le cas où des erreurs sont détectées lors de l’exécution de cette opération.

La création et mise en service de la partie temps réel peut ne pas aboutir. En effet,

certaines opérations en rapport avec les cartes d’E/S peuvent ne pas se dérouler

correctement en raison d’une défaillance du matériel.

Dès qu’elle rencontre une erreur, la fonction mettreEnServiceInterfacePO() génère un message d’erreur puis s’interrompt. Les messages d’erreur sont des messages textuels rangés dans une variable de type chaîne de caractères : la variables texteCRConfigCcde de la zone

de mémoire partagée MPprocessCcde.

La fonction mettreEnServiceInterfacePO() utilisera la fonction de bibliothèque sprintf()

pour générer un message d’erreur et le ranger directement dans cette variable.

Exemple :

char texteCRConfigCcde [160] ;

int jcr ;

jvl = sprintf (pMPprocessCcde->versionLogiciel,

"\nProcessus RTSS : version %s du %s", VERSION_LOGICIEL, DATE_LOGICIEL);

jcr = sprintf (texteCRConfigCcde,

"\nErreur lors de la validation de l’acces direct a la carte PC104BIM :") ;

sprintf (texteCRConfigCcde + jcr,

"\n\tErreur RtEnablePortIo (0x%x, 0x%x) = %d",

PORT_EPP_BASE, PORT_EPP_RANGE, GetLastError()) ;

…..



La fonction mettreEnServiceInterfacePO() retourne TRUE si l’opération de création de la partie contrôle/commande a pu se dérouler sans aucune erreur, et FALSE si à la suite d’une erreur elle n’a pu aller à son terme.

Pour envoyer au processus Win32 RTX le compte-rendu de fin de l’opération de création et d’initialisation de la partie contrôle/commande, le thread primaire aura

simplement, après l’appel de la fonction mettreEnServiceInterfacePO(), à affecter la bonne valeur à la variable codeCRConfigCcde :

CONFIG_CCDE_OK si la fonction mettreEnServiceInterfacePO() retourne TRUE,

CONFIG_CCDE_ERR si elle retourne FALSE,

puis à mettre dans l’état arrivé l’événement evCRprocessCcde.

Lorsque la fonction mettreEnServiceInterfacePO() a retourné FALSE, le thread primaire se termine après avoir clos les handles vers les objets IPC de communication et synchronisation avec le processus Win32 RTX.

10.1.3 Algorithme général du thread primaire

Fixer et mémoriser le niveau de priorité du thread primaire ouvrirCanauxVersSupervision ()

Si mettreEnServiceInterfacePO () = VRAI alors :

Créer le timer RTX de gestion de la tâche automate

Créer suspendue la tâche collecteObs

Modifier la priorité de la tâche collecteObs

Créer l’objet evFinCycleAutomate de type event à reset manuel

Activer le timer RTX de gestion de la tâche automate

Envoyer au processus Win32 RTX un compte-rendu de mise en service de la partie

contrôle/commande (avec codeCRConfigCcde = CONFIG_CCDE_OK)

iCcdeActif := VRAI

Démarrer l’exécution de la tâche collecteObs

Attendre l’occurrence du signal evCdeFinProcessCcde

iCcdeActif := FAUX

Attendre la fin de la tâche collecteObs

Désactiver et détruire le timer RTX de gestion de la tâche automate mettreHorsServiceInterfacePO() ;

sinon

Envoyer au processus Win32 RTX un compte-rendu de non mise en service de la

partie contrôle/commande (avec codeCRConfigCcde = CONFIG_CCDE_ERR)

finSi

fermerCanauxVersSupervision () Fin du processus RTSS



10.2 La tâche de collecte des observations

10.2.1 Rôle de la tâche collecteObs

Les observations faites par l’automate sur l’état de la partie opérative, la tâche

collecteObs les collecte, éventuellement les synthétise, puis met à jour, à l’intention de la tâche afficheObs du niveau Supervision, les images d’un certain nombre de variables d’état du niveau Contrôle/commande.

Suivant les applications, cette tâche assurera une ou plusieurs des fonctions suivants :

1. Traitements effectués à chaque période d’échantillonnage en fonction de l’état de

l’automate, ou systématiquement, quelque soit cet état.

2. Traitements effectués périodiquement, selon une périodicité multiple de la période d’échantillonnage, en fonction de l’état de l’automate et de la partie opérative, ou systématiquement, quelque soit cet état.

3. Mise à jour, dans la zone de mémoire partagée MP_Observations, des images de variables d’état de niveau Contrôle/commande : la valeur de ces variables images seront exploitées par la tâche afficheObs pour la mise à jour de l’affichage au niveau de l’IHM.

La tâche collecteObs signale au niveau Supervision les alarmes, l’une après l’autre, en

prenant toujours celle qui est en tête de la file alarmes. Le signalement de l’alarme suivante est fait lorsque la précédente alarme signalée a été acquittée par l’opérateur.

La variable alarmeSignalee mémorise le numéro de l’alarme qui est présentement signalée à l’opérateur et qui n’a pas encore été acquittée par ce dernier.

10.2.2 Algorithme de la tâche collecteObs

cpMAJ_iVE := periodeMAJ_iVE alarmeSignalee := 0

TantQue iCcdeActif = VRAI faire : Attendre le signal de réveil émis par la tâche automate

cpMAJ_iVE := cpMAJ_iVE - 1 // Gestion de la périodicité de MAJ des iVE Si cpMAJ_iVE = 0 alors : cpMAJ_iVE := periodeMAJ_iVE Si alarmeSignalee = 0 alors : gestionFIFO (LECTURE, &alarmes, 0, &alarmeSignalee) <> 0) Si alarmeSignalee <> 0 alors : RAZ du signal evAcquitAlarme finSi sinon Si réception du signal evAcquitAlarme alors : gestionFIFO (RETRAIT, &alarmes, 0, &alarmeSignalee) alarmeSignalee := 0 finSi finSi iVE_etatPO := etatPO

iVE_ssEtatPO := ssEtatPO iVE_alarmeSignalee := alarmeSignalee

Mettre à jour l’image des autres variables d’état de l’application Signaler à la tâche afficheObs cette mise à jour (evMAJObs) finSi finTantQue

Fin de la tâche collecteObs



10.3 La tâche automate

La tâche automate tout à la fois gère les entrées/sorties avec le procédé physique et

assure le contrôle/commande de ce dernier d’après les directives qu’il reçoit du niveau Supervision.

La tâche automate est une tâche périodique : il s’agit plus précisément de la séquence de traitement qui a été associée à un thread timer RTX lors de la création de ce dernier, et qui

est exécutée à chaque expiration du temporisateur ; la périodicité d’exécution de cette séquence est fixée à la valeur de la période d’échantillonnage des entrées/sorties. C’est un paramètre de configuration du niveau Contrôle/commande.

Si l’échantillonnage des E/S se fait selon des périodicités différentes, la période du

timer RTX associé à l’automate est celle qui correspond à la plus petite période

d’échantillonnage.

A la fin de chacune de ses exécutions périodiques, la tâche automate réveille les autres tâches du niveau Contrôle/commande (cf. § 9.2.1 Choix relatifs à l’organisation de

l’activité des tâches).

Lors de certaines opérations non immédiates de contrôle/commande (en fait lors d’opérations conjointes du niveau Supervision et du niveau Contrôle/commande), l’automate acquiert à chaque période d’échantillonnage (ou à une périodicité multiple de celle-ci) des

données d’E/S et les transmet à la tâche realiseOpSvisionNI du niveau Supervision.

La transmission de ces données se fait selon le schéma de communication producteur/consommateur, la tâche automate jouant le rôle de producteur et le tâche realiseOpSvivion, celui de consommateur.

C’est donc une fonction occasionnelle que la tâche automate a à assurer à la suite

d’une demande de service reçu du niveau Supervision. Avant de pouvoir envoyer des

messages de données E/S, la tâche automate doit ouvrir le canal de communication

avec le processus Win32 RTX, puis, quand l’opération est terminée, le fermer et

signaler cette fermeture au processus Win32 RTX.

Exemple d’organigramme général de la tâche automate

Si iSynchroCcde <> 0 alors :

declencherAlarme (AL_synchroCcde, 0)

finSi

Quand (etatPO)

= EN_DEFAILLANCE :

gestionPO_EN_DEFAILLANCE ()

= EN_PREPARATION :

gestionPO_EN_PREPARATION ()

= EN_CDE_BO :

Si gestionPO_EN_CDE_BO (&causeFinOpCcde) = VRAI alors : // Préparation et envoi à la tâche superviseur du message de compte rendu :

causeItOp := causeFinOpCcde

Si causeItOp = 0 alors :

codeCRCcde := CR_OP_OK

sinon

codeCRCcde := CR_OP_IT

finSi



vCR_etatPO := etatPO

vCR_ssEtatPO := ssEtatPO

RtReleaseSemaphore (hSemaPCRCcde, 1, NULL)

finSi

finQuand

// Test de la présence éventuelle d’un message de demande de service envoyé par la tâche

superviseur :

Si RtWaitForSingleObject (hEvOrdreCcde, 0) = WAIT_OBJECT_0 alors :

causeRefus := 0

Si alarmes non acquittées alors :

causeRefus := AL_NON_ACQUIT

sinon

Si etatPO = EN_CDE_BO ET ssEtatPO = AU_REPOS alors :

Prendre en compte la demande de service et

renseigner la variable typeOP (catégorie de l’opération à réaliser)

Si valeur de codeOrdreCcde inconnue alors :

causeRefus := -1

finSi

sinon

causeRefus := INCOMPATIBLE

finSi

finSi

// Préparation et envoi du message de prise en compte ou non de la demande de service :

typeOpCcde := 0

causeRefus := 0

Quand (causeRefus)

= -1:

codePCcde := PC_INCONNU

= 0:

codePCcde := PC_ACCEPTE

typeOpCcde := typeOp

= AL_NON_ACQUIT ou INCOMPATIBLE :

codePCcde := PC_REFUSE

causeRefus := causeRefus (variable locale)

finQuand

vPC_etatPO := etatPO

vPC_ssEtatP := ssEtatPO

RtReleaseSemaphore (hSemaPCRCcde, 1, NULL)

finSi

iSynchroCcde := NB_TACHES // Réveil des autres taches du niveau Contrôle/commande :

RtPulseEvent (hEvFinCycleAutomate)

*******************

Documents

jkjljljljl