Vous êtes sur la page 1sur 92

Conservatoire

Chaire

National

des

d’automatisme

Arts et

industriel

Métiers

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

applications

pour les

de contrôle-commande

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

Pierre BLANDIN

Conservatoire

Chaire

National

des

d’automatisme

UE mixte Automatisme C1

Arts et

industriel

Métiers

(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

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,

BLANDIN P. :

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

d’Automatique, CNAM Paris, 2008-2009

BLANDIN P. :

2008

Support de formation à RTX 8.1, Laboratoire d’Automatique, CNAM Paris,

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

********

SOMMAIRE

1.

LES APPLICATIONS DE CONTROLE/COMMANDE

7

 

1.1 CARACTERISTIQUES DES APPLICATIONS DE CONTROLE / COMMANDE

7

1.2 DEVELOPPEMENT DES APP LICATIONS DE CONTROLE/COMMANDE

8

1.3 PROGRAMMATION DES APP LICATIONS DE CONTROLE/COMMANDE

9

2. ÉLABORATION D’UNE ARCHITECTURE LO GICIELLE TYPE

11

 

2.1 DECOMPOSITION FONCTIO NNELLE DE LA COMMANDE

11

2.2 JUDICIEUSE DES TRAITEMENTS INFORMATIQUES

REPARTITION

14

CHOIX DUNE

2.3 ARCHITECTURE LOGICIELLE TYPE

14

3. CARACTERIS TIQUES GENERALES DES FONCTIONNALITES A IMPLEMENTER

17

 

3.1 LES DIFFERENTES CATEGORIES DOPERATIONS

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/comman de

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 SPECI FIQUES

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 LOPERATEUR 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

A RCHITECTURE 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 RELATIF S AUX IHM ET A LEUR MISE EN OE UVRE

25

4.3 DEMARRAGE ET TERMINAI SON 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 DE S THREADS DU PROCESSUS W IN32 RTX

27

CONCLUSION

28

A NNEXE : A PROPOS DU DEVELOPPEM ENT ET DU DEPLOIEMENT DUNE APPLICATION

29

5. SYNCHRONISATION ET COMMUNICATION ENTR E L’IHM ET LE CŒUR D E L’APPLICATION

31

 

5.1

M ODES DE SYNCHRONISAT ION 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 LINTERFACE ENTRE L’IHM ET LE CŒUR DE LAPPLICATION

36

5.4 LES FONCTIONS DINTERFACE 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 PROCES S US

43

 

6.1 1 : PARAMETRES ET COMPTE -RENDU DE CONFIGURATION DU NIVEAU CCDE

CANAL

44

6.2 2

CANAL

: ORDRES ET COMPTE RENDUS RELATIFS AUX OPERATIONS DE CCDE 46

6.2.1 A propos des messages de demande de service

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 DUNE 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 D E L’IHM

57

7.1

STRUCTURE DU THREAD P RIMAIRE DU PROCESSUS W IN32 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 SE RVEUR 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

A NNEXE : 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 REALISEOP SVISIONNI

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 CO MMUNICATION ENTRE LE S 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 L A 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 : DES CRIPTION DES THREADS

87

10.1

LE THREAD PRIMAIRE ET LA FONCTION METTRE ENSERVICEINTERFACEPO()

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 TACHE DE COLLECTE DES OBSERVATIONS

LA

90

10.3 TACHE

LA

AUTOMATE

 

91

UE Automatisme C1 (AUT209)

1. Les applications de contrôle/commande

1. Les applications de contrôle/commande

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

applications de contrôle/commande 1 .

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 :

grande diversité de dispositifs d’entrées/sorties : procédés continus (entrées/sorties de type continu ou

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,continus (entrées/sorties de type continu ou analogique), procédés mixtes ;  le respect des propriétés de

procédés mixtes ;de type numérique) : systèmes à événements discrets,  le respect des propriétés de la sûreté

le respect des propriétés de la sûreté de fonctionnement, en particulier :

de la sûreté de fonctionnement, en particulier : fiabilité (continuité de service), sécurité (garantie de

fiabilité (continuité de service),

sécurité (garantie de la non occurrence de défaillances) ;en particulier : fiabilité (continuité de service),  la prise en compte de comportements concurrents

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 contrainte s 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

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é signaux).

de

de traitement

importante

(traitement

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 fon ctionnement 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

C1 (AUT209) 1. Les applications de contrôle/commande 1.3 Programmation des 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 compl exité 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…),

statistique

traitement

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’a ssociation de plusieurs la ngages et/ou bibliothèques de programmes spécialisées (traitement de signaux, traitement d’i ma ges, 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.

de type blocs fonctionnels très utilisé dans ce domaine. Il est intéressant de noter que la

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.

de contrôle/commande peut ainsi être globalement

schématisée :

Une

telle

application

être globalement schématisée : Une telle application Opérateur Système temps réel Micro-ordinateur équipé

Opérateur

Système temps réel Micro-ordinateur équipé de Windows et RTX actions observations Procédé physique
Système temps réel
Micro-ordinateur équipé de
Windows et RTX
actions
observations
Procédé physique

2.1 Décomposition fonctionnelle de la commande

Dans un premier temps, nous allons examiner comme nt le système de commande peut être struc turé 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.

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 gl obalement 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.

faut détailler le couplage général existant entre les deux catégories de fonctions. 12 Pierre B LANDIN

UE Automatisme C1 (AUT209)

2. Élaboration d’une architecture logicielle type

Le modèle Supervision / contrôlecommande (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ôlecommande vers supervision, nécessite aussi deux catégories d’informations :

des observations qui, synthétisées par la partie contrôlecommande, 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écification s sont prises en compte.

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

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.

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 a pplication 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 ).

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 .

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.

UE Automatisme C1 (AUT209)

2. Élaboration d’une architecture logicielle type

2. Élaboration d’une architecture logicielle type Opérateur Processus Win32 RTX Supervision Fonctions

Opérateur

Élaboration d’une architecture logicielle type Opérateur Processus Win32 RTX Supervision Fonctions non

Processus Win32 RTX

Supervision

Fonctions non déterministes

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

Ordres Réactions Paramètres Observations Processus RTSS Contrôle - commande Fonctions déterministes Gestion des
Ordres
Réactions
Paramètres
Observations
Processus RTSS
Contrôle - commande
Fonctions déterministes
Gestion des E/S avec le procédé physique
Actions
Observations
Procédé physique

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.

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 a ucune hypothèse n’est fait e 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

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 peu t ê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.

durée d’exécution

d’une opération

s’apprécie essentiellement au

regard

de

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.

UE Automatisme C1 (AUT209)

3. Caractéristiques des fonctionnalités

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 de s 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

UE Automatisme C1 (AUT209)

3. Caractéristiques des fonctionnalités

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

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.

comprendre

3

taches :

la

tâche

superviseur ,

la

tâche

afficheObs

et

la

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 termine ra 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)

Demandes de service spécifiques à l’application Demande de préparation de l’affichage de l’état du du
Demandes de service
spécifiques à l’application
Demande de préparation de
l’affichage de l’état du
du système et de la PO
Demande d’interruption
de l’opération non
immédiate en cours
Demande
d’acquittement de
l’alarme signalée
Tâche superviseur
Tâche afficheObs
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.
Elle prépare pour l’IHM l’affi chage :
 de l’état du système et de la PO,
 des messages de service émis par
la tâche superviseur
Demandes de service
conduisant à des opérations
de contrôle-commande
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
Observations sur l’état de la PO
et de l’automate.
Alarme à signaler à l‘opérateur

Processus RTSS

niveau Contrôle/commande

UE Automatisme C1 (AUT209)

4. Choix structurels

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 cont rô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é p ar 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.

4.

Choix structurels

UE Automatisme C1

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

typeIHM = IHM_CONSOLE

typeIHM = IHM_OPC

aucune IHM n’est en service

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

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.

UE Automatisme C1 (AUT209)

4. Choix structurels

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 p eut ê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

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

tâche afficheObs

Le thread primaire

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

(prioriteThreadPrimaire + 3) (prioriteThreadPrimaire + 2) (prioriteThreadPrimaire + 1) (prioriteThreadPrimaire) (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.

4.

Choix structurels

UE Automatisme C1

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.

UE Automatisme C1 (AUT209)

4. Choix structurels

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 :

pour le processus RTSS :

nomApplication_win32

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 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.

sous

dossier

intitulé

configuration

contenant

tous

les

fichiers

de

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.

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
Cœur de l’application

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.

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 :

Interface Homme machine (IHM) Demandes de service spécifiques à l’application Demande de préparation de
Interface Homme machine (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
tâche superviseur
Demandes de préparation
de messages destinés à
l’opérateur
tâche afficheObs

Messages textuels prêts à être affichés par l’IHM

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.

UE Automatisme C1 (AUT209)

5. Communication entre IHM et tâches de supervision

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 :

puis atten d le message

1. L’IHM transmet la demande à la tâche afficheObs

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)

Code de la demande de service :

int codeDdeService ;

Paramètres des demandes de service :

; Paramètres des demandes de service : … declencherDdeService() acquitterCRddeService() tâche

declencherDdeService()

acquitterCRddeService()

tâche superviseur

5.

Communication entre IHM et tâches de supervision

UE Automatisme C1

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 à

0

codeOpEnCours

CODE_CRddeService

Valeur à donner à

Valeur à donner à

codeCRddeService

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 .

UE Automatisme C1 (AUT209)

5. Communication entre IHM et tâches de supervision

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 d e 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 Sys tè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

5.

Communication entre IHM et tâches de supervision

UE Automatisme C1

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 d e 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 c onsole 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.

UE Automatisme C1 (AUT209)

5. Communication entre IHM et tâches de supervision

IHM de type console IHM de type OPC Messages envoyés par BALconsole la tâche afficheObs
IHM de type console
IHM de type OPC
Messages envoyés par
BALconsole
la tâche afficheObs
Mise à jour
Code de la demande de service :
declencherDdeService()
arreterOpNIenCours()
preparerAffichageEtat()
int codeDdeService ;
Paramètres des demandes de service :
mettreAJourDataOpNIO()
acquitterCRddeService()
acquitterAlarme()
Autres variables de l’interface entre IHM
et les tâches superviseur et afficheObs :
Variables donnant l'état de la PO et du système de commande :
1) Variables non spécifiques à l'application :
Type de l’ IHM en service :
byte
etatPO;
char
int typeIHM
byte
ssEtatPO;
char
Type de l’opération en cours :
byte
alarmeCcde;
char
int typeOpEnCours ;
byte
codeOpEnCours;
char
Pointeur sur les données à MAJ (cas d’une opération NIO) :
byte
codeCRddeService;
char
texteEtatPO[ ];
texteSsEtatPO[ ];
texteAlarmeCcde[ ];
texteOpEnCours[ ];
texteCRddeService[ ];
int *pDataOpNIO ;
byte
causeItOpEnCours;
Indicateur de mise à jour des VE textuelles :
signed char iMAJtexte[6] ;
char
texteEtatCcde[ ];
Période en ms de màj des variables associéex aux items L :
2) variables spécifiques à l'application :
int periodeMajVarEnL ;
Mise à jour
Messages envoyés par l’IHM
evReveilIHM
BALafficheObs
et par la tâche superviseur
tâche superviseur
tâche afficheObs

5.

Communication entre IHM et tâches de supervision

UE Automatisme C1

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.