Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
INTEGRATED SUPERVISION AND CONTROL SYSTEM
Document Type and Number:
WIPO Patent Application WO/2010/122057
Kind Code:
A1
Abstract:
The present invention relates to an integrated system (1) for supervising and controlling a transportation system, comprising: a plurality of applications (3, 4, 5, 6, 7, 8, 9) for supervising devices of the transportation system; a built-in human-machine interface (10); an infrastructure (2) with a service-oriented architecture; said supervision applications (3, 4, 5, 6, 7, 8, 9) and human-machine interface (10) interfacing with the infrastructure (2) via Web services (133, 143, 153, 163, 173, 183, 193). The integrated supervision and control system (1) according to the invention can be used in operation and control stations, for example in the field of ground transportation networks.

Inventors:
FLOUS OLIVIER (FR)
Application Number:
PCT/EP2010/055269
Publication Date:
October 28, 2010
Filing Date:
April 21, 2010
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
THALES SA (FR)
FLOUS OLIVIER (FR)
International Classes:
G05B23/02
Foreign References:
US20070294369A12007-12-20
EP1589391A22005-10-26
US20020193888A12002-12-19
Other References:
None
Attorney, Agent or Firm:
LUCAS, LAURENT (FR)
Download PDF:
Claims:
REVENDICATIONS

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

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

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

Description:
Système intégré de supervision et de commandement

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.

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

• 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 à 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, 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.

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. Il 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. Il 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 sûreté 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 sûreté 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.

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.

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 résolution d'incidents. 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 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 ;

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

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 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 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 Ohented 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. Une implémentation pouvant être retenue pour l'infrastructure SOA 2 peut être une architecture SOA basée sur un bus de services. Le bus de services à un rôle de médiateur, aussi appelé middleware en langage anglo-saxon, entre un consommateur et un producteur de service. Un middleware est une couche de logiciels qui crée un réseau d'échange d'informations entre différentes applications informatiques. Le bus de services permet notamment de réaliser un couplage lâche. Un couplage est une métrique indiquant un niveau d'interaction entre deux ou plusieurs composants logiciels comme des fonctions, des modules, des objets, des applications. Deux composants sont dits couplés s'ils échangent de l'information. On parle de couplage faible, couplage léger ou couplage lâche si les composants échangent peu d'information. Le bus de services peut aussi fournir un ensemble de services :

• des fonctionnalités de fractionnement, combinaison, permettant de construire un appel sur plusieurs services : une orchestration ; lesdites fonctionnalités reposant sur des patterns EIP, acronyme pour l'expression anglo-saxonne Enterprise Intégration Pattern, signifiant modèle d'intégration d'entreprise et notamment décrit dans l'ouvrage Enterprise Intégration Patterns de G. Hohpe et B. Woolf ;

• des fonctionnalités de gestion de version de services ;

• des fonctionnalités de supervision et de contrôle des services. Le bus de service est un ESB, acronyme pour l'expression anglo- saxonne Enterprise Service Bus, signifiant bus de service d'entreprise. Les services bus peuvent être construits selon des standards comme XML, JMS, ou encore les services web. Le standard XML, acronyme pour l'expression anglo-saxonne Extensible Markup Language, signifiant langage extensible de balisage, est un langage informatique de balisage générique. Le standard XML sert essentiellement à stocker et transférer des données de type texte Unicode structurées en champs arborescents. Le standard JMS, acronyme pour l'expression Java Message Service signifiant service de messages Java est L'interface de programmation Java Message Service permet d'envoyer et de recevoir des messages de manière asynchrone entre applications ou composants Java. Les services Web WS- * désignent une implémentation logicielle des spécifications WS- * . Les services Web WS- * reposent sur un ensemble de protocoles et de standards de base utilisés pour l'échange de données entre applications dans des environnements hétérogènes : - Le SOAP, acronyme pour l'expression anglo-saxonne Simple Object Access Protocol est un protocole de RPC orienté objet bâti sur XML. RPC, acronyme pour l'expression anglo-saxonne Remote Procédure CaII, est un protocole permettant de faire des appels de procédures sur un ordinateur distant à l'aide d'un serveur d'applications ; - le WSDL, acronyme pour l'expression anglo-saxonne Web Service

Description Langage, décrit une Interface publique d'accès à un Service

Web, notamment dans le cadre d'architectures de type SOA ; le WSDL est utilisé pour la description des services web, de leurs opérations, des messages utilisés et de leur localisation au sens internet : URI/URL. URI étant un acronyme pour l'expression anglo-saxonne Uniform Resource

Identifier, signifiant littéralement identifiant uniforme de ressource. Une

URI est une courte chaîne de caractères identifiant une ressource sur un réseau. URL est un acronyme pour l'expression anglo-saxonne Uniform

Resource Locator, signifiant littéralement localisateur uniforme de ressource. Une URL est une chaîne de caractères utilisée pour adresser des ressources du World Wide Web. Le World Wide Web, littéralement la

« toile d'araignée mondiale », communément appelé le Web, est un système hypertexte public fonctionnant sur Internet qui permet de consulter, avec un navigateur, des pages accessibles sur des sites. Les logiciels écrits dans divers langages de programmation et sur diverses plates-formes et dans différents environnements embarqués, DSI, peuvent employer des services web WS- * pour échanger des données à travers des réseaux informatiques comme Internet. Des systèmes intégrés de supervision s'appuyant habituellement sur des réseaux standards comme internet, ce type de protocole est particulièrement bien adapté pour permettre la plus large intégration possible d'applications existantes, d'applications fournies par des éditeurs ou d'applications nouvellement développées.

L'ESB est principalement un outil d'échange asynchrone disposant d'interfaces standardisées comme des interfaces standardisées SOAP, JMS ou intégré comme JBI. JMS, acronyme pour l'expression anglo-saxonne Java Message Service, est une interface de programmation permettant d'envoyer et de recevoir des messages de manière asynchrone entre applications ou composants Java. JBI, acronyme pour l'expression anglo- saxonne Java Business Intégration, est une norme édictée dans le document JSR 208. L'ESB peut aussi offrir des services à valeur ajoutée, comme des traductions, des transformations, activées par des événements. Dans le cadre d'un système intégré de supervision, l'ESB peut être préconfiguré pour prendre en charge différentes fonctionnalités de supervision comme : un affichage de situations, des contrôles/commandes, au travers d'EIP spécifiques et de plusieurs services définis. L'ESB permet également, par son architecture, de s'adapter aux besoins supplémentaires spécifiques à n'importe quel service de supervision.

La figure 1 représente à titre d'exemple sept applications de supervision. D'autres types 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 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 ;

• 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. 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, Ie 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 antiintrusion. 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 NHM 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. Il 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 1 1 . 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 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 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 à 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 1 1 , 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 NHM 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 1 1 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 NHM 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. Il 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 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 synchroniser automatiquement les ascenseurs avec le trafic, ce qui permet aux passagers de sortir plus rapidement de la station.

Le système selon l'invention fournit avantageusement un système 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 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 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.

Avantageusement, l'invention permet d'améliorer la sûreté de fonctionnement du système en utilisant des services web éprouvés en matière de sécurité.