Brevet FR2944886A1 — publié le 20101029

Système intégré de supervision et de commandement Domaine technique La présente invention concerne un système intégré de supervision et de commandement. Un système intégré de supervision et de commandement trouve une application dans des postes centraux de commande, ou centres opérationnels, par exemple dans le domaine des réseaux de transport terrestre, de la sécurité d'infrastructures critiques ou encore de la supervision du transport d'énergie. Exposé de l'art antérieur Un système de supervision, par exemple d'un système de transport ferroviaire, comprend différentes fonctions comme : • une fonction de commande et de contrôle d'équipements électromécaniques, appelée généralement SCADA, acronyme de l'expression anglo-saxonne Supervisory Control And Data 15 Acquisition ; • une fonction de gestion du trafic ferroviaire ; • une fonction de vidéosurveillance. Deux des objectifs d'un système de supervision de transport ferroviaire sont notamment : 20 • dans le cadre d'un fonctionnement normal : assurer la circulation des trains, la sécurité et le confort des utilisateurs des trains, ainsi que les communications avec le personnel à bord des trains ou dans les stations ; • dans le cas d'un incident : aider un opérateur du centre de contrôle à 25 assurer la sécurité des utilisateurs et à assurer un retour à des conditions opérationnelles normales aussi rapidement que possible et dans de bonnes conditions de sécurité. Un des principaux problèmes auxquels sont confrontés les constructeurs de système de supervision est d'intégrer différents systèmes de supervision, 30 propres aux différentes fonctions, afin d'assurer un fonctionnement cohérent du système de supervision aussi bien en fonctionnement normal que dans une situation de crise. 2 Un autre problème concerne la maintenance et l'évolution d'un système de supervision : durant le cycle de vie d'un système de supervision, il est souvent difficile de remplacer une fonction principale sans qu'il n'y ait impact sur les autres fonctions. En effet, les différentes applications réalisant les fonctions utilisent pour s'intégrer dans le système de supervision des protocoles dédiés à chaque application. Il est ainsi nécessaire à chaque changement d'application d'implémenter de nouveaux protocoles. II peut également y avoir différentes fonctions réalisées par une même application. Ceci rend difficile l'évolution d'un système de supervision. Afin d'améliorer l'évolutivité des systèmes de supervision, des architectures, dites � en silo �, ont été mises en place. Ces architectures comportent une application par fonction. Chaque application a sa propre interface homme machine, ou IHM, et ses propres interfaces avec des équipements à superviser. Les différentes applications ne communiquent pas, ou peu, entre elles. Des opérateurs utilisant les différentes applications de supervision assurent une cohésion de leurs actions sur les équipements supervisés, en communicant verbalement entre eux les informations nécessaires. Par exemple un système de supervision d'un réseau de transport terrestre peut comporter une application de supervision de système de billettique, une application de supervision du trafic des trains, une application de supervision des équipements de contrôle d'accès aux quais. Dans une architecture d'un système de supervision en silo, chaque application possède donc son propre poste de supervision. II est donc difficile pour un seul opérateur d'appréhender de façon globale une situation. Une tenue de situation nécessite donc de nombreux échanges d'informations entre les différents opérateurs en charge d'une ou plusieurs applications de supervision. En situation de stress, les communications entre opérateurs deviennent difficiles et leurs actions peuvent alors souffrir d'un manque de cohésion, crucial en situation de crise. Ce manque de cohésion ne permet pas donc pas des réactions efficaces en présence d'un incident. Un autre type d'architecture, dite tout intégrée, permet de fournir une IHM intégrée permettant à un opérateur de visualiser le système de manière globale. Ce type d'architecture intègre dans une même application toutes les fonctions de supervision du système. L'architecture est généralement bâtie autour d'un logiciel unique, basé sur un logiciel intermédiaire par exemple le SCADA. Une telle architecture, tout intégrée, est peu adaptée à la prise en compte de fonctions métier complexes. De plus les évolutions sont limitées car compliquées et risquées. D'un point de vue sureté de fonctionnement, une architecture tout intégrée est peu sure. En effet, une fonction non sure dans le système peut entrainer des défaillances dans des fonctions critiques du point de vue sureté de fonctionnement du système. Une architecture tout intégrée peut souffrir de problèmes de performance. En effet, l'acquisition des données émanant des différents équipements du système sont traités par une même application. L'afflux d'informations au niveau de l'application peut ralentir considérablement celle-ci. Une architecture tout intégrée est peu évolutive et difficilement adaptable à des contraintes liées à différents clients. Résumé de l'invention Un but de l'invention est notamment de pallier les inconvénients précités. A cet effet, l'invention a pour objet un système intégré de supervision et de commandement d'un système de transport. Le système comporte notamment • plusieurs applications de supervision d'équipements du système de transport ; • une interface homme machine intégrée ; • une infrastructure ayant une architecture orientée services ; Les applications de supervision, et l'interface homme machine peuvent s'interfacer avec l'infrastructure par l'intermédiaire de services web. Le système peut exécuter des processus métier notamment définis dans une base de données de règles métier. L'interface homme machine affiche notamment des pas du processus métier. Le système peut permettre à un utilisateur d'agir sur le déroulement d'un processus métier en effectuant ou non un ou plusieurs pas du processus métier par l'intermédiaire de l'interface homme machine intégrée. Les applications de supervision et l'infrastructure peuvent être configurées par un même outil de configuration. Autres avantages de l'invention L'invention a notamment pour principaux avantages de permettre de réduire les risques d'erreur des opérateurs lors de l'exécution des différentes procédures et notamment lors de l'exécution de procédure de 5 résolution d'incidents. Brève description des figures D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit, donnée à titre illustratif et non limitatif, et faite 10 en regard des dessins annexés qui représentent : • la figure 1 : une représentation schématique d'une architecture d'un système intégré de supervision selon l'invention ; • la figure 2 : un exemple d'exécution d'un processus métier par le système selon l'invention ; 15 • la figure 3a : un exemple de gestion d'événement par le système selon l'invention ; • la figure 3b : un exemple de gestion d'alarmes par le système selon l'invention. 20 Description de l'invention (au moyen d'un exemple de réalisation) La figure 1 représente de manière schématique une architecture 1 d'un système intégré de supervision et de commandement selon l'invention. La figure 1 représente pour l'exemple une architecture selon l'invention 25 appliquée au domaine du transport terrestre notamment ferroviaire. Cependant le système de supervision selon l'invention peut s'appliquer à d'autres systèmes de supervision tels que : • de manière générales des systèmes de supervision et de communication intégrés pour des activités de transport comme : des 30 lignes urbaines de métro, tramway, des grandes lignes de trains, des tunnels, des parkings ; • des systèmes de supervision de la sécurité d'infrastructures critiques comme des immeubles et de grandes installations de type musées, aéroports, sites industriels, des raffineries, des centres villes ; • des systèmes de supervision du transport d'énergie : transport de pétrole, de gaz, d'électricité, distribution d'eau. L'architecture 1 intégrée du système selon l'invention repose sur l'utilisation d'une infrastructure SOA 2, SOA étant un acronyme pour l'expression anglo-saxonne Service Oriented Architecture signifiant architecture orientée services. Une infrastructure SOA est communément appelé framework SOA, littéralement cadre d'application SOA. Une infrastructure SOA comporte un ensemble de bibliothèques de classes abstraites ou non, permettant notamment une implémentation de services par des applications hétérogènes. L'utilisation d'une infrastructure SOA 2 permet avantageusement d'intégrer dans le système de supervision selon l'invention des applications existantes hétérogènes. La figure 1 représente à titre d'exemple sept applications de supervision. D'autres type d'applications de supervision peuvent également être intégrées. La figure 1 représente notamment les applications de supervision suivantes : • une application de supervision SCADA 3, SCADA étant un acronyme pour l'expression anglo-saxonne Supervisory Control And Data 20 Acquisition ; • une application de supervision ATS 4, ATS étant un acronyme pour l'expression anglo-saxonne Automatic Train Supervision signifiant supervision automatique des trains ; • une application de supervision de systèmes billettiques 5 ; 25 • une application de supervision de systèmes d'informations aux voyageurs 6 ; • une application de supervision de systèmes de contrôle d'accès 7 ; • une application de supervision de systèmes de vidéo surveillance 8 ; • une application de supervision de systèmes de communications 9. 30 Une application de supervision de systèmes de communication 9 peut intégrer des interfaces de communications de type : • Radio TETRA, acronyme pour l'expression anglo-saxonne Trans European Trunked Radio, un système TETRA étant un système radio mobile professionnel bi-directionnel ; • VoIP, acronyme pour l'expression voix sur réseau IP, IP signifiant Protocol Internet ; • WiFi, le WiFi étant une technique de réseau informatique sans fil mise en place pour fonctionner en réseau interne ; • GSMR, acronyme pour l'expression anglo-saxonne Global System for Mobile communications Railways, GSMR est un standard de communication sans fil basé sur le GSM, Global Système for Mobile communications, norme numérique de seconde génération pour la téléphonie mobile. Le GSMR est développé spécifiquement pour les applications et les communications ferroviaires. Chaque application de supervision s'interface avec l'infrastructure SOA 2 par l'intermédiaire d'un connecteur SOA 133, 143, 153, 163, 173, 183, 193. Les connecteurs SOA sont des interfaces basées sur le principe des Web Services, ou Services Web en français, Web faisant référence à internet. Les Web Services sont des logiciels conçus pour supporter une interopérabilité entre deux machines interagissant à travers un réseau. Les services web sont notamment des interfaces de programmation pouvant être accessibles par l'intermédiaire d'un réseau comme internet et exécutées par un système distant hébergeant un service web dédié. Avantageusement l'utilisation de services web pour réaliser les interfaces entre l'infrastructure SOA 2 et les différentes applications 3, 4, 5, 6, 7, 8, 9 permet de modifier une application sans impact sur le fonctionnement des autres applications, chaque application gardant son indépendance. De plus le remplacement d'une application par une autre application est simplifié. L'application de supervision SCADA 3 est reliée aux équipements SCADA 132 qu'elle supervise comme : des détecteurs de fumée, des escaliers mécaniques d'une station de métro, des systèmes de ventilation, des systèmes de contrôle de l'environnement, des systèmes d'alimentation électrique. L'application de supervision SCADA 3 est également interfacée avec une interface homme machine, IHM SCADA 131, dédiée à l'application de supervision SCADA 3. L'application de supervision ATS 4 comporte des interfaces avec des équipements ATS 142 qu'elle supervise comme : des trains, des métros. L'application de supervision ATS 4 est également interfacée avec une interface homme machine, IHM ATS 141, dédiée à l'application de supervision ATS 4. L'application de supervision de systèmes billettiques 5 comporte des interfaces avec des équipements billettiques 152 qu'elle supervise comme : des valideurs de titre de transport, des terminaux de vente de titre de transport, des portillons d'accès aux stations. L'application de supervision de systèmes billettiques 5 est également interfacée avec une interface homme machine, IHM Billettique 151, dédiée à l'application de supervision de systèmes billettiques 5. L'application de supervision de systèmes d'informations aux voyageurs 6 comporte des interfaces avec des équipements d'information aux voyageurs 162 qu'elle supervise comme : des écrans d'affichage, des hauts parleurs. L'application de supervision de systèmes d'informations aux voyageurs 6 est également interfacée avec une interface homme machine, IHM Information voyageurs 161, dédiée à l'application de supervision de systèmes d'informations aux voyageurs 6. L'application de supervision de systèmes de contrôle d'accès 7 comporte des interfaces avec des équipements de contrôle d'accès 172 qu'elle supervise comme : des lecteurs de badges, des alarmes anti- intrusion. L'application de supervision de systèmes de contrôle d'accès 7 est également interfacée avec une interface homme machine, IHM contrôle d'accès 171, dédiée à l'application de supervision de systèmes de contrôle d'accès 7. L'application de supervision de systèmes de vidéo surveillance 8 comporte des interfaces avec des équipements de vidéo surveillance 182 qu'elle supervise comme : des caméras. L'application de supervision de systèmes de vidéo surveillance 8 est également interfacée avec une interface homme machine, IHM vidéo surveillance 181, dédiée à l'application de supervision de systèmes de vidéo surveillance 8. L'application de supervision de systèmes de communications 9 comporte des interfaces avec des équipements de vidéo surveillance 192 qu'elle supervise comme : des bornes d'appel d'urgence, des radios, des téléphones. L'application de supervision de systèmes de communications 9 est également interfacée avec une interface homme machine, IHM communications 191, dédiée à l'application de supervision de systèmes de communications 9. Une interface homme machine, IHM intégrée 10 est également interfacée à l'infrastructure SOA 2 par l'intermédiaire d'interfaces basées sur des services web. L'IHM intégrée 10 permet de visualiser toutes les informations de supervisions provenant des différentes applications de supervision 3, 4, 5, 6, 7, 8, 9 et transitant par le l'infrastructure SOA 2. L'IHM intégrée 10 permet également d'agir sur les différents équipements en ayant accès aux fonctionnalités proposées par les différentes applications de supervision 3, 4, 5, 6, 7, 8, 9. L'IHM intégrée 10 peut être utilisée par plusieurs opérateurs différents, chaque opérateur pouvant avoir un rôle de supervision défini. La définition d'un rôle de supervision dans l'IHM intégrée 10 permet d'avoir accès à un nombre restreint d'actions sur différents équipements tout en conservant la possibilité de visualiser des informations provenant de l'ensemble des applications. Avantageusement, chaque opérateur peut réaliser une action en prenant en compte la situation de l'ensemble des équipements même ceux dont il n'a pas la charge. Ceci assure une cohésion de l'ensemble des actions effectuées par les différents opérateurs. L'infrastructure SOA 2 a un rôle d'orchestration des différentes actions de supervision. En effet, l'infrastructure SOA 2 peut comporter une base de données de règles métier 11. Les règles métier permettent de définir des procédures à effectuer selon des contextes opérationnels. Un contexte opérationnel étant défini par un ensemble de paramètres transmis par les applications de supervision 3, 4, 5, 6, 7, 8, 9 comme des états d'équipements, des événements particuliers ou des alarmes, les alarmes étant des événements auxquels est attachée une notion de criticité. La base de données de règles métiers peut contenir par exemple des procédures standards, des procédures d'urgences. Un exemple de procédure métier est représenté sur la figure 2. Ainsi les procédures métier ne sont pas implémentées dans l'infrastructure SOA 2. L'infrastructure SOA 2 récupère dans la base de données des règles métier 11 les procédures métier à exécuter. Ainsi, il est simple de modifier les procédures métiers, il suffit de modifier les procédures stockées dans la base de données des règles métier 11, sans qu'aucune modification de l'infrastructure SOA 2 ni des applications de supervisions 3, 4, 5, 6, 7, 8, 9 ne soit nécessaire. Les procédures métier définies dans la base de données 10 sont spécifiques à la supervision du système. Un outil de configuration 12 peut permettre de configurer l'infrastructure SOA 2 afin d'assurer une configuration cohérente des différentes applications 3, 4, 5, 6, 7, 8, 9. II permet également de configurer les règles métier de l'infrastructure SOA 2. La figure 2 représente de manière schématique un exemple d'exécution d'un processus métier par le système de supervision intégré selon l'invention. Le processus métier 20 représenté figure 2 s'applique au domaine du transport terrestre. Le processus métier 20 est défini au niveau de la base de données des règles métier 11. Le processus métier 20 est exécuté par l'infrastructure SOA 2 qui orchestre ainsi les différentes actions des applications de supervision impliquées. Une application ATS 142 transmet à l'application de supervision ATS 4 l'information suivante : un train entre dans la station de train 21. Sur réception de cette information, l'infrastructure SOA 2 exécute automatiquement le processus métier 20 suivant : • ordre 22 de commutation d'une caméra pointée sur l'arrivée du train, transmis par l'infrastructure SOA 2 à l'application de supervision des systèmes de vidéo surveillance 8 ; • ordre 23 d'affichage d'une information signalant l'arrivée du train aux voyageurs, transmis par l'infrastructure SOA 2 à l'application de 25 supervision des systèmes d'informations aux voyageurs 6 ; • ordre 24 de positionnement des ascenseurs de la station au niveau correspondant au niveau du quai d'arrivée du train, transmis par l'infrastructure SOA 2 à l'application de supervision SCADA 3. Chaque application de supervision est ensuite responsable de répercuter au 30 niveau des équipements qu'elle supervise l'ordre qu'elle a reçu de l'infrastructure SOA 2. Ainsi les processus métier peuvent être exécutés automatiquement, sans que l'intervention d'un opérateur soit nécessaire, ce qui allège considérablement le travail des opérateurs qui peuvent alors se consacrer à 35 des procédures plus complexes, nécessitant une expertise humaine. Par ailleurs il est très simple de modifier le processus métier sans modifier aucune des applications. Par exemple, dans l'exemple précédent, s'il est décidé de jouer une musique de fond sur des haut-parleurs de la station dans lequel un train arrive, il suffit de rajouter une description de cette règle dans la base de règle métier et un service correspondant de l'application Information Voyageurs 6 est appelé. D'autres processus métier, pouvant aussi être définis dans la base de données des règles métier 11, peuvent nécessiter des actions de la part d'un opérateur comme un acquittement, par exemple, avant d'effectuer la procédure automatiquement, et éventuellement une saisie d'informations. L'opérateur a également la possibilité d'effectuer les procédures métier manuellement s'il le souhaite. Par exemple il peut spécifier au niveau de l'IHM intégrée 10 qu'il souhaite effectuer les procédures en mode manuel. L'utilisation en mode manuel du système de supervision permet à l'opérateur d'intervenir lorsqu'un événement non prévu dans une procédure survient. Ainsi l'opérateur peut agir en toute circonstance. Le système de supervision selon l'invention est donc un système intégré, l'ensemble des procédures de supervision étant réalisable à partir d'une seule interface homme machine : l'IHM intégrée 10 et exécutées de manière centralisées par l'infrastructure SOA 2. L'orchestration des différentes actions par l'infrastructure SOA 2 permet d'assurer une cohérence entre les différentes actions. Par exemple, l'infrastructure SOA 2 peut vérifier qu'une action est bien accomplie par un équipement avant de demander l'exécution d'une autre action. Les figures 3a et 3b représentent respectivement un synoptique de traitement d'un événement 30 reçu par l'infrastructure SOA 2 et d'une alarme 31 reçue par l'infrastructure SOA 2. Un premier ensemble de processus métier définis dans la base de données 11 peut concerner par exemple le traitement d'un événement 30 provenant d'une application de supervision. Un événement 30 est par exemple l'arrivée d'un train dans une station tel que représenté sur la figure 2. Un événement 30 ne nécessite pas obligatoirement un traitement. Dans ce cas, le système de supervision n'a pas de réaction 301. Un premier processus métier peut indiquer à l'infrastructure SOA 2 que, sur réception d'un premier événement, l'infrastructure SOA 2 ne réagit pas. Un deuxième processus métier peut aussi indiquer que l'infrastructure SOA 2 doit router le premier événement vers l'IHM intégrée 10 par exemple ou vers une autre application de supervision. Un troisième processus métier peut indiquer que sur réception d'un deuxième événement, l'infrastructure SOA 2 doit exécuter automatiquement un quatrième processus métier, il peut également préciser que l'infrastructure SOA 2 doit router le deuxième événement vers un destinataire précisé dans le quatrième processus métier. Un deuxième ensemble de processus métier pouvant être définis dans la base de données peut concerner le traitement d'une alarme 31 par le système de supervision selon l'invention. Une alarme 31 nécessite obligatoirement un acquittement de l'opérateur pour vérifier qu'il a bien pris connaissance de cette alarme. Un traitement, qui peut être un processus métier automatique 311, peut alors être nécessaire. Sur réception d'une alarme, suivant ce qui a été configuré au niveau de l'infrastructure SOA, l'opérateur après acquittement sera amené soit à visualiser l'exécution automatisée de la procédure automatique 3101, soit devra interagir avec une procédure interactive 3102. II peut également être configuré qu'aucune réaction du système n'est attendue suite à l'acquittement de certaines alarmes 3103. Une procédure automatique est un processus métier choisi par l'opérateur et défini dans la base de données 11. Une procédure interactive peut être un processus métier, aussi défini dans la base de données 11, mais nécessitant une ou plusieurs actions de la part de l'opérateur. La procédure interactive permet de guider l'opérateur dans la réalisation de la procédure afin qu'il n'oublie aucune étape par exemple. Certaines étapes d'une procédure interactive peuvent être effectuées de manière automatique par certaines applications de supervision sur demande de l'infrastructure SOA 2. Pour chaque pas de la procédure non automatisée, l'opérateur pourra au choix et en fonction de ce qui a été configuré au niveau de l'infrastructure SOA 2 - demander au système d'effectuer cette action ; décider de ne pas effectuer ce pas de la procédure ; - effectuer manuellement l'action qui est définie et indiquer qu'elle a abouti ; effectuer manuellement l'action qui est définie et indiquer qu'elle a échoué; D'autres processus métier non représentés sur les figures 3a et 3b peuvent concerner uniquement la transmission d'informations reçues par une première application de supervision à une deuxième application de supervision par exemple. L'utilisation de procédures automatiques ou semi-automatiques permet une amélioration de la fiabilité de l'exécution des procédures, l'opérateur étant guidé dans le cas de procédures semi-automatiques afin qu'aucun étape ne soit omise. L'utilisation de procédures automatiques ou semi-automatiques permet également un gain de temps dans l'exécution des procédures. L'automatisation de certains processus métier permet une 15 réduction des coûts d'exploitation du système global, par exemple il est alors possible de réduire le nombre des opérateurs de supervision. De plus l'automatisation des processus métier permet d'automatiser par exemple les informations aux voyageurs permettant une meilleure information des passagers. Il est également possible de 20 synchroniser automatiquement les ascenseurs avec le trafic, ce qui permet aux passagers de sortir plus rapidement de la station. Avantages Le système selon l'invention fournit avantageusement un système 25 d'aide à l'opérateur lui permettant d'effectuer les différentes procédures de manière sécurisée : le système propose en effet une liste d'actions à effectuer et permet de réaliser certaines actions automatiquement. Les actions automatiques permettent avantageusement d'améliorer la rapidité d'exécution des procédures, ce qui peut être crucial lors de procédures 30 d'urgence, afin de garantir la sécurité du public. Avantageusement, l'utilisation d'une IHM unique permet à l'opérateur de contrôler plus facilement les différentes applications du système de supervision. L'architecture du système intégré selon l'invention permet 35 avantageusement une intégration simple de multiples applications de supervision pouvant provenir de différents fournisseurs. L'architecture permet également de remplacer une application par une autre application sans impact sur le système de supervision. De même les interactions entre les différentes applications peuvent être modifiées sans intervenir sur les applications elles-mêmes. L'utilisation du framework SOA confère avantageusement à l'architecture du système selon l'invention un caractère modulaire qui permet d'intégrer, de modifier, de remplacer des applications de supervision hétérogène sans impact sur les autres applications. ~o Avantageusement, l'invention permet d'améliorer la sureté de fonctionnement du système en utilisant des services web éprouvés en matière de sécurité. REVENDICATIONS1. Système intégré de supervision et de commandement (1) d'un système de transport, caractérisé en ce qu'il comporte : • plusieurs applications de supervision d'équipements (3, 4, 5, 6, 7, 8, 9) du système de transport ; • une interface homme machine intégrée (10) ; • une infrastructure (2) ayant une architecture orientée services ; lesdites applications de supervision (3, 4, 5, 6, 7, 8, 9), et l'interface homme machine (10) s'interfaçant avec l'infrastructure (2) par l'intermédiaire de services web (133, 143, 153, 163, 173, 183, 193). 2. Système selon la revendication 1 caractérisé en ce qu'il exécute des processus métier (20) définis dans une base de données (11) de règles 15 métier. 3. Système selon la revendication 2, caractérisé en ce que l'interface homme machine (10) affiche des pas du processus métier. 20 4. Système selon la revendication 3 caractérisé en ce qu'il permet à un utilisateur d'agir sur le déroulement d'un processus métier en effectuant ou non un ou plusieurs pas du processus métier (20) par l'intermédiaire de l'interface homme machine intégrée (10). 25 5. Système selon la revendication 1, caractérisé en ce que les applications de supervision (3, 4, 5, 6, 7, 8, 9) et l'infrastructure (2) sont configurées par un même outil de configuration (12).