jkjljljljl | Informatique | Automatisation\nenregistrerEnregistrer jkjljljljl pour plus tard\n24 vues92 pages\nÉtude de cas GANESH\nUE mixte Automatisme C1\nArchitecture logicielle type\n1. Les applications de contrôle/commande\n2. Élaboration d’une architecture logicielle type\n3. Caractéristiques générales des fonctionnalités à implémenter\n4. Choix structurels découlant du type de fonctionnalités à implémenter\n5. Communication entre IHM et tâches permanentes de supervision\n6. Synchronisation et communication entre les 2 processus\n7. Le processus Win32 RTX : implémentation de l’IHM\n8. Le processus Win32 RTX : implémentation du niveau Supervision\n9. Le processus RTSS : structuration du niveau Contrôle/commande\n10. Le processus RTSS : description des threads\nTél. : 01 42 16 88 44\nFax : 01 45 86 21 18\nSite web : http://automatique.cnam.fr/\nCOTTET F., RENARD P. : Programmation graphique des applications de contrôle/commande,\nTechniques de l’Ingénieur, traité « Informatique industrielle ».\nCALVEZ 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,\nBLANDIN P. :\nSupport de cours sur les Systèmes temps réel multitâches, Laboratoire\nd’Automatique, CNAM Paris, 2008-2009\nSupport de formation à RTX 8.1, Laboratoire d’Automatique, CNAM Paris,\nSur le site web du Laboratoire http://automatique.cnam.fr/ on accède aux deux derniers documents pédagogiques en suivant le chemin suivant :\nFormations et diplômes -> Les unités d'enseignement -> AUT107\nLES APPLICATIONS DE CONTROLE/COMMANDE\n1.1 CARACTERISTIQUES DES APPLICATIONS DE CONTROLE / COMMANDE\n1.2 DEVELOPPEMENT DES APP LICATIONS DE CONTROLE/COMMANDE\n1.3 PROGRAMMATION DES APP LICATIONS DE CONTROLE/COMMANDE\n2. ÉLABORATION D’UNE ARCHITECTURE LO GICIELLE TYPE\n2.1 DECOMPOSITION FONCTIO NNELLE DE LA COMMANDE\n2.2 JUDICIEUSE DES TRAITEMENTS INFORMATIQUES\n2.3 ARCHITECTURE LOGICIELLE TYPE\n3. CARACTERIS TIQUES GENERALES DES FONCTIONNALITES A IMPLEMENTER\n3.1 LES DIFFERENTES CATEGORIES D’OPERATIONS\nLa notion d’opération dans une application de contrôle/commande\nCritères de classement des opérations d’une application de contrôle/comman de\nTypologie des opérations d’une application de contrôle/commande\nOpérations spécifiques et opérations non spécifiques à une application\n3.2 IMPLEMENTATION, EN FONCTION DE LEUR CATEGORIE , DES OPERATIONS SPECI FIQUES\n3.2.1 La tâche dite superviseur\n3.2.2 Le traitement des opérations relevant du niveau Supervision\n3.2.3 Répartition des traitements à effectuer en fonction de la catégorie de l’opération\nORDRES DE L’OPERATEUR NON SPECIFIQUES A UNE APPLICATION\nDemande d’affichage de l’état du système de commande et de la partie opérative\nDemande d’interruption de l’opération non immédiate en cours\nAcquittement de l’alarme signalée\n4. CHOIX STRUCTURELS DECOULANT DU TYPE DE FONCTIONNALITES A IMPLEMENTER\nA RCHITECTURE GENERALE DU NIVEAU SUPERVISION\nLes tâches permanentes : la tâche superviseur et la tâche afficheObs\nLa tâche temporaire realiseOpSvisionNI\nSchéma récapitulatif de l’architecture du niveau Supervision\nPartie logicielle du système de commande\n4.2 CHOIX DE BASE RELATIF S AUX IHM ET A LEUR MISE EN OE UVRE\n4.3 DEMARRAGE ET TERMINAI SON DE L ’APPLICATION DE CONTROLE-COMMANDE\nLancement et démarrage de l’application\nArrêt du système de commande et terminaison de l’application\nNIVEAU DE PRIORITE DE S THREADS DU PROCESSUS W IN32 RTX\nA NNEXE : A PROPOS DU DEVELOPPEM ENT ET DU DEPLOIEMENT D’UNE APPLICATION\n5. SYNCHRONISATION ET COMMUNICATION ENTR E L’IHM ET LE CŒUR D E L’APPLICATION\nM ODES DE SYNCHRONISAT ION ET NATURE DES INFORMATIONS ECHANGEES\nProcédure de traitement d’une demande de service\nProcédure de traitement d’une demande de préparation de l’affichage\nCOMMUNICATION ENTRE IHM, TACHE SUPERVISEUR ET TACHE AFFICHEOBS\nSynchronisation et communication entre l’IHM et la tâche superviseur\nSynchronisation et communication entre la tâche superviseur et la tâche afficheObs\nSynchronisation et communication entre l’IHM et la tâche afficheObs\n5.3 STRUCTURE DE L’INTERFACE ENTRE L’IHM ET LE CŒUR DE L’APPLICATION\n5.4 LES FONCTIONS D’INTERFACE APPELEES PAR L’IHM\n5.4.1 Description des 6 fonctions\n5.4.2 Liens entre les 6 fonctions et le serveur OPC (cas d’une IHM de type OPC)\n6. S YNCHRONISATION ET COMMUNICATION ENTRE LES 2 PROCES S US\n6.1 1 : PARAMETRES ET COMPTE -RENDU DE CONFIGURATION DU NIVEAU CCDE\n: ORDRES ET COMPTE RENDUS RELATIFS AUX OPERATIONS DE CCDE 46\n6.2.1 A propos des messages de demande de service\nInformations nécessaires à la réalisation d’une opération non immédiate ouverte\nInterruption d’une opération non immédiate de contrôle -commande\nLes messages de prise en compte et de compte-rendu\nDONNEES E/S ACQUISES LORS D’UNE OPERATION DE CCDE\n6.4 CANAL 4 : OBSERVATIONS SUR L ’ETAT DE L ’AUTOMATE ET DE LA PO\nLes variables images des variables d’état du système de contrôle/commande\nLes variables images non spécifiques à une application particulière\nMise à jour périodique des variables images\nL’acquittement de l’alarme signalée\n7. LE PROCESS US WIN32 RTX : IMPLEMENTATION D E L’IHM\nSTRUCTURE DU THREAD P RIMAIRE DU PROCESSUS W IN32 RTX\nProgramme principal du thread primaire\ncreerCanauxVersCcde() et detuireCanauxVersCcde()\ncreerNiveauSupervision() et detruireNiveauSupervision()\nLes fonctions de gestion du dialogue avec l’application depuis la console\nCONFIGURATION DE L ’APPLICATION ET DU SE RVEUR OPC\nLes différents niveaux de configuration d’une application\nLa fonction configureCcde()\nGESTION DE L ’IHM CONSOLE\n7.3.1 La fonction gestionIHMconsole()\n7.3.2 La fonction opIHMconsole()\nGESTION DE L ’IHM DE TYPE OPC\nLa fonction gestionIHMopc()\nLa description de la base de données exposée par le serveur OPC\nLes fonctions de l’API avec l’application appServeurOPC\nExemple de fonction gestionIHMopc()\nA NNEXE : EXEMPLE DE DESCRIPTION DE LA BASE DE DONNEES EXPOSEE\n8. LE PROCESS US WIN32 RTX : IMPLEMENTATION DU NIVEAU SUPERVISION\nLA TACHE SUPERVISEUR\n8.1.1 Fonctionnalités assurées par la tâche superviseur\n8.1.2 Organigramme général de la tâche superviseur\n8.1.3 La fonction superviseOpCcde()\nLA TACHE REALISEOP SVISIONNI\n8.2 1 Caractéristiques générales de la tâche realiseOpSvivion\nOrganigramme général de la fonction de thread traiteDataES\nLA TACHE AFFICHEOBS\n9. LE PROCESS US RTSS : STRUCTURATION DU NIVEAU CONTROLE/COMMANDE\nSTRUCTURE DU PROCESSUS RTSS\nLa raison d’être des différents threads du processus RTSS\nNiveau de priorité des threads du processus RTSS\nSYNCHRONISATION ET CO MMUNICATION ENTRE LE S TACHES\nChoix relatifs à l’organisation de l’activité des tâches\nMécanisme de terminaison des tâches\nCommunication entre les tâches du niveau Contrôle/commande\nCOMMUNICATION ENTRE L A TACHE AUTOMATE ET LE NIVEAU SUPERVISION\n9.3.1 Communication entre la tâche automate et la tâche superviseur\n9.3.2 Transmission de données E/S au niveau Supervision\n10. LE PROCESS US RTSS : DES CRIPTION DES THREADS\nLE THREAD PRIMAIRE ET LA FONCTION METTRE ENSERVICEINTERFACEPO()\n10.1.1 Déroulement du thread primaire\n10.1.2 La fonction spécifique mettreEnServiceInterfacePO()\n10.1.3 Algorithme général du thread primaire\n10.2 TACHE DE COLLECTE DES OBSERVATIONS\nUE Automatisme C1 (AUT209)\nLe contenu de ce chapitre est extrait de l’article Programmation graphique des\napplications de contrôle/commande 1 .\nUne 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…\n1.1 Caractéristiques des applications de contrôle/commande\nLes 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 :\n le respect de contraintes temporelles adaptées au procédé piloté ;\n la gestion d’une grande diversité de dispositifs d’entrées/sorties :\nprocédés continus (entrées/sorties de type continu ou analogique),\nprocédés discrets (entrées/sorties de type numérique) : systèmes à événements discrets,\nprocédés mixtes ;\n le respect des propriétés de la sûreté de fonctionnement, en particulier :\nfiabilité (continuité de service),\nsécurité (garantie de la non occurrence de défaillances) ;\n la prise en compte de comportements concurrents (parallélisme de l’environnement).\nUne définition de ces systèmes de contrôle-commande pourrait être la suivante : « un\nsystè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 ».\nLa 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 :\n de l’ordre de la milliseconde ou inférieure : systèmes radar, systèmes vocaux, systèmes de mesures physiques ;\n de l’ordre de la seconde : systèmes de visualisation (interface homme-machine) ;\n de l’ordre de la minute : chaîne de fabrication ;\n de l’ordre de l’heure : contrôle de réactions chimiques.\n1 Programmation graphique des applications de contrôle/commande , par Francis COTTET et Patrick RENARD, Techniques de l’Ingénieur, traité Informatique industrielle.\nPierre BLANDIN, Laboratoire d’Automatique, CNAM Paris\nLes applications de contrôle/commande\nUE Automatisme C1\n1.2 Développement des applications de contrôle/commande\nL’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.).\nLe 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 :\ncompteur é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 :\n application formée de multiples équipements (exemple : chaîne de fabrication) ;\n applications nécessitant un haut niveau de sûreté de fonctionnement en utilisant de la redondance matérielle ;\n application requérant une capacité signaux).\nIl 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.).\nAu niveau de l’architecture logicielle d’applications de contrôle-commande, nous pouvons distinguer cinq grandes parties (cf. figure 1) :\n1. le traitement des données internes à l’application : analyse spectrale, loi de commande, etc. ;\n2. les relations avec le procédé à piloter au travers des capteurs/actionneurs et des cartes d’entrées/sorties :\n mesures dans le sens procédé  système de pilotage, et\n commandes dans sens système de pilotage  procédé ;\n3. la gestion de l’interface vers l’opérateur avec la visualisation des données et l’entrée des consignes ;\n4. la relation avec le réseau : réseau local ou bus de terrain ;\n5. la liaison vers une unité de stockage de masse pour la sauvegarde des données.\nAinsi, dans le cas général, le logiciel d’une application de contrôle-commande remplit\ntrois fonctionnalités notées sur la figure 2 , à savoir :\n1. Acquisition de données ;\n2. Analyse et traitement de données ;\n3. Restitution de données.\nPierre BLANDIN, CNAM Paris\n1.3 Programmation des applications de contrôle/commande\nComme 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 :\n1. Acquisition et restitution de données :\n contrôle de cartes d’entrées/sorties analogiques ou numériques,\n contrôle d’instruments par l’intermédiaire de liaisons normalisées : GPIB, RS- 232, VXI, etc.,\n liaison réseau (par exemple TCP/IP), base de données… ;\n2. Traitement de données :\n traitement numériques des signaux (FFT, corrélation, filtrage, fenêtrage…),\n traitement d’images (extraction de contour…),\n élaboration de lois de commande (par exemple, régulation PID),\n maîtrise statistique du procédé (par exemple, analyse de Pareto) ;\n3. Présentation des données :\n interface graphique et interactive,\n représentation de courbes 2D et 3D, représentation d’images,\n stockage des données (impression, archivage…), génération de documents…,\n distribution sur réseau (Internet, Intranet…).\nÉ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.\nIl 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 ).\nNous 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).\nSous 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,\net qui donc peut être Windows 2000, Windows XP ou Windows Vista.\nPour 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.\nde contrôle/commande peut ainsi être globalement\nMicro-ordinateur équipé de\nWindows et RTX\n2.1 Décomposition fonctionnelle de la commande\nDans 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.\nPour 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.\nCe modèle est décrit dans l’encart ci-dessous.\nÉlaboration d’une architecture logicielle type\nLe modèle Supervision / contrôle-commande\nPour 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).\nL’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.\nDe tels systèmes se structurent en au moins deux niveaux :\n un niveau supervision qui assure l’interface avec l’exploitant pour la conduite globale de l’application ;\n 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.\nLes 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.\nhié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.\nLe modèle Supervision / contrôle–commande (suite)\nLe couplage descendant, de supervision vers contrôle-commande, nécessite deux catégories d’informations :\n des paramètres, qui vont qualifier les objectifs à atteindre pour la partie opérative : température de consigne, temps de réponse…\n 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.\nLe couplage ascendant, de contrôle–commande vers supervision, nécessite aussi deux catégories d’informations :\n des observations qui, synthétisées par la partie contrôle–commande, permettront de suivre le déroulement des opérations,\n des réactions, pour signaler au niveau supérieur des situations particulières à prendre en compte.\nLes entrées et sorties pour l’exploitation sont associées à la supervision. Les autres entrées et sorties sont associée à la partie commande.\nMéthode à suivre pour l’emploi de ce modèle\nDe 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.\nLe choix de ce modèle étant fait, la démarche pour sa mise en œuvre est la suivante :\n Identifier les entités liées à chacun des deux niveaux.\n Rechercher par analyse des spécifications, les variables de couplage nécessaires : paramètres dans un sens, observations dans l’autre.\n Rechercher ensuite les événements de couplage, c’est-à-dire les ordres dans un sens, les réactions dans l’autre.\n 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.\n Vérifier la solution pour s’assurer que toutes les spécification s sont prises en compte.\nD’après J.L. CALVEZ : Spécification et conception des systèmes, une méthodologie, p. 334\nLa 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 :\n un processus où seront implémentées les fonctions du niveau Supervision,\n un processus où seront implémentées les fonctions du niveau Contrôle/commande.\n2.2 Répartition judicieuse des traitements informatiques\nPour 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.\nSi, 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 !).\nCes 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.\nAinsi 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 ).\nStructure d’une application temps réel utilisant RTX\nUne application temps réel faisant appel à l’extension temps réel RTX comportera généralement au moins deux processus travaillant de concert :\n 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),\n un processus RTSS dans lequel sont implémentées les fonctionnalités temps réel (déterministes) de l’application.\nIl 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 .\n2.3 Choix d’une architecture logicielle type\nVoici 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 :\n1. 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.\n2. 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.\nProcessus Win32 RTX\nFonctions non déterministes\nGestion d’une interface graphique avec l’utilisateur (GUI)\nGestion des E/S avec le procédé physique\nDeux points de vue sont donc à l’origine de cette architecture type, et de ce fait la justifient :\n1. La décomposition fonctionnelle hiérarchique de la commande fait apparaître :\n un niveau supervision qui assure l’interface avec l’exploitant pour la conduite globale de l’application,\n2. Une application temps réel faisant appel à l’extension RTX de IntervalZero comporte\nnécessairement au moins deux processus travaillant de concert :\n 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 ;\nAinsi, 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.\n3. Caractéristiques des fonctionnalités\nPour 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.\nDans 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 :\n 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 ;\n et d’autre part, aux mécanismes de synchronisation et de communication à mettre en place entre ces différentes tâches.\nLa 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.\n3.1 Les différentes catégories d’opérations\nAvant de décrire les critères qui ont présidé à l’élaboration de la typologie des\nopérations réalisées par les applications de contrôle/commande à la suite d’ordres ou\n3.1.1 La notion d’opération dans une application de contrôle/commande\nUne 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é.\nCompte 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.\nUne 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.\nAinsi 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.\nLe 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.\nCaractéristiques des fonctionnalités\n3.1.2 Critères de classement des opérations d’une application de contrôle/commande\nLa 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 :\n1. Opération de supervision et/ou opération de contrôle/commande\nCeci signifie que l’opération demandée par l’utilisateur sera réalisée :\n soit par le niveau Supervision (processus Win32 RTX),\n soit par le niveau Contrôle/commande (processus RTSS),\n soit conjointement par le niveau Supervision et le niveau Contrôle/commande.\n2. Opération immédiate ou opération non immédiate\nUne 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.\nUne 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.\ns’apprécie essentiellement au\n3. Opération non immédiate fermée ou opération non immédiate ouverte\nOn 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.\nExemple : 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.\nLe 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.\nExemple : 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.\nUne 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.\nL’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.\n3.1.3 Typologie des opérations d’une application de contrôle/commande\nA 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 :\n1. opération immédiate relevant du niveau Supervision\n2. opération immédiate relevant du niveau Contrôle/commande\n3. opération non immédiate (ouverte ou fermée) relevant du niveau Supervision\n(ouverte ou fermée) relevant du niveau\n5. opération non immédiate (ouverte ou fermée) relevant conjointement du niveau Supervision et du niveau Contrôle/commande .\nUne opération non immédiate fermée conjointe de supervision et de contrôle - commande est par exemple :\n 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),\n 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\n3.1.4 Opérations spécifiques et opérations non spécifiques à une application\nAu 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 :\n d’une part, les opérations spécifiques à une application de contrôle/commande particulière ;\n 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.\n3.2 Implémentation, en fonction de leur catégorie, des opérations spécifiques\nConsidé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.\nUne 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.\nLa 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.\nL’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.\nC’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.\nLa tâche superviseur effectue elle-même les traitements relatifs aux opérations immédiates relevant du niveau Supervision.\nPar contre, il semble préférable qu’une tâche du niveau Supervision, distincte de la tâche superviseur, assure les traitement relatifs aux :\n opérations non immédiates du niveau Supervision,\n opérations non immédiates relevant conjointement du niveau Supervision et du niveau Commande/commande.\nCette tâche, appelée realiseOpSvisionNI, assurera ponctuellement les traitements relatifs à ces catégorie d’opérations spécifiques.\nEn définitive, suivant la nature de l’opération demandée, celle -ci est réalisée par :\n la tâche superviseur elle-même s’il s’agit d’une opération immédiate du niveau Supervision ;\n la tâche realiseOpSvisionNI s’il s’agit d’une opération non immédiate du niveau Supervision ;\n le niveau Contrôle/commande s’il s’agit d’une opération de contrôle/commande (immédiate ou non immédiate).\nUne 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.\nLe 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 :\nCatégorie de l’opération…\nOpération réalisée par …\nimmédiate du niveau Supervision\n… la tâche superviseur\nimmédiate du niveau Contrôle/commande\n… le niveau Contrôle/commande\nnon immédiate du niveau Supervision\n… la tâche realiseOpSvisionNI\nnon immédiate du niveau Contrôle/commande\nnon immédiate conjointe\n… le niveau Contrôle/commande et la tâche\n3.3 Ordres de l’opérateur non spécifiques à une application\nParmi 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 :\n1. Demande d’affichage de l’état du système de commande et de la partie opérative\n2. Demande d’interruption de l’opération non immédiate en cours\n3. Acquittement de l’alarme signalée à l’opérateur.\nCes 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.\n3.3.1 Demande d’affichage de l’état du système de commande et de la partie opérative\nLorsque 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.\nCet 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.\n3.3.2 Demande d’interruption de l’opération non immédiate en cours\nL’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.\nAinsi, 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.\nCatégorie de l’opération non immédiate en cours\nLa demande d’interruption sera prise en compte par …\n3.3.3 Acquittement de l’alarme signalée\nChaque 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.\nCet 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.\nSi 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.\n4. Choix structurels\n4.1 Architecture générale du niveau Supervision\nDes fonctionnalités à implémenter, il découle donc que le niveau Supervision va\nLes 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.\nLa 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.\n4.1.1 Les tâches permanentes : la tâche superviseur et la tâche afficheObs\nSuivant 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 :\n S’il s’agit d’une opération immédiate du niveau Supervision, elle exécute elle- même cette opération.\n 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.\n S’il s’agit d’une opération du niveau Contrôle/commande, elle transmet la demande de service au niveau Contrôle/commande.\n 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.\nQuant à 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 .\n4.1.2 La tâche temporaire realiseOpSvisionNI\nCréé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.\nLors 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.\nLa 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.\nIl 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.\n4.1.3 Schéma récapitulatif de l’architecture du niveau Supervision\nDemande de préparation de\nl’affichage de l’état du\ndu système et de la PO\nde l’opération non\nimmédiate en cours\nElle reçoit toutes les demandes de service\nspécifiques à l’application. Elle n’exécute que les\nopérations immédiates du niveau Supervision mais\nsupervise l’exécution de toutes les autres.\nElle prépare pour l’IHM l’affi chage :\n de l’état du système et de la PO,\n des messages de service émis par\nla tâche superviseur\nconduisant à des opérations\nTraitements relatifs à une opération non\nTraitements relatifs à la partie supervision\nd’une opération non immédiate conjointe\nObservations sur l’état de la PO\net de l’automate.\nAlarme à signaler à l‘opérateur\n4.1.4 Partie logicielle du système de commande\nDans notre architecture type, la partie logicielle du système de commande de la partie opérative est constituée des éléments suivants :\n le processus RTSS,\n toutes les tâches (ou threads) du processus Win32 RTX, autre que le programme principal du thread primaire.\nLe 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.\nIl 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.\n4.2 Choix de base relatifs aux IHM et à leur mise en oeuvre\nL’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 :\n1. Une IHM de type caractères (ou texte ou console).\nL’utilisateur interagit avec l’application depuis la console, celle qui est active durant l’exécution du fichier .exe du processus Win32 RTX.\n2. Une IHM de type OPC.\nL’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.\nLe 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.\nDans 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.\nPour l’élaboration de l’architecture logicielle type, les choix suivants ont été faits en ce qui concerne l’IHM :\n 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.\n 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 :\nIHM 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.\n 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\nUne variable globale typeIHM indiquera si une IHM est effectivement en service et quel est son type :\ntypeIHM = AUCUNE_IHM\ntypeIHM = IHM_CONSOLE\ntypeIHM = IHM_OPC\naucune IHM n’est en service\nmise en œuvre d’une IHM de type caractères\nmise en œuvre d’une IHM de type OPC\n4.3 Démarrage et terminaison de l’application de contrôle-commande\n4.3.1 Lancement et démarrage de l’application\nLe lancement de l’application se fait depuis l’ordinateur support du système de commande en ouvrant le fichier .exe du processus Win32 RTX.\nAvant 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.\nLe 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.\nLa 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.\nAprè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.\nEn ce point du déroulement de l’application, l’opérateur a en réalité le choix entre les 3 actions suivantes :\n1. Mettre en service l’IHM de type console\n2. Mettre en service l’IHM de type OPC\n3. Commander l’arrêt du système de commande.\n4.3.2 Arrêt du système de commande et terminaison de l’application\nLe 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.\nLa 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.\nComme 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.\nA la suite d’une demande d’arrêt du système de commande, le thread primaire du\nprocessus Win32 RTX :\n1. É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.\n2. 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.\nLa 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.\n4.4 Niveau de priorité des threads du processus Win32 RTX\nÉ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).\nA l’intérieur de cette classe de priorité, sont donnés aux tâches du processus Win32\nRTX les indices de priorité suivants par ordre décroissant :\n tâche superviseur\n tâche realiseOpSvisionNI (lors d’une opération conjointe)\n tâche afficheObs\n Le thread primaire\n tâche realiseOpSvisionNI (lors opération de supervision)\n(prioriteThreadPrimaire + 3) (prioriteThreadPrimaire + 2) (prioriteThreadPrimaire + 1) (prioriteThreadPrimaire) (prioriteThreadPrimaire - 1)\navec prioriteThreadPrimaire = THREAD_PRIORITY_LOWEST (= RT_PRIORITY_MIN + 1).\nLe 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 :\n 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.\nEn 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\nla fin de la tâche realiseOpSvisionNI.\n 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.\nLes différentes tâches du processus Win32 RTX auront donc comme indice de priorité les valeurs suivantes :\nNom de priorité symbolique Windows\nNom de priorité symbolique RTSS\nRT_PRIORITY_MIN + 4\nRT_PRIORITY_MIN + 3\nRT_PRIORITY_MIN + 2\nRT_PRIORITY_MIN + 1\nLes niveaux de priorité à donner aux tâches du processus RTSS devront être strictement supérieurs à RT_PRIORITY_MIN + 4.\nPartant 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.\nCeci a été fait en prenant tout particulièrement en compte :\n1. les différentes catégories d’opérations susceptibles d’être implémentées dans une application de contrôle-commande ;\n2. les ordres de l’opérateur que l’on retrouve dans toute application de contrôle- commande ;\n3. 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.\nDans les chapitres suivants, nous allons de plus en plus détailler la mise en œuvre de cette architecture logicielle type.\nAnnexe : A propos du développement et du déploiement d’une application\nEn 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.\nDéveloppement d’une application de contrôle/commande\nUn projet Visual Studio C++ distinct sera créé pour chacun des processus Win32 RTX et RTSS.\nCeci 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\n(cf. Support de formation à RTX 8.1, § 2.3.2, p. 16).\nLe nom donné à ces 2 projets Visual Studio C++ sera ainsi formé :\n pour le processus Win32 RTX :\n pour le processus RTSS :\nIl 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.\nPour 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.\nIl 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.\nDéploiement d’une application de contrôle/commande\nTous les fichiers relatifs à l’application seront rangés dans un dossier portant le nom de l’application.\n1. le fichier exécutable correspondant au processus Win32 RTX, c’est-à-dire le fichier portant le nom : nomApplication_win32.exe\n2. le fichier exécutable correspondant au processus RTSS, c’est-à-dire le fichier portant le nom : nomApplication_rtss.rtss\n3. un configuration de l’application\n4. 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.\n5. Communication entre IHM et tâches de supervision\n5. Synchronisation et communication entre l’IHM et le cœur de l’application\nNous 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.\nPour é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.\nNotons cependant dès maintenant que cet objectif ne sera pas totalement atteint :\nla 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.\nIHM de type console\nIHM de type OPC\nles différents types d’IHM et le cœur de l’application\nLa 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.\nMais 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.\nCommunication entre IHM et tâches de supervision\n5.1 Modes de synchronisation et nature des informations échangées\nLa 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.\nLa 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) :\n d’une part, les messages de service générés à l’intention de l’IHM par la tâche superviseur,\n 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).\nLa communication entre l’IHM, la tâche superviseur et la tâche afficheObs peut être ainsi schématisée :\nde l’affichage de l’état\nDemandes de préparation\nde messages destinés à\nMessages textuels prêts à être affichés par l’IHM\n5.1.1 Procédure de traitement d’une demande de service\nPour toute demande de service adressée à la tâche superviseur, la procédure de traitement suivante a été adoptée :\n1. 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.\n2. 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.\n3. 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.\n4. 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.\n5. 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.\n6. 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.\nLorsqu’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.\n5.1.2 Procédure de traitement d’une demande de préparation de l’affichage\nLorsque 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.\nLorsque 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 :\npuis atten d le message\n1. L’IHM transmet la demande à la tâche afficheObs\ncontenant le texte à afficher.\n2. 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.\n3. La tâche afficheObs transmet ensuite à l’IHM un message contenant le texte à afficher.\n5.2 Communication entre IHM, tâche superviseur et tâche afficheObs\n5.2.1 Synchronisation et communication entre l’IHM et la tâche superviseur\nDe 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 .\nCode de la demande de service :\nint codeDdeService ;\nParamètres des demandes de service :\nAprè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().\nEn 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\nun objet de type sémaphore d’exclusion mutuelle.\nL’IHM émet le signal d’acquittement en direction de la tâche superviseur en appelant la fonction acquitterCRddeService() :\n 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) ;\n 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).\n5.2.2 Synchronisation et communication entre la tâche superviseur et la tâche afficheObs\nDe 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 :\n1. codeOpEnCours : code de l’opération en cours\n2. codeCRddeService : code du compte rendu à une demande de service\n3. causeItOpEnCours : code de la cause de l’éventuelle interruption de l’opération en cours.\nIl est à noter que c’est la tâche afficheObs, et non la tâche superviseur, qui modifiera la valeur de ces variables.\nLorsque 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 .\nLe 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.\nComme 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 :\nValeur à donner à\nLa valeur à donner à causeItOpEnCours est celle qui été transmise à la tâche\nsuperviseur par le niveau Contrôle/commande ou par la tâche realiseOpSvisionNI.\nChaque 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 .\nLa 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).\n5.2.3 Synchronisation et communication entre l’IHM et la tâche afficheObs\nCommunication dans le sens IHM vers tâche afficheObs\nSi 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.\nPour 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 :\nLe 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.\nLe paramètre 2 pourra éventuellement être utilisé pour indiquer le type d e format désiré pour cet affichage.\nCommunication dans le sens tâche afficheObs vers IHM\nEn 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.\nCas d’une IHM de type console\nS’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.\nLors 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).\nOn définit les 5 structures de message suivantes :\nAdresse de texteOpEnCours\nAdresse de texteCRddeService\nAdresse de texteEtatCcde\nAdresse de texteAlarmeCcde\nLe tableau ci-après précise la signification des 4 variables de type chaine de caractères.\nTexte décrivant l’opération en cours d’exécution\nTexte 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\nTexte décrivant l’état actuel de la partie opérative et du système de commande\nTexte décrivant la nature de l’alarme signalée\nCas d’une IHM de type OPC\nAucun 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.\nLa 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.\nSynchronisation entre la tâche afficheObs et l’IHM\nA la fin de chacune de ses exécutions périodiques, la tâche afficheObs émet un signal\nen 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.\nDans 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.\nDans 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.\nL’interface entre les différents types d’IHM et le cœur de l’application se compose des éléments suivants :\n une variable indiquant, notamment à la tâche afficheObs, le type d’IHM effectivement en service ( typeIHM).\n 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.\n 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).\nLe 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.\nIl apparaît que la tâche afficheObs transmet sous des formes différentes à l’IHM les\ninformations qu’elle doit lui communiquer, suivant qu’il s’agit d’une IHM de type console ou d’une IHM de type OPC.\nMessages envoyés par\nla tâche afficheObs\nAutres variables de l’interface entre IHM\net les tâches superviseur et afficheObs :\nVariables donnant l'état de la PO et du système de commande :\n1) Variables non spécifiques à l'application :\nType de l’ IHM en service :\nType de l’opération en cours :\nint typeOpEnCours ;\nPointeur sur les données à MAJ (cas d’une opération NIO) :\nint *pDataOpNIO ;\nIndicateur de mise à jour des VE textuelles :\nsigned char iMAJtexte ;\nPériode en ms de màj des variables associéex aux items L :\n2) variables spécifiques à l'application :\nint periodeMajVarEnL ;\nMessages envoyés par l’IHM\net par la tâche superviseur\n5.4 Les fonctions d’interface appelées par l’IHM\nAu nombre de six, ces fonctions qui permettent la communication entre l’IHM et l’application proprement dite présentent les caractéristiques communes suivantes :\n à l’exception de la fonction mettreAJourDataOpNIO() , elles sont appelées à la suite d’un ordre de l’opérateur ;\n l’exécution de chacune d’elles donne lieu à l’émission d’un signal en direction du cœur de l’application ;\n 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.\nPour é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.\nLa fonction declencherDdeService()\nCette fonction est appelée par l’IHM lorsque, l’opérateur déclenche une demande de service spécifique à l’application.\nComme 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é.\nLa 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.\nOrganigramme général de la fonction declencherDdeService()\nSi état de l’objet evDdeService = non signalé alors :\nMettre l’objet evDdeService dans l’état signalé Retourner TRUE\nA la fin du traitement d’une demande de service, l’objet evDdeService est remis dans l’état non signalé par la tâche superviseur.\nAinsi, 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.\nLa fonction mettreAJourDataOpNIO()\nLors 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.\nChaque 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.


Site web à Arles, Appuie sur On ! L'expertise de l'équipe Com'On\n04 Apr 2016 - 11 May 2020\nNotre équipe pour votre site web et bien plus, à votre service !\nCom’On crée votre site web à Arles et met une équipe dédiée à votre service !\nVous vous devez de gérer votre entreprise, vous ne pouvez consacrer le temps nécessaire ou prendre un salarié à temps plein pour créer votre site web et gérer l’image de votre entreprise sur Internet.\nRésolument axée PME, notre équipe connaît parfaitement vos problématiques et chacun est expert dans son domaine pour vous assurer d’avoir des outils professionnels à la pointe de la technologie actuelle.\nChez Com’On chaque pôle de développement est confié à un expert métier, ainsi un graphiste « désigne », un développeur « programme », un webmaster optimise votre positionnement, un documentaliste s’informe sur votre métier et les dernières innovations, et la ligne rédactionnelle est mise en forme par un rédacteur professionnel !\nLe résultat pour vous et vos futurs clients : aucune erreur technique sur nos outils, des chartes graphiques en 5K sans défaut, des contenus innovants et percutants pour les internautes, optimisés pour les moteurs de recherche et surtout sans aucune faute d’orthographe, donc des outils fiables, professionnels et qui vont facilement se hisser dans les premières pages, car toute la ligne de production est maîtrisée en interne de A à Z !\nChez Com’On on ne lésine pas sur la qualité de notre prestation et la qualité des hommes et des femmes qui sont à votre service !\nCommuniquer et developper ses parts de marché sur Internet n’est pas si simple ! Une équipe dédiée dont chacun maîtrise son métier doit vous être proposée !\nLors de vos futures demandes de renseignement ou demandes de devis, exigez le détail de l’équipe de l’agence qui va vous accompagner…\nAuriez-vous l’idée d’appeler un plaquiste pour construire votre maison ?\nNON ! Lui sera très bon pour les séparations de pièces, le second oeuvre ou l’isolation, mais il n’est pas maçon !\nDans la communication et le marketing c’est la même chose :\nun graphiste n’est pas développeur ou programmeur, un concepteur multimédia n’est pas spécialisé en papeterie et un infographiste n’est sûrement pas rédacteur web et encore moins expert SEO (référencement et positionnement)\nIci vous pouvez découvrir les différents métiers qui doivent intervenir pour un réel travail avec un résultat professionnel :\nUn Consultant Marketing vous est dédié.\nLors d’un audit, il dégagera avec vous un objectif spécifique, réalisera avec vous un cahier des charges sur mesure pour votre site web et une liste de mots clés ciblés… Il est votre conseiller et chef de projet qui fera le lien direct avec notre studio.\nVotre graphiste est en relation directe avec vous. Après un entretien, il cible vos doléances et vous propose vos pistes sur mesure, il adapte votre charte à tous vos supports et dessine votre site web.\nUn impact marketing digne des grandes entreprises !\nWebmaster ou concepteur multimédia\nUn concepteur multimédia vous est dédié. Il programme, édite et met en page votre site web, ce qui vous permet d’avoir un modèle de site web unique, programmé pour vous et suivant les fonctionnalités désirées. L’avantage c’est qu’en programmant votre site web, il le connaît et maîtrise les codes qui le font fonctionner pour une garantie de qualité et stabilité inégalées.\nUn rédacteur web documentaliste est à votre service ! Trop de professionnels font l’erreur de créer un site Internet qui leur convient à eux avec des textes trop techniques.\nVotre site web doit cibler vos clients et leurs donner des informations pertinentes !\nLa rédaction doit être irréprochable !\nVous échangerez à travers un cahier des charges afin que les textes soient clairs, précis et ciblés sur les recherches et questions de vos clients.\nManager de votre communauté, il est l’ange gardien des réseaux sociaux.\nIl est l’animateur de vos outils numériques.\nEn perpétuel contact avec vous, il gère vos contenus et vos actualités sur votre site Internet et vos réseaux sociaux.\nIl est à vos cotés pendant toute la durée de la mission que vous nous confiez !\nRéférenceur ou expert SEO\nSEO = Search Engine Optimization (optimisation pour les moteurs de recherche)\nIl inscrit votre site Internet sur les moteurs de recherche, vous propose un glossaire de mots clés pertinents dans l’intérêt du positionnement de votre site web.\nDans le but d’atteindre vos objectifs, il peut vous proposer des campagnes ciblées :\nGoogle Adwords, campagne Facebook, compte premium Viadeo…\nCopyright © 2019 - Com'On-Solution – Agence de conseil, création site internet & agence SEO à Arles, Bouches du Rhône


Que voir en un week-end à Lyon ? Que voir en un week-end à Lyon ?\nPremiers pas à Lyon pour un week-end\n9 février 2016 Marie\nFrance, Récits de voyage\nDepuis notre retour d’Asie, à part une petite escapade au Portugal et une semaine en Irlande, nous n’avons plus le temps de voyager loin et longtemps. On a donc décidé de privilégier des destinations proches, en France, parce que nous n’avons pas encore tout découvert de notre cher hexagone et que quelques villes nous faisaient de l’œil depuis longtemps. Parmi elles, Lyon et Lille. Le hasard faisant toujours bien les choses, nous avons visité ces deux villes le mois dernier et si tout semble diamétralement les opposer – aussi bien architecturalement que météorologiquement ou gastronomiquement parlant – elles partagent pourtant un bon point commun : nous avoir enchantés autant l’une que l’autre. Mais restons à Lyon, d’abord. Pour Matt, ce n’était pas une première et il a vraiment aimé y retourner. Pour moi, c’était un petit rêve. Malgré tout, toujours au bout du monde, j’ai mis du temps avant d’aller finalement la visiter. Verdict ? Je n’ai pas été déçue du voyage. Ce petit Paris, avec la montagne pour horizon, a tous les avantages de la capitale sans les inconvénients (donc sans les Parisiens… ça va, on peut rigoler !).\nJe suis contente de ne pas avoir pu tout voir en deux jours, même si nous avons eu le temps de parcourir une grande partie de la ville, parce que j’aurai ainsi une bonne raison d’y revenir. Mais si comme nous, vous avez peu de temps pour visiter Lyon, voici un conseil d’itinéraire assez classique pour vous laisser séduire par la ville aux petits bouchons.\nQue voir à Lyon en un week-end ?\nDescendre les pentes de la Croix Rousse par les traboules\nDepuis le temps qu’on me parlait de ces fameuses traboules, je suis contente de les avoir enfin vues de mes yeux et traversées dans tous les sens… ou presque. En vérité, impossible de se perdre puisqu’il faut suivre les petites flèches indiquant son chemin. On passe alors par des endroits secrets entre escaliers démesurés et murs de pierre redécorés par le street art local. La Croix Rousse est en effet le quartier « bobo-arty-hipster » de Lyon où souffle un vrai vent de liberté. C’est là que l’on trouve des supers petits cafés, des galeries, des bars sympas, une scène culturelle très développée, et donc également de superbes fresques murales. On espère d’ailleurs avoir le temps un jour de se faire une petite chasse aux tags lors d’un prochain voyage !\nLes pentes de la Croix Rousse – Lyon ©voyagesadeux\nFaire une pause dans la cour du musée des Beaux-Arts\nAprès avoir dévalé la Croix Rousse, vous pourrez vous offrir un petit moment de répit dans le joli jardin du musée des Beaux-Arts, situé sur la place des Terreaux et souvent délaissé par les touristes qui préfèrent justement profiter de la superbe fontaine Bartholdi (et on peut les comprendre, c’est vrai que cette mini fontaine de Trevi est un des principaux monuments à voir à Lyon). Le fait est qu’on a quand même préféré ce petit coin vert où on s’imagine même revenir bouquiner en été.\nMusée des beaux art – Lyon ©voyagesadeux\nFontaine Barholdi – Lyon ©voyagesadeux\nSe promener sur les quais de Saône… ou du Rhône ?\nA Lyon au moins, vous aurez le choix entre deux rivières, bien plus larges que la Seine. Niveau sensations en revanche, vous aurez vraiment l’impression d’être comme à Paris. En tout cas, ce fut la mienne. De jolis ponts, des bâtiments haussmanniens sur les deux rives, mais moins de monde ou de pollution, donc gros potentiel romantique !\nLes quais de Lyon ©voyagesadeux\nFlâner (rapidement) dans le Vieux Lyon\nLes vieux quartiers se ressemblent tous et celui de Montpellier aura toujours ma préférence. Le vieux Lyon est un vivier à touristes et à petits bouchons que l’on vous déconseille (pas qu’on les ais testés mais une bonne adresse n’a pas besoin d’un serveur racoleur pour vous asseoir à sa table en s’adressant à vous en anglais et les bouchons du Vieux Lyon surabusent de cette stratégie). On vous recommande toutefois de vous aventurer dans les petites impasses pour déboucher sur de jolies cours intérieures et de vous balader le nez en l’air pour admirer l’architecture remarquable de ce quartier historique de Lyon.\nLe Vieux Lyon ©voyagesadeux\nGrimper (à pied !) jusqu’à la Fourvière\nAprès un bon petit bouchon lyonnais, rien de mieux que les 237 marches (on ne s’est pas amusés à compter, mais on croit Google sur parole) qui montent jusqu’à la colline de la Fourvière pour éliminer les calories. Arrivé en haut, vous aurez des étoiles dans les yeux et un super panorama, plus une double église pour le prix d’une (façon de parler, l’entrée est gratuite). N’ayant rien à envier à la Bonne Mère marseillaise, l’église de la Fourvière se détache en deux parties, entre détails gothiques impressionnants d’un côté et une version plus flamboyante, toute en dorures, de l’autre. A vous de choisir votre préférée. Pas très loin, si vous êtes féru d’histoire, les restes du théâtre romain sont un endroit sympa à découvrir, surtout pour la vue.\nLa Fourvière – Lyon ©voyagesadeux\nS’offrir un tour de Grande Roue place Bellecour, de nuit\nPour finir ce premier jour à Lyon en beauté, direction la place Bellecour à la nuit tombée pour admirer la vue panoramique aux lueurs (si c’est le bon moment dans l’année) de la grande roue éclairée. Profitez-en également pour aller découvrir la place des Jacobins à deux pas et vous amuser à désigner qui est la plus belle entre elle et la place des Terreaux. Nous, on n’a pas réussi à se décider…\nPlace Bellecour – Lyon ©voyagesadeux\nPlace des Jacobins – Lyon ©voyagesadeux\nAller dire bonjour à la rencontre des deux fleuves, à Confluence\nPour un dimanche au calme, direction Confluence, ou plutôt l’arrêt juste avant. Vous pourrez ainsi descendre à pied les docks, entre superbes péniches et bâtiments design, jusqu’à la rencontre des deux fleuves (la Saône et le Rhône) où se donnent rendez-vous tous les joggeurs.\nConfluence – Lyon ©voyagesadeux\nSe mettre au vert au Parc de la Tête d’or\nUn week-end à Lyon sans un passage par son parc de la Tête d’or revient à ne pas mettre un pied à Central Park en allant à New York. Pour continuer sur le registre des comparaisons, on lui a plutôt trouvé des airs de Vondelpark à Amsterdam, et même en janvier, il est très agréable de s’y promener. N’oubliez pas d’aller dire bonjour aux daims qui gambadent gaiement au cœur du parc et de faire un tour dans les jolies serres (mention spéciale pour celle des plantes carnivores). Et si vous avez le temps, essayez de retrouver la fameuse tête d’or enfouie quelque part !\nParc de la Tête d’or – Lyon ©voyagesadeux\nS’abriter de la pluie au Musée des miniatures et des décors de cinéma\nSi nous avons choisi la pluie comme prétexte pour aller visiter ce musée, on aurait quand même fini par s’y rendre un jour où l’autre, comme tout bon cinéphile qui se respecte. J’ai pu poser avec la reine des Aliens, admirer les trucages les plus gores des plus grands films made in Hollywood et surtout tomber sous le charme des reconstitutions miniatures au dernier étage. En bref, la visite parfaite à faire quand il pleut à Lyon (mais pas que).\nMusée des miniatures et des décors du cinéma – Lyon ©voyagesadeux\nOn espère vous avoir donné assez d’idées pour bien occuper votre week-end à Lyon et en avoir bientôt plein d’autres, plus originales, hors des sentiers battus… et à vrai dire, ça ne saurait tarder !\nEncore merci à Laure et Ossian (#sisilafamille) pour leur accueil et leurs bons conseils de visite <3\nconfluence fourvière Lyon parc de la tête d'or place bellecour traboules vieux lyon week-end\nTour du Ring of Kerry, l’un des plus beaux sites d’Irlande\nLille : une ville à croquer en un week-end !\n4 réponses to “Premiers pas à Lyon pour un week-end”\nFranck Laboue dit\nBeaux souvenirs, j’ai habité en Isère lorsque je travaillais à l’aéroport il y a déjà plusieurs années. J’adorais mes balades dans le vieux Lyon, en vous lisant je me rend compte que je suis passé à coté de pas mal de belles choses ! A+\nContents de t’avoir fait découvrir de nouvelles choses à Lyon, même si on pensait n’avoir suggéré que les essentiels 🙂 Comme quoi, on peut toujours être surpris ! Même ici à Paris, nous n’avons pas encore tout visité, c’est souvent le problème, on se dit qu’on aura le temps plus tard et finalement on ne le prend jamais 🙂\nTrès bel article sur ma belle ville lyonnaise. Tu as visité de très beaux endroits !


5 péchés capitaux qui peuvent détruire votre franchise - et comment les éviter - Créer son entreprise\nL'industrie des aliments et des boissons est un jeu difficile. Soixante pour cent des restaurants ne dépassent pas leur première année et 80 pour cent font faillite dans les cinq ans. Ce sont des probabilités difficiles.\nLe franchisage supprime certains des risques de l'équation en vous offrant un modèle éprouvé avec lequel travailler. Mais être un franchiseur avec un modèle éprouvé sous le bras ne signifie pas que vous êtes soudainement à l'épreuve des balles ou à l'abri des lois de l'économie. Si vous commencez à commettre des erreurs directes, vous échouerez.\nVoici les cinq raisons pour lesquelles la plupart des gens échouent en tant que propriétaire d'une franchise. Évitez à tout prix ces péchés capitaux:\nPéché 1: complaisance financière\njeDans votre vie personnelle, vous adoptez probablement une approche pratique des finances. Votre entreprise requiert la même attention. Ne soyez pas complaisant et ne supposez pas que simplement parce que l’argent arrive, vous pouvez le régler et l’oublier. Creusez dans les finances.\nConnexes: sauvage pour les animaux? Découvrez les 6 meilleures franchises pour les amoureux des animaux\nVous pourriez avoir un chiffre d'affaires de 900 000 $, mais vos marges de travail sont-elles plus élevées qu'elles ne devraient l'être? Votre coût des marchandises (COGS) augmente-t-il régulièrement parce que votre gérant de bar a acheté 50 types de vins différents parce que vous ne disposez pas d'un système d'inventaire capable de suivre les marques que vous avez déjà sous la main? Peut-être que vous n'avez pas fait de demande de prix (DP) depuis plus de cinq ans, donc vous ne savez même pas s'il existe une offre concurrentielle qui pourrait vous faire économiser de l'argent.\nNe laissez pas ce genre de complaisance s'instaurer. Cela peut ébranler cette ligne du haut jusqu'à ce que soudainement, la ligne du bas ne soit pas si chaude.\nPéché 2: obtusité opérationnelle\nVous devez connaître votre entreprise de fond en comble. Cela ne signifie pas seulement connaître vos COGS et vos SKU, cela signifie savoir comment l'entreprise fonctionne et comment reconnaître si quelque chose ne va pas. Si le coût des marchandises est censé être de 23% mais qu'il affiche 40%, ou s'il y a un écart dans l'inventaire, vous devez savoir exactement où chercher pour trouver l'écart.\nEst-ce votre première franchise? Si tel est le cas, il est judicieux de savoir comment gérer de manière opérationnelle tous les aspects de l’entreprise. Bien sûr, vous n'aurez peut-être pas besoin de laver la vaisselle, de jeter des boissons ou de commander des serviettes en papier pendant les opérations quotidiennes normales, mais si quelqu'un appelle malade ou ne se présente tout simplement pas, vous devez pouvoir intervenir et faire rouler la machine. Le message à retenir ici? Il est utile de connaître les opérations de votre entreprise de fond en comble.\nPéché 3: Mauvais choix d'embauche\nCette prochaine friandise peut sembler évidente, mais, étonnamment, elle mérite d'être mentionnée: embauchez de bonnes personnes. C'est votre affaire. Vous voulez qu'il réussisse, ce qui signifie que vous devez embaucher les meilleures personnes pour le gérer. N'embauchez pas la première personne qui postule pour l'emploi qui passe une vérification des antécédents et qui a un pouls.\nEn relation: À quoi ressemblera la franchise de restaurants en 2021\nAussi: embauchez pour vos faiblesses. Si vous êtes une personne introvertie, soucieuse du détail et à l'aise avec les aspects des coulisses, assurez-vous d'embaucher quelqu'un qui a une personnalité plus extravertie et front-of-house. Si vous êtes une personne ayant une vue d'ensemble, des idées, embauchez quelqu'un qui est une personne qui «faisons les choses», etc. Embauchez des personnes qui compléteront ce que vous apportez à l'entreprise avec ce qu'elles apportent à l'entreprise.\nSin 4: Gestion du risque myope\nAu-delà de la mise en place de plans d'urgence en cas de catastrophe naturelle, de pandémie, de perturbation de la chaîne d'approvisionnement ou de tout autre problème, les franchisés doivent être comme des joueurs d'échecs. Ils ont besoin de voir l'ensemble du tableau, de penser à plusieurs mouvements à venir et d'imaginer plusieurs scénarios possibles qui pourraient se produire.\nUn impact sur une industrie apparemment non liée peut avoir un effet domino qui se répercute sur les industries B et C et vous fait basculer la tête, même si vous êtes dans l'industrie D. En termes pratiques, cela signifie que si vous êtes un vendeur de hot-dogs , et vous ne vous souciez que de ce qui affecte le hot-dog et le pain, vous ne pensez pas assez largement. Élargir votre champ de vision vous aidera à mieux anticiper les boules de courbe inattendues afin de pouvoir pivoter et vous adapter.\nSin 5: Offres médiocres\nFaites-vous une faveur et faites au moins une chose mieux que les autres. Vous devez avoir au moins une chose qui l'écrase, que ce soit un élément de menu particulier, votre service client, votre ambiance ou autre chose. Ce quelque chose de spécial est la façon dont vous obtenez des clients et les fidélisez.\nEn d'autres termes: sachez ce que vous faites bien et exécutez-le. Si vous aimez les rondelles d'oignon, vendez les meilleures rondelles d'oignon au monde. Si une sélection de bières tueur est votre carte de visite, assurez-vous que vous êtes approvisionné à neuf. Mais n'essayez pas d'être tout pour les gens si cela signifie que tout est «moyen».\nConnexes: Les meilleures franchises alimentaires de l'année\nDes échecs se produisent dans l'industrie des aliments et des boissons, mais ils ne doivent pas être inévitables. En évitant ces cinq péchés capitaux, les franchisés peuvent maintenir leurs entreprises sur le vif et dans le noir, afin qu'ils puissent récolter avec succès les fruits de leur investissement.\nPouvons-nous avoir un amen?\n← Les femmes sont-elles plus susceptibles de perdre la garde si elles prétendent que leur enfant a été abusé sexuellement par le père? → L'astuce de cinq minutes qui vous aidera à avoir des réunions plus productives


"Le temps des consciences" - Regards protestants\nRegards protestants > Société > « Le temps des consciences »\nQuelles en sont les origines et comment y faire face ? Ces questions sont partout posées . Parmi les réponses, on peut retenir un livre rapportant une rencontre entre Nicolas Hulot et Frédéric Lenoir : « D’un monde à l’autre. Le temps des consciences » (1).\nCes deux personnalités ont un parcours original et leur rencontre est donc prometteuse. « Nicolas Hulot a passé une partie de sa vie à voyager dans les parties les plus reculées du monde au fil de son émission de télévision : Ushaïa. Engagé depuis trente ans dans la protection de l’environnement , il fut ministre de la transition écologique et solidaire de mai 2017 à août 2018. Auteur de nombreux ouvrages, il a créé la Fondation Nicolas Hulot pour la Nature et l’Homme ». « Frédéric Lenoir est philosophe et sociologue, auteur de nombreux essais et romans traduits dans une vingtaine de langues. Il est notamment l’auteur des best sellers : « Du Bonheur », « Un voyage philosophique », « La puissance de la joie » ou « Le miracle Spinoza ». Il est cofondateur de la fondation Seve (Savoir Être et Vivre Ensemble) qui propose des ateliers de philosophie avec des enfants » (page de couverture). Le parcours de Frédéric Lenoir est diversifié à la fois quant à ses fonctions et quant à ses intérêts (2). En effet, si ses nombreux livres témoignent de son évolution spirituelle (3), il est connu aussi pour avoir été directeur du Monde des religions. Nous avons ici présenté son remarquable livre : « La guérison du monde » paru en 2012. Dans ce livre, Frédéric Lenoir envisage la crise qui affecte nos sociétés et il en présente les menaces et les opportunités : « Un chemin de guérison pour l’humanité. La fin d’un monde. Le début d’une renaissance » (4). On retrouve l’approche de Frédéric Lenoir dans ce livre : « Le temps des consciences » et on y trouve aussi l’authenticité et l’originalité de la démarche de Nicolas Hulot. De la crise du progrès à la recherche de sens, le livre se […]\nL’histoire de Philo, de l’esclavage à la lumière\nUn témoignage fort. Du Bénin à la région parisienne, l'histoire d'une femme qui a réussi à sortir de l'esclavage domestique.