Brevet FR2953954A1 — publié le 20110617

DISPOSITIF D'ELABORATION DES ALERTES D'UN SYSTEME D'AERONEF Le domaine de l'invention concerne la surveillance des alertes des systèmes avioniques d'aéronef. Les systèmes avioniques comportent généralement leur propre moyen de détection d'anomalie et de génération d'alerte pouvant transmettre les alertes à un système de gestion centralisée des alertes (« Flight Warning System » en langage anglo-saxon). Ainsi un tel système de gestion des alertes est capable d'alerter l'équipage, de faire connaître les défauts de l'avion et de lister à l'équipage les procédures à appliquer en réponses aux alertes affichées par le système. Un système centralisé de gestion des alertes constitue un progrès par rapport à des reports d'alertes par sous-système qui ne permettraient pas à l'équipage d'avoir une vue d'ensemble en cas de survenance concomitante de plusieurs alertes. En outre, le système de gestion centralisée des alertes comporte les moyens d'envoyer les alertes détectées et traitées à un système d'enregistrement des données de vol ainsi qu'à un système de maintenance de l'aéronef et de synchroniser les messages audio associés aux alertes. Les systèmes avioniques hébergent aussi leur propre mécanisme de détection d'anomalies fonctionnelles dont le résultat est ensuite transmis directement à la fonction de gestion des alertes. Plus généralement, on distingue la partie «Monitoring», c'est-à-dire de surveillance des anomalies fonctionnelles, hébergée principalement dans les systèmes avioniques et partiellement dans la fonction de gestion des alertes et la fonction «Consolidation» hébergée dans le système de gestion des alertes qui, à un résultat de surveillance, suivant les conditions de vol, associe une alerte. Les principales fonctions du système de gestion centralisée des alertes sont la collecte des données des systèmes avioniques, la détection des alertes, le filtrage des alertes et l'annonce des alertes. La principale difficulté est la détection des alertes qui suppose une bonne connaissance de l'état des systèmes et qui consiste en la détection d'anomalies fonctionnelles réalisées par les fonctions de surveillance des systèmes avioniques et du système de gestion centralisée des alertes. Actuellement, le problème est résolu par les systèmes avioniques et le système de gestion centralisée et la solution technique au problème est basée sur le traitement des flux d'entrée (collecte des données des systèmes avioniques) via des logiques de type booléenne : AND, OR, NOR, NOT, retard, confirmation, step... . Comme représentée par la figure 1, les solutions utilisées pour la gestion des alertes comporte un système de gestion centralisée des alertes (FWS) pouvant récupérer différentes informations. Ces informations fournies au système FWS peuvent être des données simples et des alertes directement générées par les systèmes externes. Lorsque les systèmes avioniques hébergent leur propre fonction de détection d'anomalies fonctionnelles, l'alerte associée à l'anomalie est ensuite transmise directement au système FWS. Les alertes sont prises en compte par un module de gestion des alertes et le système FWS peut afficher à l'équipage les alertes ainsi que les procédures associées pour résoudre le problème lié à l'alerte. Lorsque les informations sont des données simples, le module de gestion des alertes effectue une interprétation des données reçues afin de déterminer s'il est nécessaire de générer une alerte. A cette fin, le module de gestion d'alertes met en oeuvre une fonction de détection d'alertes. L'aéronef étant constitué de systèmes complexes le système FWS doit être capable de traiter une multitude d'alertes et d'informations. Le problème des solutions actuelles provient du fait que les systèmes avioniques et la fonction de gestion centralisée ne connaissent pas la topologie et les interactions entre les systèmes avioniques car les configurations des systèmes sont implicitement incluses dans les logiques de détection des alertes. Ces logiques peuvent s'avérer erronées notamment dans le cadre de pannes multiples ou dans le cadre de reconfiguration des systèmes. En outre, les cas de pannes multiples peuvent conduire à des alertes multiples qui impactent fortement la charge du personnel navigant. Du fait que les logiques utilisées sont statiques et monopannes, c'est-à-dire qu'à une panne donnée est associée une alerte, les algorithmes associés manquent de robustesse à des aspects de reconfiguration automatique ou de passivation sélective ou à de pannes multiples. On entend par passivation sélective le fait de ne plus utiliser une partie du réseau d'équipements. La présente invention propose un dispositif d'élaboration des alertes permettant de détecter les alertes appropriées en cas de reconfiguration d'un système avionique et, lors de situation de pannes multiples, d'afficher la ou les alertes pertinentes parmi le flot d'alertes pouvant être déclenchées en cascade suite à la panne d'un premier équipement d'un système. Plus précisément, l'invention concerne un dispositif d'élaboration d'alertes des équipements d'un aéronef communiquant au moyen d'un réseau de communication et pouvant réaliser chacun une application fonctionnelle de l'aéronef. Le dispositif comporte une base de données d'objets virtuels représentant les équipements et les composants du réseau de communication pour construire un modèle virtuel représentatif d'une part de la configuration topologique du réseau d'équipements et d'autre part de la configuration de la chaîne d'applications fonctionnelles mise en oeuvre par les équipements, des moyens pour chaque objet virtuel d'élaborer une requête de consultation du statut de l'application fonctionnelle réalisée par l'équipement associé à l'objet et du statut de l'équipement de sorte à modifier le statut de l'objet en fonction des informations reçues, des moyens de détection d'alertes pour élaborer des requêtes de consultation du statut de chacun des objets du modèle virtuel et de réception des informations du statut de la configuration topologie et fonctionnelle des objets virtuels en réponse aux requêtes de consultation de sorte à détecter des anomalies de configuration de la topologie du réseau d'équipements et de la chaîne d'applications fonctionnelles du modèle virtuel et à transmettre les alertes associées aux anomalies. Avantageusement, une requête de consultation de statut d'un objet est de format unique pour l'ensemble des objets du modèle. Avantageusement, un objet virtuel comporte une pluralité d'informations représentant le statut de l'équipement associé à l'objet et le statut de l'application fonctionnelle réalisée par l'équipement. Avantageusement, les requêtes de consultation de statut consultent la configuration topologique du modèle virtuel. Avantageusement, les requêtes de consultation de statut consultent la configuration de la chaîne d'applications fonctionnelles du modèle virtuel. Selon l'une quelconque des variantes précédentes, il comporte en outre des moyens d'activation et de désactivation des alertes issues des objets du modèle virtuel. Le modèle virtuel d'un système est une représentation en temps réel de la configuration topologique et fonctionnelle des équipements du système. L'utilisation d'un modèle virtuel est avantageuse du fait que les objets virtuels représentant les équipements du système comportent des informations de statut concernant le comportement fonctionnel et structurel au sein du réseau de communication. Ainsi, le modèle tient compte des reconfigurations éventuelles, automatiques ou non dont la passivation sélective. C'est un modèle évolutif représentant le statut du système en temps réel. De plus, le modèle est valable quelque soit les équipements et le système auquel ils appartiennent et est également indépendant des logiques de détection d'alerte. En effet, le modèle est mis à jour continuellement puis est analysé pour en déduire les états associés à des alertes. Le modèle est applicable à un équipement, à un sous-groupe d'équipements composant un système ou à la totalité des équipements et des systèmes et peut donc s'adapter à des architectures centralisées ou distribuées. Un modèle est créé à partir des fichiers de configuration propre au système réel et à sa définition et qui s'enrichit de tous les évènements qui impactent l'architecture : Téléchargement de logiciels, de tables de configuration et de données issues des bases de données embarquées, changement et chargement de nouveaux éléments dans le système, pannes d'équipements du système, reconfiguration d'un système, passivation sélective. Plus généralement, le modèle évolue en fonction de tout événement qui entraîne une modification de la configuration topologique du réseau de communication entre les équipements et systèmes et une modification de la configuration fonctionnelle des équipements.35 L'invention sera mieux comprise et d'autres avantages apparaîtront à la lecture de la description qui va suivre donnée à titre non limitatif et grâce aux figures annexées parmi lesquelles : La figure 1 représente un schéma simplifié d'une architecture 5 fonctionnelle d'une solution de gestion des alertes dans un aéronef selon l'état de la technique. La figure 2 représente un schéma simplifié de l'architecture fonctionnelle de la solution de gestion des alertes dans un aéronef selon l'invention. 10 La figure 3 illustre les fonctions du dispositif revendiqué pour élaborer des alertes. La figure 1 représente un schéma simplifié d'une architecture fonctionnelle d'une solution de gestion des alertes dans un aéronef selon 15 l'état de la technique. Les alertes et les informations d'état de l'ensemble des systèmes sont gérées de façon centralisées par le coeur de fonction du système FWS. La fonction FWS gère ensuite les informations d'état et les alertes reçues pour les afficher et éventuellement les associer à des procédures et tâches opérationnelles dans le but pour informer l'équipage de 20 la défaillance détectées et de lui afficher les tâches à réaliser en fonction de cette défaillance. En outre, le système FWS comporte des bases de données de procédures à réaliser et le coeur FWS est constitué de moyen de calcul pour mettre en oeuvre les logiques booléennes permettant d'associer à chaque alerte ou information de statut un message ou une procédure à 25 afficher dans un ou plusieurs dispositifs de visualisation du cockpit de l'aéronef. Cependant, ce mode de fonctionnement montre ses limites pour les systèmes complexes où, lorsque plusieurs alertes sont déclenchées par les systèmes notamment par un effet cascade entre les systèmes, les logiques booléennes ne permettent pas de synthétiser efficacement le flux 30 d'informations pour aider l'équipage à prendre les bonnes décisions. Pour cela, comme illustré en figure 2, l'invention propose un dispositif d'élaboration d'alertes 100 provenant de un ou plusieurs systèmes 6 d'un aéronef pour la surveillance des alertes des systèmes d'un aéronef 35 civil ou militaire qui remplissent par exemple les diverses fonctions nécessaires à l'accomplissement d'un vol. Un système avionique 6 comporte le plus souvent plusieurs équipements communicants agencés dans un réseau de communication (ADCN pour « Airborne Data Communication Network » en langage anglo-saxon). Ces équipements et autres systèmes de l'aéronef communiquent entre eux et avec l'environnement par un réseau physique selon un format de donnée de type ARINC 429. Cette norme de communication est la plus utilisée pour la communication entre les systèmes complexes d'aéronef, toutefois l'invention ne se limite pas à ce type de norme de communication. Le dispositif d'élaboration des alertes selon l'objet revendiqué permet de fournir au système FWS des données d'alertes prenant en compte la topologie du réseau de communication entre les équipements et systèmes ainsi que le comportement fonctionnel de chacun d'eux et l'ensemble de la chaîne fonctionnelle réalisée par les équipements. Le ou les modèles 2 élaborés par le dispositif selon l'invention représentent les systèmes par : - un niveau physique: les équipements matériels, les connecteurs, les câbles. - un niveau logique ou d'application fonctionnelle: les applications, les OS (« operating software »), les messages de données, les chemins de données des bus multiplexés par exemple. - un niveau fonctionnel représentant l'ensemble de la chaîne d'application fonctionnelle: les fonctions avions "calcul position" et les flux fonctionnels comme les données "vitesse", "position" par exemple. A chacun de ces niveaux est attribué un statut dans un objet virtuel du modèle virtuel2. Une logique d'alerte est une logique booléenne sur les statuts des fonctions et des chaines fonctionnelles (succession de fonctions et de flux fonctionnel). Ces fonctions et flux fonctionnels sont alloués sur le niveau logique (une fonction de calcul de position est associée à trois applications logicielles par exemple), lui même alloué sur le niveau physique (une première application sur un premier équipement, une seconde application sur un second équipement ...). Au cours du fonctionnement des systèmes, des évènements intrinsèques au système 6 ainsi que des évènements propres à l'environnement d'utilisation du système viennent modifier la configuration des équipements du système 6. Par exemple, lors d'une défaillance d'un calculateur d'un équipement mettant en oeuvre initialement une application donnée, cet équipement peut être désactivé et la réalisation de l'application en question peut être réorientée sur un autre calculateur. Il s'agit dans cet exemple d'un cas de reconfiguration des systèmes pouvant être automatique ou manuelle. Des fichiers de configuration propres au système réel s'enrichissent de tous les éléments ayant des répercutions sur la configuration des systèmes. Ces évènements peuvent être par exemple le téléchargement et mise à jour de logiciels, des tables de configuration, de bases de données, le changement et chargement de nouveaux équipements dans le système, les pannes d'équipements du système, la reconfiguration du système et la passivation sélective d'un équipement. Le modèle contient la topologie du réseau des équipements du système réel et les relations de propagation des défaillances. Par exemple, une alerte est déclenchée lorsque le pilote automatique ne reçoit pas la vitesse aérodynamique. L'algorithme de détection des alertes considère que tout est valide quand la chaîne fonctionnelle "calcul de la vitesse", "transport de la vitesse", "traitement de la vitesse" est bon. Ces fonctions sont allouées sur une application calcul, sur un réseau de communication logique et sur une application de traitement. Dans le modèle, cette application de calcul est allouée à un équipement, le réseau de communication à un réseau multiplexé type ethernet avec une succession de switch, et deux calculateurs de pilotage automatique. Dans cette configuration, l'algorithme prend en compte l'état de tous ces objets, issus de l'état des composants réels du système dont ceux des switchs. Si le réseau Ethernet ne fonctionne plus et que les données sont transmises par un réseau de type A429 via une fonction de « dataconcentration » qui communique via un bus de communication A429 aux calculateurs du pilotage automatique. L'algorithme ne change pas mais l'allocation de l'application fonctionnelle sur l'équipement de communication physique change. L'algorithme prend désormais en compte l'état des bus de communication A429 et de la « dataconcentration » pour élaborer l'alerte Les objets du modèle transmettent leur résultat de détection de défaillance en réponse à des sollicitations provenant de l'algorithme de détection (communication perdue, data non reçu, « failed »...), les états normaux et des autres qui sont perçus comme une défaillance (« OFF », « in test », «in dataloading », « crew action »...), les conditions environnementales qui peuvent influer sur son comportement (température trop élevé, MEU/SBU (« Multiple Event Upset », « Single Bit Upset »), givrage, vitesse trop élevée...) ou leur état sain... La figure 3 illustre le fonctionnement du dispositif revendiqué pour élaborer des alertes. Un système réel 6 comprend une pluralité d'équipements communicants connectés entre eux par un réseau de communication. Ces équipements réalisent des fonctions nécessaires au déroulement de la mission du système 6 et évolue au cours de son fonctionnement. Les évènements 7 de modifications et d'évolutions impactant la configuration topologique et fonctionnelle du système 6 sont enregistrés dans des fichiers de configurations 5. En réponse à ces évènements, les fichiers de configuration fournissent les ordres de configuration 52 vers les équipements et le réseau de communication du système réel 6. Le dispositif 100 d'élaboration des alertes du système d'équipements 6 comporte un moyen de simulation d'un modèle virtuel 2 du système d'équipements 6. Ce modèle reproduit l'architecture du système réel 6 et est constitué d'objets virtuels représentant les équipements, les applications fonctionnelles réalisées par ses équipements et les éléments de communication du système réel 6. Le modèle représente la topologie du système ainsi que les interactions entre les équipements du système. Ce model est constitué et mis à jour à partir des données réelles (dont par exemple les fichiers de configuration 5) du réseau d'équipement et des équipements eux-mêmes en temps réel. Ce modèle est hébergé par un ou des calculateurs et est, soit distribué entre les systèmes et le système FWS, soit centralisé (par exemple au sein du système FWS ou dans un calculateur indépendant dédié à la simulation d'un modèle). Ce serveur peut être accédé par un plusieurs systèmes recherchant un même modèle ou plusieurs modèles différents. Le modèle 2 est initialement construit par une fonction 1 de création de modèle utilisant une base de données 8 constituant une bibliothèque d'objets virtuels. Le modèle est supporté par une architecture construite sur une base programmation objet. Chacun des objets représente un comportement d'équipement (commutateur, lien, port, connecteur, etc.). A partir des fichiers de configuration 5 représentant la configuration du système réel et la bibliothèque d'objets virtuels, la fonction 1 de création du modèle établit un modèle virtuel 6 représentant la topologie du système ainsi que les interactions entre les équipements. Chaque évènement ayant un impact sur le système réel 6 est enregistré dans les fichiers de configuration servant également à construire le modèle virtuel. Ainsi, le modèle est mis à jour en temps réel et représente le comportement courant du système. Le dispositif selon l'invention comprend également des moyens 61 permettant de transmettre en temps réel des informations directement entre les équipements et le modèle 2 permettant ainsi de maintenir le modèle à jour et de transmettre des réponses 61 suite à des interrogations 21 provenant du modèle si un objet du modèle sollicité par l'algorithme de détection des alertes ne contient pas l'information demandée. Pour chaque objet, la façon de répondre à la sollicitation 31 est différente. Dans un premier exemple, un objet correspondant à un équipement réel avec une capacité de traitement et de communication, va par exemple le contacter et lui demander de lancer un test et de communiquer le résultat. Un autre objet associé à un câble réel, va solliciter les équipements destinataires par exemple pour demander s'ils reçoivent bien les données attendues. Dans un second exemple, lorsqu'un équipement est défaillant et que l'application est portée sur un second équipement, l'information est transmise au modèle virtuel qui se met à jour automatiquement en déplaçant l'objet associé à l'application. Les logiques d'alertes au niveau fonctionnel sont allouées sur les applications au niveau logique, elles mêmes allouées sur des équipements au niveau physique. Cette logique d'alerte est conservée, le modèle lui a évolué (allocation du logique sur le physique), le résultat prend donc en compte cette reconfiguration. La détection des alertes est réalisée par un moyen de calcul 3 exploitant le modèle 2 en associant des alertes à des états du modèle. Ainsi des états du modèle peuvent être utilisés pour détecter les cas de déclenchement d'alertes en cascade et d'alerte multiples pour déduire les alertes les plus appropriées à transmettre au personnel naviguant. Pour cela, les objets virtuels du modèle possèdent une interface avec l'algorithme de détection permettant au moyen de calcul 3 mettant en oeuvre l'algorithme de détection de transmettre des requêtes de consultation de statut 31 vers chacun des objets du modèle. Ces objets envoient des réponses 22 au moyen de calcul de détection d'alerte 3. L'algorithme d'alerte fournit l'état de la chaîne d'applications fonctionnelles considérée dans le système considéré et ainsi peut en déduire l'alerte adéquate à transmettre au pilote. D'autres informations peuvent être issues de l'analyse: tout statut de chaque équipement, maillon de la chaîne défaillant. Pour filtrer les fausses alertes, le modèle est mis à jour en fonction des évolutions du système réel. Si un calculateur est en statut éteint (« OFF »), ce statut est indiqué dans le statut de l'objet associé. En parcourant le modèle, l'algorithme ne s'intéresse qu'aux objets qui sont associés à la fonction considérée et traite à la fois leur état constaté et la visibilité de leur état. Plus précisément, si le statut d'un équipement réel est valide mais que le chemin entre le modèle et l'équipement est coupé par un autre équipement en panne, le modèle le traite en "non visible", si le chemin est bon, le modèle le traite en "bon"._Selon les états du modèle, l'algorithme génère des alertes 32 qui sont ensuite transmises vers un dispositif de gestion des alertes permettant la présentation des alertes à l'équipage avec les informations voulues, comme par exemple les procédures et tâches à réaliser pour traiter la panne. L'invention s'applique aux systèmes de gestion centralisée des alertes provenant des équipements d'un aéronef et particulièrement à la fonction de détection des alertes. REVENDICATIONS1. Dispositif d'élaboration d'alertes (32) des équipements (6) d'un aéronef communiquant au moyen d'un réseau de communication et pouvant réaliser chacun une application fonctionnelle de l'aéronef, caractérisé en ce qu'il comporte : - une base de données (8) d'objets virtuels représentant les équipements et les composants du réseau de communication pour construire un modèle virtuel (2) représentatif d'une part de la configuration topologique du réseau d'équipements et d'autre part de la configuration de la chaîne d'applications fonctionnelles mise en oeuvre par les équipements (6), - des moyens pour chaque objet virtuel d'élaborer une requête de consultation (21) du statut de l'application fonctionnelle réalisée par l'équipement (6) associé à l'objet et du statut de l'équipement de sorte à modifier le statut de l'objet en fonction des informations reçues, - des moyens de détection d'alertes (3) pour élaborer des requêtes de consultation (31) du statut de chacun des objets du modèle virtuel (2) et de réception (22) des informations du statut de la configuration topologie et fonctionnelle des objets virtuels en réponse aux requêtes de consultation de sorte à détecter des anomalies de configuration de la topologie du réseau d'équipements et de la chaîne d'applications fonctionnelles du modèle virtuel et à transmettre les alertes (32) associées aux anomalies. 2. Dispositif selon la revendication 1, caractérisé en ce qu'une requête 25 de consultation (31) de statut d'un objet est de format unique pour l'ensemble des objets du modèle (2). 3. Dispositif selon la revendication 1, caractérisé en ce qu'un objet virtuel (2) comporte une pluralité d'informations représentant le statut de l'équipement (6) associé à l'objet et le statut de l'application fonctionnelle 30 réalisée par l'équipement (6). 4. Dispositif selon la revendication 1, caractérisé en ce que les requêtes de consultation (31) de statut consultent la configuration topologique du modèle virtuel. . Dispositif selon la revendication 1, caractérisé en ce que les requêtes de consultation (31) de statut consultent la configuration de la chaîne d'applications fonctionnelles du modèle virtuel. 6. Dispositif selon l'une quelconque des revendications précédentes, 5 caractérisé en ce qu'il comporte en outre des moyens d'activation et de désactivation des alertes issues des objets du modèle virtuel.