Patrick Bellot, Tuan Dang (EDF), Ngo Cao Cuong (PhD)
Contexte et besoins
Le renforcement de la sûreté des installations et de la sécurité des équipes d’intervention sur le terrain en fonctionnement normal, incidentel ou accidentel nécessite le croisement fort entre les données issues de la salle de commande et celles acquises en situation sur le terrain lors des interventions. Il s’agit alors de développer de véritables applications contextuelles à partir des services élémentaires (ex. acquisition de données) ou avancés (ex. accès aux diagnostics des équipements dans l’état courant de la tranche nucléaire) pour renforcer le dialogue en temps réel entre les équipes en salle de commande et celles du terrain qui peuvent donc partager davantage, si besoin, la même vision de l’état de la tranche. Pour ce faire, il est indispensable d’orchestrer de façon transparente, fiable et tolérante aux pannes les services qui sont nécessaires à ces applications.
Il s’agit en effet d’orchestrer de façon dynamique des réseaux de services dans l’espace et dans le temps pour offrir aux métiers en tout temps et en tout lieu de la centrale des services dont ils ont besoin. Les bénéfices ainsi obtenus sont nombreux : réduction du temps d’intervention, fiabilisation et sécurisation des actions terrain, etc. Un exemple de réseau de services est le réseau de capteurs sans fil de type OCARI.
Démarche scientifique
Afin de lever les verrous ci-dessus, on se propose d’introduire le concept de « Service Oriented Middleware for Context Awareness » basé sur un intergiciel (middleware) intelligent et autonome orienté messages (Autonomic Message Oriented Middleware for Context Awareness Applications, AMOCA). Les différents appareillages concernés sont reliés par des réseaux de différentes natures : liens filaires, wifi, ad hoc, réseaux de capteurs WSN, etc. Certains équipements sont mobiles. Un tel middleware devrait être capable de proposer de multiples fonctions tout en permettant l’abstraction de nombreux éléments matériels et organisationnels.
La première fonction de tout middleware, et donc d’AMOCA, est d’assurer les communications. Nous proposons des communications orientées messages nécessaires et suffisantes pour l’orchestration des services. Le routage endogène d’AMOCA se doit d’être robuste et résistant aux pannes. Pour cela, nous proposons une approche basée sur le réseau de recouvrement (Overlay Network) ROSA développé à Télécom ParisTech [1,2,3,4,5]. Installé sur un réseau filaire IP, l’intelligence de ce réseau de recouvrement est capable de trouver instantanément une nouvelle route (s’il est possible d’en construire une) et de router les messages en cas de panne d’un élément du réseau sous-jacent ou de congestion du trafic. ROSA est basé sur le maintien d’un facteur appelé densité dans des cliques virtuelles (appelées lumps) dont le cycle de vie est dynamique et auto-adaptatif. Il est autonome, robuste et passe à l’échelle (scalability). Il maintient en permanence une structure appelée Chain of Lumps (CoL) autorisant un routage efficace. Il devrait pouvoir être adapté à l’hétérogénéité des matériels et des réseaux mis en œuvre dans une centrale nucléaire et, en particulier, supporter la mobilité de certains équipements. En cas de panne ou de congestion dans le réseau sous-jacent, un routage de secours résilient basé sur les principes de ROSA (Emergency Rescue Overlay Transport, EROT) se mettra en place pour transporter les messages. Les principaux verrous scientifiques sont l’adaptation de ROSA au cadre décrit ci-dessus, de démontrer mathématiquement la robustesse du routage de secours résultant et enfin, de proposer des patrons de conceptions (design patterns) pour l’architecture du réseau afin de tirer le meilleur parti du routage de secours EROT.
Nous proposons d’intégrer la gestion des services indispensables au fonctionnement des applications contextuelles dans le middleware. Cela va de la publication de services, la découverte et la localisation de services, la gestion d’accès et la sécurisation des transactions jusqu’à la composition de services. En ce sens, AMOCA sera aussi une infrastructure d’intégration et d’orchestration de services reposant sur un routage robuste des messages et un protocole de signalisation adapté pour l’accès aux services disponibles. Pour cet aspect d’AMOCA, il faut prévoir un volet technologique, un volet conceptuel et des aspects normalisation. Du point de vue technologique, Télécom ParisTech a déjà une boîte à outils (toolkit) nommé SAW (Stand Alone Web) permettant un développement d’applications orientées services particulièrement efficaces [6,7,8]. Ce toolkit a été appliqué avec succès pour une application Web significative et opérationnelle. Il devra être étendu et adapté aux contraintes et au contexte de ce projet, en particulier du point de vue de la sécurité car l’authentification et l’intégrité des messages sont des propriétés indispensables dans notre contexte. Du point de vue conceptuel, il faudra d’abord recenser les types de services concernés par le contexte applicatif des centrales nucléaires. Il faudra intégrer les flux de données (streams) produits par les réseaux de capteurs de type OCARI. Certains services de base seront mobiles : des dosimètres ou des PDA produisant également des flux de données et des informations de localisation plus ou moins précises. Du fait de la diversité des matériels existants, une approche Web services est possible et souhaitable mais ce doit être une approche légère (Light Web Services) demandant une reformulation des outils. Il faudra définir un langage de publication de services de type WSDL mais allégé car adapté et restreint au contexte. L’intermédiaire (services broker) sera le middleware lui-même servant à la fois de fournisseur (par délégation dans le cas des réseaux de capteurs de type OCARI) et d’annuaire de services. Il faudra également inventer un langage de composition de services probablement basé sur les langages synchrones existants. Pour cela, il faudra déterminer les différents modes d’assemblage de services envisagés et utiles. Ce langage doit permettre toute sorte de composition de services comme par exemple de générer un flux d’alertes en fonction de la valeur de certains capteurs, de synchroniser des flux ou de générer des flux d’actions (commandes d’actionneurs ou alertes en salle de commande) en fonction de flux d’alertes définis par composition. Ces compositions de services, une fois publiées sur le middleware, seront, c’est innovant, pris en charge par le middleware lui-même qui devra les implémenter de manière transparente. Le middleware proposera une vue abstraite des services mobiles pour que les spécifications n’aient pas à tenir compte de la mobilité des sources. Il devra être capable de prendre en compte l’intermittence des services. Au niveau applicatif, il faudra fournir les outils permettant d’interroger les services dont les sorties (outputs) pourront être des données ou des flux de données. Ici aussi, un travail conceptuel sera nécessaire car les flux sont difficilement pris en compte par les services orientés messages. La conception de cet aspect du middleware se basera sur des approches existantes (GSN, TinyDB, Acquire, Cougar, SQS, MIT Aurora, Stanford Stream, Berkeley TelegraphCQ, …).
L’objectif de ce travail est donc la conception d’un middleware innovant, robuste et flexible. Ce chef d’orchestre sera capable d’intégrer de manière sécurisée les différentes notions de services nécessaires au contrôle-commande d’une centrale nucléaire mais il pourra certainement être appliqué dans d’autres contextes industriels ou militaires critiques. Cette thèse comporte de nombreux défis scientifiques et techniques tant du point de vue de la robustesse, de la sécurité que de l’intégration de services.
