Contexte : données et infrastructure

Depuis les débuts de la démarche ASAP le décloisonnement des données opérationnelles fait partie des axes de travail. Il s’agit de mettre à disposition les données des systèmes opérationnels dans un environnement non critique en toute sécurité vis-à-vis de l’opérationnel afin d’être utilisées rapidement, facilement par les développeurs dans de nouvelles applications à forte valeur ajoutée pour les opérationnels mais aussi pour les managers. Cette démarche innovante pour la DSNA repose sur une solution technique en cours d’élaboration (cf GT ATM2 : infrastructure réseau, serveurs d’application, liaisons inter-centre services d’échanges de données élaborés). Un cas typique de besoin est l’affichage dans une même interface des configurations piste d’un ou plusieurs terrains en temps réel à des fins de supervision.

Data@cdg

Ce concept « données + infrastructure » étudié au niveau national rencontre une implémentation similaire à une échelle locale sur le site de CDG. Il s’agit de data@CDG qui se définit comme un « système de captation, centralisation et mise à disposition simplifiée des données opérationnelles brutes des systèmes de navigation aérienne de CDG ». Les données visées sont des données brutes des systèmes de la navigation aérienne, aussi bien CNS qu’ATM de la plateforme. Elles doivent être livrées dans un environnement non critique matérialisé par un équipement de réseau local nommé ROC, tout en respectant les exigences règlementaires ; dans ROC, il doit être démontré une unique fois qu’il n’est pas possible de « remonter » vers les systèmes « OP » critiques. Les applicatifs situés dans cet environnement non critique peuvent alors bénéficier des données recopies des données opérationnelles brutes en temps réel, sans nécessité de devoir se conformer aux fortes exigences de sûreté et sécurité du domaine critique.

Capture d'écran

Comment ça marche ?

Concrètement, les données sont captées directement sur les systèmes situés dans le domaine critique par « espionnage » des flux sur leurs interfaces réseau. Pour cela un équipement réseau spécifique de type TAP est utilisé . Celui-ci doit garantir qu’aucune information ne remonte vers le domaine critique. Les flux captés sont concentrés vers l’outil SIMA(*) qui permet de les enregistrer à des fins d’archivage et rejeu et les diffuser en temps réel.

De quoi est-ce constitué ?

Le système DATA@CDG est constitué d’un « moteur » et d’un « chassis ». Le chassis est une architecture réseau, le moteur est un logiciel appelé SIMA et développé à CDG depuis 2007. DATA@CDG au sens strict est constitué de 2 briques :

  • collecte /capture des données sur environnement critique [via équipement réseau spécifique] ;
  • stockage et diffusion des données en environnement non critique [ application SIMA]. Par ailleurs, une brique cliente de DATA@CDG existe déjà et permet de valider les incréments de développement de DATA@CDG : TABS (TABleau de Situation opérationnelle) qui est une IHM de visualisation de la situation opérationnelle de CDG.

Capture d'écran

Relations ASAP – DATA@CDG

Ce projet, sans être identique dans les choix techniques et le périmètre, rejoint complètement la démarche ASAP dans ses besoins et réflexions . DATA@cdg s’intéresse à la fourniture de données brutes, non altérées, non enrichies. Les traitements standards de préparation de données (nettoyage, mesure de la pertinence, de la qualité) sont volontairement hors du périmètre de DATA@CDG, tandis qu’ils sont bien présents côté ASAP et ATM2. Une certaine organisation des données émerge de la juxtaposition des projets DATA@CDG, ATM2 et FEAT/BIGDATA : DATA@CDG alimente un cloud de données opérationnelles brutes, ATM2 alimente des données plus ou moins raffinées, FEAT/BigDATA alimente les indicateurs DSNA de très haut-niveau.

Capture d'écran

Etat actuel et planning

DATA@CDG est un projet constitué d’une core team de 6 personnes (3 SE / 3ST) pouvant bénéficier de l’expertise d’autres agents . Actuellement, un prototype existe déjà et démontre la faisabilité technique du concept dans l’environnement de test : ce prototype est constitué de toute la chaine « système espionné / TAP /SIMA serveur / Serveur TABS / Client TABS ». L’étape de développement actuel vise désormais à déployer le premier incrément de ce système sur quelques systèmes choisis côté opérationnel. Désormais, le vrai enjeu de cette phase du projet est de pouvoir répondre à toutes les exigences de sécurité et de sureté que nécessite le domaine opérationnel : EPIS, SWAL, Assurance logiciel, SSI, le tout en respectant les procédures standards de DO et DTI (EB avec solution …).

Vous voulez en savoir plus ?

C’est par ici !