EP4068244A1 - Procédé d'assistance au pilotage d'aéronefs - Google Patents

Procédé d'assistance au pilotage d'aéronefs Download PDF

Info

Publication number
EP4068244A1
EP4068244A1 EP22165059.1A EP22165059A EP4068244A1 EP 4068244 A1 EP4068244 A1 EP 4068244A1 EP 22165059 A EP22165059 A EP 22165059A EP 4068244 A1 EP4068244 A1 EP 4068244A1
Authority
EP
European Patent Office
Prior art keywords
aircraft
mission
resolution
module
capability
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22165059.1A
Other languages
German (de)
English (en)
Inventor
Laurent Flotte
Sylvain Yan
Amandine Audouy
Valentin DUPONT
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Thales SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thales SA filed Critical Thales SA
Publication of EP4068244A1 publication Critical patent/EP4068244A1/fr
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
    • G08G5/0004—Transmission of traffic-related information to or from an aircraft
    • G08G5/0013—Transmission of traffic-related information to or from an aircraft with a ground station
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
    • G08G5/003—Flight plan management
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
    • G08G5/0017—Arrangements for implementing traffic-related aircraft activities, e.g. arrangements for generating, displaying, acquiring or managing traffic information
    • G08G5/0021—Arrangements for implementing traffic-related aircraft activities, e.g. arrangements for generating, displaying, acquiring or managing traffic information located in the aircraft
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
    • G08G5/003—Flight plan management
    • G08G5/0039—Modification of a flight plan
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
    • G08G5/0047—Navigation or guidance aids for a single aircraft
    • G08G5/0052—Navigation or guidance aids for a single aircraft for cruising
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
    • G08G5/0073—Surveillance aids
    • G08G5/0078—Surveillance aids for monitoring traffic from the aircraft
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
    • G08G5/0073—Surveillance aids
    • G08G5/0086—Surveillance aids for monitoring terrain
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
    • G08G5/0073—Surveillance aids
    • G08G5/0091—Surveillance aids for monitoring atmospheric conditions

Definitions

  • the invention is in the technical field of aircraft mission management, and relates more particularly to an aircraft piloting assistance device.
  • FWS Alert or "Flight Warning System”
  • FMS Management or “Flight Management System”
  • Surveillance type systems systems of the Alert or "Flight Warning System” (FWS) type, systems of the Management or “Flight Management System” (FMS) type, and Surveillance type systems.
  • FWS Alert or "Flight Warning System”
  • FMS Management or “Flight Management System”
  • Alert type systems are currently implemented on all types of aircraft. Their usefulness is twofold: to alert the pilot when an abnormal situation arises, and if necessary to present the procedures for dealing with the failure to return to a situation under control, guaranteeing the safety of the flight and the return to the ground of the aircraft. .
  • the FWS also offers a list of inoperative systems (“INOP SYS”) as well as actions, to be processed later, to cover the repercussions of the failure on the rest of the mission (“DEFFERRED PROCEDURE / LIMITATIONS”) ).
  • IOP SYS inoperative systems
  • actions to be processed later, to cover the repercussions of the failure on the rest of the mission
  • LIMITATIONS inoperative systems
  • the systems are increasingly interconnected, and the number of failures which can be generated by the system can turn out to be relatively high. In this case, it is the pilot who must manage and interpret the accumulation of information and limitations which may be applicable to his situation.
  • the information to be presented to the crew is determined statically by an analysis which is made during the design of the system and of the device. This analysis is made by considering all of the missions of the aircraft including the worst case, which is not necessarily the case of the mission in progress.
  • FMS flight management systems
  • Guidance devices that aim to calculate a route to perform the guidance of the device. These devices guide the aircraft, possibly while checking the active trajectory and triggering an alert to the crew or a reconfiguration when the situation deteriorates. This type of device only covers the current flight plan which is calculated by the device and not alternative flight plans.
  • TCAS traffic alert and collision avoidance systems
  • TAWS terrain and obstacles
  • ISS weather radar systems
  • the pilot must content himself with analyzing a subset of data that seems relevant to him, because he has neither the time nor the capacity to reconsider the context as a whole, the information being too numerous. Also, the pilot is generally content to consider that the only changes vis-à-vis the initial situation are those that triggered the analysis. However, this is not necessarily the case. For example, the weather at one of the possible diversion airports may have changed between the preparation of the flight and its execution, and then render the diversion solution at this airport inoperative.
  • the pilot can rely on the airplane type documentation (QRH) ("Quick Reference Handbook"), either in paper form or digitized through an (EFB) ("Electronic Flight Bag”), in order to seek the main elements and information to be taken into account and cross-checked to analyze the situation.
  • QRH airplane type documentation
  • EFB Electronic Flight Bag
  • the known assistance systems aim to provide aids to the pilot to enable him to analyze the impact of a change of context on a mission in progress.
  • the known assistance solutions are rather based on the definition of a score which allows the pilot to see the status of various possible diversion airports, but they do not describe how to carry out the solution.
  • Open mode systems cover hardware that can accommodate software that is not certified but submitted to “OPS-Approval” by the operator.
  • the open world has the advantage of having fewer development constraints, with shorter development and deployment processes and finally a possible connection to “cloud” type servers that can share data via Internet networks.
  • the "Avionics” is in the "CLOSED” category, and in opposition the "Open World” is not in the "CLOSED” category.
  • Avionics systems primarily deal with the tactical and safety aspects of a change of context, i.e. oriented towards an immediate reaction that the pilot must have, and they do not analyze the medium/long term consequences. . Even if these systems were to evolve in order to integrate suggestion capacities, they would soon find themselves limited in terms of computing power and also in terms of capacities for collecting new data, in particular because their development and evolution cycles are long cycles, due in particular to certification constraints.
  • Open world systems (therefore not certified) are not connected to avionics. They therefore have a fragmented view of a current situation because they do not continuously integrate the state of the aircraft and the evolution of the planned mission.
  • the current systems do not take into account either all of the data originating from the aircraft, or various services originating from the open world.
  • the information that the pilot retrieves is then fragmented and does not allow him to make a decision with an overall view of the flight context and the environmental context.
  • Such systems and methods must make it possible to correlate all of the information that is available and make it possible to provide a pilot or a crew with the best options in order to enable him/them to make a decision.
  • An object of the present invention is a device for assistance to a crew or "Pilot assistant" which comprises means making it possible to analyze then to reliably correlate all relevant information concerning a device, as well as its environment, in order to determine whether an adaptation of a current situation must be carried out and, if necessary, to propose solutions which appear most relevant for this adjustment.
  • Another object of the invention is a piloting assistance method which comprises steps making it possible to recover context data from different sources (i.e. aircraft avionics, ground data, open world data); to build a coherent overall context; to identify gaps between this context and the initial context of the mission as planned; and to resolve these discrepancies by proposing different alternatives, in order to allow the pilot to choose among the alternatives proposed or to study others.
  • sources i.e. aircraft avionics, ground data, open world data
  • the device of the invention is able to adapt to any avionics, without the principles and concepts described and used in the suggestion mechanisms being affected.
  • the figure 1 illustrates an example of architecture of a piloting assistance system according to the invention.
  • the aircraft piloting assistance device (100) of the invention generally comprises at least one skills module (102), a management module (104), a processing module (106) and a resolution module (108).
  • the management module (104) is configured to manage contentions and flow priorities transiting between different modules and to direct the exchanges between the different modules of the device.
  • the piloting assistance device of the invention further comprises an HMI man-machine interface (110) configured to manage the various human-machine interactions in the context of the use of the piloting assistance device of the invention .
  • the HMI is configured (i.e. comprises different interfaces adapted to the type of interaction) to allow one or more operators to interact with different modules of the assistance device or "Assistant", and with different services and/or components of the avionics and/or the open world, on board and/or on the ground.
  • the skills module (102) comprises at least one “Management of avionic systems” capability, one “Mission management” capability, and one “Environment management” capability.
  • the architecture of the “Management of avionic systems” capability relies on several functional components which are a “System Management Driver”, a “System Management Service” and a “System Management Skill”.
  • the “System Management Driver” is configured to perform the role/function of abstracting the utility architecture from the systems in order to “trivialize” the link between an inoperative system and the resulting limitations.
  • FCOM Fluor Crew Operating Manual
  • the architecture of the systems differing from one carrier to another, the limitations can be triggered by different root causes (for example a single or double failure).
  • the components of the systems rarely have the same names from one wearer to another.
  • the “System Management Driver” module makes it possible to avoid this problem by absorbing the associated variability. To do this, each inoperative system is associated with a failure family and an unmarked limitation family, per configuration file.
  • the “commoditization” component thus makes it possible to acquire all the useful data while freeing itself from the constraints inherent to the carrier (name of the data, source selection logic). This is the case, for example, for data such as aircraft weight, heading, radio frequencies, fuel flow, etc.
  • the architecture of the “Mission Management” capability relies on several functional components which are an “FMS Driver”, a “Leg Services”, a “Mission Skill”.
  • the device of the invention allows, via a capability register (208) coupled to a capability database (210), adding and/or removing application components to the skill module (102).
  • a capability register (208) coupled to a capability database (210)
  • Each component once registered according to its field of competence, can organize the calls to the various respective services and systems (avionics; non-avionics; ground) making it possible to carry out the functions of event calculation (204) and request processing (206 ).
  • the skill domain of a capability is declared in the capabilities register (208) and recorded in the capabilities database (210) in order to indicate the functional domain of the application component, the nature of the data relating to this functional domain , the type/format of data the capability will need to perform the event computation (204) and request processing (206) functions, and the type/format of data the capability will produce.
  • the “event calculation” function (204) of an application component is responsible for consolidating the information received before sending and soliciting an event from the Assistant. It is configured to prevent mass solicitations and ensure more relevant notifications are sent. Indeed, it must be ensured that the context leading to the notification corresponds to a stable state. For example, an engine failure will cause the loss of several systems. This loss is not simultaneous. It is therefore necessary to wait until the situation is stable before notifying. The risk if this is not done is to trigger irrelevant calculations and suggestions towards the pilot because only taking into account part of the situation which is not stabilized.
  • the event calculation function essentially consists in calculating the operational limitations of the aircraft.
  • the event calculation function essentially consists of generating mission data.
  • the event calculation function essentially consists of calculating meteorological events.
  • the "Process requests" function (206) of an application component consists in receiving, via the management module (104), resolution requests sent by the resolution module (108), then in processing these requests by requesting the services and appropriate systems to retrieve data, and return a response to the resolution module via the management module.
  • the request processing function essentially consists of checking the status of the systems and performing a "what if” simulation (for example, what would be the impacts on the aircraft if such an avionic system were in failure?: "I lost system 1, I have an alternate route suggestion that relies on using system 2, what happens if I lose system 2? If I have another alternative more robust in case of loss of system 2, it is perhaps better to favor this one”).
  • the request processing function essentially consists of checking the compliance of the mission, calculating a mission update and promoting the flight plan, i.e. providing the flight plan to avionics systems (notably FMS) for acceptance.
  • Verification of mission compliance essentially consists of verifying that all the minimum information necessary for the conduct of a mission (eg type of aircraft, departure and arrival airport, weight and fuel data, etc.) are available and that the mission is feasible from the point of view of the environment and the state of the aircraft, i.e. the aircraft will not land at an airport with high winds on arrival if the aircraft is not I'm not able to, nor go to divert on an airport which one cannot reach for lack of sufficient fuel or because of an altitude too high taking into account the performances.
  • a mission eg type of aircraft, departure and arrival airport, weight and fuel data, etc.
  • the request processing function essentially consists of checking the conformity of the weather forecast, i.e. checking that the weather forecast is compatible with the mission (the mission can be carried out under the weather conditions forecast on its route , on airports).
  • the device of the invention comprises a processing module (106).
  • the processing module is configured on the one hand to determine what are the possible impacts on the mission in progress from the events which are calculated by the application components (illustrated in picture 3 ), and on the other hand to perform solution relevance checks that are generated by the application components to adapt the current mission (shown in figure 4 ).
  • the picture 3 illustrates the configuration of the components of the processing module (106) implemented during the processing of an event, to determine whether or not the event has an impact on the mission.
  • the processing module receives as input the data routed by the management module (104).
  • the management module transmits the information calculated or transmitted by the various skills modules, either during the calculation of an event (for example the wind values updated in the case of a weather event notification by the " management of the environment”), or when processing a request for resolution (for example the impacts on the aircraft's capacities in the event of a failure).
  • the information supplied to the management module is calculated from data acquired from various sources of certified avionics and/or non-certified avionics, from sources external and/or internal to the aircraft. The data is put into a format usable by open world (non-avionics) systems.
  • the “Systems management” capability calculates an event from information on the state of the aircraft systems which is collected from the avionics part, and in the example chosen, reporting a “system failure”.
  • the processing carried out by the processing module (106) is based on an analysis according to an ontology.
  • the processing carried out by the processing module (106) is based on an analysis according to predefined rules.
  • the impact which is determined consists in the fact that a diversion of the aircraft is required or recommended.
  • the figure 4 illustrates the elements used to determine a suggestion for adapting a mission.
  • the figure 4 illustrates the components of the resolution module (108) and the configuration of the components of the processing module (106) to perform verifications of the relevance of resolution proposals to adapt the current mission.
  • the resolution requests component (402) Based on the impact information on the current mission, for example a required diversion, the resolution requests component (402) generates corresponding requests.
  • the requests are routed to the capacities which must process them via the management module (104), based on the information available in the capacities register (208).
  • requests are established to interrogate at least the "Mission management" capability in order to obtain proposals for diversion to airports able to offer it.
  • the example is simplified but that more or less complex resolution requests can be sent to one or more capacities depending on the nature of the impact that has been calculated.
  • the requests are processed by the respective capabilities from data acquired from different sources of certified avionics or non-certified avionics, from sources external or internal to the aircraft.
  • the impact resolution proposals received are evaluated via the processing module (106).
  • the evaluation of a proposal successively implements the functionalities of the context component (404) by calculating a context resulting from the mission if the solution of the proposal was implemented, from the component of discrepancies (406) between the resulting context and the initial context, and the impact component (408) by determining what the impact on the mission would be if the solution of the proposal were implemented.
  • the processing carried out by the processing module (106) is based on an analysis according to an ontology.
  • the processing carried out by the processing module (106) is based on an analysis according to predefined rules.
  • the resolution request component (402) can generate new requests according to the impact which has been calculated, and receive new solution proposals which are evaluated by the processing module (106).
  • the sorting component (410) is configured to weight the solutions found, according to sorting criteria adapted to the situation and to the problems of the crew.
  • the weighting criteria can be adapted a posteriori in order to stick better and better to the situation over time.
  • this makes it possible to enrich the knowledge of the device in post analysis.
  • the suggestion component (412) is configured to structure the selected suggestions, so as to be able to notify the crew and present them (110) the elements with the associated rationale.
  • a minimum of three suggestions is offered to the crew.
  • the recording of this information makes it possible to enrich the search for a solution which becomes more efficient over time.
  • the device of the invention makes it possible to transfer the elements of this alternative on the avionics side, or even on the ground side, so that it becomes the new mission reference.
  • the device makes it possible to follow the execution of the new reference in order to detect deviations.
  • the device makes it possible to contextualize the use of the various services according to the policies of the airline companies and of the users of the system (pilots).
  • the figure 5a illustrates an example of implementation of the piloting assistance device of the invention where all the modules are integrated on a certified avionics computing platform.
  • the figure 5b illustrates another example of implementation of the piloting assistance device of the invention where all the modules are integrated on a non-certified avionics computing platform.
  • the figure 5c illustrates another example of implementation of the pilot assistance device of the invention where the modules are distributed between certified avionics computing platforms, non-certified avionics computing platforms and computing platforms of ground infrastructure.
  • the processing and resolution components are implemented on a non-certified avionics computing platform.
  • the ground infrastructure platform is connected to the avionics platform by a data link.

Landscapes

  • Engineering & Computer Science (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Traffic Control Systems (AREA)

Abstract

La présente invention propose un dispositif d'assistance au pilotage d'un aéronef comprenant :- un module de compétences comprenant une pluralité de composants applicatifs ou capacités, chaque capacité ayant un domaine de compétence et étant configurée selon un même format logique pour calculer des événements à partir de données acquises de différentes sources de l'avionique certifiée ou de l'avionique non-certifiée et/ou de différentes sources externes ou sources internes à l'aéronef, et pour traiter des requêtes de résolution et générer des propositions de résolution ;- un module de traitement comprenant des composants configurés pour déterminer l'existence d'un impact sur la mission en cours de l'aéronef, soit à partir d'un événement calculé, soit à partir d'une proposition de résolution ;- un module de résolution comprenant des composants configurés pour émettre des requêtes de résolution à partir de l'existence d'un impact, et des composants configurés pour construire une solution d'adaptation de la mission en cours de l'aéronef à partir d'au moins une proposition de résolution; et- un module de gestion comprenant des composants configurés pour gérer des contentions et des priorités de flux, et des composants configurés pour aiguiller les échanges entre les différents modules du dispositif.

Description

    Domaine de l'invention
  • L'invention est dans le domaine technique de la gestion de mission d'aéronefs, et concerne plus particulièrement un dispositif d'assistance au pilotage d'aéronefs.
    • Etat de la Technique
  • Dans les aéronefs de complexité croissante, la gestion stratégique de la mission d'un aéronef, qu'il soit civil ou militaire, implique une charge de travail des pilotes de plus en plus importante, en particulier lorsqu'un évènement survient, qu'il soit interne à l'appareil (tel que par exemple une défaillance d'un système, un problème médical d'un passager) ou externe à celui-ci (tel que par exemple un changement de météo, une dégradation d'une installation), ou alors opérationnel (par exemple une modification de la mission telle que prévue à l'origine).
  • La gestion d'aéronef et de son environnement repose actuellement sur trois types de systèmes avioniques connus : des systèmes de type Alerte ou « Flight Warning System » (FWS), des systèmes de type Gestion ou « Flight Management System » (FMS), et des systèmes de type Surveillance.
  • Les systèmes de type Alerte (FWS) sont actuellement implémentés sur tous les types d'aéronefs. Leur utilité est double : alerter le pilote lorsqu'une situation anormale survient, et le cas échéant lui présenter les procédures permettant de traiter la défaillance pour revenir à une situation sous contrôle, garantissant la sécurité du vol et le retour au sol de l'appareil.
  • Sur certains systèmes plus élaborés, le FWS propose également une liste des systèmes inopérants (« INOP SYS ») ainsi que des actions, à traiter ultérieurement, pour couvrir les répercussions de la défaillance sur le reste de la mission (« DEFERRED PROCEDURE / LIMITATIONS »). Dans les aéronefs actuels, les systèmes sont de plus en plus interconnectés, et le nombre de défaillances qui peuvent être générées par le système peut s'avérer relativement important. Dans ce cas, c'est le pilote qui doit gérer et interpréter le cumul des informations et des limitations qui peuvent être applicables à sa situation.
  • Par ailleurs, il faut également noter que dans les systèmes FWS actuels, les informations à présenter à l'équipage sont déterminées de manière statique par une analyse qui est faite lors du design du système et de l'appareil. Cette analyse est faite en considérant l'intégralité des missions de l'aéronef incluant le pire cas, ce qui n'est pas forcément le cas de la mission en cours.
  • Il est également connu plusieurs systèmes de gestion du vol (FMS), comme ci-après.
  • Des dispositifs de type « Route Solver » selon l'anglicisme consacré, qui visent à calculer une route sécurisée vis-à-vis du relief, de la météo. Ce calcul ne prend pas en compte l'état de l'appareil et ses restrictions.
  • Des dispositifs de guidage qui visent à calculer une route pour effectuer le guidage de l'appareil. Ces dispositifs guident l'appareil, éventuellement tout en vérifiant la trajectoire active et en déclenchant une alerte vers l'équipage ou une reconfiguration lorsque la situation se dégrade. Ce type de dispositif ne couvre que le plan de vol en cours qui est calculé par le dispositif et non des plans de vol alternatifs.
  • Des dispositifs de sécurisation de la trajectoire qui visent à sécuriser la trajectoire selon certaines menaces. Là aussi, ces dispositifs ne prennent généralement pas en compte l'état de l'appareil et ses restrictions.
  • Il est aussi connu plusieurs systèmes de type Surveillance, que sont les systèmes d'alerte de trafic et d'évitement de collision (TCAS) pour « Traffic Collision Avoidance System », les systèmes d'avertissement et d'alarme d'impact vis-à-vis du terraine et des obstacles (TAWS) pour « Terrain Awareness and Warning System », les systèmes radar méteo « Weather Radar » ou (ISS) pour « International Space Station ». Ces systèmes ont pour objectif de déclencher des alertes si un aéronef est trop proche d'une situation dangereuse du point de vue respectivement, du trafic, du terrain et de la météo. Ils adressent donc davantage une situation tactique plutôt que stratégique et ils ne permettent pas notamment de traiter une trajectoire/un plan de vol alternatif.
  • Avec les différents systèmes de l'état de l'art, lorsqu'un changement de l'état de l'appareil ou un évènement extérieur survient, le pilote doit analyser les informations fournies et déterminer une stratégie d'adaptation de la mission qui lui parait être la meilleure.
  • La plupart du temps, le pilote doit se contenter d'analyser un sous-ensemble de données qui lui parait pertinent, car il n'a ni le temps, ni la capacité de reconsidérer le contexte dans sa globalité, les informations étant trop nombreuses. Aussi, le pilote se contente généralement de considérer que, les seuls changements vis-à-vis de la situation initiale, sont ceux ayant déclenché l'analyse. Cependant, cela n'est pas forcément le cas. Par exemple, la météo sur un des aéroports de déroutement possible, peut avoir évoluée entre la préparation du vol et son exécution, et alors rendre la solution de déroutement sur cet aéroport inopérante.
  • Enfin, parmi les moyens à sa disposition, outre les systèmes d'alerte ou de surveillance évoqués précédemment, le pilote peut s'appuyer sur la documentation avion de type (QRH) (« Quick Reference Handbook »), soit sous forme papier, soit digitalisée au travers d'un (EFB) (« Electonic Flight Bag »), en vue de chercher les principaux éléments et informations à prendre en compte et à croiser pour faire son analyse de la situation.
  • Ainsi, les systèmes d'assistance connus visent à apporter des aides au pilote pour lui permette une analyse de l'impact d'un changement de contexte sur une mission en cours.
  • Les approches connues sont en priorité focalisées sur la présentation d'informations à l'équipage. Les brevets, U.S. 10, 096, 253 intitulé "Methods and systems for presenting diversion destinations" et U.S. 10,109, 203 intitulé "Methods and systems for presenting en route diversion destinations", proposent de telles approches. Cependant, elles ne fournissent pas de propositions qui soient basées sur des multicritères.
  • De plus, les solutions d'assistance connues sont plutôt basées sur la définition d'un score qui permet au pilote de voir le statut de différents aéroports de déroutement possible, mais elles ne décrivent pas comment réaliser la solution.
  • Enfin, les systèmes existants sont soit des systèmes purement avioniques soumis aux contraintes de certification sur le matériel et le logiciel, soit des systèmes dits du « monde ouvert », encore appelés systèmes non-avioniques, c'est-à-dire des systèmes non certifiés (non soumis aux mêmes contraintes de certification que les systèmes certifiés). Les systèmes du mode ouvert couvrent du matériel pouvant accueillir du logiciel non certifié mais soumis à l' « OPS-Approval » par l'opérateur. Le monde ouvert a pour bénéfice d'avoir moins de contraintes de développement, avec des processus de développement et de déploiement plus courts et enfin une possible connexion à des serveurs de type « cloud » pouvant partager des données via les réseaux internet. Dit autrement, en se référant au standard Arinc 811, l'« Avionique » se trouve dans la catégorie « CLOSED », et en opposition le « Monde Ouvert » n'est pas dans la catégorie « CLOSED ».
  • Les systèmes avioniques traitent avant tout des aspects tactiques et de sécurité d'un changement de contexte, c'est-à-dire orientés vers une réaction immédiate que le pilote doit avoir, et ils n'analysent pas les conséquences à moyens/longs termes. Même si ces systèmes évoluaient afin d'intégrer des capacités de suggestions, ils se trouveraient vite limités en termes de puissance de calcul et également en termes de capacités de collecte de nouvelles données, notamment du fait que leurs cycles de développement et d'évolution sont des cycles longs, du fait notamment des contraintes de certification.
  • Les systèmes monde ouvert (donc non certifiés) ne sont pas connectés à l'avionique. Ils ont donc une vision parcellaire d'une situation courante car ils n'intègrent pas de manière continue l'état de l'appareil et l'évolution de la mission prévue.
  • Ainsi, pour permettre à un pilote de prendre une décision, les systèmes actuels ne tiennent pas compte ni de l'ensemble des données provenant de l'aéronef, ni de divers services provenant du monde ouvert. Les informations que le pilote récupère sont alors parcellaires et ne lui permettent pas de prendre une décision avec une vision globale du contexte de vol et du contexte environnemental.
  • Aussi, il existe alors un besoin pour des systèmes et des procédés d'assistance avancés qui permettent d'aider un pilote à analyser l'impact d'un changement de contexte sur la mission en cours de l'aéronef.
  • De tels systèmes et procédés doivent permettre de corréler l'intégralité des informations qui sont disponibles et permettre de fournir à un pilote, à un équipage, les meilleures options afin de lui/leur permettre de prendre une décision.
    • Résumé de l'invention
  • Un objet de la présente invention est un dispositif d'assistance à un équipage ou « Assistant pilote » qui comprend des moyens permettant d'analyser puis de corréler de manière fiable l'intégralité d'informations pertinentes concernant un appareil, ainsi que son environnement, afin de déterminer si une adaptation d'une situation courante doit être réalisée et, le cas échéant, de proposer des solutions qui apparaissent les plus pertinentes pour cette adaptation.
  • Un autre objet de l'invention est un procédé d'assistance au pilotage qui comprend des étapes permettant de récupérer des données de contexte de différentes sources (i.e. avionique de l'appareil, données sol, données monde ouvert) ; de construire un contexte global cohérent ; d'identifier des écarts entre ce contexte et le contexte initial de la mission tel que prévu ; et de résoudre ces écarts en proposant différentes alternatives, afin de permettre au pilote de choisir parmi les alternatives proposées ou d'en étudier d'autres.
  • De manière générale, la solution proposée réalise un « Assistant pour équipage » (un ou plusieurs pilotes), afin :
    • d'aider à prendre en compte des changements de l'environnement impactant une mission ;
    • de réduire le temps passé à mener des activités récurrentes sans grande valeur ajoutée, en préparant et en anticipant certaines tâches ;
    • de réduire les erreurs humaines, par la mise en place de rappels et d'une assistance contextualisée ;
    • d'aider à répondre aux attentes des passagers et des opérateurs.
  • Avantageusement, le dispositif de l'invention est apte à s'adapter à n'importe quelle avionique, sans que les principes et les concepts décrits et utilisés dans les mécanismes de suggestion ne soient affectés.
  • Pour obtenir les résultats recherchés, il est proposé un dispositif d'assistance au pilotage d'un aéronef comprenant :
    • un module de compétences comprenant une pluralité de composants applicatifs ou capacités, chaque capacité ayant un domaine de compétence et étant configurée selon un même format logique pour calculer des évènements à partir de données acquises de différentes sources de l'avionique certifiée ou de l'avionique non-certifiée et/ou de différentes sources externes ou sources internes à l'aéronef, et pour traiter des requêtes de résolution et générer des propositions de résolution ;
    • un module de traitement comprenant des composants configurés pour déterminer l'existence d'un impact sur la mission en cours de l'aéronef, soit à partir d'un évènement calculé, soit à partir d'une proposition de résolution ;
    • un module de résolution comprenant des composants configurés pour émettre des requêtes de résolution à partir de l'existence d'un impact, et des composants configurés pour construire une solution d'adaptation de la mission en cours de l'aéronef à partir d'au moins une proposition de résolution;
      et
    • un module de gestion comprenant des composants configurés pour gérer des contentions et des priorités de flux, et des composants configurés pour aiguiller les échanges entre les différents modules du dispositif.
  • Selon des modes de réalisation alternatifs ou combinés :
    • Le dispositif comprend de plus un registre de capacités et une base de données de capacités pour enregistrer et stocker le domaine de compétence de chaque capacité.
    • Le module de traitement comprend :
      • un composant de contexte configuré pour soit calculer un contexte courant de la mission en cours pour un évènement qui est analysé, soit calculer un contexte résultant de la mission en cours pour une proposition de résolution qui est analysée ;
      • un composant d'écarts configuré pour identifier tout écart entre le contexte initial de la mission de l'aéronef et, le contexte courant ou le contexte résultant ; et
      • un composant d'impact configuré pour déterminer en fonction du ou des écarts identifiés, un impact sur la mission en cours, de l'évènement analysé ou de la proposition de résolution analysée.
    • Les composants du module de traitement sont configurés pour effectuer une analyse selon une ontologie.
    • Les composants du module de traitement sont configurés pour effectuer une analyse selon des règles prédéfinies.
    • Le module de résolution comprend de plus un module de tri pour évaluer et sélectionner des propositions de résolution.
    • Le module de tri est configuré pour évaluer et sélectionner des propositions de résolution selon des critères de pondération.
    • Le module de compétences comprend au moins une capacité dont le domaine de compétence est celui de la gestion des systèmes avioniques, une capacité dont le domaine de compétence est celui de la gestion de la mission de l'aéronef, et une capacité dont le domaine de compétence est celui de la gestion de l'environnement.
    • Le dispositif comprend de plus une interface homme-machine configurée pour gérer les interactions d'un ou plusieurs opérateurs avec les différents modules du dispositif.
  • L'invention couvre de plus :
    • une plateforme de calcul de l'avionique certifiée, comprenant un dispositif d'assistance au pilotage d'aéronef selon l'invention.
    • une plateforme de calcul de l'avionique non certifiée, comprenant un dispositif d' assistance au pilotage d'aéronef selon l'invention.
    • une plateforme de calcul comprenant un dispositif d'assistance au pilotage d'aéronef selon l'invention, dans laquelle les modules du dispositif d'assistance au pilotage d'aéronef sont répartis entre l'avionique certifiée, l'avionique non certifiée et une infrastructure sol connectée à l'avionique par une liaison de donnée.
    Description des figures
  • D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit et des figures des dessins annexés dans lesquels :
    • La [FIG. 1] est une illustration simplifiée de l'architecture du dispositif d'assistance au pilotage selon l'invention ;
    • La [FIG. 2] illustre la structure des composants applicatifs du module de compétence du dispositif d'assistance au pilotage de l'invention ;
    • La [FIG. 3] illustre les éléments du dispositif d'assistance au pilotage de l'invention mis en oeuvre pour déterminer l'existence d'un impact sur la mission d'un aéronef ;
    • La [FIG. 4] illustre les éléments du dispositif d'assistance au pilotage de l'invention mis en oeuvre pour déterminer et générer une suggestion d'adaptation de la mission d'un aéronef;
    • Les [FIG. 5a], [FIG. 5b], [FIG. 5c] illustrent des variantes d'implémentation du dispositif d'assistance au pilotage de l'invention.
    Description détaillée de l'invention
  • La figure 1 illustre un exemple d'architecture d'un système d'assistance au pilotage selon l'invention. Le dispositif (100) d'assistance au pilotage d'un aéronef de l'invention comprend généralement au moins un module de compétences (102), un module de gestion (104), un module de traitement (106) et un module de résolution (108).
  • Le module de gestion (104) est configuré pour gérer des contentions et des priorités de flux transitant entre différents modules et pour aiguiller les échanges entre les différents modules du dispositif.
  • Le dispositif d'assistance au pilotage de l'invention comprend de plus une interface homme-machine IHM (110) configurée pour gérer les différentes interactions homme-machine dans le cadre de l'utilisation du dispositif d'assistance au pilotage de l'invention.
  • L'IHM est configurée (i.e. comporte différentes interfaces adaptées au type d'interaction) pour permettre à un ou plusieurs opérateurs d'interagir avec différents modules du dispositif d'assistance ou « Assistant », et avec différents services et/ou composants de l'avionique et/ou du monde ouvert, à bord et/ou au sol.
  • Les interactions et informations échangées se font via différentes configurations d'interface que sont, a minima :
    • une interface configurée « Opérateur (pilote) / Assistant » pour solliciter l'Assistant de différentes manières (multimodalité): langage naturel, tactile, « Eyes tracking », son/alarme sonore, microgesture, mais également au travers de sollicitations informatiques (notifications).
    • une interface configurée « MRO » (« Maintenance Repair & Overhaul ») pour interagir avec un service de maintenance, réparation et révision :
      • Dans le sens MRO → Assistant :
        • Echange des capacités de maintenance par aéroport.
        • « Spare » disponibles par centres.
      • Dans le sens Assistant → MRO :
        • Envoi des pannes détectées.
    • une interface configurée « ATC » (« Air Traffic Control ») pour interagir avec le contrôle du trafic aérien :
      • Dans le sens ATC → Assistant, envoi de :
        • « D-NOTAM » de l'anglais « Digital Notice To AirMen » ou format numérique de l'information qui est un message publié par les agences gouvernementales de contrôle de la navigation aérienne dans le but d'informer les pilotes d'événements (évolutions, fermetures, pannes, travaux, zone interdite, ...) sur les infrastructures. Lors de la préparation d'un vol, le pilote doit les consulter pour assurer la sécurité de sa mission.
        • Consignes ATC.
        • « D-ATIS » de l'anglais « Digital Automatic Terminal Information Service » qui est un service automatique de diffusion permettant aux pilotes de recevoir en continu (nouvel enregistrement généralement toutes les demies heures) des informations sur les aéroports les plus fréquentés. Ces messages peuvent notamment contenir les données Météo, les pistes en service, l'approche disponible, ...
      • Dans le sens Assistant → ATC, envoi de :
        • Signalement de situations météo dangereuses (« windshear » ou vent cisaillant, turbulences, conditions givrantes).
    • une interface configurée « Environnement » pour interagir avec des services de météorologie aptes à fournir des données environnementales :
      • Dans le sens Sol → Assistant, envoi de :
        • Météo (« wind », « windshear », temperature, convections, « icing », « ASHTAM » qui est un NOTAM spécial permettant de décrire le statut de l'activité d'un volcan quand celui-ci est de nature à impacter le déroulement/la sécurité des vols, « SNOWTAM » qui est un NOTAM spécial relatif aux conditions d'enneigement des pistes d'un aérodrome, ...).
        • « Weather uplink » (enroute), qui est un message transmis via le Datalink (liaison sol/bord) contenant les informations météo (vents, températures) sur les points de la trajectoire planifiée.
        • « METAR » pour « METeorogical Aerodrome Report » qui est un rapport sur les conditions météorologiques telles qu'observées au sol sur un aérodrome, « TAF » pour « Terminal Aerodrome Forecast » qui est une prévision météorologique valide pour 6 à 30h pour un aérodrome, utilisant un encodage similaire au format METAR, sur les aéroports.
        • Conditions météo sur l'aéroport d'arrivée et les aéroports de déroutement possibles.
        • Etats des pistes d'atterrissage prévues et possibles (niveau de contamination, présence de pluie, neige...).
        • Trafic autour de l'appareil (air + sol).
    • une interface configurée « Mission » pour interagir avec des systèmes aptes à fournir des données relatives à la mission de l'aéronef :
      • Dans le sens Avionique → Assistant, envoi de :
        • Plan de vol actif
        • Capacités opérationnelles requises pour la réalisation de la mission (type de décollage, type d'approche...).
        • Temps de vol restant.
        • Fuel à bord
        • Poids
        • Modifications du plan de vol depuis l'avionique
        • Position avion courante
      • Dans le sens Assistant → Avionique, envoi de :
        • Plan de vol suggéré par l'Assistant et choisi par le pilote
        • Facteur de surconsommation carburant (« Perf Factor »)
        • Facteur de dégradation de performances (pertes de poussée, trainée aérodynamique, distance de freinage).
    • une interface configurée « Systèmes » pour interagir avec des systèmes aptes à fournir des données relatives à l'état des systèmes de l'aéronef :
      • Dans le sens Avionique → Assistant, envoi de :
        • Liste des systèmes inopérants.
        • Alertes détectées.
        • Actions pilotes sur les procédures « FWS » (« Flight Warning System ».
        • Etats / position de certains systèmes (position des becs et volets, « anti-ice » actif ou non).
      • Dans le sens Application monde ouvert → Assistant, envoi de :
        • Limitations / restrictions identifiées dans le « e-Logbook ».
        • « MEL ».
      • Dans le sens Assistant → Application monde ouvert :
        • Défaillances détectées pour l'e-Logbook.
      • Dans le sens Assistant → Avionique :
        • Restriction du domaine de vol (vitesse, altitude)
        • Actions sur les commandes et timing associé (activation dégivrage...).
  • Les données requises par le dispositif de l'invention sont :
    • Base de données aéroportuaire (position des aéroports, caractéristiques des pistes, procédures de décollage et d'atterrissage, classification en termes de difficulté (liée au terrain, au trafic)).
    • Base de données contenant les altitudes de sécurité.
    • Infrastructures associées à l'aéroport (hôtel, centre de réparation, moyens de transport)
    • Carte géopolitique et contraintes associées (visa).
    • Base de données contenant les associations systèmes inopérant <-> limitations opérationnelles.
    • Base de données performances à l'atterrissage / au décollage.
    • Base de données consommation.
  • Les données échangées avec le sol pour les besoins du dispositif de l'invention sont :
    • Suggestions réalisées
    • Choix des pilotes
    • Contextes associés
    • Requêtes pilotes
    • Modifications pilotes réalisées sur les suggestions
    • Ecart entre suggestions et vol réalisé / données de vol
    • Données algorithmiques internes (par exemple, suggestions réalisées sur une version N+1 de l'Assistant « mode ghost »).
  • Le module de compétences (102) comprend une pluralité 'n' de composants applicatifs aussi désignés comme capacités (capacité1, ... capacitéi, ..., capacitén). Chaque capacité est configurée selon un même format logique pour opérer au moins trois types de fonctions, illustrées sur la figure 2, à savoir :
    • déclarer un domaine de compétence (202) ;
    • calculer des évènements (204) ;
    • traiter des requêtes de résolution et générer des propositions de résolution (206).
  • Le module de compétences (102) comprend au moins une capacité « Gestion des systèmes avioniques, une capacité « Gestion de la mission », et une capacité « Gestion de l'environnement ».
  • La capacité « Gestion des systèmes avioniques » a pour fonction générale de connaitre le statut de l'aéronef, et ainsi :
    • de collecter l'état des systèmes avions depuis la partie avionique.
    • de déterminer les limitations opérationnelles en fonction de l'état (réel ou soumis par le pilote après une simulation « what if ») des systèmes avioniques. Un test « what-if » est une simulation de ce qui arriverait si un évènement se produisait.
    • de vérifier la compatibilité entre un changement de situation (par exemple : une modification de plan de vol requis par le pilote / induit par un changement de contexte environnemental) et l'état (réel ou soumis par le pilote) de la machine.
    • de transmettre des consignes/des objectifs sur les systèmes de l'appareil (changement d'état d'un système, action sur le système).
    • de monitorer la bonne exécution de la consigne/la réalisation des objectifs.
  • Dans un mode d'implémentation, l'architecture de la capacité « Gestion des systèmes avioniques » s'appuie sur plusieurs composants fonctionnels que sont un « System Management Driver », un « System Management Service » et un « System Management Skill ».
  • Le « System Management Driver » est configuré pour exercer le rôle / la fonction d'abstraire l'architecture des utilitaires des systèmes afin de « banaliser » le lien entre un système inopérant et les limitations qui en résultent. En effet, des analyses de FCOM « Flight Crew Operating Manual » menées sur différents porteurs montrent que les limitations opérationnelles sont peu ou prou du même type quel que soit le porteur. Néanmoins, l'architecture des systèmes différant d'un porteur à l'autre, les limitations peuvent être déclenchées par des causes racines différentes (par exemple une panne simple ou double). Par ailleurs, les composants des systèmes ont rarement les mêmes appellations d'un porteur à l'autre. Aussi avantageusement, le module « System Management Driver » permet de s'abstraire de cette problématique en absorbant la variabilité associée. Pour ce faire, chaque système inopérant est associé à une famille de panne et une famille de limitation banalisée, par fichier de configuration.
  • Un exemple non limitatif est donné pour la famille de panne moteur « Famille = Engine », pour laquelle il peut être associé une cause racine « Faute = Engine 1 System » et une limitation résultante « Delay Take Off », où les paramètres ne sont plus associés à un aéronef spécifique, et deviennent des paramètres génériques.
  • Le composant de « banalisation » permet ainsi d'acquérir toutes les données utiles tout en s'affranchissant des contraintes inhérentes au porteur (nom des données, logiques de sélection de source). C'est le cas par exemple pour des données comme la masse avion, le cap, les fréquences radio, le fuel flow...
  • Le « System management Service » est configuré pour exercer plusieurs rôles/fonctions, qui sont :
    • de stocker l'état des différents systèmes et données reçus de l'avionique ainsi que différentes autres données. Cet état peut être soit reçu directement d'un FWS (i.e. une liste des systèmes inopérants), soit déduit des actions pilotes sur les procédures (i.e. un système peut par exemple fonctionner correctement mais être coupé pour réduire la consommation électrique, ce qui peut engendrer des limitations). Ce stockage est rendu nécessaire par le fait que les informations reçues peuvent refléter non pas l'état de l'appareil mais les modifications qui lui sont apportées et évoluer dans le temps (par exemple, le fuel à bord qui peut être utilisé en plus de l'information de défaillance pour évaluer l'ampleur/l'évolution d'une fuite carburant. En situation normale, ces informations permettent par exemple de savoir que le pilote a sélectionné une commande particulière qui n'est pas directement retrouvée dans les données d'état de systèmes (un dégivrage activé par exemple)).
    • de consolider et calculer l'impact des limitations. A partir de la liste des systèmes inopérants, il établit une liste de limitations (par ex, si deux systèmes en panne génèrent une limitation sur la même capacité - longueur de piste par ex - il produit un résultat global). Pour ce faire, ce composant embarque une mécanique de calcul de logiques/valeurs configurable permettant de définir le traitement à apporter sur des limitations de même nature. Une solution possible est celle fournie par le composant « Détection » du FWS. Suivant les cas, par exemple, les limitations en vitesse peuvent se cumuler ou bien il peut être nécessaire de juste prendre la plus pénalisante.
  • Ainsi, sont par exemple identifiés les services suivants (liste non exhaustive) :
    • Facteur de surconsommation. Ce facteur permet de dire en fonction de la panne détectée de combien l'appareil va surconsommer par rapport à la normale.
    • Longueur de piste nécessaire: Cette information permet de déterminer la longueur nécessaire pour l'appareil pour se poser en fonction de son état, de sa masse et des conditions météo.
    • Minimas d'approche: Cette information permet de dire, en fonction de l'état de l'appareil, quel minima est atteignable.
    • Réduction de l'enveloppe de vol: Cette information permet d'identifier si, en fonction de son état, l'appareil est limité en altitude, vitesse, roulis et configuration de décollage/atterrissage.
  • Le « System management Skill » a pour rôles / fonctions :
    • de consolider l'état de l'appareil : A partir des informations produites par le « System Management Service », et une fois qu'il a déterminé que l'appareil est dans un état stabilisé, il génère une notification pour informer des modifications réalisées/subies par l'appareil.
    • de vérifier à partir des informations sur l'état des systèmes, si une modification de contexte est compatible du point de vue de l'état de l'appareil (« Check System State Compliance »), comme par exemple une modification du plan de vol pour passer d'un atterrissage CAT3a à une procédure LPV : est-ce que l'appareil peut faire du LPV ? Ce mécanisme est nécessaire pour s'assurer de prendre en compte de manière rétroactive des limitations n'ayant pas eu d'impact ou ayant eu un impact différent lorsqu'elles sont survenues. Par exemple, la perte de la capacité LPV est sans impact si cette capacité n'est pas prévue dans la mission initiale mais rend une modification de plan de vol impossible si celle-ci est requise dans la modification prévue.
    • d'interroger la capacité pour évaluer l'impact d'une dégradation fictive soumise par le pilote de l'état de la machine ( « Simulate What If »).
  • Le composant « Gestion de l'environnement » a pour fonction de :
    • de collecter, capturer, consolider et mémoriser la situation environnementale, les données environnementales via la connectivité sol/bord :
      • venant de l'ATC : D-NOTAM (états des moyens de guidage et de communication, Restrictions de vol), Consignes ATC, D-ATIS (états des pistes, airport services), traffic autour de l'appareil ;
      • venant des services météo : Meteo (wind, windshear, temperature, convections, icing, ASHTAM, SNOWTAM...), météo « enroute », METAR, TAF et états des pistes sur les aéroports de destination et de déroutement possible.
    • de vérifier la compatibilité entre un changement de situation (par exemple : une modification de plan de vol requis par le pilote / induit par un changement de l'état de la machine) et le contexte environnemental (vent cisaillant, NOTAMS, etc.)
  • La capacité « Gestion de la mission » est en lien avec les applications fournissant les données météo relatives au vol et ainsi a pour fonction :
    • de collecter les données mission depuis la partie avionique.
    • de vérifier la compatibilité entre un changement de situation (ex : modification de plan de vol requis par le pilote/induit par un changement de contexte environnemental ou bien appareil) et les caractéristiques de la mission (destination, quantité de carburant, profil de vol).
    • de déterminer des modifications de la mission susceptibles d'être compatibles avec l'environnement et l'état de l'appareil (réels ou soumis par le pilote : « what if »).
    • de transférer les modifications de mission sélectionnées par l'équipage à la partie avionique.
  • Dans un mode d'implémentation, l'architecture de la capacité « Gestion de la mission » s'appuie sur plusieurs composants fonctionnels que sont un « FMS Driver », un « Leg Services », un « Mission Skill ».
  • Le « FMS Driver » a pour rôle d'abstraire le système de gestion de mission (par exemple un FMS) de l'appareil, et il permet :
    • de récupérer des informations sur la mission en cours comme par exemple le plan de vol de la mission en cours, le type d'approche ainsi que la quantité de carburant à bord de l'appareil.
    • de transférer des modifications de plan de vol issues des suggestions proposées. Pour ce faire, il convertit les requêtes de résolution reçues au format protocolaire attendu par le FMS présent à bord.
  • Le « Leg Services » a pour rôle :
    • de stocker le plan de vol courant et de diffuser l'information. Par ce biais, il permet aux différentes capacités et services d'accéder aux données du plan de vol en gérant les accès concurrents aux informations.
    • de promouvoir et transmettre vers l'avionique des modifications de mission issues des suggestions. Pour ce faire, le composant s'interface avec le « FMS Driver ».
  • Le « Mission Skill » a pour rôle :
    • de produire une notification une fois que l'état de la mission est stabilisé. de s'assurer de la conformité de la mission (« Check Mission Compliance ») à un changement de contexte lié à l'environnement (par exemple un détour pour éviter une situation météo dégradée) ou à l'état de la machine (par exemple une surconsommation). Pour s'assurer de la conformité, une simple comparaison est réalisée entre ce qui est prévu et le contexte courant augmenté d'une marge. Aussi, l'accès aux données suivantes de la mission est nécessaire:
      • Temps de vol restant (cas de fuite carburant, dépressurisation par ex).
      • Quantité de carburant, quantité prévue à l'arrivée (fuite de carburant)
      • Catégorie de décollage et d'approche prévue (ILS, GLS, LPV, RNP AR...)
      • Piste prévue et Longueur associée.
      • Altitude de croisière (limitation du domaine de vol)
      • Vitesse horizontale et verticale max (limitation du domaine de vol).
    • d'évaluer et de proposer une solution en cas d'évolution du contexte (« Compute Mission Update »). Les éléments non sécurisés (infrastructures sol par exemple) sont utilisés comme critères de tri entre différentes suggestions. Les services suivant sont identifiés comme nécessaires :
      • Ajout d'un délai additionnel: permet d'évaluer la faisabilité (arrivée dans les délais, risque météo) et le coût induit (surconsommation) par un retard.
      • Définition d'un aéroport de diversion en fonction de :
        • Durée de vol maximale (cas de fuite carburant, dépressurisation par ex).
        • De la quantité de carburant (fuite)
        • Des catégories d'approche disponibles (limitation empêchant de réaliser une approche ILS, GLS, LPV, RNP AR...)
        • De la distance d'atterrissage requise (limitations sur le système de freinage).
      • Définition d'un évitement latéral en fonction de :
        • La météo
        • Le fuel à bord
        • L'heure d'arrivée visée
        • Définition d'une modification de plan de vol (vertical ou horizontal) en fonction des restrictions du domaine de vol (vitesse, altitude).
  • Selon des variantes de réalisation, le module de compétences peut comprendre d'autres capacités, comme par exemple, de manière non limitative :
    • une capacité « ATC » en charge (i.e. son domaine de compétence, sa fonction) de décoder des messages « datalink ATC » ;
    • une capacité multimodalité traduisant des consignes ATC - voix ;
    • une capacité dont le domaine de compétence (sa fonction) est de récupérer des informations de maintenance ;
    • une capacité dont le domaine de compétence (sa fonction) est de capturer les sélections pilotes et de les suivre dans le temps en monitorant les paramètres associés.
  • Revenant à la figure 2, avantageusement, le dispositif de l'invention permet, via un registre de capacités (208) couplé à une base de données de capacités (210), l'ajout et/ou le retrait de composants d'applicatifs au module de compétences (102). Chaque composant une fois enregistré selon son domaine de compétence, peut organiser les appels aux différents services et systèmes (avionique ; non-avionique ; sol) respectifs permettant de réaliser les fonctions de calcul d'événement (204) et de traitement de requêtes (206).
  • Le domaine de compétence d'une capacité est déclaré dans le registre de capacités (208) et enregistré dans la base de données de capacités (210) afin d'indiquer le domaine fonctionnel du composant applicatif, la nature des données relative à ce domaine fonctionnel, le type/format de données dont la capacité va avoir besoin pour exercer les fonctions de calcul d'événement (204) et de traitement de requêtes (206), et le type/format de données que la capacité va produire.
  • La fonction « calcul d'évènement » (204) d'un composant applicatif se charge de consolider les informations reçues avant l'envoi et la sollicitation d'événement à l'Assistant. Il est configuré pour empêcher les sollicitations massives et assurer l'envoi de notifications plus pertinentes. En effet, il faut s'assurer que le contexte conduisant à la notification correspond bien à un état stable. Par exemple, une panne moteur va engendrer la perte de plusieurs systèmes. Cette perte n'est pas simultanée. Il faut donc attendre que la situation soit stable avant de notifier. Le risque si ce n'est pas fait est de déclencher des calculs et des suggestions non pertinentes vers le pilote car prenant en compte seulement une partie de la situation qui n'est pas stabilisée.
  • Pour le composant « Gestion des systèmes avioniques », la fonction de calcul d'événement consiste essentiellement à calculer des limitations opérationnelles de l'aéronef.
  • Pour le composant « Gestion de la mission », la fonction de calcul d'événement consiste essentiellement à générer des données de mission.
  • Pour le composant « Gestion de l'environnement », la fonction de calcul d'événement consiste essentiellement à calculer des évènements météorologiques.
  • La fonction « Traiter des requêtes » (206) d'un composant applicatif consiste à recevoir via le module de gestion (104) des requêtes de résolution émises par le module de résolution (108), puis à traiter ces requêtes en sollicitant les services et systèmes appropriés pour récupérer des données, et renvoyer une réponse au module de résolution via le module de gestion.
  • Pour le composant « Gestion des systèmes avioniques », la fonction de traitement de requête consiste essentiellement à vérifier l'état des systèmes et faire une simulation « what if » (par exemple quels seraient les impacts sur l'avion si tel système avionique était en panne ? : « j'ai perdu le système 1, j'ai une suggestion de route alternative qui repose sur l'utilisation du système 2, que ce passe t'il si je perds le système 2 ? Si j'ai une autre alternative plus robuste en cas de perte du système 2, il vaut peut-être mieux privilégier celle-ci »).
  • Pour le composant « Gestion de la mission », la fonction de traitement de requête consiste essentiellement à vérifier la conformité de la mission, à calculer une mise à jour de la mission et à promouvoir le plan de vol, i.e. fournir le plan de vol vers les systèmes avioniques (FMS notamment) pour acceptation.
  • La vérification de la conformité de la mission consiste essentiellement à vérifier que toutes les informations minimales nécessaires au déroulement d'une mission (ex : type d'avion, aéroport de départ et d'arrivée, données de masse et de carburant...) sont disponibles et que la mission est réalisable du point de vue de l'environnement et de l'état de l'appareil, i.e. l'aéronef ne va pas atterrir sur un aéroport avec des vents violents à l'arrivée si l'appareil n'en est pas capable, ni aller se dérouter sur un aéroport qu'on ne peut atteindre faute de fuel suffisant ou en raison d'une altitude trop élevée compte tenu des performances.
  • Pour le composant « Gestion de l'environnement », la fonction de traitement de requête consiste essentiellement à vérifier la conformité de la météo, i.e. vérifier que la météo est compatible avec la mission (la mission est réalisable dans les conditions météo prévues sur son trajet, sur les aéroports).
  • Revenant à la figure 1, comme indiqué le dispositif de l'invention comprend un module de traitement (106). Le module de traitement est configuré d'une part pour déterminer quels sont les éventuels impacts sur la mission en cours à partir des évènements qui sont calculés par les composants applicatifs (illustré en figure 3), et d'autre part pour effectuer des vérifications de pertinence de solutions qui sont générées par les composants applicatifs pour adapter la mission en cours (illustré en figure 4).
  • La figure 3 illustre la configuration des composants du module de traitement (106) mis en oeuvre lors du traitement d'un événement, pour déterminer si l'évènement a un impact ou non sur la mission.
  • Pour des raisons de simplification de la description et de clarté, un exemple est pris pour la description du traitement d'un événement, qui correspond à la défaillance d'un système par la capacité « Gestion des systèmes ». L'homme du métier généralisera les mécanismes décrits à d'autres évènements et à d'autres composants applicatifs. Ainsi, un autre exemple est celui d'un événement calculé par la capacité « Gestion de l'environnement » correspondant à un changement de météo (le traitement de cet évènement engendrant une proposition de contournement de zone).
  • Le module de traitement reçoit en entrée les données routées par le module de gestion (104). Le module de gestion transmet les informations calculées ou émises par les différents modules de compétences, soit lors du calcul d'un évènement (par exemple les valeurs de vents mises à jour dans le cas d'une notification d'événement météo par la capacité « gestion de l'environnement »), soit lors du traitement d'une requête de résolution (par exemple les impacts sur les capacités de l'avion dans le cas d'une défaillance). Les informations fournies au module de gestion sont calculées à partir de données acquises de différentes sources de l'avionique certifiée et/ou de l'avionique non-certifiée, de sources externes et/ou internes à l'aéronef. Les données sont mises dans un format utilisable par les systèmes du monde ouvert (non avionique).
  • Comme illustré sur la figure 3, la capacité « Gestion des systèmes » calcule un évènement à partir d'informations sur l'état des systèmes avions qui sont collectées depuis la partie avionique, et dans l'exemple choisi remontant une « défaillance d'un système ».
  • De manière générale, le module de traitement (106) comprend :
    • un composant de contexte (302) configuré pour calculer un contexte courant global de la mission en cours sur un évènement qui est analysé ;
    • un composant d'écarts (304) configuré pour identifier tout écart / toute différence entre le contexte courant global fourni par le composant de calcul de contexte (302) et le contexte initial de la mission de l'aéronef ; et
    • un composant d'impact (310) configuré pour déterminer quel est l'impact de l'évènement sur la mission, en fonction du/des écarts identifiés par le composant d'identification d'écarts (304).
  • Dans un mode de réalisation, les traitements réalisés par le module de traitement (106) sont basés sur une analyse selon une ontologie.
  • Dans un mode de réalisation, les traitements réalisés par le module de traitement (106) sont basés sur une analyse selon des règles prédéfinies.
  • Dans l'exemple choisi, l'impact qui est déterminé consiste en ce qu'un déroutement de l'aéronef est requis ou recommandé.
  • La figure 4 illustre les éléments mis en oeuvre pour déterminer une suggestion d'adaptation d'une mission. En particulier, la figure 4 illustre les composants du module de résolution (108) et la configuration des composants du module de traitement (106) pour effectuer des vérifications de pertinence de propositions de résolution pour adapter la mission en cours.
  • De manière générale, le module de résolution (108) comprend :
    • un composant de requêtes de résolution (402) configuré pour construire et émettre des requêtes de résolution pour interroger des composants applicatifs selon leur domaine de compétence et en fonction de l'impact qui a été calculé;
    • un composant de tri (410) configuré pour trier des propositions de résolution ; et
    • un composant de suggestion (412) configuré pour construire une solution d'adaptation de la mission en cours de l'aéronef selon l'évaluation des propositions de résolution.
  • A partir des informations d'impact sur la mission en cours, par exemple un déroutement requis, le composant de requêtes de résolution (402) génère des requêtes correspondantes.
  • Les requêtes sont routées vers les capacités devant les traiter via le module de gestion (104), en s'appuyant sur les informations disponibles dans le registre de capacités (208).
  • Ainsi, dans l'exemple choisi, des requêtes sont établies pour interroger au moins la capacité « Gestion de la mission » de manière à obtenir des propositions de déroutement vers les aéroports pouvant le proposer. L'homme du métier comprend que l'exemple est simplifié mais que des requêtes de résolution plus ou moins complexes peuvent être adressées à une ou plusieurs capacités selon la nature de l'impact qui a été calculé.
  • Les requêtes sont traitées par les capacités respectives à partir de données acquises de différentes sources de l'avionique certifiée ou de l'avionique non-certifiée, de sources externes ou internes à l'aéronef.
  • Les propositions de résolution d'impact reçues sont évaluées via le module traitement (106). L'évaluation d'une proposition met en oeuvre successivement les fonctionnalités du composant de contexte (404) en calculant un contexte résultant de la mission si la solution de la proposition était implémentée, du composant d'écarts (406) entre le contexte résultant et le contexte initial, et du composant d'impact (408) en déterminant quel serait l'impact sur la mission si la solution de la proposition était implémentée.
  • Dans un mode de réalisation, les traitements réalisés par le module de traitement (106) sont basés sur une analyse selon une ontologie.
  • Dans un mode de réalisation, les traitements réalisés par le module de traitement (106) sont basés sur une analyse selon des règles prédéfinies.
  • Avantageusement, le composant de requête de résolution (402) peut générer de nouvelles requêtes en fonction de l'impact qui a été calculé, et recevoir de nouvelles propositions de solutions qui sont évaluées par le module de traitement (106).
  • Le composant de tri (410) est configuré pour pondérer les solutions trouvées, en fonction de critères de tri adaptés à la situation et aux problématiques équipage.
  • Avantageusement, en enregistrant les choix pilotes qui sont faits et le contexte associé, les critères de pondération peuvent être adaptés a postériori afin de coller de mieux en mieux à la situation au fil du temps. De plus, en capturant les alternatives effectivement sélectionnées/réalisées, cela permet d'enrichir les connaissances du dispositif en post analyse.
  • Le composant de suggestion (412) est configuré pour structurer les suggestions retenues, de manière à pouvoir notifier l'équipage et lui présenter (110) les éléments avec le rationnel associé.
  • Dans un mode de réalisation, pour éviter les erreurs, un minimum de trois suggestions est proposé à l'équipage. Avantageusement, l'enregistrement de ces informations permet d'enrichir la recherche de solution qui devient plus performante au fil du temps.
  • Une fois l'alternative choisie validée, le dispositif de l'invention permet de transférer les éléments de cette alternative côté avionique, voire côté sol, afin qu'elle devienne la nouvelle référence mission.
  • Le dispositif permet de suivre l'exécution de la nouvelle référence afin de détecter les écarts.
  • Avantageusement, le dispositif permet de contextualiser l'utilisation des différents services en fonction des politiques des compagnies aériennes et des utilisateurs du système (pilotes).
  • La figure 5a illustre un exemple d'implémentation du dispositif d'assistance au pilotage de l'invention où tous les modules sont intégrés sur une plateforme de calcul de l'avionique certifiée.
  • La figure 5b illustre un autre exemple d'implémentation du dispositif d'assistance au pilotage de l'invention où tous les modules sont intégrés sur une plateforme de calcul de l'avionique non-certifiée.
  • La figure 5c illustre un autre exemple d'implémentation du dispositif d'assistance au pilotage de l'invention où les modules sont repartis entre des plateformes de calcul de l'avionique certifiée, des plateformes de calcul de l'avionique non-certifiée et des plateformes de calcul d'une infrastructure sol. Dans cette implémentation, les composants de traitement et de résolution sont implémentés sur une plateforme de calcul de l'avionique non-certifiée. La plateforme de l'infrastructure sol est connectée à la plateforme avionique par une liaison de données.

Claims (12)

  1. Un dispositif (100) d'assistance au pilotage d'un aéronef comprenant :
    - un module de compétences (102) configuré pour enregistrer selon un même format logique des composants applicatifs dits capacités, chaque capacité ayant un domaine de compétence caractérisant son domaine fonctionnel, la nature et le format des données relatives à ce domaine fonctionnel, et étant configurée pour opérer dans son domaine de compétence au moins des fonctions consistant à :
    - calculer des évènements à partir de données relatives audit domaine fonctionnel acquises de différentes sources de l'avionique certifiée ou de l'avionique non-certifiée et/ou de différentes sources externes ou sources internes à l'aéronef ;
    - traiter des requêtes de résolution d'événements impactant la mission en cours d'un aéronef, lesdits évènements étant calculés par ladite capacité et/ou par d'autres capacités, lesdites requêtes étant traitées à partir de données relatives audit domaine fonctionnel de ladite capacité acquises de différentes sources de l'avionique certifiée ou de l'avionique non-certifiée et/ou de différentes sources externes ou sources internes à l'aéronef ;
    - générer des propositions de résolution d'évènements ;
    - un module de traitement (106) comprenant des composants configurés pour déterminer l'existence d'un impact sur la mission en cours de l'aéronef, soit pour un évènement calculé par une capacité , soit pour une proposition de résolution d'événements générée par une capacité ;
    - un module de résolution (108) comprenant des composants configurés pour :
    - émettre des requêtes de résolution vers une ou plusieurs capacités du module de compétence,
    - évaluer des propositions de résolution d'évènements ;
    - construire des solutions d'adaptation de la mission en cours de l'aéronef à partir d'au moins une proposition de résolution d'évènements ;
    et
    - un module de gestion (104) comprenant des composants configurés pour gérer des contentions et des priorités de flux, et des composants configurés pour aiguiller les échanges entre les différents modules du dispositif.
  2. Le dispositif selon la revendication 1 comprenant de plus un registre de capacités (208) et une base de données de capacités (210) pour enregistrer et stocker le domaine de compétence de chaque capacité.
  3. Le dispositif selon la revendication 1 ou 2 dans lequel le module de traitement (106) comprend :
    - un composant de contexte (302, 404) configuré pour calculer soit un contexte courant de la mission en cours de l'aéronef pour un évènement analysé, soit un contexte résultant de la mission en cours de l'aéronef pour une proposition de résolution d'événements analysée ;
    - un composant d'écarts (304, 406) configuré pour identifier tout écart entre le contexte initial de la mission de l'aéronef et, le contexte courant ou le contexte résultant qui est calculé ; et
    - un composant d'impact (310, 408) configuré pour déterminer en fonction du ou des écarts identifiés, l'existence d'un impact sur la mission en cours de l'aéronef.
  4. Le dispositif selon l'une quelconque des revendications 1 à 3 dans lequel les composants du module de traitement (106) sont configurés pour effectuer une analyse selon une ontologie.
  5. Le dispositif selon l'une quelconque des revendications 1 à 4 dans lequel les composants du module de traitement (106) sont configurés pour effectuer une analyse selon des règles prédéfinies.
  6. Le dispositif selon l'une quelconque des revendications 1 à 5 dans lequel le module de résolution comprend de plus un module de tri (410) pour sélectionner des propositions de résolution.
  7. Le dispositif selon la revendication 6 dans lequel le module de tri (410) est configuré pour sélectionner des propositions de résolution selon des critères de pondération.
  8. Le dispositif selon l'une quelconque des revendications 1 à 7 dans lequel le module de compétences comprend au moins une capacité dont le domaine de compétence est celui de la gestion des systèmes avioniques, une capacité dont le domaine de compétence est celui de la gestion de la mission de l'aéronef, et une capacité dont le domaine de compétence est celui de la gestion de l'environnement.
  9. Le dispositif selon l'une quelconque des revendications 1 à 8 comprenant de plus une interface homme-machine (110) configurée pour gérer les interactions d'un ou plusieurs opérateurs avec les différents modules du dispositif.
  10. Plateforme de calcul de l'avionique certifiée, comprenant un dispositif d'assistance au pilotage d'aéronef selon l'une quelconque des revendications 1 à 9.
  11. Plateforme de calcul de l'avionique non certifiée, comprenant un dispositif d'assistance au pilotage d'aéronef selon l'une quelconque des revendications 1 à 9.
  12. Plateforme de calcul comprenant un dispositif d'assistance au pilotage d'aéronef selon l'une quelconque des revendications 1 à 9, dans laquelle les modules du dispositif d'assistance au pilotage d'aéronef sont répartis entre l'avionique certifiée, l'avionique non certifiée et une infrastructure sol connectée à l'avionique par une liaison de donnée.
EP22165059.1A 2021-03-29 2022-03-29 Procédé d'assistance au pilotage d'aéronefs Pending EP4068244A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR2103184A FR3121256B1 (fr) 2021-03-29 2021-03-29 Procédé d’assistance au pilotage d’aéronefs

Publications (1)

Publication Number Publication Date
EP4068244A1 true EP4068244A1 (fr) 2022-10-05

Family

ID=77317050

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22165059.1A Pending EP4068244A1 (fr) 2021-03-29 2022-03-29 Procédé d'assistance au pilotage d'aéronefs

Country Status (3)

Country Link
US (1) US20220343766A1 (fr)
EP (1) EP4068244A1 (fr)
FR (1) FR3121256B1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090276149A1 (en) * 2008-05-02 2009-11-05 Honeywell International Inc. Cognitive aricraft hazard advisory system (cahas)
US20170011635A1 (en) * 2014-03-13 2017-01-12 Honeywell International Inc. System and method for intelligently mining information and briefing an aircrew on conditions outside the aircraft
US20180075758A1 (en) * 2016-09-13 2018-03-15 Thales Decision-making aid for revising a flight plan
US10096253B2 (en) 2015-11-30 2018-10-09 Honeywell International Inc. Methods and systems for presenting diversion destinations
US10109203B2 (en) 2016-09-07 2018-10-23 Honeywell International Inc. Methods and systems for presenting en route diversion destinations

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090276149A1 (en) * 2008-05-02 2009-11-05 Honeywell International Inc. Cognitive aricraft hazard advisory system (cahas)
US20170011635A1 (en) * 2014-03-13 2017-01-12 Honeywell International Inc. System and method for intelligently mining information and briefing an aircrew on conditions outside the aircraft
US10096253B2 (en) 2015-11-30 2018-10-09 Honeywell International Inc. Methods and systems for presenting diversion destinations
US10109203B2 (en) 2016-09-07 2018-10-23 Honeywell International Inc. Methods and systems for presenting en route diversion destinations
US20180075758A1 (en) * 2016-09-13 2018-03-15 Thales Decision-making aid for revising a flight plan

Also Published As

Publication number Publication date
FR3121256B1 (fr) 2024-02-16
US20220343766A1 (en) 2022-10-27
FR3121256A1 (fr) 2022-09-30

Similar Documents

Publication Publication Date Title
EP1955305B1 (fr) Dispositif et procede de mise a jour dynamique des zones de vol prohibees dans un aeronef
FR3000195B1 (fr) Architecture hybride pour systeme aeronautique
CA2291865C (fr) Procede de mise en oeuvre d&#39;une unite de service de trafic air
FR3035534B1 (fr) Procede et systeme de communication et de partage d&#39;informations pour aeronef
FR3035711A1 (fr) Systemes et procedes pour fournir des donnees actualisees a un aeronef
EP2375299A1 (fr) Systeme de gestion de vol d&#39;un aeronef sans pilote a bord de l&#39;aeronef
FR3061342A1 (fr) Gestion des messages aux navigants aeriens
FR3038750A1 (fr) Procede d&#39;integration d&#39;un nouveau service de navigation dans un systeme avionique embarque a architecture ouverte de type client-serveur, en particulier d&#39;un service de manoeuvre fim
FR2906921A1 (fr) Procede de formation d&#39;une trajectoire d&#39;urgence en 3d pour aeronef et dispositif de mise en oeuvre
FR2898972A1 (fr) Procede et dispositif de surveillance de l&#39;altitude de vol minimum d&#39;un aeronef
FR2820867A1 (fr) Procede automatise de suivi et d&#39;organisation de deplacement de vehicules au sol et d&#39;identification de corps etrangers sur les pistes dans une zone aeroportuaire
FR2893747A1 (fr) Systeme, assiste par satellite, d&#39;alerte de collisions et de gestion du trafic de vehicules, tels que des aeronefs
FR3093221A1 (fr) Procédé et système de mise à jour automatique d’un plan de vol courant d’un aéronef.
FR3030805A1 (fr) Qualite de service d&#39;un systeme de gestion de vol
CA3037319A1 (fr) Systeme d&#39;etablissement de plan de vol operationnel d&#39;aeronef et procede associe
FR2908904A1 (fr) Systeme de pilotage d&#39;un aeronef comportant une base de donnees aeronautique.
FR3038751A1 (fr) Procede d&#39;integration d&#39;une application d&#39;optimisation de route (s) sous contraintes dans un systeme embarque avionique a architecture ouverte de type client serveur
EP2656221B1 (fr) Dispositif de maintenance centralise pour aeronefs
FR2963859A1 (fr) Procede et systeme de transmission des donnees d&#39;enregistreurs de vol en cas d&#39;urgence
EP4068244A1 (fr) Procédé d&#39;assistance au pilotage d&#39;aéronefs
EP4068245A1 (fr) Dispositif d&#39;assistance au pilotage d&#39;aéronefs
CA3020086A1 (fr) Procede de controle de la restitution d&#39;alerte(s) et/ou de procedure(s) de reconfiguration systeme(s), produit programme d&#39;ordinateur et systeme de controle associes
FR3072816A1 (fr) Procede de determination de point(s) limite (s) de decision relative au declenchement d&#39;une manoeuvre d&#39;evitement par un aeronef, dispositif et programme d&#39;ordinateur associes
CA2772516A1 (fr) Dispositif et procede d&#39;evaluation des capacites operationnelles d&#39;un aeronef
FR2954842A1 (fr) Dispositif et procede de gestion de tache pour le pilotage d&#39;un aeronef

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20230309

RBV Designated contracting states (corrected)

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230427