EP4058959A1 - Espace collaboratif de gestion de contexte de plan de vol - Google Patents

Espace collaboratif de gestion de contexte de plan de vol

Info

Publication number
EP4058959A1
EP4058959A1 EP20793409.2A EP20793409A EP4058959A1 EP 4058959 A1 EP4058959 A1 EP 4058959A1 EP 20793409 A EP20793409 A EP 20793409A EP 4058959 A1 EP4058959 A1 EP 4058959A1
Authority
EP
European Patent Office
Prior art keywords
modification
flight plan
objects
message
interaction
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
EP20793409.2A
Other languages
German (de)
English (en)
Inventor
Jérôme Sacle
François TERREE
Guy Deker
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 EP4058959A1 publication Critical patent/EP4058959A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/101—Collaborative creation, e.g. joint development of products or services
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft
    • G08G5/20—Arrangements for acquiring, generating, sharing or displaying traffic information
    • G08G5/21—Arrangements for acquiring, generating, sharing or displaying traffic information located onboard the aircraft
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft
    • G08G5/20—Arrangements for acquiring, generating, sharing or displaying traffic information
    • G08G5/22—Arrangements for acquiring, generating, sharing or displaying traffic information located on the ground
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft
    • G08G5/20—Arrangements for acquiring, generating, sharing or displaying traffic information
    • G08G5/26—Transmission of traffic-related information between aircraft and ground stations
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft
    • G08G5/30—Flight plan management
    • G08G5/34—Flight plan management for flight plan modification
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft
    • G08G5/50—Navigation or guidance aids
    • G08G5/55—Navigation or guidance aids for a single aircraft
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft
    • G08G5/50—Navigation or guidance aids
    • G08G5/59—Navigation or guidance aids in accordance with predefined flight zones, e.g. to avoid prohibited zones

Definitions

  • the present invention relates to the field of avionics and more particularly to the definition of the management of aircraft flight plans and their context.
  • Flight plans are used to calculate the trajectories followed by the aircraft, and allow the various operators (pilot, air traffic controller, etc.) to assess, in advance, the path that will be followed by the aircraft. Flight plans are generally defined by a succession of waypoints, each waypoint being generally associated with a passage time and an altitude.
  • the pilot of an aircraft has a display of the flight plan, allowing him to view the current flight plan context including the flight plan and the environment such as weather, NOTAMs, traffic, airspaces, etc., but also to modify it.
  • the modification can then be submitted to a flight management system which verifies that the modified flight plan will indeed be flyable by the aircraft, and whether or not the modification is validated.
  • CCS Ground Control Center
  • ATC Air Traffic Control air traffic control centers
  • OCC operators' operational centers
  • the operators and systems on the ground and on board must be able to communicate on the aircraft flight plan, for various reasons: if the pilot modifies the flight plan, the CCS air traffic controllers must be informed in order to be able to verify that the new flight plan is well compatible with the constraints of the airspace (for example, with the trajectories of other aircraft, airspace, etc.).
  • a CCS can requesting a modification of the flight plan from the aircraft, for example to adapt to modifications of air traffic in the current airspace or to the operational needs of the operator. More generally, operators on the ground or on board can submit a modification of the flight plan.
  • Today's ground-to-shore communications possibilities include the exchange of radio messages between the ground and on-board. These messages can take the form of voice communication, or data exchanges. If these messages allow submitting changes to the flight plan from the ground to the edge, or vice versa, the possibilities for interaction remain limited.
  • the invention relates to a first system comprising: at least one display device configured to display a set of objects comprising a reference flight plan of the aircraft and at least one environment object or of context; at least one input interface; at least one communication port configured to communicate with at least a second system; at least one calculation unit configured, on reception, by the communication port, of a message indicating a first description of a modification of said set, in order to: generate the display of the modification; receive validation or rejection of the modification by the input interface; send, via the at least one communication port, a message to the second system containing: in the event of validation, a second description of said modification; otherwise, an indication that the change was rejected.
  • At least one calculation unit is configured, on receipt of a modification of the set of objects by the input interface, in order to: generate the display of the modification; send, through at least one communication port, a message to the second system containing a first description of the modification; receiving from the second system a message containing an indication of the rejection of the modification, or a second description of the modification; if the message received from the second system is a rejection message, or if the first and second description are different, canceling the modification; otherwise, validate the modification.
  • At least one environment or context object comprises at least one object belonging to a type of object chosen from a group comprising: a text area; an informational symbol; a closed surface; a pseudo point on the reference flight plan; a graphic element; a flight plan section separate from the reference flight plan.
  • the first system comprises at least one flight management system, and in which the at least one calculation unit is configured: on receipt of a modification of the reference flight plan by the at least one flight management, display the modification and send, via the at least one communication port, a message containing a description of the modified reference flight plan; if said modification of the set of objects received by the input interface is a modification of the flight plan, and is validated, send it to the flight management system.
  • the at least one calculation unit is configured, on receipt of a modification of the set of objects, to: check whether said modification of the reference flight plan involves an interaction between the reference flight plan modified and a other object of the set; if the modification involves an interaction, create a functional object symbolizing the interaction.
  • At least one calculation unit is configured to: check whether the modification of the reference flight plan involves the passage of the modified reference flight plan in an existing or new closed surface; if the modification involves the passage of the modified reference flight plan in an existing or new closed surface, create a pseudo point at the entry of said flight plan into the closed surface, and a pseudo point at the exit of said flight plan of the closed surface.
  • the at least one calculation unit is configured, on receipt of a modification of the set of objects, to: check whether said modification implies a suppression of the interaction between the modified reference flight plan and another object of the set; if the modification involves the removal of the interaction, remove a functional object symbolizing the interaction.
  • the at least one calculation unit is configured, on receipt of a modification of the set of objects comprising the addition or modification of an environment or context object, in order to: check whether said modification involves an interaction between the reference flight plan and the added or modified environment or context object; if the modification involves an interaction, create a functional object symbolizing the interaction.
  • the added or modified environment or context object is an added or modified closed surface
  • at least one calculation unit is configured to: check whether the modification involves the passage of the reference flight plan in the closed surface added or modified; if the modification involves the passage of the reference flight plan in the added or modified closed surface, create a pseudo point at the entry of said flight plan in the added or modified closed surface, and a pseudo point at the exit of said plane of the added or modified closed surface.
  • the at least one calculation unit is configured, on receipt of a modification of the set of objects comprising the deletion of an environment or context object, in order to: check whether said modification implies a deletion the interaction between the reference flight plan and the deleted environment or context object; if the modification involves the removal of the interaction, remove a functional object symbolizing the interaction.
  • the at least one calculation unit is configured to perform an encoding of an object prior to sending a message, and to perform a decoding of an object following the reception of a message, the encoding of the object comprising: a section of code comprising a predefined code defining the type of object, and for each of the attributes of the object, a predefined code defining the type of the attribute; an alphanumeric sequence defining, for each of the attributes, the associated value.
  • the at least one calculation unit is configured to perform a coding of a modification of the reference flight plan prior to sending a message, and to perform a decoding of a modification of the flight plan reference following the reception of a message
  • the coding of the modification of the reference flight plan comprising: a code section comprising a predefined code defining a modification of the reference flight plan, and for each of the flight plan functions modified flight, a predefined code defining the type of function; an alphanumeric sequence defining the modified waypoints, and, for each of the functions, the associated parameter values.
  • the first and the second modification of the set are represented respectively in a first and a second coding of an object or of a modification of the reference flight plan; the at least one computing unit is configured to check whether the first and second modifications are the same by checking whether the first and second encodings are the same.
  • the communication port is configured to communicate with a plurality of second systems;
  • the computing unit is configured, on receipt, by the communication port, of the message indicating the description of the modification, and in the event of validation, to send, via the at least one communication port, to each of the second systems of said plurality, the message containing the second description of the modification.
  • the subject of the invention is also a method implemented by computer comprising: the reception, by at least one communication port of a first system, configured to communicate with at least one second system, of a message indicating a first description a modification of a set of objects comprising a reference flight plan of an aircraft and at least one environment or context object; the display of said modification on at least one display device of the first system; receiving the validation or rejection, through an input interface of the first system; sending, via the at least one communication port, a message to the second system containing: in the event of validation, a second description of said modification; otherwise, an indication that the change was rejected.
  • the subject of the invention is also a computer program comprising program code instructions recorded on a computer readable medium, said program code instructions being configured to: receive, via at least one communication port of a first system, configured to communicate with at least a second system, of a message indicating a first description of a modification of a set of objects comprising a reference flight plan of an aircraft and at least one environment object or context; displaying said modification on at least one display device of the first system; receive validation or rejection, through an input interface of the first system; send, through at least one communication port, a message to the second system containing: if validated, a second description of said modification; otherwise, an indication that the change was rejected.
  • Figure 1 an example of two systems collaborating on an interactive flight plan context according to a set of embodiments of the invention
  • Figure 2 an example of a graphical interface according to a set of embodiments of the invention
  • Figure 3 several examples of objects of a graphical interface in a set of embodiments of the invention.
  • Figure 4 a first example of creation of derived objects, before and after revision of a flight plan, in a set of embodiments of the invention
  • FIG. 5 a second example of creation of derived objects, before and after revision of a flight plan, in a set of embodiments of the invention
  • FIG. 6 an example of the creation of a derived object function of a flight plan after insertion of an original object with a closed surface, in a set of embodiments of the invention
  • FIG. 7a an example of coding of an object, according to a set of embodiments of the invention
  • Figure 7b an example of coding of a flight plan revision, according to a set of embodiments of the invention.
  • Figure 8 a method of applying a modification to a ground system, and validating the modification to an on-board system in a set of embodiments of the invention
  • FIG. 9 a method of applying a modification to an on-board system, and of validating the modification to a ground system in a set of embodiments of the invention.
  • Certain Anglo-Saxon acronyms commonly used in the technical field of the present application may be used during the description. These acronyms are listed in the table below, with in particular their Anglo-Saxon expression and their meaning as well as the definition of the main terms of the technical field in which the invention is situated.
  • Figure 1 shows an example of two systems collaborating on an interactive flight plan according to a set of embodiments of the invention.
  • System 1000 is an aircraft on-board system
  • System 1100 is an Air Operations Ground Control System (CCS).
  • CCS Air Operations Ground Control System
  • the system 1000 controls the trajectory of the aircraft, while the system 1100 interacts with the system 1000, but cannot directly control the trajectory of the aircraft.
  • the 1000 and 1100 systems are given as an example only.
  • the system 1000 can control the trajectory of an aircraft remotely, it can for example be a system for controlling a drone remotely.
  • the system 1000 can interact with several systems, for example several CCS.
  • the systems of the invention can, more generally, be systems allowing remote viewing of the aircraft flight plan, and interaction with the first system. These may, for example, be operations control centers, for example maritime surveillance drone control centers.
  • the invention can be applied more generally to any set of systems comprising a system capable of visualizing the context of the flight plan of an aircraft, and of piloting from the flight plan, and at least one system capable of in viewing the flight plan context and interacting with the first system on this flight plan context.
  • the system 1000 can for example be an onboard system of an aircraft, comprising an application of EFB type which can be for example a navigation and flight optimization application or extended FMS having the capacity to interface with avionics. , for example an FMS.
  • EFB type which can be for example a navigation and flight optimization application or extended FMS having the capacity to interface with avionics.
  • extended FMS having the capacity to interface with avionics.
  • FMS for example an FMS.
  • the system 1000 includes at least one display device 1010 configured to display a first set of elements comprising a reference flight plan of the aircraft, and depending on the circumstances of the mission, objects in the context of the flight plan.
  • the display device can typically consist of one or more aircraft screens.
  • This device displays at least one flight plan of the aircraft, but also objects that can influence the flight plan (s).
  • the objects may in particular include:
  • Elements of the environment or context of the aircraft can thus be both elements of the physical environment of the aircraft (for example, a mountain, danger zone, waypoint, airport, etc.), as well as context objects used for the communication between the edge and the ground (it can then be for example text zones, pseudo-points on the trajectory ).
  • the invention is more generally applicable to any object the display of which may be of interest in the context of exchanges of information between operators in connection with the navigation of an aircraft.
  • the first system 1000 also includes at least one input interface 1020.
  • This interface can include any type of interface capable of receiving input data from the operator (in this example, from the pilot of the aircraft).
  • the first system 1000 also includes at least one communication port 1030 capable of communicating with the system 1100.
  • the communication port 1030 can typically include a VHF, HF or SatCom radio communication antenna, and, in the case where the system 1000 is an on-board system of an aircraft communicating with the ground, the communication can be done by the datalink protocol.
  • the communication port 1030 is therefore able to send and receive messages with the system 1100.
  • the system 1000 finally comprises at least one calculation unit 1040.
  • the at least one calculation unit 1040 can be any type of calculation unit capable of performing computer calculations.
  • the computing unit can be a processor configured with machine instructions, a microprocessor, an integrated circuit, a microcontroller, a programmable logic circuit, or any other computing unit capable of being programmed to perform computing operations.
  • the system 1100 can be a control system for air operations on the ground (CCS), or, more generally, a system making it possible to remotely view and modify the context of the flight plan of the aircraft.
  • the system 1100 can thus execute an OFP type application connected to the operator's flight plan generation tool.
  • the system 1100 can also be connected to applications and tools, such as those relating to the weather forecast, to airspace flight information, in order to automatically integrate elements to be brought to the attention of the first system.
  • the system 1100 includes at least one display device 1110 configured to display one or more flight plans and a set of objects associated with this or these flight plans.
  • the display device 1110 can typically include one or more screens.
  • the 1100 system also includes at least one 1120 input interface, which can include any type of input interface that allows an operator to enter data: keyboard, microphone, mouse, etc.
  • the system 1100 also includes at least one communication port 1130 capable of communicating with the system 1000.
  • the communication port 1130 can typically include a radio communication antenna, and, in the case where the system 1000 is an on-board system, an aircraft communicating with the ground, the communication can be done by a datalink protocol.
  • the communication port 1130 is therefore able to send and receive digital messages with the first system 1000.
  • different data link protocols can be used.
  • the so-called ACARS or ATN datalink protocols can be used to transmit data between the system 1000 and the system 1100.
  • the second system 1100 finally comprises at least one calculation unit 1140.
  • the at least one calculation unit 1140 can be any type of calculation unit capable of performing computer calculations.
  • the computing unit can be a processor configured with machine instructions, a microprocessor, an integrated circuit, a microcontroller, a programmable logic circuit, or any other computing unit capable of being programmed to perform computing operations.
  • One of the objectives of the invention is to synchronize, in real time, the first and second sets of objects, in order to allow the operators of the different systems to view, in real time, the same flight plan and the same objects, while doing independent work of processing sets of objects.
  • the systems 1000 and 1100 exchange messages, via their communication ports 1030, 1130.
  • the messages sent from the system 1100 to the system 1000 are denoted 1200, and the messages sent from the system 1000 to the system 1200 are denoted 1210.
  • FIG. 1 represents a single message 1200, and a single message 1210, the invention can be applied to exchanges of numerous successive messages between the system 1000 and the system 1100.
  • the flight plan and associated objects can be created and modified in different ways: an operator, on the ground or on board, can make modifications, for example by proposing a modification of the flight plan, by adding a text box, or by modifying or adding an environmental element, such as a no-go zone.
  • a modification can also come from a flight management system modifying the flight plan.
  • a message describing the change is sent to at least one of the other systems.
  • a modification of the second set of objects is made at the system 1100 level
  • a message 1200 describing the modification is sent by the system 1100 to the system 1000.
  • a message 1210 describing the modification is sent from system 1000 to system 1100.
  • the messages are encoded using a code system making it possible to define the objects, their status and attributes. and their modifications. The messages can thus be encoded and decoded in a transparent manner by the systems 1000, 1100.
  • An example of the encoding and decoding of objects is provided in FIGS. 7a and 7b.
  • the at least one computing unit 1040, 1140 Upon receipt of a message 1200, 1210 indicating a modification of the set of objects, the at least one computing unit 1040, 1140 is configured 1040, 1041 to generate the display of the modification. In order to highlight the modification, it can be highlighted in different ways: highlight, color, blink, highlight, highlight, pop-up, etc. This allows the operator of the system receiving the message to view the change. He can then use the input interface 1020, 1120 to validate or reject 1042, 1142 the modification.
  • the set of objects is updated at the level of the system (s) that received the change, ground side or on board side. Then, at least one computing unit 1040, 1140 sends back to the other system (s) an update of the dynamic flight plan and of the associated objects as actually implemented.
  • At least one computing unit 1040, 1140 is configured to send, through at least one communication port 1043, 1143, a message 1210, 1200 to other systems containing:
  • modified reference flight plan will be used to refer to the reference flight plan to which the modification has been made, after acceptance.
  • unmodified reference flight plan can also be used to designate the reference flight plan, either before modification or for which the modification has been refused.
  • the ground-based CCS flight operations control system can propose modifications to the on-board system that the latter can accept, reject or adjust, the reverse may not be authorized.
  • the on-board system can propose modifications to the CCS ground system, for example Air Control (ATC) which can accept, reject or adjust them, the reverse being possible in this particular case.
  • ATC Air Control
  • a modification of the flight plan, or of another of the displayed objects is carried out on one of the systems implementing the invention, this modification is sent to the other systems.
  • the operator of each of the onboard systems (or ground in the case of ATC) can then accept or reject the modification.
  • some or all of the objects are accepted, they are modified in the receiving system, and a response message detailing the modification as performed by the receiving system is returned.
  • the sending system can then check whether the modification made by the system is identical to the modification sent. If this is the case, the modification is accepted in the status of the considered object.
  • the invention makes it possible to synchronize the representation of the flight plan and the surrounding objects between the system 1000 and the system 1200. In fact, changes made on one side are propagated to the other.
  • This makes it possible to create a collaborative workspace, in which the different operators, for example a pilot and an air operations controller, can interact in real time.
  • This is referred to as a deterministic dynamic flight plan context, because the flight plan and its context are dynamically shared between all the systems collaborating on the flight plan. It is also deterministic in the sense that it is uninterpretable.
  • a response message is returned with a status indicating either rejection of the change or, when the change is accepted, a resend of the change. same modification, or subsequent modifications. This way, the sender of a change can check whether the change was applied identically, or involved subsequent changes.
  • the invention also makes it possible to guarantee better air safety, since the various operators have up-to-date information at all times and in real time. While the invention is generally presented in the context of communication between an aircraft and an operational control center, it is also applicable to many other cases, such as communication between an aircraft and several other control centers. operational controls or even control towers, or communication between several control centers of a drone.
  • the first system 1000 includes at least one flight management system 1050. If the first system is an on-board system of an aircraft, the flight management system can typically be operated. an FMS. If the first system 1000 is a remote drone control system, the flight management system 1050 can be a system for calculating the trajectory of the drone from the flight plan, on the ground or on board. In all cases, the flight management system 1050 is able to verify the ability of the aircraft to follow a flight plan, in particular in view of its aerodynamic performance, to calculate a trajectory from the flight plan, and to enslave the aircraft on the trajectory, for example by sending instructions to an autopilot or AFCS.
  • the flight management system 1050 is able to verify the ability of the aircraft to follow a flight plan, in particular in view of its aerodynamic performance, to calculate a trajectory from the flight plan, and to enslave the aircraft on the trajectory, for example by sending instructions to an autopilot or AFCS.
  • the at least one computing unit 1040 can bi-directionally interact with the flight management system 1050, to send or receive changes to the flight plan.
  • a modification of the flight plan can be initiated by the flight management system 1050. It is then transmitted to at least one computing unit 1040, and integrated into the graphic interface.
  • an avionics-initiated flight plan modification does not need to be validated by the operator of System 1000: it can be transmitted directly to System 1100.
  • changes to the flight plan in the collaborative interface can be sent to the avionics, as soon as they are validated at both the system 1000 and system 1100 level, or manually at the request of the system operator. 1000.
  • Figure 2 shows an example of a graphical interface in one embodiment of the invention.
  • the graphical interface 200 can be used by both the first system 1000 and the second system 1100. It represents all the objects in the workspace.
  • the set of objects in the environment of the flight plan 210 defined in particular by waypoints 211, 212, and 213, include:
  • - zones defined along the flight plan o a GPS 220 service interruption prediction zone; a turbulence prediction zone 221;
  • a change of speed 230 (change to Mach 79); o a creation or a change of offset (lateral shift) of trajectory at a point 231, o a climb towards a new FL at a point 213; o a point of no return to the departure aerodrome 240; o a point equidistant or equi-time between the departure and arrival aerodromes 241;
  • An inactive flight plan section that does not belong to the active flight plan.
  • the same graphical interface is displayed on each of the systems, and allows each of the operators to have the same view of the modified flight plan and of its environment for this mission. Indeed, the ground operators can see several missions but for a given mission, the flight plan and the interface are the same as those of the flight in question. This thus allows smoother interaction between the various operators, in particular between the pilots and the operators on the ground.
  • the graphical interface 200 can be executed, in the form of a specific module, by the computing units 1040, 1140 can execute, in connection with the display devices 1010, 1110, and the input interfaces 1020, 1120 respectively.
  • operators can zoom, shift the view, but also interact with it, including modifying the flight plan, adding objects or validating objects added by other operators.
  • the graphical interface 200 allows the definition of characteristics of objects, and their placement on the map. It also allows you to view their insertion, and send them to other systems using the shared interface.
  • Each of the objects can be defined using an attribute library, including among others: a type, a label, a text, and a function.
  • the shape and position of an object can be defined in several ways. For example, they can be defined graphically on the mission interface, in the form of a succession of points, or by entering parameters in textual form.
  • Figure 3 shows several exemplary objects of a graphical interface in a set of embodiments of the invention.
  • the objects exchanged by the messages can, according to different embodiments of the invention, belong to different categories.
  • revisions of the flight plan can be the addition or deletion of one or more points, procedure (s), section (s) of FPL.
  • revisions dynamically update the flight plan.
  • revision 310 consists of a “DirectTo” type flight plan revision instruction instructing the aircraft to go directly to waypoint WPT2, without going through waypoint WPT1. If this change is accepted, the initial flight plan 311, including waypoint WPT 1, then waypoint WPT2, becomes flight plan 312, in which the aircraft proceeds directly to waypoint WPT2, at starting from a geographical starting point (latitude / longitude) TP which is also shared between the ground and the edge.
  • These revisions can come from navigation applications or from the 1040 flight management system and can include: o usual navigation functions, such as the Direct To, offset, add, delete point (s) functions , waiting pattern, procedure (s) ...; o updates to parts of flight plans.
  • a flight plan review can be initiated by an operator on one of the interfaces 1020, 1120, or by the flight management system 1040.
  • objects can also be of one of the following types:
  • pseudo point defined as another type of point created by the operator or the system that can be fixed or moving along the flight plan, different from a fixed waypoint from a database;
  • any graphic object that can be inserted into a navigation interface can be used by the invention, whether it is of a purely informative or graphic nature (example: a text zone), or whether it contains information likely to interact with the reference flight plan (example: a closed surface representing a meteorological danger zone.
  • flight plan is a function directly applicable in the flight plan management function within the meaning of the state of the art of the navigation functions of an FMS flight management system, for example the erasure of a point , the activation of a Direct To, the insertion of a vertical rise step ...
  • - a type defines the type of graphic objects: point, area ...;
  • a position this can be defined in different ways, for example by geographic coordinates, or a relative position on the flight plan;
  • a function defining an interaction with the flight plan for example, an area crossed by the flight plan generates a function such as an offset (lateral shift).
  • a system can be used to view multiple different flight plans, of multiple aircraft.
  • an air traffic control system can alternately display several different flight plans corresponding to different aircraft with which the air traffic controller can communicate.
  • the objects to be displayed can be more or less relevant depending on the flight plan considered: objects can be defined, in general, at a location regardless of the flight plan considered. For example, a closed surface indicating a storm is a relevant object regardless of the flight plan or the aircraft considered. We will then speak of a universal object, displayed regardless of the flight plan considered on the CCS side.
  • the universal objects are displayed regardless of the flight plan studied, and the specific objects only. when the flight plan to which it is associated is displayed. This allows for example an operator of the operational control center to change flight plan to collaborate with different aircraft, while having a set of universal objects permanently visible.
  • An object of type "text zone” can place a text providing an indication to the other operators. For example, a text “NO ENTRY FL 200 FL 400" indicates that an area is no-fly between FL 200 and 400.
  • Symbol type objects can be defined from a library of symbols common to the different systems, each symbol being defined by an identifier in the library.
  • the symbol 320 represents orographic waves (or "mountain waves" in English) and can be inserted by one of the operators at any place in the work area that can be associated with a geographical area.
  • the use of a common symbol base allows the interactive addition of symbols immediately understandable by all operators, allowing even smoother interaction between the different operators.
  • Closed areas can be defined by a set of geographic positions defining a geometric shape, delimited by an outline, a fill meeting a criterion associated with the object and a label.
  • the hatched area of Zone 330 defines a meteorological hazard.
  • An object of the "enhancement” type defines a geometric figure arranged around an object of the interface. This figure can in particular be defined by a shape, a color and a thickness, in order to highlight an element represented on the interface.
  • objects 340 and 341 respectively highlight waypoints "SIROD", and an "LSTR" airport, to signify that LSTR airport is a preferred diversionary airport.
  • flight plan section 350 defines a flight plan section between waypoints WPTA, WPTB, and the ARPTI airport.
  • a “pseudo point” type object represents a pseudo point on the flight plan, that is to say a point on the flight plan that does not involve any modification or revision of the flight plan. this one. For example, it could be an informative point.
  • the pseudo-point 360 associated with the label “PNR” (Point of No Return), indicates a point on the flight plan from which the aircraft can no longer make a U-turn to reach the departure aerodrome. with minimum fuel on board.
  • FIG. 4 represents a first example of creation of derived objects, before and after revision of a flight plan, in a set of embodiments of the invention.
  • the interaction of certain objects with the dynamic flight plan induces the creation of other objects, which may be called derived objects.
  • At least one computing unit is configured for:
  • This new object is a derived object.
  • each system according to the invention can permanently update a list of original objects, and derived objects, and iteratively add or delete derived objects, when the modifications of the original objects involve the creation or the removal of an interaction with the flight plan.
  • the modifications on the derived objects are made, and a feedback message is sent to the sending system, with all the changes applied, on the original objects and the derived objects.
  • an interaction between the flight plan and other objects involves placing or removing pseudo-points when the flight plan enters or leaves a closed surface.
  • the addition or deletion of pseudo-points can occur, either when a closed surface is added or deleted, or when the flight plan is modified.
  • Pseudo-points can be associated with flight plan functions depending on the meaning of the closed surface. Figure 6 provides an example of such an association.
  • derivative objects can be used, according to different embodiments of the invention.
  • the interaction between the flight plan and a surface or a volume can generate the production and modification of objects such as 4D volumes, varying over time.
  • these volumes may represent the entry of the aircraft into a danger zone.
  • the flight plan 410 initially comprises the points 420, 421 and 422.
  • Two closed surfaces 430, 440 are defined in the environment of the flight plan. Initially, the flight plan crosses the surface 440, entering it at pseudo-point 441, and exiting at pseudo-point 442.
  • the flight plan is then modified into a flight plan 411, by deleting the waypoint 421: the aircraft then goes directly from point 420 to point 422. It then no longer crosses zone 440, but zone 430: the pseudo-points 441 and 442 are deleted, but the pseudo-points 431 and 432 are added, respectively at the entry and exit of the aircraft from the closed surface 430.
  • FIG. 5 represents a second example of creation of derived objects, before and after revision of a flight plan, in a set of embodiments of the invention.
  • the flight plan 510 consists of waypoints 520, 521 and 522, and crosses the closed zone 530. Derived objects are thus present: the pseudo-points 540 and 541, respectively representing the entrance and the exit from the closed surface 530.
  • the flight plan 510 is modified into a flight plan 511: the waypoint 521 is replaced by the point 523.
  • the flight plan then still crosses the surface 530, but the entry and exit points are modified. . Consequently, the pseudo-points 540 and 541 are deleted, and replaced by the pseudo-points 542 and 543 respectively located at the new entry into the area 530, and at the new exit from the area.
  • FIG. 6 represents an example of creation of a derived object function of a flight plan after insertion of an original object closed surface, in a set of embodiments of the invention.
  • a closed surface 620 is added on the ground side, delimiting an offset navigation zone (lateral shift) of distance 5 nautical miles to the right of the flight plan 600. This surface is crossed by the flight plan. After addition on the ground side, the surface is sent to the on-board system.
  • the on-board system checks whether the interaction between the surface and the flight plan induces the creation of derived objects.
  • the answer is positive, and two waypoints 630 and 631 are added to the flight plan, respectively at the entry of the flight plan into the surface, and at the exit of the flight plan from the surface.
  • These points flight paths are associated respectively with a start and end of flight offset function (lateral shift) of 5 nautical miles.
  • This example is given by way of non-limiting example only and, in general, the interaction of a surface with a flight plan to generate the creation of waypoints on the flight plan, associated with a function depending on the meaning of the closed surface.
  • FIGS. 7a and 7b respectively represent an example of coding of an object, and an example of coding of a flight plan revision, according to a set of embodiments of the invention.
  • the calculation units 1040, 1140 are configured to encode the objects added or modified before sending a message, and to decode, symmetrically, the object. upon receipt of a message for inclusion.
  • the coding of additions or modifications can take different forms. For example, a label can be assigned to added and / or modified objects. A time stamp can also be inserted, corresponding to the last modification of the object.
  • an object 710a is defined by one or more attributes, which can for example be chosen from the following attributes: type, position, label, text, function.
  • the object 710a can for example be a context or environment object.
  • the encoding of the object is based on a list of predefined codes defining the different types of objects and attributes, and consists of representing the object as follows:
  • a predefined code representing the type of objects then, for each attribute present for the object, a predefined code representing each type of attribute.
  • These sets of codes represent a section of code 721a.
  • This section can also include an object identifier chosen from identifiers of an object among table 730a of objects already added in the interface. This makes it possible to detect that the coding defines a modification of an object already present, and not the addition of a new object; - then, an alphanumeric sequence of characters 722a defines, for each attribute, the associated value.
  • an object could be represented as below:
  • each type of object is coded in alphanumeric form.
  • an object of type "zone” will be represented by the attribute "Z”
  • an object of type "Mountain wave” by the attribute "M”;
  • each type of object is associated with a set of predefined attributes.
  • attributes of a zone Z will be a series of positions defined in the form of latitude and longitudes;
  • a series of alphanumeric characters is inserted for each of the attributes, for example a series of characters representing the successive latitudes and longitudes for an object of zone type.
  • the reverse operation can be done: first the code section 721a is decoded, which makes it possible to determine what type of object is decoded, and what attributes are present. Then, the alphanumeric sequence 722a is read in order to provide a value for each of the attributes.
  • each type of attribute is associated with a sequence of alphanumeric characters of predefined length.
  • the geographic coordinates of objects can be defined by a series of characters of a given length representing their latitude and longitude.
  • the encoding of objects according to different embodiments of the invention can be combined with the encoding, standardized, of waypoints.
  • the standard code of a waypoint can be inserted into the code of the object exchanged between interfaces according to the invention.
  • FIG. 7b An example of coding of flight plan modifications is presented in FIG. 7b.
  • this is only a non-limiting example, and any type of coding allowing deterministic coding and decoding of flight plan modifications can be used according to various embodiments of the invention.
  • a modification of the flight plan 710b can be defined by one or more waypoints, and one or more flight plan functions.
  • the functions can for example be trajectories resulting from specific functions of the onboard system, such as the offset trajectory (lateral offset).
  • a 720b coding of the flight plan modifications may include:
  • a section of code 721 b comprising: a predefined code defining that it is a modification of the flight plan; o for each of the functions of the modification, a predefined code defining the type of function.
  • a function When a function is modified, its identifier can be indicated, from among a table 730b of the functions of the flight plan; - an alphanumeric sequence 722b defining the coordinates of each waypoint, and the parameters of the added functions.
  • this convention allows changes to the flight plan to be exchanged transparently between the different systems using a shared interface.
  • the alphanumeric sequence only contains the parameter values corresponding to the coding of the waypoints and functions actually present in the modification. This convention therefore allows compact coding of the modifications to the flight plan, and bandwidth savings.
  • the receiving system upon receipt of a modification of the set of objects, applies the modification, presents it to an operator, and, if the latter approves the modification, recodes the modification, as applied to the receiving system, to return it to the sending system. It is then sufficient for the sending system to compare the codes of the modification sent and the modification received to check the integrity of the modification on the receiver side: if the codes are identical, the modification will have been applied identically to the receiver side. .
  • This code mechanism therefore provides a simple and efficient method of validating the integrity of the changes with all the systems involved, and ensuring that the changes are correctly synchronized by the different systems.
  • FIG. 8 represents a method of applying a modification to a ground system, and of validating the modification to an on-board system in a set of embodiments of the invention.
  • a modification of a set of objects of an interface is carried out by an air traffic controller in the system 1100, and sent to the system 1000.
  • this method is given by way of non-limiting example only: some steps are only used for certain embodiments of the invention.
  • systems 1000 and 1100 are given by way of example only. More generally, this method can be implemented between a system having only access to the shared interface, and a system having access to a flight management system. Likewise, the pilot and the air traffic controller can be replaced by other operators, such as a remote drone pilot.
  • Figures 8 and 9 show examples of creating ground-side and edge-side objects, respectively. Indeed, although the ground-side and edge-side interaction exhibits a large number of symmetrical characteristics, in a set of embodiments of the invention, certain differences are present. For example, on-board modifications can be considered to have priority over modifications on the ground side. Thus, some modifications on the edge side do not require validation on the ground side. Likewise, the interaction with the avionics takes place on the board side. These principles may also, more generally, be applicable to an interaction between a system having access only to the interface, and a system having access to a flight management system.
  • Figures 8 and 9 are presented, for the sake of simplicity, for the interaction between two systems.
  • the invention is applicable to interactions between more than two systems on the same shared interface: in this case, it suffices to send the modifications to all of the systems, and to extend the concept of validation to the return of all the systems, a modification being considered as definitively adopted only when it is validated by all the systems.
  • the steps of method 8000 can in particular be executed by calculation units 1040, 1140.
  • the air traffic controller performs a modification of the set of objects of the interface, as represented by the system 1100.
  • This modification may for example consist of the creation of an object, the modification or deletion of an existing object, or a modification of the flight plan.
  • the modification is carried out in particular by the inputs 1120, in connection with the display 1110.
  • the modification can for example consist of a modification of the flight plan 210, the deletion or the modification of one of the original objects of the interface (for example one of the objects 220, 221, 240, 241, 250, 251), or adding a new object.
  • the method may include an intermediate step of displaying the modification in the system 1100, validating the modification as displayed by the air traffic controller, and ordering the shipment.
  • the modification is coded, for example according to the principles discussed with reference to FIGS. 7a and 7b.
  • step 8030 the change is sent to system 1000.
  • step 8040 the modification is received by the system 1000 and decoded.
  • step 8050 the modification is displayed by the system 1000, to be seen by the pilot.
  • the pilot can then validate or reject the modification, in particular via at least one input interface 1020.
  • the feedback (validation or rejection of the pilot) is received.
  • step 8070 the type of return is tested.
  • a reject message 8080 is sent from system 1000 to system 1100.
  • the change is canceled at step 8090 in system 1100, which therefore reverts to state prior.
  • step 8100 the impact of the modification on the derived objects is verified, for example on the model explained with reference to FIGS. 4 and 5: if, following the modification, derived objects must be created, modified or deleted, these modifications are evaluated and displayed in step 8100.
  • step 8110 the modification, as applied in system 1000, is recoded.
  • This recoding step 8110 therefore comprises the encoding of the received modification, as actually applied at the system 1000 level, and if applicable, an encoding of the modifications of the derived objects.
  • changes to the derived objects are calculated, encoded, and sent later.
  • step 8120 the recoding of the modification is sent to the system 1100.
  • step 8130 the recoding is received by the system 1100.
  • step 8140 the system 1100 verifies that the recoding (excluding modifications of the derived objects) is identical to the initial encoding, carried out in step 8020).
  • step 8160 The modification is then canceled in step 8160.
  • This step 8160 can in particular include a notification from the air traffic controller that the modification is canceled, and the cancellation of the display. It can also include sending a message to system 1000, so that it also cancels the change on its side.
  • the air traffic controller can then, if desired, re-make a modification, and method 8000 is executed again, with a new modification.
  • step 8180 the system 1000 checks whether the modifications have an impact on the flight plan. This is the case, for example, if the modification sent is a modification of the collaborative flight plan, or if certain objects impact the flight plan, as in the example in Figure 6.
  • step 8200 validation of the pilot is received. In the event that the pilot rejects the modifications to the flight plan implied by the modification, this modification is canceled. A message is sent to the system 1100 to inform the air traffic control, and to cancel the modification on the system 1100 side. After validation by the pilot, the modification of the flight plan is sent in step 8210 to the flight management system 1050.
  • the flight management system rejects the modification, for example if it is not compatible with the aerodynamic performance of the aircraft, the modification is canceled, in both the 1000 and 1100 system.
  • Figure 9 shows a method of applying a modification to an on-board system, and validating the modification to a ground system in a set of embodiments of the invention.
  • a modification of a set of objects of an interface is carried out in the system 1000, either by action of the pilot, or by reception of a modification of the flight plan by the flight management system 1050, and sent to the system 1000.
  • this method is given by way of non-limiting example only: certain steps are only used for certain embodiments of the invention.
  • systems 1000 and 1100 are given by way of example only. More generally, this method can be implemented between a system having only access to the shared interface, and a system having access to a flight management system. Likewise, the pilot and the air traffic controller can be replaced by other operators, such as a remote drone pilot.
  • the steps of method 9000 can in particular be executed by calculation units 1040, 1140.
  • a modification of the set of objects of the interface is received as input.
  • This modification can for example consist in the creation of an object, the modification or the modification. deletion of an existing object, or a modification of the flight plan.
  • the modification can in particular be initiated by: the pilot, who enters them through the inputs 1020, in connection with the display 1010;
  • the flight management system 1050 which initiates a modification of the flight plan. If this modification is validated by the pilot, the modification is received as input to method 9000.
  • the modification can for example consist of a modification of the flight plan 210, the deletion or the modification of one of the original objects of the interface (for example one of the objects 220, 221, 240, 241, 250, 251), or adding a new object.
  • step 9020 If, following the modification, derived objects are to be created, modified or deleted, these modifications are evaluated and displayed in step 9020.
  • the pilot can then, in a set of embodiments of the invention, accept or reject modifications. If he refuses, the change is canceled.
  • the modification does not come from the flight management system 1050, but involves a modification thereof, and where the pilot accepts the modifications, the modification of the flight plan is sent to the flight management system. 1050.
  • the flight management system rejects the modification, for example if it is not compatible with the aerodynamic performance of the aircraft, the modification is canceled.
  • step 9040 pilot validation is received, for all modifications.
  • the modification or modifications (initial modification, modifications of the derived objects, modifications of the flight plan following the FMS dispatch) are coded, for example according to the principles discussed with reference to FIGS. 7a and 7b.
  • step 9060 all of the modifications are sent to the system 1100.
  • step 9070 all of the modifications are received by the system 1100.
  • step 9080 the modifications are displayed by the system 1100, to be seen by the air traffic controller.
  • the air traffic controller must validate or not the modifications.
  • the air traffic controller may need to validate all changes.
  • the modifications sent by the on-board can all be automatically applied to the ground, without validation from the air traffic controller.
  • only certain types of modifications for example, modifications to the flight plan) can be submitted for validation by the air traffic controller.
  • the modification is subject to validation by the air traffic controller, the latter can validate or reject the modification, in particular via inputs 1120.
  • the feedback (validation or rejection of the air traffic controller) is received.
  • the subsequent steps 9100, 9110, 9120 are also activated only if the modification is subject to validation by the air traffic controller.
  • step 9100 the type of return is tested.
  • a rejection message 9110 is sent from system 1100 to system 1000.
  • the changes are reverted at step 9120 in system 1000, which therefore reverts to state prior.
  • step 9130 the modifications, as applied in the system 1100, are recoded.
  • This recoding step 9130 therefore comprises the encoding of the modifications received, as effectively applied at the level of the system 1100.
  • changes to the derived objects are calculated, encoded, and sent later.
  • step 9140 the recoding of the modification is sent to the system 1000.
  • step 9150 the recoding is received by the system 1000.
  • step 9160 the system 1000 verifies that the recoding is identical to the initial encoding, performed in step 9050.
  • step 9180 can in particular comprise a notification of the pilot that the modifications are canceled, and the cancellation of the display. It can also include sending a message to the system 1100, so that the latter also cancels the modification on its side.
  • the pilot can then, if desired, re-make a modification, and method 9000 is executed again, with a new modification.
  • the coding of the changes can be sent back to the system 1100, without reverting the changes.
  • a validation message 9190 is sent to the system 1100.
  • the message 9190 is received by the system 1100.
  • the systems are well synchronized, and the modification becomes final.
  • the 9000 method demonstrates the ability of the invention to allow several systems to work, collaboratively, on flight plans, while ensuring that the modifications made by either side are correct. synchronized between the different systems.
  • a system can, for example, "centralize" operations.
  • the modifications of the objects of the collaborative interface are propagated from the central system to the others, and the examples developed above can be generalized. For example, if a change is made on the central system, it will be propagated to other systems, and can be rolled back if at least one of the other systems rejects the change. If a modification is received by the central system, and validated by the latter, a message comprising the modification can be sent to the other systems. This allows the collaborative interface to be deployed to more than two systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Data Mining & Analysis (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Traffic Control Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Navigation (AREA)

Abstract

L'invention concerne la gestion des éléments du contexte d'un ou des plans de vols. Plus spécifiquement, l'invention concerne des systèmes, méthodes et programmes d'ordinateur permettant un travail collaboratif en temps réel sur et autour d'un ou des plans de vol entre plusieurs systèmes distants. Pour ce faire, un premier système selon l'invention comprend la réception d'une modification, effectuée sur un deuxième système, d'un plan de vol et d'un ensemble d'objets associés ou d'un autre ensemble d'objets non associés, l'affichage de la modification, et, si la modification est validée, le renvoi de la modification, telle qu'appliquée sur le premier système, au deuxième système pour assurer l'unicité autour de l'espace collaboratif de navigation entre des intervenants distants.

Description

Espace collaboratif de gestion de contexte de plan de vol
DESCRIPTION
Domaine de l’invention
La présente invention concerne le domaine de l’avionique et plus particulièrement de la définition de la gestion des plans de vols d’aéronefs et de leur contexte.
Etat de l’art précédent
Les plans de vols sont utilisés pour calculer les trajectoires suivies par les aéronefs, et permettre aux différents opérateurs (pilote, contrôleur aérien...) d’évaluer, à l’avance, le chemin qui sera suivi par l’aéronef. Les plans de vols sont généralement définis par une succession de points de cheminement, chaque point de cheminement étant généralement associé à un temps de passage et une altitude.
De manière classique, le pilote d’un aéronef dispose d’un affichage du plan de de vol, lui permettant de visualiser le contexte de plan de vol actuel incluant le plan de vol et l’environnement tel que la météo, les NOTAMs, le trafic, les espaces aériens, etc, mais également de le modifier. La modification peut alors être soumise à un système de gestion de vol qui vérifie que le plan de vol modifié sera bien volable par l’aéronef, et valide ou non la modification.
Il est également intéressant pour des opérateurs au sol, notamment les centres CCS (Centre de Contrôle au Sol) comprenant les centres de contrôle aérien (ATC Air Traffic Control) et les centres opérationnels des opérateurs (OCC), de connaître le contexte de plan de vol de l’aéronef. En particulier, les opérateurs et systèmes au sol et à bord doivent pouvoir communiquer sur le plan de vol de l’aéronef, pour différentes raisons : si le pilote modifie le plan de vol, les contrôleurs aériens CCS doivent en être informés pour pouvoir vérifier que le nouveau plan de vol est bien compatible avec les contraintes de l’espace aérien (par exemple, avec les trajectoires des autres aéronefs, les espaces aériens...). Inversement, un CCS peut demander une modification du plan de vol à l’aéronef, par exemple pour s’adapter à des modifications de la circulation aérienne dans l’espace aérien courant ou à des besoins opérationnels de l’opérateur. De manière plus générale, des opérateurs au sol ou à bord peuvent soumettre une modification du plan de vol.
Aujourd’hui, les possibilités de communications entre le sol et le bord comprennent l’échange de messages radios entre le sol et le bord. Ces messages peuvent prendre la forme de communication vocales, ou d’échanges de données. Si ces messages permettent de soumettre des modifications du plan de vol du sol vers le bord, ou inversement, les possibilités d’interaction restent limitées.
En effet, dans les procédures actuelles, lorsque des modifications du plan de vol sont demandées, le plan de vol est défini soit au sol par le CCS soit à bord, et le nouveau plan de vol est renvoyé en entier à l’autre partie. Ceci induit plusieurs désavantages. Tout d’abord, le volume de données échangées est très important. Ceci induit une latence dans les communications, et un engorgement des canaux de données entre le bord et le sol. De plus, l’interaction entre le sol et le bord est limitée : si une modification du plan de vol, ou d’un paramètre de calcul de celui-ci est soumise par le sol ou le bord, le temps de validation de la modification sera important. Enfin, ces communications ne permettent pas de s’assurer qu’un plan de vol identique est partagé en temps réel entre le sol et le bord.
Le même problème se pose de manière plus générale lorsque plusieurs opérateurs travaillent à distance sur le plan de vol d’un aéronef. Par exemple, plusieurs centres de contrôle ATC ou de commande de drone peuvent suivre le plan de vol d’un drone. La même problématique de synchronisation des informations sur le plan de vol du drone se présente alors.
Il y a donc besoin d’un espace de travail partagé permettant de visualiser et modifier un plan de vol ou un contexte de plan de vol d’un aéronef de manière interactive entre plusieurs opérateurs, et ce à distance et en temps réel.
Résumé de l’invention
A cet effet, l’invention a pour objet un premier système comprenant : au moins un dispositif d’affichage configuré pour afficher un ensemble d’objets comprenant un plan de vol de référence de l’aéronef et au moins un objet d’environnement ou de contexte ; au moins une interface d’entrée ; au moins un port de communication configuré pour communiquer avec au moins un deuxième système ; au moins une unité de calcul configurée, à la réception, par le port de communication d’un message indiquant une première description d’une modification dudit ensemble, pour : générer l’affichage de la modification ; recevoir une validation ou un rejet de la modification par l’interface d’entrée ; envoyer, par l’au moins un port de communication, un message au deuxième système contenant : en cas de validation, une deuxième description de ladite modification ; sinon, une indication du rejet de la modification.
Avantageusement, l’au moins une unité de calcul est configurée, à la réception d’une modification de l’ensemble d’objets par l’interface d’entrée, pour : générer l’affichage de la modification ; envoyer, par l’au moins un port de communication, un message au deuxième système contenant une première description de la modification ; recevoir du deuxième système un message contenant une indication du rejet de la modification, ou une deuxième description de la modification ; si le message reçu du deuxième système est un message de rejet, ou si la première et la deuxième description sont différentes, annuler la modification ; sinon, valider la modification.
Avantageusement, l’au moins un objet d’environnement ou de contexte comprend au moins un objet appartenant à un type d’objets choisi dans un groupe comprenant : une zone de texte ; un symbole informatif ; une surface fermée ; un pseudo point sur le plan de vol de référence ; un élément graphique ; une section de plan de vol distincte du plan de vol de référence.
Avantageusement, le premier système comprend au moins un système de gestion de vol, et dans lequel l’au moins une unité de calcul est configurée : à la réception d’une modification du plan de vol de référence par l’au moins un système de gestion de vol, afficher la modification et envoyer par l’au moins un port de communication, un message contenant une description du plan de vol de référence modifié ; si ladite modification de l’ensemble d’objets reçue par l’interface d’entrée est une modification du plan de vol, et est validée, l’envoyer au système de gestion de vol.
Avantageusement, l’au moins une unité de calcul est configurée, à la réception d’une modification de l’ensemble d’objets, pour : vérifier si ladite modification du plan de vol de référence implique une interaction entre le plan de vol de référence modifié et un autre objet de l’ensemble ; si la modification implique une interaction, créer un objet fonctionnel symbolisant l’interaction.
Avantageusement, l’au moins une unité de calcul est configurée pour : vérifier si la modification du plan de vol de référence implique le passage du plan de vol de référence modifié dans une surface fermée existante ou nouvelle ; si la modification implique le passage du plan de vol de référence modifié dans une surface fermée existante ou nouvelle, créer un pseudo point à l’entrée dudit plan de vol dans la surface fermée, et un pseudo-point à la sortie dudit plan de vol de la surface fermée.
Avantageusement, l’au moins une unité de calcul est configurée, à la réception d’une modification de l’ensemble d’objets, pour : vérifier si ladite modification implique une suppression de l’interaction entre le plan de vol de référence modifié et un autre objet de l’ensemble ; si la modification implique la suppression de l’interaction, supprimer un objet fonctionnel symbolisant l’interaction.
Avantageusement, l’au moins une unité de calcul est configurée, à la réception d’une modification de l’ensemble d’objets comprenant l’ajout ou la modification d’un objet d’environnement ou de contexte, pour : vérifier si ladite modification implique une interaction entre le plan de vol de référence et l’objet d’environnement ou de contexte ajouté ou modifié ; si la modification implique une interaction, créer un objet fonctionnel symbolisant l’interaction.
Avantageusement, l’objet d’environnement ou de contexte ajouté ou modifié est une surface fermée ajoutée ou modifiée, et l’au moins une unité de calcul est configurée pour : vérifier si la modification implique le passage du plan de vol de référence dans la surface fermée ajoutée ou modifiée ; si la modification implique le passage du plan de vol de référence dans la surface fermée ajoutée ou modifiée, créer un pseudo point à l’entrée dudit plan de vol dans la surface fermée ajoutée ou modifiée, et un pseudo-point à la sortie dudit plan de vol de la surface fermée ajoutée ou modifiée.
Avantageusement, l’au moins une unité de calcul est configurée, à la réception d’une modification de l’ensemble d’objets comprenant la suppression d’un objet d’environnement ou de contexte, pour : vérifier si ladite modification implique une suppression de l’interaction entre le plan de vol de référence et l’objet d’environnement ou de contexte supprimé ; si la modification implique la suppression de l’interaction, supprimer un objet fonctionnel symbolisant l’interaction. Avantageusement, l’au moins une unité de calcul est configurée pour effectuer un codage d’un objet préalablement à l’envoi d’un message, et effectuer un décodage d’un objet suite à la réception d’un message, le codage de l’objet comprenant : une section de code comprenant un code prédéfini définissant le type d’objet, et pour chacun des attributs de l’objet, un code prédéfini définissant le type de l’attribut ; une suite alphanumérique définissant, pour chacun des attributs, la valeur associée.
Avantageusement, dans lequel l’au moins une unité de calcul est configurée pour effectuer un codage d’une modification du plan de vol de référence préalablement à l’envoi d’un message, et effectuer un décodage d’une modification du plan de vol de référence suite à la réception d’un message, le codage de la modification de plan de vol de référence comprenant : une section de code comprenant un code prédéfini définissant une modification du plan de vol de référence, et pour chacune des fonctions de plan de vol modifiées, un code prédéfini définissant le type de fonction ; une suite alphanumérique définissant, les points de cheminement modifiés, et, pour chacune des fonctions, les valeurs de paramètres associées.
Avantageusement, la première et la deuxième modification de l’ensemble sont représentées respectivement en un premier et un deuxième codage d’un objet ou d’une modification du plan de vol de référence ; l’au moins une unité de calcul est configurée pour vérifier si les première et deuxième modifications sont identiques en vérifiant si les premier et deuxième codages sont identiques.
Avantageusement, le port de communication est configuré pour communiquer avec une pluralité de deuxièmes systèmes ; l’unité de calcul est configurée, à la réception, par le port de communication, du message indiquant la description de la modification, et en cas de validation, pour envoyer, par l’au moins un port de communication, à chacun des deuxièmes systèmes de ladite pluralité, le message contenant la deuxième description de la modification.
L’invention a également pour objet une méthode mise en oeuvre par ordinateur comprenant : la réception, par au moins un port de communication d’un premier système, configuré pour communiquer avec au moins un deuxième système, d’un message indiquant une première description d’une modification d’un ensemble d’objets comprenant un plan de vol de référence d’un aéronef et au moins un objet d’environnement ou de contexte ; l’affichage de ladite modification sur au moins un dispositif d’affichage du premier système ; la réception de la validation ou du rejet, par une interface d’entrée du premier système ; l’envoi, par l’au moins un port de communication, d’un message au deuxième système contenant : en cas de validation, une deuxième description de ladite modification ; sinon, une indication du rejet de la modification.
L’invention a également pour objet un programme d’ordinateur comprenant des instructions de code de programme enregistrées sur un support lisible par ordinateur, lesdites instructions de code de programme étant configurées pour : recevoir, par au moins un port de communication d’un premier système, configuré pour communiquer avec au moins un deuxième système, d’un message indiquant une première description d’une modification d’un ensemble d’objets comprenant un plan de vol de référence d’un aéronef et au moins un objet d’environnement ou de contexte ; afficher ladite modification sur au moins un dispositif d’affichage du premier système ; recevoir la validation ou du rejet, par une interface d’entrée du premier système ; envoyer, par l’au moins un port de communication, d’un message au deuxième système contenant : en cas de validation, une deuxième description de ladite modification ; sinon, une indication du rejet de la modification.
D’autres caractéristiques, détails et avantages de l’invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d’exemple et qui représentent, respectivement :
Figure 1 un exemple de deux systèmes collaborant sur un contexte de plan de vol interactif selon un ensemble de modes de réalisation de l’invention ;
Figure 2 un exemple d’une interface graphique selon un ensemble de modes de réalisation de l’invention ;
Figure 3 plusieurs exemples d’objets d’une interface graphique dans un ensemble de modes de réalisation de l’invention ;
Figure 4 un premier exemple de création d’objets dérivés, avant et après révision d’un plan de vol, dans un ensemble de modes de réalisation de l’invention ;
Figure 5 un deuxième exemple de création d’objets dérivés, avant et après révision d’un plan de vol, dans un ensemble de modes de réalisation de l’invention ; Figure 6 un exemple de création d’un objet dérivé fonction de plan de vol après insertion d’un objet original surface fermée, dans un ensemble de modes de réalisation de l’invention ; figure 7a un exemple de codage d’un objet, selon un ensemble de modes de réalisation de l’invention ;
Figure 7b un exemple de codage d’une révision de plan de vol, selon un ensemble de modes de réalisation de l’invention ;
Figure 8 une méthode d’application d’une modification sur un système sol, et de validation de la modification sur un système bord dans un ensemble de modes de réalisation de l’invention ;
Figure 9 une méthode d’application d’une modification sur un système bord, et de validation de la modification sur un système sol dans un ensemble de modes de réalisation de l’invention. Certains acronymes anglo-saxons couramment utilisés dans le domaine technique de la présente demande pourront être employés au cours de la description. Ces acronymes sont listés dans le tableau ci-dessous, avec notamment leur expression anglo-saxonne et leur signification ainsi que la définition des principaux termes du domaine technique dans lequel se situe l’invention.
La figure 1 représente un exemple de deux systèmes collaborant sur un plan de vol interactif selon un ensemble de modes de réalisation de l’invention.
Dans l’exemple de la figure 1 , le système 1000 est un système de bord d’un aéronef, et le système 1100 est un système de contrôle sol (CCS) des opérations aériennes. Ainsi, le système 1000 contrôle la trajectoire de l’aéronef, alors que le système 1100 interagit avec le système 1000, mais ne peut pas asservir directement la trajectoire de l’aéronef. Cependant, les systèmes 1000 et 1100 sont donnés à titre d’exemple uniquement. Selon d’autres modes de mise en oeuvre de l’invention, le système 1000 peut contrôler la trajectoire d’un aéronef à distance, il peut par exemple s’agir d’un système de contrôle d’un drone à distance. De même, le système 1000 peut interagir avec plusieurs systèmes, par exemple plusieurs CCS. Les systèmes de l’invention peuvent, de manière plus générale, être des systèmes permettant la visualisation à distance du plan de vol de l’aéronef, et l’interaction avec le premier système. Il peut par exemple s’agir de centres de contrôles d’opérations, par exemple des centres de contrôle de drones de surveillance maritime.
Ainsi, l’invention peut s’appliquer de manière plus générale à tout ensemble de systèmes comprenant un système apte à visualiser le contexte de plan de vol d’un aéronef, et piloter à partir du plan de vol, et au moins un système apte à visualiser le contexte de plan de vol et interagir avec le premier système sur ce contexte de plan de vol.
Le système 1000 peut par exemple être un système de bord d’un aéronef, comprenant une application de type EFB pouvant être par exemple une application de navigation et d’optimisation du vol ou FMS étendu ayant la capacité de s’interfacer avec l’avionique, par exemple un FMS.
Le système 1000 comprend au moins un dispositif d’affichage 1010 configuré pour afficher un premier ensemble d’éléments comprenant un plan de vol de référence de l’aéronef, et en fonction des circonstances de la mission, des objets du contexte du plan de vol.
Le dispositif d’affichage peut typiquement consister en un ou plusieurs écrans de l’aéronef. Ce dispositif affiche au moins un plan de vol de l’aéronef, mais aussi des objets pouvant influer sur le ou les plans de vol. Les objets peuvent notamment comprendre :
- des éléments de l’environnement du plan de vol ;
- des éléments de l’environnement, ou de contexte de l’aéronef.
Des éléments de l’environnement ou de contexte de l’aéronef peuvent ainsi être aussi bien des éléments de l’environnement physique de l’aéronef (par exemple, une montagne, zone de danger, waypoint, aéroport...), que des objets de contexte utilisés pour la communication entre le bord et le sol (il peut alors s’agir par exemple de zones de texte, de pseudo-points sur la trajectoire...). L’invention est plus généralement applicable à tout objet dont l’affichage peut présenter un intérêt dans le cadre d’échanges d’informations entre opérateurs en lien avec la navigation d’un aéronef.
Le premier système 1000 comprend également au moins une interface d’entrée 1020. Cette interface peut comprendre tout type d’interface apte à recevoir des données d’entrée de l’opérateur (dans cet exemple, du pilote de l’aéronef).
Le premier système 1000 comprend également au moins un port de communication 1030 apte à communiquer avec le système 1100. Le port de communication 1030 peut typiquement comprendre une antenne de communication radio VHF, HF ou SatCom, et, dans le cas où le système 1000 est un système de bord d’un aéronef communiquant avec le sol, la communication peut se faire par le protocole datalink. Le port de communication 1030 est donc apte à envoyer et recevoir des messages avec le système 1100.
Le système 1000 comprend enfin au moins une unité de calcul 1040. L’au moins une unité de calcul 1040 peut être n’importe quel type d’unité de calcul apte à effectuer des calculs informatiques. Par exemple, l’unité de calcul peut être un processeur configuré avec des instructions machines, un microprocesseur, un circuit intégré, un microcontrôleur, un circuit logique programmable, ou tout autre unité de calcul apte à être programmée pour effectuer des opérations de calcul. Le système 1100 peut être un système de contrôle des opérations aériennes au Sol (CCS), ou, de manière plus générale, un système permettant de visualiser et modifier à distance le contexte de plan de vol de l’aéronef. Le système 1100 peut ainsi exécuter une application de type OFP connectée à l’outil de génération de plan de vol de l’opérateur. Le système 1100 peut également être connecté à des applications et outils, comme ceux relatifs à la météo, aux informations de vol de l’espace aérien, afin d’intégrer de manière automatisée des éléments à porter à la connaissance du premier système.
Le système 1100 comprend au moins un dispositif d’affichage 1110 configuré pour afficher un ou plusieurs plans de vol et un ensemble d’objets associé à ce ou ces plans de vol. Le dispositif d’affichage 1110 peut typiquement comprendre un ou plusieurs écrans.
Le système 1100 comprend également au moins une interface d’entrée 1120, pouvant comprendre tout type d’interface d’entrée autorisant un opérateur à entrer des données : clavier, micro, souris, etc.
Le système 1100 comprend également au moins un port de communication 1130 apte à communiquer avec le système 1000. Le port de communication 1130 peut typiquement comprendre une antenne de communication radio, et, dans le cas où le système 1000 est un système de bord d’un aéronef communiquant avec le sol, la communication peut se faire par un protocole datalink. Le port de communication 1130 est donc apte à envoyer et recevoir des messages numériques avec le premier système 1000.
Selon différents modes de réalisation de l’invention, différents protocoles de liaison de données peuvent être utilisés. Notamment les protocoles datalink dits ACARS ou ATN peuvent être utilisés pour transmettre des données entre le système 1000 et le système 1100.
Le deuxième système 1100 comprend enfin au moins une unité de calcul 1140. L’au moins une unité de calcul 1140 peut être n’importe quel type d’unité de calcul apte à effectuer des calculs informatiques. Par exemple, l’unité de calcul peut être un processeur configuré avec des instructions machines, un microprocesseur, un circuit intégré, un microcontrôleur, un circuit logique programmable, ou tout autre unité de calcul apte à être programmée pour effectuer des opérations de calcul. L’un des objectifs de l’invention est de synchroniser, en temps réel, les premier et deuxième ensembles d’objets, afin de permettre aux opérateurs des différents systèmes de visualiser, en temps réel le même plan de vol et les mêmes objets, tout en effectuant un travail indépendant de traitement des ensembles d’objets.
A cet effet les systèmes 1000 et 1100 échangent des messages, via leurs ports de communication 1030, 1130. Afin de simplifier la figure 1 , les messages envoyés du système 1100 au système 1000 sont notés 1200, et les messages envoyés du système 1000 au système 1200 sont notés 1210. Bien que la figure 1 représente un unique message 1200, et un unique message 1210, l’invention peut être appliquée à des échanges de nombreux messages successifs entre le système 1000, et le système 1100.
Le plan de vol et les objets associés peuvent être crées et modifiés de différentes manières : un opérateur, au sol ou à bord, peut apporter des modifications, par exemple en proposant une modification du plan de vol, en ajoutant une zone de texte, ou en modifiant ou ajoutant un élément d’environnement, telle qu’une zone interdite. Une modification peut également être issue d’un système de gestion de vol modifiant le plan de vol.
En cas de modification d’un ensemble d’objets sur l’un des systèmes, un message décrivant la modification est envoyé à l’un au moins des autres systèmes.
Par exemple, si une modification du deuxième ensemble d’objets est effectuée au niveau du système 1100, un message 1200 décrivant la modification est envoyé par le système 1100 au système 1000. Inversement, si une modification est effectuée sur le premier ensemble d’objets côté bord, un message 1210 décrivant la modification est envoyé du système 1000 au système 1100. Dans un ensemble de modes de réalisation de l’invention, les messages sont codés grâce à un système de code permettant de définir les objets, leurs statuts et attributs et leurs modifications. Les messages peuvent ainsi être codés et décodés de manière transparente par les systèmes 1000, 1100. Un exemple de codage et décodage d’objets est fourni en figures 7a et 7b.
A la réception d’un message 1200, 1210 indiquant une modification de l’ensemble d’objets, l’au moins une unité de calcul 1040, 1140 est configurée 1040, 1041 pour générer l’affichage de la modification. Afin de bien mettre en évidence la modification, celle-ci peut être mise en évidence de différentes manières : surbrillance, couleur, clignotement, surbrillance, surlignage, pop-up, etc. Ceci permet à l’opérateur du système recevant le message de visualiser la modification. Il peut alors utiliser l’interface d’entrée 1020, 1120 pour valider ou refuser 1042, 1142 la modification.
Si la modification est acceptée, l’ensemble d’objets est mis à jour au niveau du (des) système(s) qui a (ont) reçu la modification, côté sol ou côté bord. Ensuite, l’au moins une unité de calcul 1040, 1140 renvoie vers l’autre (les autres) système(s) une mise à jour du plan de vol dynamique et des objets associés tels qu’effectivement mis en oeuvre.
Enfin, l’au moins une unité de calcul 1040, 1140 est configurée pour envoyer, par l’au moins un port de communication 1043, 1143, un message 1210, 1200 aux autres systèmes contenant :
- en cas de validation, ladite modification du plan de vol dynamique et des objets associés, afin d’assurer que le système émetteur et les systèmes receveurs ont un contexte de plan de vol identique et valider qu’il n’y a pas eu de corruption ;
- sinon, une indication du rejet de la modification.
Dans la demande, on appellera « plan de vol de référence modifié », le plan de vol de référence auquel la modification a été apportée, après acceptation. On pourra également désigner par le terme « plan de vol de référence non modifié » le plan de vol de référence, soit avant modification, soit dont la modification aura été refusée.
Ce procédé est assujetti aux droits de modification de chacun des systèmes. Par exemple, le système sol de contrôle des opérations aériennes CCS peut proposer des modifications vers le système bord que ce dernier peut accepter, refuser ou ajuster, l’inverse pouvant ne pas être autorisé. De même le système bord peut proposer des modifications vers le système sol CCS, par exemple le Contrôle Aérien (ATC) qui peut les accepter, refuser ou ajuster, l’inverse étant dans ce cas particulier possible.
Plus concrètement, si une modification du plan de vol, ou d’un autre des objets affichés, est effectuée sur l’un des systèmes mettant en oeuvre l’invention, cette modification est envoyée aux autres systèmes. L’opérateur de chacun des systèmes bord (ou sol dans le cas de l’ATC) peut alors accepter ou refuser la modification. En cas d’acceptation d’une partie ou de l’ensemble d’objets, ces derniers sont modifiés dans le système récepteur, et un message de réponse détaillant la modification telle que réalisée par le système récepteur est renvoyée. Le système envoyeur peut alors vérifier si la modification effectuée par le système est bien identique à la modification envoyée. Si c’est le cas, la modification est acceptée dans le statut de l’objet considéré.
Ainsi, l’invention permet de synchroniser la représentation du plan de vol et des objets environnants entre le système 1000 et le système 1200. En effet, des modifications effectuées d’un côté sont propagées de l’autre. Ceci permet de créer un espace de travail collaboratif, dans lequel les différents opérateurs, par exemple un pilote et un contrôleur des opérations aériennes, peuvent interagir en temps réel. On parle alors de contexte de plan de vol dynamique déterministe, car le plan de vol et son contexte sont partagés dynamiquement entre l’ensemble des systèmes collaborant au plan de vol. Il est par ailleurs déterministe au sens où il est non interprétable.
De plus, lorsqu’un message est envoyé d’un système à l’autre avec une modification, un message de réponse est renvoyé avec un statut indiquant soit le rejet de la modification, soit, lorsque la modification est acceptée, un renvoi de la même modification, ou de modifications subséquentes. Ainsi, l’envoyeur d’une modification peut vérifier si la modification a été appliquée à l’identique, ou a impliqué des modifications subséquentes.
Toutes ces caractéristiques permettent de fiabiliser et sécuriser les communications entre les différents opérateurs, en particulier entre le sol et le bord des aéronefs.
Ceci permet aussi une interaction en temps réel entre les différents opérateurs.
La latence des communications se trouve également réduite. En effet, le temps de validation d’un plan de vol à la fois par le sol et le bord est considérablement réduit par rapport aux procédures existantes : les pilotes et contrôleurs aériens n’ont par exemple pas besoin de communiquer par le biais de messages vocaux.
L’invention permet également de garantir une meilleure sécurité aérienne, car les différents opérateurs disposent en permanence, et en temps réel, d’informations à jour. Si l’invention est, de manière générale, présentée dans le cadre d’une communication entre un aéronef et un centre de contrôle opérationnel, elle est également applicable à de nombreux autres cas, tels que la communication entre un aéronef et plusieurs autres centres de contrôle opérationnels voire tours de contrôle, ou la communication entre plusieurs centres de contrôle d’un drone.
Dans un ensemble de modes de réalisation de l’invention, le premier système 1000 comprend au moins un système de gestion de vol 1050. Si le premier système est un système de bord d’un aéronef, le système de gestion de vol peut typiquement être un FMS. Si le premier système 1000 est un système de contrôle d’un drone à distance, le système de gestion de vol 1050 peut être un système de calcul de trajectoire du drone à partir du plan de vol, au sol ou à bord. Dans tous les cas, le système de gestion de vol 1050 est apte à vérifier la capacité de l’aéronef à suivre un plan de vol, notamment au vu de ses performances aérodynamiques, à calculer une trajectoire à partir du plan de vol, et à asservir l’aéronef sur la trajectoire, par exemple en envoyant des instructions à un pilote automatique ou AFCS.
L’au moins une unité de calcul 1040 peut interagir de manière bidirectionnelle avec le système de gestion de vol 1050, pour envoyer ou recevoir des modifications du plan de vol.
Dans un ensemble de modes de réalisation de l’invention, une modification du plan de vol peut être initiée par le système de gestion de vol 1050. Elle est alors transmise à l’au moins une unité de calcul 1040, et intégrée dans l’interface graphique. Dans un ensemble de modes de réalisation de l’invention, une modification du plan de vol initiée par l’avionique n’a pas besoin d’être validée par l’opérateur du système 1000 : elle peut être directement transmise au système 1100.
Inversement, les modifications du plan de vol dans l’interface collaborative peuvent être envoyées à l’avionique, dès qu’elles sont validées à la fois au niveau du système 1000 et du système 1100, ou manuellement sur requête de l’opérateur du système 1000.
Ceci permet de s’assurer que le plan de vol collaboratif affiché sur l’interface collaborative est bien consistant avec le plan de vol utilisé par l’avionique, et de modifier dynamiquement le plan de vol depuis chacun des systèmes implémentant l’invention. Ceci permet également de prendre en compte les modifications du plan de vol issues de l’avionique.
La figure 2 représente un exemple d’une interface graphique dans un mode de réalisation de l’invention.
L’interface graphique 200 peut être utilisée aussi bien par le premier système 1000, que par le deuxième système 1100. Elle représente l’ensemble des objets de l’espace de travail.
Dans l’exemple de la figure 2, l’ensemble des objets dans l’environnement du plan de vol 210, défini notamment par les points de cheminement 211 , 212, et 213, comprend :
- des zones définies le long du plan de vol : o une zone de prédiction d’interruption de service GPS 220 ; o une zone de prédiction de turbulences 221 ;
- des modifications du plan de vol, ou informations définies sur le plan de vol : o un changement de vitesse 230 (passage à Mach 79) ; o une création ou un changement d’offset (décalage latéral) de trajectoire à un point 231 , o une montée vers un nouveau FL à un point 213; o un point de non-retour vers l’aérodrome de départ 240 ; o un point équidistant ou équi-temps entre les aérodromes de départ et d’arrivée 241 ;
- des informations définies en dehors du plan de vol : o une localisation de zone dangereuse 250 ; o une localisation de zone interdite 251 ; o une mise en valeur d’un aérodrome de dégagement 252. o Une section de plan de vol inactive n’appartenant pas au plan de vol actif De manière générale, lorsque les dernières modifications sont validées par chacun des systèmes, la même interface graphique s’affiche sur chacun des systèmes, et permet à chacun des opérateurs de disposer d’une même vue du plan de vol modifié et de son environnement pour cette mission. En effet, les opérateurs au sol peuvent voir plusieurs missions mais pour une mission donnée, le plan de vol et l’interface sont les même que ceux du vol en question. Ceci permet ainsi une interaction plus fluide entre les différents opérateurs, notamment entre les pilotes et les opérateurs au sol.
L’interface graphique 200 peut être exécutée, sous la forme d’un module spécifique, par les unités de calcul 1040, 1140 peuvent exécuter, en lien avec les dispositifs d’affichage 1010, 1110, et les interfaces d’entrée 1020, 1120 respectivement.
De nombreuses actions peuvent être effectuées sur l’interface graphique. Par exemple, les opérateurs peuvent zoomer, décaler la vue, mais également interagir avec, notamment en modifiant le plan de vol, ajoutant des objets ou en validant des objets ajoutés par d’autres opérateurs.
L’interface graphique 200 permet la définition de caractéristiques des objets, et leur placement sur la carte. Elle permet également de visualiser leur insertion, et de les envoyer vers les autres systèmes utilisant l’interface partagée.
Chacun des objets peut être défini à l’aide d’une bibliothèque d’attributs, comprenant entre autres : un type, un label, un texte, et une fonction. La forme et la position d’un objet peuvent être définies de plusieurs manières. Par exemple, elles peuvent être définies graphiquement sur l’interface de mission, sous la forme d’une succession de points, ou en rentrant des paramètres sous forme textuelle.
La figure 3 représente plusieurs exemples d’objets d’une interface graphique dans un ensemble de modes de réalisation de l’invention.
Les objets échangés par les messages, peuvent, selon différents modes de mise en oeuvre de l’invention, appartenir aux différentes catégories.
Indépendamment des objets, on considère les révisions du plan de vol. Il peut s’agir de l’ajout ou la suppression d’un ou plusieurs points, de procédure(s), de section(s) de FPL. Ces révisions mettent à jour le plan de vol de manière dynamique. Par exemple, la révision 310 consiste en une instruction de révision du plan de vol de type « DirectTo » donnant instruction à l’aéronef de se rendre directement au point de cheminement WPT2, sans passer par le point de cheminement WPT1. Si cette modification est acceptée, le plan de vol initial 311 , comprenant le point de cheminement WPT 1 , puis le point de cheminement WPT2, devient le plan de vol 312, dans lequel l’aéronef se rend directement au point de cheminement WPT2, à partir d’un point de départ géographique (latitude/longitude) T-P qui est lui aussi partagé entre le sol et le bord. Ces révisions peuvent être issues d’applications de navigation ou du système de gestion de vol 1040 et peuvent comprendre : o des fonctions usuelles de navigation, telles que les fonctions Direct To, offset (décalage latéral), ajout, effacement de point(s), circuit d’attente, procédure(s)... ; o des mises à jour de parties de plans de vol.
Une révision du plan de vol peut être initiée par un opérateur sur l’une des interfaces 1020, 1120, ou par le système de gestion de vol 1040.
Dans un ensemble de modes de réalisation, les objets peuvent également appartenir à l’un des types suivants :
- une zone de texte ;
- un symbole informatif ;
- une surface fermée ;
- un pseudo point défini comme un autre type de point crée par l’opérateur ou le système pouvant être fixe ou mouvant le long du plan de vol, différent d’un point de cheminement fixe issu d’une base de données ;
- un élément graphique ;
- une section de plan de vol non reliée au plan de vol de référence.
De manière plus générale, tout objet graphique pouvant s’insérer dans une interface de navigation peut être utilisé par l’invention, qu’il soit de nature purement informative ou graphique (exemple : une zone de texte), ou qu’il contienne des informations susceptibles d’interagir avec le plan de vol de référence (exemple : une surface fermée représentant une zone de danger météorologique. Une révision de plan de vol est une fonction directement applicable dans la fonction de gestion de plan de vol au sens de l’état de l’art des fonctions de navigation d’un système de gestion de vol FMS, par exemple l’effacement d’un point, l’activation d’un Direct To, l’insertion d’un échelon vertical de montée...
Ces objets sont définis par un ensemble d’attributs pouvant notamment comprendre:
- un type : définit le type d’objets graphique : point, surface... ;
- une position : celle-ci peut être définie de différentes manières, par exemple par des coordonnées géographiques, ou une position relative sur le plan de vol ;
- un label ;
- un texte ;
- le cas échéant, une fonction définissant une interaction avec le plan de vol (par exemple, une zone traversée par le plan de vol génère une fonction comme un offset (décalage latéral).
Dans un ensemble de modes de réalisation de l’invention, un système peut être utilisé pour visualiser plusieurs plans de vol différents, de plusieurs aéronefs. Par exemple, un système de contrôle aérien peut afficher alternativement plusieurs plans de vols différents correspondant à différents aéronefs avec lesquels le contrôleur aérien peut communiquer.
Les objets à afficher peuvent être plus ou moins pertinents en fonction du plan de vol considéré : des objets peuvent être définis, de manière générale, à un emplacement quel que soit le plan de vol considéré. Par exemple, une surface fermée indiquant une tempête constitue un objet pertinent quel que soit le plan de vol ou l’aéronef considéré. On parlera alors d’objet universel, s’affichant quel que soit le plan de vol considéré du côté du CCS.
Au contraire certains objets ne sont pertinents que pour un plan de vol donné. Par exemple, un pseudo-point sur un plan de vol ne devra être affiché que pour un plan de vol considéré, et pas pour les autres aéronefs. On parle alors d’objet spécifique, associé à un plan de vol dynamique donné.
Dans un ensemble de modes de réalisation de l’invention, les objets universels sont affichés quel que soit le plan de vol étudié, et les objets spécifiques uniquement lorsque le plan de vol auquel il est associé est affiché. Ceci permet par exemple à un opérateur du centre de contrôle opérationnel de changer de plan de vol pour collaborer avec différents aéronefs, tout en disposant d’un ensemble d’objets universels visibles en permanence.
Un objet de type « zone de texte » peut placer un texte fournissant une indication aux autres opérateurs. Par exemple, un texte « NO ENTRY FL 200 FL 400 » indique qu’une zone est interdite de vol entre les FL 200 et 400.
Les objets de type symbole peuvent être définis à partir d’une bibliothèque de symboles commune aux différents systèmes, chaque symbole étant défini par un identifiant dans la bibliothèque. Par exemple, le symbole 320 représente des ondes orographiques (ou « mountain waves » en anglais) et peut être inséré par l’un des opérateurs à tout endroit de la zone de travail pouvant être associé à une zone géographique. L’utilisation d’une base commune de symboles permet d’ajouter de manière interactive des symboles immédiatement compréhensibles par tous les opérateurs, ce qui permet une interaction encore plus fluide entre les différents opérateurs.
Des zones fermées peuvent être définies par un ensemble de positions géographiques définissant une forme géométrique, délimitée par un contour, un remplissage répondant à un critère associé à l’objet et un label. Par exemple, l’espace hachuré de la zone 330 définit un danger météorologique.
Un objet de type « mise en valeur » définit une figure géométrique disposée autour d’un objet de l’interface. Cette figure peut notamment être définie par une forme, une couleur et une épaisseur, afin de mettre en valeur un élément représenté sur l’interface. Par exemple, les objets 340 et 341 mettent respectivement en valeur les points de cheminement « SIROD », et un aéroport « LSTR », afin de signifier que l’aéroport LSTR est un aéroport préféré en diversion.
Un objet de type « section de plan de vol » représente un ensemble de points et/ou d’éléments de plan de vol indépendants du plan de vol dynamique. Par exemple, la section de plan de vol 350 définit une section de plan de vol entre les points de cheminement WPTA, WPTB, et l’aéroport ARPTI.
Un objet de type « pseudo point » représente un pseudo point du plan de vol, c’est-à- dire un point sur le plan de vol n’impliquant pas de modification ou de révision de celui-ci. Par exemple, il peut s’agir d’un point informatif. Par exemple, le pseudo-point 360, associé au label « PNR » (Point de Non-Retour), indique un point du plan de vol à partir duquel l’aéronef ne peut plus faire demi-tour pour rejoindre l’aérodrome de départ avec le carburant minimum à bord.
La figure 4 représente un premier exemple de création d’objets dérivés, avant et après révision d’un plan de vol, dans un ensemble de modes de réalisation de l’invention.
Dans un ensemble de modes de réalisation de l’invention, l’interaction de certains objets avec le plan de vol dynamique induit la création d’autres objets, que l’on pourra appeler objets dérivés.
Ainsi, à la réception d’une modification de l’ensemble d’objets, l’au moins une unité de calcul est configurée pour :
- vérifier si ladite modification implique une interaction entre le plan de vol et un autre objet de l’ensemble ;
- si la modification implique une interaction, créer un objet symbolisant l’interaction. Ce nouvel objet est un objet dérivé.
Inversement, si la modification des objets implique la suppression d’une interaction avec le plan de vol, les objets dérivés correspondants peuvent être supprimés. A cet effet, chaque système selon l’invention peut tenir en permanence à jour une liste d’objets originaux, et d’objets dérivés, et ajouter ou supprimer de manière itérative des objets dérivés, lorsque les modifications des objets originaux impliquent la création ou la suppression d’une interaction avec le plan de vol.
Ceci permet de repérer automatiquement les points d’intérêts liés à l’interaction entre le plan de vol et son environnement.
Ceci peut se faire, soit lorsqu’un opérateur modifie les objets. Les objets dérivés sont alors créés localement, puis envoyés aux autres systèmes en même temps que la modification initiale.
Dans un ensemble de modes de réalisation de l’invention, lorsque des objets originaux sont créés sur un système bord, ou de manière plus générale sur un système comprenant une interface avec l’avionique, d’éventuelles modifications des objets dérivés sont calculées, puis l’ensemble des modifications (sur les objets originaux, et sur les objets dérivés) sont envoyées aux systèmes sol.
Ceci peut également se faire à la réception d’un message indiquant une modification effectuée sur un système émetteur. Dans ce cas, les modifications sur les objets dérivées sont effectuées, et un message de retour est envoyé au système émetteur, avec l’ensemble des changements appliqués, sur les objets originaux et les objets dérivés.
Dans un ensemble de modes de réalisation de l’invention, lorsque des objets originaux sont créés sur un système sol, ou plus généralement sur un système non avionique, les objets dérivés des plans de vol non affichés dans le système sol ne sont pas créés ; seuls les objets originaux et les objets dérivés (issus de l’interaction avec un ou des plans de vol) sont créés. Les objets originaux sont alors envoyés vers le système bord, qui les prendra en compte pour générer les objets dérivés.
Dans un ensemble de modes de réalisation de l’invention, une interaction entre le plan de vol et les autres objets consiste à placer ou supprimer des pseudo-points lorsque le plan de vol entre ou sort d’une surface fermée. L’ajout ou la suppression des pseudo-points peut survenir, soit lorsqu’une surface fermée est ajoutée ou supprimée, soit lorsque le plan de vol est modifié. Les pseudo-points peuvent être associés à des fonctions de plan de vol dépendant de la signification de la surface fermée. La figure 6 fournit un exemple d’une telle association.
Ceci permet de repérer l’entrée et la sortie de l’aéronef de zones particulières. Par exemple, si la zone fermée représente une zone de turbulences, l’entrée et la sortie de l’aéronef des turbulences peuvent être automatiquement représentées.
D’autres types d’objets dérivés sont utilisables, selon différents modes de réalisation de l’invention. Par exemple, l’interaction entre le plan de vol et une surface ou un volume peut générer la production et la modification d’objets tels que des volumes 4D, variant dans le temps. Par exemple, ces volumes peuvent représenter la pénétration de l’aéronef dans une zone de danger.
Dans l’exemple de la figure 4, le plan de vol 410 comprend initialement les points 420, 421 et 422. Deux surfaces fermées 430, 440 sont définies dans l’environnement du plan de vol. Initialement, le plan de vol travers la surface 440, en y entrant au pseudo-point 441 , et en en sortant au pseudo-point 442. Le plan de vol est ensuite modifié en un plan de vol 411 , en supprimant le point de cheminement 421 : l’aéronef va alors directement du point 420 au point 422. Il ne traverse alors plus la zone 440, mais la zone 430 : les pseudo-points 441 et 442 sont supprimés, mais les pseudo-points 431 et 432 sont ajoutés, respectivement à l’entrée et la sortie de l’aéronef de la surface fermée 430.
La figure 5 représente un deuxième exemple de création d’objets dérivés, avant et après révision d’un plan de vol, dans un ensemble de modes de réalisation de l’invention.
Dans cet exemple, le plan de vol 510 est constitué des points de cheminement 520, 521 et 522, et traverse la zone fermée 530. Des objets dérivés sont ainsi présents : les pseudo-points 540 et 541 , représentant respectivement l’entrée et la sortie de la surface fermée 530.
Ensuite, le plan de vol 510 est modifié en un plan de vol 511 : le point de cheminement 521 est remplacé par le point 523. Le plan de vol traverse alors toujours la surface 530, mais les points d’entrée et de sortie sont modifiés. En conséquence, les pseudo-points 540 et 541 sont supprimés, et remplacés par les pseudo-points 542 et 543 respectivement situés à la nouvelle entrée dans la zone 530, et à la nouvelle sortie de la zone.
La figure 6 représente un exemple de création d’un objet dérivé fonction de plan de vol après insertion d’un objet original surface fermée, dans un ensemble de modes de réalisation de l’invention.
Dans cet exemple, une surface fermée 620 est ajoutée côté sol, délimitant une zone de navigation en offset (décalage latéral) de distance à 5 miles nautiques à droite du plan de vol 600. Cette surface est traversée par le plan de vol. Après ajout côté sol, la surface est envoyée au système bord.
Le système bord vérifie alors si l’interaction entre la surface et le plan de vol induit la création d’objets dérivés. Dans cet exemple, la réponse est positive, et deux points de cheminement 630 et 631 sont ajoutés sur le plan de vol, respectivement à l’entrée du plan de vol dans la surface, et à la sortie du plan de vol de la surface. Ces points de cheminement sont associés respectivement à une fonction de début et de fin de vol en offset (décalage latéral) de 5 miles nautiques.
Cet exemple est donné à titre d’exemple non limitatif uniquement et, de manière générale, l’interaction d’une surface avec un plan de vol pour engendrer la création de points de cheminement sur le plan de vol, associé à une fonction dépendant de la signification de la surface fermée.
Les figures 7a et 7b représentent respectivement un exemple de codage d’un objet, et un exemple de codage d’une révision de plan de vol, selon un ensemble de modes de réalisation de l’invention.
Afin de pouvoir communiquer de manière déterministe les objets, et modifications des objets, les unités de calcul 1040, 1140 sont configurées pour coder les objets ajoutés ou modifiés avant l’envoi d’un message, et décoder, de manière symétrique, l’objet à la réception d’un message en vue de son inclusion. Le codage des ajouts ou modifications peut prendre différentes formes. Par exemple, un label peut être attribué aux objets ajoutés et/ou modifiés. Une estampille temporelle peut également être insérée, correspondant à la dernière modification de l’objet.
Dans l’exemple de la figure 7a, un objet 710a est défini par un ou plusieurs attributs, pouvant être par exemple choisis parmi les attributs suivants : type, position, label, texte, fonction. L’objet 710a peut par exemple être un objet de contexte ou d’environnement.
Dans un ensemble de modes de réalisation, le codage de l’objet est basé sur une liste de codes prédéfinis définissant les différents types d’objets et d’attributs, et consiste à représenter l’objet de la manière suivante :
- tout d’abord un code prédéfini représentant le type d’objets, puis, pour chaque attribut présent pour l’objet, un code prédéfini représentant chaque type d’attribut. Ces ensembles de codes représentent une section de code 721a. Cette section peut également comprendre un identifiant d’objet choisi parmi des identifiant d’un objet parmi tableau 730a d’objets déjà ajoutés dans l’interface. Ceci permet de détecter que le codage définit une modification d’un objet déjà présent, et non l’ajout d’un nouvel objet ; - ensuite, une suite alphanumérique de caractères 722a définit, pour chaque attribut, la valeur associée.
Par exemple, un objet pourra être représenté comme ci-dessous :
- chaque type d’objet est codé sous formée alphanumérique. Par exemple, un objet de type « zone » sera représenté par l’attribut « Z », un objet de type « Mountain wave » par l’attribut « M » ;
- chaque type d’objet est associé à un ensemble d’attributs prédéfinis. Par exemple les attributs d’une zone Z seront une série de positions définies sous formes de latitude et de longitudes ;
- une suite de caractères alphanumériques est insérée pour chacun des attributs, par exemple une suite de caractères représentant les latitudes et les longitudes successives pour un objet de type zone.
A la réception d’un message, l’opération inverse peut être effectuée : tout d’abord la section de code 721a est décodée, ce qui permet de déterminer quel est le type d’objet décodé, et quels attributs sont présents. Ensuite, la suite alphanumérique 722a est lue afin de fournir une valeur à chacun des attributs.
Cette convention permet d’échanger des messages définissant les objets de manière déterministe : les créations et modifications d’objets peuvent être codées et décodées de manière transparente par les différents systèmes. Ce codage des objets permet donc une interopérabilité dans la gestion des objets entre les différents systèmes. Cependant, elle est donnée à titre d’exemple non limitatif uniquement, et n’importe quelle convention permettant de coder et décoder les objets peut être utilisée selon différents modes de réalisation de l’invention.
Dans un ensemble de modes de réalisation de l’invention, chaque type d’attribut est associé à une suite de caractères alphanumériques de longueur prédéfinie. Par exemple, les coordonnées géographiques des objets peuvent être définies par une suite de caractères d’une longueur donnée représentant leur latitude et leur longitude.
Ceci permet, une fois les types d’attributs utilisés par l’objet définis dans la section de code 721a, de ne stocker dans le codage de l’objet que les caractères alphanumériques nécessaires aux attributs effectivement utilisés par l’objet. Ceci permet donc de coder les objets de manière compacte, et donc d’économiser de la bande passante lors des échanges de messages.
Le codage des objets selon différents modes de réalisation de l’invention peut être combiné au codage, normalisé, des points de cheminement. Par exemple, le code normalisé d’un point de cheminement peut être inséré dans le code de l’objet échangé entre les interfaces selon l’invention.
Dans tous les cas, l’inclusion de caractères alphanumériques uniquement pour les attributs modifiés permet un codage compact et une économie de bande passante pour la communication entre les systèmes distants.
Le même principe est appliqué aux modifications de plan de vol qui peuvent être codées et décodées grâce à un codage partagé entre les différents systèmes utilisant l’invention.
Un exemple de codage de modifications de plan de vol est présenté en figure 7b. Ici encore, il ne s’agit que d’un exemple non limitatif, et tout type de codage permettant un codage et un décodage déterministe de modifications de plan de vol peut être utilisé selon différents modes de réalisation de l’invention.
Une modification du plan de vol 710b peut être définie par un ou plusieurs points de cheminement, et une ou plusieurs fonctions de plan de vol. Les fonctions peuvent être par exemple des trajectoires issues de fonctions spécifiques du système bord, telles que la trajectoire en offset (décalage latéral).
Un codage 720b des modifications du plan de vol peut comprendre :
- une section de code 721 b comprenant : o un code prédéfinit définissant qu’il s’agit d’une modification de plan de vol ; o pour chacune des fonctions de la modification, un code prédéfini définissant le type de fonction. Lorsqu’une fonction est modifiée, son identifiant peut être indiqué, parmi un tableau 730b des fonctions du plan de vol ; - une suite alphanumérique 722b définissant les coordonnées de chaque point de cheminement, et les paramètres des fonctions ajoutées.
Un exemple de codage d’une modification de plan de vol : Fonction « Direct To » (aller vers) vers le point de cheminement ABCDE. Le « Direct To » est codé « D », la suite définissant le codage fonctionnel est D ABCDE.
Comme pour les objets, cette convention permet d’échanger les modifications du plan de vol, de manière transparente entre les différents systèmes utilisant une interface partagée.
De plus, la suite alphanumérique ne contient que les valeurs de paramètres correspondant au codage des points de cheminement et fonctions effectivement présents dans la modification. Cette convention permet donc un codage compact des modifications du plan de vol, et des économies de bande passante.
Par ailleurs, le codage des objets, et modifications de plan de vol permet une validation efficace de l’intégrité des modifications.
En effet, comme expliqué plus haut, à la réception d’une modification de l’ensemble d’objets, le système récepteur applique la modification, la présente à un opérateur, et, si celui-ci approuve la modification, recode la modification, telle qu’appliquée au système récepteur, pour la renvoyer au système émetteur. Il suffit alors au système émetteur de comparer les codes de la modification envoyée, et de la modification reçue, pour vérifier l’intégrité de la modification côté récepteur : si les codes sont identiques, la modification aura bien été appliquée à l’identique côté récepteur.
Ce mécanisme de codes fournit donc une méthode simple et efficace permettant de valider l’intégrité des modifications auprès de tous les systèmes impliqués, et de s’assurer que les modifications sont correctement synchronisées par les différents systèmes.
La figure 8 représente une méthode d’application d’une modification sur un système sol, et de validation de la modification sur un système bord dans un ensemble de modes de réalisation de l’invention. Dans cet exemple, une modification d’un ensemble d’objets d’une interface est effectuée par un contrôleur aérien dans le système 1100, et envoyée au système 1000. Cependant, cette méthode est donnée à titre d’exemple non limitatif uniquement : certaines étapes ne sont utilisées que pour certains modes de réalisation de l’invention.
De plus, la mise en oeuvre par les systèmes 1000 et 1100 est donnée à titre d’exemple uniquement. De manière plus générale, cette méthode peut être mise en oeuvre entre un système ayant uniquement accès à l’interface partagée, et un système ayant accès à un système de gestion de vol. De même, le pilote et le contrôleur aérien peuvent être remplacés par d’autres opérateurs, tels qu’un pilote de drone à distance.
Les figures 8 et 9 montrent respectivement des exemples de création d’objets côté sol et côté bord. En effet, bien que l’interaction côté sol et côté bord présente un grand nombre de caractéristiques symétriques, dans un ensemble de modes de réalisation de l’invention, certaines différences sont présentes. Par exemple, les modifications côté bord peuvent être considérées comme prioritaires par rapport aux modifications côté sol. Ainsi, certaines modifications côté bord ne requièrent pas de validation côté sol. De même, l’interaction avec l’avionique se fait côté bord. Ces principes peuvent également, de manière plus générale, être applicables à une interaction entre un système ayant accès uniquement à l’interface, et un système ayant accès à un système de gestion de vol.
Enfin, les figures 8 et 9 sont présentées, pour des raisons de simplicité, pour l’interaction entre deux systèmes. Cependant, il s’agit là d’un mode de réalisation non limitatif : l’invention est applicable à des interactions entre plus de deux systèmes sur la même interface partagée : il suffit dans ce cas d’envoyer les modifications à l’ensemble des systèmes, et d’étendre la notion de validation au retour de l’ensemble des systèmes, une modification étant considérée comme définitivement adoptée que lorsqu’elle est validée par l’ensemble des systèmes.
Les étapes de la méthode 8000 peuvent notamment être exécutées par les unités de calcul 1040, 1140.
Dans une première étape 8010, le contrôleur aérien effectue une modification de l’ensemble d’objets de l’interface, tel que représenté par le système 1100. Cette modification peut par exemple consister en la création d’un objet, la modification ou la suppression d’un objet existant, ou une modification du plan de vol. La modification est notamment effectuée par les entrées 1120, en lien avec l’affichage 1110.
Dans l’exemple de l’interface 200, la modification peut par exemple consister en une modification du plan de vol 210, la suppression ou la modification d’un des objets originaux de l’interface (par exemple un des objets 220, 221 , 240, 241 , 250, 251), ou l’ajout d’un nouvel objet.
La méthode peut comprendre une étape intermédiaire d’affichage de la modification dans le système 1100, de validation de la modification telle qu’affichée par le contrôleur aérien, et de commande de l’envoi.
Ensuite, dans une étape 8020 la modification est codée, par exemple selon les principes discutés en référence aux figures 7a et 7b.
A l’étape 8030 la modification est envoyée au système 1000.
A l’étape 8040 la modification est reçue par le système 1000 et décodée.
A l’étape 8050 la modification est affichée par le système 1000, pour être vue par le pilote.
Le pilote peut alors valider ou rejeter la modification, notamment via l’au moins une interface d’entrée 1020. A l’étape 8060 le retour (validation ou rejet du pilote) est reçu.
A l’étape 8070 le type de retour est testé.
En cas de rejet, un message de rejet 8080 est envoyé du système 1000 au système 1100. Lorsque ce message est reçu par le système 1100, la modification est annulée à l’étape 8090 dans le système 1100, qui revient donc à l’état antérieur.
Sinon, si le pilote a validé la modification, à l’étape 8100 l’impact de la modification sur les objets dérivés est vérifiée, par exemple sur le modèle expliqué en référence aux figures 4 et 5 : si, suite à la modification, des objets dérivés doivent être créés, modifiés ou supprimés, ces modifications sont évaluées et affichées à l’étape 8100.
A l’étape 8110 la modification, telle qu’appliquée dans le système 1000, est recodée. Cette étape 8110 de recodage comprend donc le codage de la modification reçue, telle qu’effectivement appliquée au niveau du système 1000, et si applicable, un codage des modifications des objets dérivés.
Dans d’autres modes de réalisation de l’invention, les modifications des objets dérivés sont calculées, codées et envoyées ultérieurement.
A l’étape 8120 le recodage de la modification est envoyé au système 1100.
A l’étape 8130 le recodage est reçu par le système 1100.
A l’étape 8140 le système 1100 vérifie que le recodage (hors modifications des objets dérivés) est identique au codage initial, effectué à l’étape 8020).
Si les codages ne sont pas identiques 8150, cela signifie qu’une erreur est survenue, et que la modification n’a pas été adoptée à l’identique par le système 100.
La modification est alors annulée à l’étape 8160. Ceci permet de s’assurer que les modifications sont bien appliquées à l’identique sur les différents systèmes, et donc de fiabiliser l’interaction entre les systèmes. Cette étape 8160 peut notamment comprendre une notification du contrôleur aérien que la modification est annulée, et l’annulation de l’affichage. Elle peut également comprendre l’envoi d’un message au système 1000, pour que celui-ci annule également la modification de son côté.
Le contrôleur aérien, peut alors, s’il le souhaite, ré-effectuer une modification, et la méthode 8000 est exécutée à nouveau, avec une nouvelle modification.
Si les codages sont bien identiques, un message de validation 8170 est envoyé au système 1000. Les systèmes sont bien synchronisés, et la modification devient alors définitive.
A l’étape 8180 le système 1000 vérifie si les modifications ont un impact sur le plan de vol. C’est par exemple le cas si la modification envoyée est une modification du plan de vol collaboratif, ou si certains objets impactent le plan de vol, comme dans l’exemple de la figure 6.
Si un impact sur le plan de vol existe, celui-ci est affiché au pilote à l’étape 8190.
A l’étape 8200, la validation du pilote est reçue. Dans le cas où le pilote rejette les modifications du plan de vol impliquées par la modification, celle-ci est annulée. Un message est envoyé au système 1100 pour informer le contrôler aérien, et annuler la modification côté système 1100. Après validation du pilote, la modification du plan de vol est envoyée à l’étape 8210 au système de gestion de vol 1050.
Dans le cas où le système de gestion de vol rejette la modification, par exemple si elle n’est pas compatible avec les performances aérodynamiques de l’aéronef, la modification est annulée, à la fois dans le système 1000 et 1100.
Dans le cas où la modification du plan de vol est acceptée par le système de gestion de vol 1050, mais implique de nouvelles modifications, celles-ci sont reçues par l’interface collaborative, comme expliqué par exemple en figure 9.
La figure 9 représente une méthode d’application d’une modification sur un système bord, et de validation de la modification sur un système sol dans un ensemble de modes de réalisation de l’invention.
Dans cet exemple, une modification d’un ensemble d’objets d’une interface est effectuée dans le système 1000, soit par action du pilote, soit par réception d’une modification de plan de vol par le système de gestion de vol 1050, et envoyée au système 1000. Cependant, cette méthode est donnée à titre d’exemple non limitatif uniquement : certaines étapes ne sont utilisées que pour certains modes de réalisation de l’invention.
De plus, la mise en oeuvre par les systèmes 1000 et 1100 est donnée à titre d’exemple uniquement. De manière plus générale, cette méthode peut être mise en oeuvre entre un système ayant uniquement accès à l’interface partagée, et un système ayant accès à un système de gestion de vol. De même, le pilote et le contrôleur aérien peuvent être remplacés par d’autres opérateurs, tels qu’un pilote de drone à distance.
Les étapes de la méthode 9000 peuvent notamment être exécutées par les unités de calcul 1040, 1140.
Dans une première étape 9010, est reçue en entrée une modification de l’ensemble d’objets de l’interface, tel que représenté par le système 1000. Cette modification peut par exemple consister en la création d’un objet, la modification ou la suppression d’un objet existant, ou une modification du plan de vol.
La modification peut notamment être initiée par : - le pilote, qui les entre par les entrées 1020, en lien avec l’affichage 1010 ;
- le système de gestion de vol 1050, qui initie une modification du plan de vol. Si cette modification est validée par le pilote, la modification est reçue en entrée de la méthode 9000.
Dans l’exemple de l’interface 200, la modification peut par exemple consister en une modification du plan de vol 210, la suppression ou la modification d’un des objets originaux de l’interface (par exemple un des objets 220, 221 , 240, 241 , 250, 251), ou l’ajout d’un nouvel objet.
Si, suite à la modification, des objets dérivés doivent être créés, modifiés ou supprimés, ces modifications sont évaluées et affichées à l’étape 9020. Le pilote peut alors, dans un ensemble de modes de réalisation de l’invention, accepter ou refuser les modifications. S’il refuse, la modification est annulée.
Dans les cas où la modification n’est pas issue du système de gestion de vol 1050, mais implique une modification de celui-ci, et où le pilote accepte les modifications, la modification du plan de vol est envoyée au système de gestion de vol 1050.
Dans le cas où le système de gestion de vol rejette la modification, par exemple si elle n’est pas compatible avec les performances aérodynamiques de l’aéronef, la modification est annulée.
Dans le cas où la modification du plan de vol est acceptée par le système de gestion de vol 1050, mais implique de nouvelles modifications, celles-ci sont reçues par l’interface collaborative, en tant que modification additionnelles, et affichées au pilote, qui peut les accepter ou les refuser.
A l’étape 9040, la validation du pilote est reçue, pour l’ensemble des modifications.
Ensuite, dans une étape 9050 la modification ou les modifications (modification initiale, modifications des objets dérivés, modifications du plan de vol suite à l’envoi FMS) sont codées, par exemple selon les principes discutés en référence aux figures 7a et 7b.
A l’étape 9060 l’ensemble des modifications est envoyé au système 1100. A l’étape 9070 l’ensemble des modifications est reçu par le système 1100. A l’étape 9080 les modifications sont affichées par le système 1100, pour être vue par le contrôleur aérien.
Selon différents modes de réalisation de l’invention, le contrôleur aérien doit valider ou non les modifications. Par exemple, le contrôleur aérien peut devoir valider toutes les modifications. Au contraire, les modifications envoyées par le bord peuvent toutes être automatiquement appliquées au sol, sans validation du contrôleur aérien. Enfin, seuls certains types de modifications (par exemple, les modifications du plan de vol), peuvent être soumises à validation par le contrôleur aérien.
Si la modification est sujette à validation de la part du contrôleur aérien, celui-ci peut valider ou rejeter la modification, notamment via les entrées 1120. A l’étape 9090 le retour (validation ou rejet du contrôleur aérien) est reçu. Les étapes subséquentes 9100, 9110, 9120 ne sont également activées que si la modification est sujette à validation du contrôleur aérien.
A l’étape 9100 le type de retour est testé.
En cas de rejet, un message de rejet 9110 est envoyé du système 1100 au système 1000. Lorsque ce message est reçu par le système 1000, les modifications sont annulées à l’étape 9120 dans le système 1000, qui revient donc à l’état antérieur.
Sinon, si le contrôleur aérien valide les modifications, ou si celles- ci ne sont pas sujettes à validation, à l’étape 9130 les modifications, telle qu’appliquées dans le système 1100, sont recodées. Cette étape 9130 de recodage comprend donc le codage des modifications reçues, telle qu’effectivement appliquée au niveau du système 1100.
Dans d’autres modes de réalisation de l’invention, les modifications des objets dérivés sont calculées, codées et envoyées ultérieurement.
A l’étape 9140 le recodage de la modification est envoyé au système 1000.
A l’étape 9150 le recodage est reçu par le système 1000.
A l’étape 9160 le système 1000 vérifie que le recodage est identique au codage initial, effectué à l’étape 9050.
Si les codages ne sont pas identiques 9170, cela signifie qu’une erreur est survenue, et que la modification n’a pas été adoptée à l’identique par le système 100. Les modifications sont alors annulées à l’étape 9180. Ceci permet de s’assurer que les modifications sont bien appliquées à l’identique sur les différents systèmes, et donc de fiabiliser l’interaction entre les systèmes. Cette étape 9180 peut notamment comprendre une notification du pilote que les modifications sont annulées, et l’annulation de l’affichage. Elle peut également comprendre l’envoi d’un message au système 1100, pour que celui-ci annule également la modification de son côté.
Le pilote, peut alors, s’il le souhaite, ré-effectuer une modification, et la méthode 9000 est exécutée à nouveau, avec une nouvelle modification.
Alternativement, le codage des modifications peut être à nouveau envoyé au système 1100, sans annulation des modifications.
Si les codages sont bien identiques, un message de validation 9190 est envoyé au système 1100. A l’étape 9200 le message 9190 est reçu par le système 1100. Les systèmes sont bien synchronisés, et la modification devient définitive.
Comme la méthode 8000, la méthode 9000 démontre la capacité de l’invention à permettre à plusieurs systèmes de travailler, de manière collaborative, sur des plans de vol, tout en s’assurant que les modifications apportées de part et d’autres sont bien synchronisées entre les différents systèmes.
Pour des raisons de simplicité, les exemples fournis ont trait à des échanges entre deux systèmes. De manière plus générale, l’invention est applicable à des échanges entre plus de deux systèmes. Selon un ensemble de modes de réalisation de l’invention, un système peut par exemple « centraliser » les opérations. Dans ce cas, les modifications des objets de l’interface collaborative sont propagées depuis le système central vers les autres, et les exemples développés ci-dessus peuvent être généralisés. Par exemple, si une modification est effectuée sur le système central, elle sera propagée aux autres systèmes, et pourra être annulée si l’un au moins des autres systèmes rejette la modification. Si une modification est reçue par le système central, et validée par celui-ci, un message comprenant la modification pourra être envoyé aux autres systèmes. Ceci permet de déployer l’interface collaborative à plus de deux systèmes.
Les exemples ci-dessus démontrent la capacité de l’invention à mettre en oeuvre une interface de travail et un plan de vol collaboratifs entre différents systèmes. Ils ne sont cependant donnés qu’à titre d’exemple et ne limitent en aucun cas la portée de l’invention, définie dans les revendications ci-dessous.

Claims

REVENDICATIONS
1 . Un premier système (1000, 1100) comprenant :
- au moins un dispositif d’affichage (1010, 1110) configuré pour afficher un ensemble d’objets comprenant un plan de vol de référence de l’aéronef et au moins un objet d’environnement ou de contexte ;
- au moins une interface d’entrée (1020, 1120) ;
- au moins un port de communication (1030, 1130) configuré pour communiquer avec au moins un deuxième système (1100, 1000) ;
- au moins une unité de calcul (1040, 1140) configurée, à la réception, par le port de communication (1030, 1130) d’un message (1200, 1210) indiquant une première description d’une modification dudit ensemble, pour : o générer l’affichage (1041 , 1141 ) de la modification ; o recevoir une validation ou un rejet (1042, 1142) de la modification par l’interface d’entrée (1020, 1120) ; o envoyer (1043, 1143), par l’au moins un port de communication, un message (1210, 1200) au deuxième système contenant :
■ en cas de validation, une deuxième description de ladite modification ; sinon, une indication du rejet de la modification.
2. Le premier système de la revendication 1 , dans lequel l’au moins une unité de calcul (1040, 1140) est configurée, à la réception d’une modification de l’ensemble d’objets par l’interface d’entrée (1020, 1120), pour : générer l’affichage de la modification ; - envoyer (1053, 1153), par l’au moins un port de communication, un message (1210, 1200) au deuxième système contenant une première description de la modification ;
- recevoir du deuxième système un message contenant une indication du rejet de la modification, ou une deuxième description de la modification ;
- si le message reçu du deuxième système est un message de rejet, ou si la première et la deuxième description sont différentes, annuler la modification ; sinon, valider la modification.
3. Système selon l’une des revendications 1 à 2, dans lequel l’au moins un objet d’environnement ou de contexte comprend au moins un objet appartenant à un type d’objets choisi dans un groupe comprenant :
- une zone de texte ;
- un symbole informatif ;
- une surface fermée ;
- un pseudo point sur le plan de vol de référence ;
- un élément graphique ;
- une section de plan de vol distincte du plan de vol de référence.
4. Le premier système (1000) de l’une des revendications 1 à 3, comprenant au moins un système de gestion de vol (1050), et dans lequel l’au moins une unité de calcul (1040) est configurée :
- à la réception d’une modification du plan de vol de référence par l’au moins un système de gestion de vol, afficher la modification et envoyer par l’au moins un port de communication, un message contenant une description du plan de vol de référence modifié ; - si ladite modification de l’ensemble d’objets reçue par l’interface d’entrée (1020) est une modification du plan de vol, et est validée, l’envoyer au système de gestion de vol (1050).
5. Système selon la revendication 4, dans lequel l’au moins une unité de calcul (1040, 1140) est configurée, à la réception d’une modification de l’ensemble d’objets, pour :
- vérifier si ladite modification du plan de vol de référence implique une interaction entre le plan de vol de référence modifié et un autre objet de l’ensemble ;
- si la modification implique une interaction, créer un objet fonctionnel symbolisant l’interaction.
6. Système selon la revendication 5, dans lequel l’au moins une unité de calcul (1040, 1041) est configurée pour :
- vérifier si la modification du plan de vol de référence implique le passage du plan de vol de référence modifié dans une surface fermée existante ou nouvelle (430, 440, 530) ;
- si la modification implique le passage du plan de vol de référence modifié dans une surface fermée existante ou nouvelle, créer un pseudo point à l’entrée dudit plan de vol dans la surface fermée (431, 441 , 540, 542), et un pseudo-point à la sortie dudit plan de vol de la surface fermée (432, 442, 541 , 543).
7. Système selon l’une des revendications 5 ou 6 dans lequel l’au moins une unité de calcul (1040, 1140) est configurée, à la réception d’une modification de l’ensemble d’objets, pour : vérifier si ladite modification implique une suppression de l’interaction entre le plan de vol de référence modifié et un autre objet de l’ensemble ; si la modification implique la suppression de l’interaction, supprimer un objet fonctionnel symbolisant l’interaction.
8. Système selon l’une des revendications 1 à 7, dans lequel l’au moins une unité de calcul (1040, 1140) est configurée, à la réception d’une modification de l’ensemble d’objets comprenant l’ajout ou la modification d’un objet d’environnement ou de contexte, pour :
- vérifier si ladite modification implique une interaction entre le plan de vol de référence et l’objet d’environnement ou de contexte ajouté ou modifié ;
- si la modification implique une interaction, créer un objet fonctionnel symbolisant l’interaction.
9. Système selon la revendication 8, dans lequel l’objet d’environnement ou de contexte ajouté ou modifié est une surface fermée ajoutée ou modifiée (620), et l’au moins une unité de calcul (1040, 1041 ) est configurée pour :
- vérifier si la modification implique le passage du plan de vol de référence dans la surface fermée ajoutée ou modifiée (620) ;
- si la modification implique le passage du plan de vol de référence dans la surface fermée ajoutée ou modifiée, créer un pseudo point (630) à l’entrée dudit plan de vol dans la surface fermée ajoutée ou modifiée (620), et un pseudo-point (631 ) à la sortie dudit plan de vol de la surface fermée ajoutée ou modifiée (620).
10. Système selon l’une des revendications 8 ou 9 dans lequel l’au moins une unité de calcul (1040, 1140) est configurée, à la réception d’une modification de l’ensemble d’objets comprenant la suppression d’un objet d’environnement ou de contexte, pour : - vérifier si ladite modification implique une suppression de l’interaction entre le plan de vol de référence et l’objet d’environnement ou de contexte supprimé ;
- si la modification implique la suppression de l’interaction, supprimer un objet fonctionnel symbolisant l’interaction.
11 . Système selon l’une des revendications 1 à 10, dans lequel l’au moins une unité de calcul (1040, 1140) est configurée pour effectuer un codage (720a) d’un objet préalablement à l’envoi d’un message, et effectuer un décodage d’un objet suite à la réception d’un message, le codage de l’objet comprenant :
- Une section de code (721 a) comprenant un code prédéfini définissant le type d’objet, et pour chacun des attributs de l’objet, un code prédéfini définissant le type de l’attribut ;
- une suite alphanumérique (722a) définissant, pour chacun des attributs, la valeur associée.
12. Système selon l’une des revendications 1 à 11 , dans lequel l’au moins une unité de calcul (1040, 1140) est configurée pour effectuer un codage (720b) d’une modification du plan de vol de référence préalablement à l’envoi d’un message, et effectuer un décodage d’une modification du plan de vol de référence suite à la réception d’un message, le codage de la modification de plan de vol de référence comprenant :
- une section de code (721 b) comprenant un code prédéfini définissant une modification du plan de vol de référence, et pour chacune des fonctions de plan de vol modifiées, un code prédéfini définissant le type de fonction ;
- une suite alphanumérique (722b) définissant, les points de cheminement modifiés, et, pour chacune des fonctions, les valeurs de paramètres associées.
13. Système selon l’une des revendications 11 ou 12, dépendant de la revendication 2, dans lequel :
- la première et la deuxième modification de l’ensemble sont représentées respectivement en un premier et un deuxième codage d’un objet ou d’une modification du plan de vol de référence ;
- l’au moins une unité de calcul (1040, 1140) est configurée pour vérifier si les première et deuxième modifications sont identiques en vérifiant si les premier et deuxième codages sont identiques.
14. Système selon l’une des revendications 1 à 13, dans lequel :
- le port de communication est configuré pour communiquer avec une pluralité de deuxièmes systèmes ;
- l’unité de calcul est configurée, à la réception, par le port de communication, du message indiquant la description de la modification, et en cas de validation, pour envoyer, par l’au moins un port de communication, à chacun des deuxièmes systèmes de ladite pluralité, le message contenant la deuxième description de la modification.
15. Méthode mise en oeuvre par ordinateur comprenant :
- la réception (8040, 9070), par au moins un port de communication d’un premier système (1000, 1100), configuré pour communiquer avec au moins un deuxième système (1100, 1000), d’un message (1200, 1210) indiquant une première description d’une modification d’un ensemble d’objets comprenant un plan de vol de référence d’un aéronef et au moins un objet d’environnement ou de contexte ;
- l’affichage (8050, 9080) de ladite modification sur au moins un dispositif d’affichage (1010, 1110) du premier système ;
- la réception de la validation ou du rejet (8060, 9090), par une interface d’entrée (1020, 1120) du premier système ; - l’envoi (8120, 9140), par l’au moins un port de communication, d’un message (1210, 1200) au deuxième système contenant : o en cas de validation, une deuxième description de ladite modification ; o sinon, une indication du rejet de la modification.
16. Produit programme d’ordinateur comprenant des instructions de code de programme enregistrées sur un support lisible par ordinateur, lesdites instructions de code de programme étant configurées pour :
- recevoir (8040, 9070), par au moins un port de communication d’un premier système (1000, 1100), configuré pour communiquer avec au moins un deuxième système (1100, 1000), d’un message (1200, 1210) indiquant une première description d’une modification d’un ensemble d’objets comprenant un plan de vol de référence d’un aéronef et au moins un objet d’environnement ou de contexte ;
- afficher (8050, 9080) ladite modification sur au moins un dispositif d’affichage (1010, 1110) du premier système ;
- recevoir la validation ou du rejet (8060, 9090), par une interface d’entrée (1020, 1120) du premier système ;
- envoyer (8120, 9140), par l’au moins un port de communication, d’un message (1210, 1200) au deuxième système contenant : o en cas de validation, une deuxième description de ladite modification ; o sinon, une indication du rejet de la modification ; lorsque ledit programme fonctionne sur un ordinateur.
EP20793409.2A 2019-11-14 2020-10-27 Espace collaboratif de gestion de contexte de plan de vol Pending EP4058959A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1912712A FR3103300B1 (fr) 2019-11-14 2019-11-14 Espace collaboratif de gestion de contexte de plan de vol
PCT/EP2020/080126 WO2021094081A1 (fr) 2019-11-14 2020-10-27 Espace collaboratif de gestion de contexte de plan de vol

Publications (1)

Publication Number Publication Date
EP4058959A1 true EP4058959A1 (fr) 2022-09-21

Family

ID=70613834

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20793409.2A Pending EP4058959A1 (fr) 2019-11-14 2020-10-27 Espace collaboratif de gestion de contexte de plan de vol

Country Status (4)

Country Link
US (1) US12609037B2 (fr)
EP (1) EP4058959A1 (fr)
FR (1) FR3103300B1 (fr)
WO (1) WO2021094081A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110322161A (zh) * 2019-07-10 2019-10-11 中国民航信息网络股份有限公司 航班生效批次的生效调整方法及装置
US12125393B2 (en) * 2022-01-05 2024-10-22 Honeywell International Inc. Systems and methods to corroborate an externally recommended flight plan change with flight management system
US12609039B2 (en) 2024-03-20 2026-04-21 Reliable Robotics Corporation System and method for modifying validated routes for an aircraft

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9691287B1 (en) * 2013-09-26 2017-06-27 Rockwell Collins, Inc. Graphical method to set vertical and lateral flight management system constraints

Also Published As

Publication number Publication date
WO2021094081A1 (fr) 2021-05-20
US12609037B2 (en) 2026-04-21
FR3103300B1 (fr) 2022-01-21
FR3103300A1 (fr) 2021-05-21
US20220406198A1 (en) 2022-12-22

Similar Documents

Publication Publication Date Title
FR3025920A1 (fr) Procede de calcul temps reel d'une trajectoire planifiee, notamment de plan de vol, combinant une mission, et systeme de gestion d'une telle trajectoire
FR3061342A1 (fr) Gestion des messages aux navigants aeriens
FR3027127A1 (fr) Interface tactile pour le systeme de gestion du vol d'un aeronef
EP2975361A1 (fr) Traitement des donnees d'un plan de vol
EP4058959A1 (fr) Espace collaboratif de gestion de contexte de plan de vol
EP2991274B1 (fr) Procédé d'exécution de services en temps réel adaptatif, notamment de gestion de vol et système temps réel mettant en oeuvre un tel procédé
FR2954841A1 (fr) Procede et dispositif de gestion centralise de taches a realiser par un equipage d'un aeronef en cours de vol
FR2940426A1 (fr) Dispositif d'assistance au choix d'un aeroport de deroutement
FR2954847A1 (fr) Systeme et procede de gestion centralisee d'informations de navigation
FR3021401A1 (fr) Reconfiguration de l'affichage d'un plan de vol pour le pilotage d'un aeronef
FR3048773A1 (fr) Procede et systeme de gestion d'un plan de vol multi-destination
FR3038750A1 (fr) Procede d'integration d'un nouveau service de navigation dans un systeme avionique embarque a architecture ouverte de type client-serveur, en particulier d'un service de manoeuvre fim
FR3074347A1 (fr) Systeme electronique de tele-pilotage de drones, procede de programme d'ordinateur associes
FR2935524A1 (fr) Dispositif et procede de surveillance de la localisation des aeronefs au sol
FR2939558A1 (fr) Procede de modelisation meteorologique pour le calcul d'un plan de vol d'aeronef
FR2991094A1 (fr) Dispositif de gestion de vol d'un aeronef adapte a la maitrise de contraintes de temps multiples et procede correspondant
CA3037319A1 (fr) Systeme d'etablissement de plan de vol operationnel d'aeronef et procede associe
FR3038751A1 (fr) Procede d'integration d'une application d'optimisation de route (s) sous contraintes dans un systeme embarque avionique a architecture ouverte de type client serveur
FR3030805A1 (fr) Qualite de service d'un systeme de gestion de vol
WO2021052853A1 (fr) Gestion de plans de vol par registres distribues
FR2913799A1 (fr) Procede de routage des clairances numeriques atc optimisant leur prise en compte a bord d'un aeronef
FR3108999A1 (fr) système DE SIMULATION EMBARQUE DE FONCTIONS AVIONIQUES
FR3034595A1 (fr) Procede et dispositif electronique de gestion, sous forme de sequences, de messages echanges entre un aeronef et une station au sol, produit programme d'ordinateur associe
FR3071092A1 (fr) Procede et systeme d'aide a la navigation d'un avion sur un aeroport
WO2021202545A1 (fr) Authentification hybride basée sur une chaîne de blocs

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

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

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220512

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20230223

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

Effective date: 20230427

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Free format text: PREVIOUS MAIN CLASS: G06Q0010100000

Ipc: G06Q0010101000

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

Free format text: STATUS: GRANT OF PATENT IS INTENDED

RIC1 Information provided on ipc code assigned before grant

Ipc: G06Q 10/101 20230101AFI20250822BHEP

Ipc: G08G 5/21 20250101ALI20250822BHEP

Ipc: G08G 5/22 20250101ALI20250822BHEP

Ipc: G08G 5/26 20250101ALI20250822BHEP

Ipc: G08G 5/34 20250101ALI20250822BHEP

Ipc: G08G 5/55 20250101ALI20250822BHEP

Ipc: G08G 5/59 20250101ALN20250822BHEP

INTG Intention to grant announced

Effective date: 20250905

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN