• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The invention relates to a method for managing avionic data between an FMS flight management system and one or more clients, the FMS comprising resources accessible through avionic services Ci (1, n); the execution of Ci (1, n) determining an avionic functionality Fj (1, m); each of Fj (1, m) being associated with an intrusivity parameter lk and a criticality parameter Ck; the method comprising the steps of receiving a request specifying the call to an Fj (1, m); and determining a predefined execution right of a Ci (1, n), a function of the predefined intrusiveness and / or criticality parameters associated with the Fj (1, m). Developments describe, in particular, the comparison of execution rights, the notification of a rejection, various avionics services and functions, the management of criticality ranges, the taking into account of the flight context, and so on. Aspects of software and system are described (e.g. EFB type equipment).
    公开号:FR3046273A1
    申请号:FR1502677
    申请日:2015-12-23
    公开日:2017-06-30
    发明作者:Julien Beernaert
    申请人:Thales SA；
    IPC主号:
    专利说明:

    OPEN ARCHITECTURE FOR FLIGHT MANAGEMENT SYSTEM
    Field of the Invention The invention lies in the technical field of embedded systems, and more particularly in the technical field of avionics systems of FMS type ("Flight Management System").
    State of the art
    In the field of avionics, architectures are usually defined statically.
    For example, when designing an FMS flight management system, each real-time avionics subsystem is architecture and developed to meet performance requirements (RAM, ROM, failure rate, CPU, etc.) and Quality of Service (QoS) functional) in a well-defined employment framework. The interactions between systems ("systemic interactions") are defined a priori during the development of the aircraft architecture, and the systems are generally developed and adjusted to meet the strict need for interaction as initially defined.
    When it is necessary to upgrade the architecture, the equipment whose functions must be modified must be "qualified" again, which entails high certification costs. The addition or modification of a "technical function" generates a very expensive requalification (it is necessary to prove again the performances of the global system, even when no "operational function" is modified). A recovery of the architecture and interfaces is usually required.
    These recoveries and requalification costs are currently hindering the evolution of avionics avionics systems. The scalability of the various systems is in fact limited in time, because the evolutions of a system (client or server) can not give rise to a questioning of all the connected systems for economic reasons. More broadly, these considerations affect the management of the development cycles of embedded hardware and software, the variability and standardization of components, and so on. Corrective rebounds can be expensive. Interconnection with new external avionics systems (in addition or in substitution and not directly compatible with previous ones) can lead to additional costs, systemic risks and the introduction of additional delays.
    In this general context, one of the technical problems to be solved consists in finding a way to organize the development of a flight management system architecture, in an efficient and economical way.
    Patent document FR2841999 entitled "ORIENTAL NETWORKING SYSTEM OBJECT OF EMBEDDED AERONAUTICAL EQUIPMENT" discloses a system for networking aeronautical equipment on board an aerodyne comprising, for each equipment, an object-oriented interface with means called object facade allowing it to apprehend the embedded equipment to which it is assigned, as an object, in the sense of object-oriented programming, capable of communicating with other objects in the sense of object-oriented programming according to a object-oriented client / server model and with so-called observer means identifying the events resulting from the operation of the on-board equipment. This object-oriented approach is interesting but has limitations.
    There is a need for flexible and scalable FMS flight management system architectures. SUMMARY OF THE INVENTION The invention relates to a method for managing avionic data between an FMS flight management system and one or more clients, the FMS comprising resources accessible through avionic services Ci (1, n); the execution of Ci (1, n) determining an avionic functionality Fj (1, m); each of Fj (1, m) being associated with an intrusivity parameter L and a criticality parameter C | <; the method comprising the steps of receiving a request specifying the call to an Fj (1, m); and determining a predefined execution right of a Ci (1, n), a function of the predefined intrusiveness and / or criticality parameters associated with the Fj (1, m). Developments describe, in particular, the comparison of execution rights, the notification of a rejection, various avionics services and functions, the management of criticality ranges, the taking into account of the flight context, and so on. Aspects of software and system are described (e.g. EFB type equipment).
    Advantageously, the invention takes advantage of advanced computer techniques. If the computer techniques on which the invention is based can be known individually, they are not in combination, and a fortiori in the technical field of avionics. In a superficial way, the transposition or adaptation of known computer techniques to the field of avionics may seem natural and not pose a major difficulty; in reality, it is not so. The context of application, in this case avionics, is very demanding. Many parameters influence the choice of the design of a computer architecture implemented in an aircraft. The constraints are in particular of a regulatory nature, that is at least indirectly of a technical nature, since the safety of an aircraft potentially carrying hundreds of passengers is a very complex technical matter. In avionics, F.M.S. flight management systems. ("Flight Management System") are certified by the F.A.A. ("Federal Aviation Administration"). If the regulatory requirements delimit the space of the possible techniques, they require to be interpreted technically speaking (this task in itself requires the exercise of an inventive step) and the technical possibilities "residual" remain very numerous. Peripheral developments around a regulated or certified avionics core frequently join the "problem invention" situation (a situation in which to pose the technical problem is the main inventive challenge). An erroneous analysis of the inventive step may also be carried out retrospectively. Even if computer techniques are transversal to many technical fields, the person skilled in avionics is not omniscient or omnipotent, that is to say on the initiative and / or capable of applying all of these techniques to his specific technical field of avionics. In conclusion, the inventiveness of the application of computer techniques, possibly known elsewhere, to the specific context of avionics must be considered with great care.
    Advantageously, the architecture described according to the invention makes it possible to reinforce the computer security of the avionics (in particular) and the safety of the flight of the aircraft (in general). In general, the invention makes it possible to finely control access to the critical functionalities of a flight management system. In particular, contemporary threats are taken into account (e.g. sabotage, partial takeover, other forms of piracy). The control of systemic risks is particular in terms of avionics and the architecture choices described here also meet, in addition to regulatory requirements, these security benefits.
    Advantageously and counter-intuitively, the method according to the invention does not consider the FMS flight management system certified as a "monolithic" system (in the sense of a rigid and / or non-modifiable system) but as a system which can be structured in such a way as to allow a certain granularity of access (certain imperatives notably related to certification or regulation will be respected while the identification of room for maneuver for other requirements will be exploited so as to allow added flexibility on the periphery of this "monolithic" system). Embodiments of the invention advantageously apply, that is, specifically and contextually, the approaches of considering a given system in an "atomic" or "object" manner.
    Advantageously, the classification of the functions of the flight management system according to their criticality and / or intrusiveness allows a configurable and flexible management.
    Advantageously, this layered organization ("decoupling", "segregation") makes it possible to reuse the functional and / or technical avionics capabilities offered by the functional core of the FMS flight management system to implement or implement new operational avionics functionalities, while limiting the adaptation effort required for the implementation of the new interaction model and / or the new input / output (I / O or I / O) protocols. The so-called "operational" functions (or data) of a system designate the functions (or data) of a system that render a "service" operational (eg concrete, tangible, measurable) in response to a request communicated to that system (whether the request comes from the pilot directly or indirectly, or from a third party system). The so-called "technical" functions (or data) are the functions (or data) that are necessary to perform one or more support functions, such as parameterization, configuration, supervision, observation and data injection. , or which are required for the installation, the configuration of the system, its startup, but also its debugging, its recipe or the analysis of the failures that it is in real conditions or simulated. The data or functions can be volatile (inputs and outputs) or nonvolatile (eg storage of configuration information, parameterization, etc.).
    Advantageously, the layered structure makes it possible to reuse the functional avionics capabilities and the technical avionic capabilities offered by the functional core of the system to achieve new operational avionics functionalities by limiting the adaptation effort to the implementation of the new interaction model. and / or new I / O protocols required in this framework. For example, the addition of a new avionics functionality consisting of being able to operate on existing system capabilities through a new remote means will have confined impacts "on the periphery" of the functional core. Moreover, since these new operational functions will not have, for some, the same level of criticality ("safety") as that of the functional avionics core, it is possible to apply a level of quality assurance of variable development. on the implementation of the new interaction model and / or the new protocols required in this context, for example by hosting it in its own partition (A653 for example), still without impact on the functional heart to the extent that can be reused existing functional or technical capabilities, and provided that access to these capabilities is open. In other words, an explicit and rigorous management of this segregation between the four different parts generally constituting the system according to the invention makes it possible to cancel the potential impacts on the functional core of changes relating to one or more components of the other three aspects. the system (interaction model, protocols, connected systems, information system, configuration and configuration, host platform).
    Advantageously, the method makes it possible to configure a quality of service ("QoS", acronym for Quality of Service) and to manage the access privileges of the customers, for example to optimize the recertification efforts of the functional core by equivalence class.
    Advantageously, the embodiments of the invention make it possible to ensure moreover the scalability of the different operational or technical functions, and this independently. In addition, changes to the functional core of the FMS flight management system are only introduced as a last resort and only when a new algorithmic capability is required.
    Advantageously, in a particular embodiment of the invention (embedded real-time environment), the subsystems can be associated with different levels of criticality. In this context, it is indeed advantageous to modify as little as possible the critical systems officiating as servers, given the costs and risks of degradation of said systems.
    Advantageously, the creation or management of a separate system for managing the technical functions makes it possible to adjust the processor load of the functional heart of the flight management system as well as possible.
    Advantageously, the creation or the management of a separate system for managing the technical functions makes it possible to minimize the recovery of the functional heart code of the flight management system, if appropriate.
    Advantageously, the embodiments of the invention improve the safety of the flight of the aircraft by filtering the intrusiveness of customers whose qualification level is low (and who for example may cause errors)
    Advantageously, the embodiments of the invention apply to the various functions of the onboard computer FMS. In ATA, "flight management" is part of the "navigation" and concerns ΓΑΤΑ 22 and ΓΑΤΑ 34. In the aeronautical sense, navigation systems provide services and functions of location, flight planning ("Flight Planning" ), the management of the flight path, the guidance of the aircraft (eg servo-control), the piloting of the aircraft as well as a variety of decision support systems or algorithms to optimize the mission (eg choice of the most suitable diversion airports, optimizations of the lateral or vertical trajectory to use the favorable winds, etc.).
    Advantageously, the modular architecture according to the invention can be extended: its constituent elements can be distributed in different avionic devices in order to optimize downstream development and certification efforts. Some embodiments of the invention allow for example the interconnection with other external systems (for example in addition to or replacement of existing equipment, which may not be directly compatible with the existing). Some embodiments of the invention allow the implementation of new models and protocols for interaction with the functional heart. Embodiments of the invention allow the introduction of new operational features.
    DESCRIPTION OF THE FIGURES Other characteristics and advantages of the invention will become apparent with the aid of the description which follows and the figures of the appended drawings in which:
    Figure 1 illustrates the overall technical environment of the invention;
    Figure 2 schematically illustrates the structure and functions of a known FMS flight management system;
    Figure 3 illustrates aspects of an embodiment of the invention;
    FIG. 4 schematizes examples of degrees of intrusiveness of various functionalities of the flight management system, derived from their degrees of criticality, according to one embodiment of the invention;
    FIG. 5 illustrates an embodiment with specific examples of rights of access to the different avionics functions of the FMS;
    FIG. 6 illustrates an example of classification of access rights by operational avionics functionalities;
    Figure 7 illustrates an example of classification of operational avionics functionalities according to their level of criticality (allocation of functions by criticality);
    Figure 8 shows an example of a correlation between criticality levels and access rights to avionics services;
    Figure 9 illustrates some aspects of an embodiment of the method according to the invention;
    Figure 10 illustrates an example of a dynamic process flow for a given architecture; and
    FIG. 11 illustrates examples of steps of the method according to the invention.
    DETAILED DESCRIPTION OF THE INVENTION The invention notably describes various embodiments of an open architecture. This open architecture is notably exposed through programming interfaces allowing access (in varying ways) to the avionics services of the certified and regulated flight management system.
    In one embodiment, the architecture comprises a flight management system according to the invention ("open" FMS) which comprises four interacting parts: a) a functional avionic core, ie a subset of system that implements the functional services and avionics services of the flight management system, b) an interaction model (and its variations) as well as protocols allowing an external operator to solicit the functional core, c) a system of information to manage the data or the connections and d) the hardware platform of execution of the various services.
    Figure 1 illustrates the overall technical environment of the invention. Avionics equipment or airport means 100 (for example a control tower in connection with the air traffic control systems) are in communication with an aircraft 110. An aircraft is a means of transport capable of evolving within the earth's atmosphere. . For example, an aircraft may be an airplane or a helicopter (or a drone.) The aircraft comprises a cockpit or a cockpit 120. Within the cockpit are 121 (so-called avionics equipment) flying equipment, comprising for example one or more on-board computers (calculation, storage and data storage means), including an FMS, display or data display and data acquisition means, communication means, as well as (possibly) haptic feedback means A tablet or EFB 122 (Electronic Flight Bag for Electronic Binder) may be on board, portable or integrated into the cockpit An EFB is sometimes referred to or described as a type of equipment. "(Open) world" as opposed to "avionics" type equipment (certified by the regulator), said EFB can interact (123) with avionics equipment 121. The EFB can also be in communication 124 with external computing resources, accessible by the network (for example cloud computing or "cloud computing" 125. In particular, calculations can be made locally on the EFB or partially or totally in the calculation means accessible by the network. The on-board equipment 121 is generally certified and regulated while the EFB 122 and the connected computer means 125 are generally not (or to a lesser extent). This architecture makes it possible to inject flexibility on the side of the EFB 122 while ensuring a controlled safety on the side of the onboard avionics 121.
    Figure 2 schematically illustrates the structure and avionics functions of a known FMS flight management system.
    The FMS is generally connected to many other computers (one hundred), which can also implement one or more steps of the method according to the invention (for example, the management of conditional access to granular avionic services can advantageously consolidate scattered avionics resources). In current architectures (regardless of the aircraft), the "Flight Planning" and "optimized trajectory" part is generally included in a dedicated computer called "FMS" for "Flight Management System" (or flight management computer). . These functions constitute the core business "Flight Management". This system can also host part of the "Location" and "Guidance".
    FIG. 2 represents an FMS with avionic functions of: - LOCNAV navigation, 170, to perform the optimal location of the aircraft according to the geolocation means (GPS, GALILEO, VHF radio beacons, inertial units); - FPLN flight plan, 110, to capture the geographical elements constituting the skeleton of the route to be followed (departure and arrival procedures, waypoints, airways); - Navigation database NAVDB 130, to build geographic routes and procedures from data included in the bases (points, tags, interception legacy or altitude ...); - Performance database, PRF DB 150, containing the aerodynamic and engine parameters of the aircraft. - Lateral trajectory TRAJ, 120: to build a continuous trajectory from the points of the flight plan, respecting the airplane performances and the confinement constraints (RNAV, RNP ...); PRED predictions, 140: to build an optimized vertical profile on the lateral trajectory; Guiding, GUID 200, to guide the aircraft in its 3D trajectory in the lateral and vertical planes, while optimizing the speed; - DATALINK digital data link, 180 to communicate with control centers and other aircraft. - Technical functions, 210 to manage the non-functional aspects of the FMS: observability, DUAL, fault recording, start-up, simulation mode, flight tests ... - Man-machine interface management (driver) HMI 220.
    The functions of the FMS flight management system can be classified into nine types of functions (F1 to F9). In the example that is illustrated, the function F1 (Human Machine Interface) is implemented in block 220 (HMI). The function F2 corresponds to the automatic guidance of the aircraft and is implemented in block 200 (GUIDANCE). Function F3, which corresponds to the monitoring and monitoring of the flight and the trajectory, is implemented in block 110 (FPLN), 120 (TRAJ) and 140 (PRED). Function F4, which corresponds to the relationship with air traffic and operational control centers, is implemented in block 180 (DATALINK). The F5 function, which corresponds to the tools for strategic decision support and flight optimization, is implemented in blocks 120 (TRAJ) and 140 (PRED). The function F6 corresponding to the flight simulation is implemented in block 210 (TECH FCT). Function F7, which corresponds to maintenance and operational conditioning, is implemented in block 210 (TECH FCT). The F8 function that corresponds to the ground &amp; flight is implemented in block 210 (TECH FCT). Function F9 which corresponds to fault analysis and flight recorder is implemented in block 210 (TECH FCT).
    Various embodiments of the invention are described below.
    There is disclosed an avionics data management method between an FMS flight management system and one or more clients of said FMS, the FMS flight management system comprising physical resources accessible through avionic services Ci (1, n); the execution of one or more avionic services Ci (1, n) determining an avionic functionality Fj (1, m); each avionic functionality Fj (1, m) being associated with an intrusivity parameter lk and a criticality parameter Ck; the method comprising the steps of receiving a request from a client, said request specifying the call to an avionic functionality Fj (1, m); and determining a parameter associated with a predefined execution right of an avionic service Ci (1, n), said parameter being a function of the predefined intrusiveness and / or criticality parameters associated with said avionic functionality Fj (1, m) )
    The intrusiveness and / or criticality parameters are associated with a functionality of the flight management system.
    The method according to the invention decouples the flight management system of the customers of this system. The "decoupling interface" is done by managing an intermediate layer between the FMS and the client, allowing or denying calls to computing resources.
    In one embodiment, resource access management is "binary": access is allowed or it is not.
    In one embodiment of the invention, access management governed by one or more priorities (predefined or dynamically defined).
    In one embodiment of the invention, the method allows active management of access to resources. Active management may include an inhibition mechanism (e.g., decreasing the associated priority, unfavorable weighting) and / or a promotion mechanism (e.g., increasing the associated priority, favorable weighting, etc.)
    According to one aspect of the invention, the definition and consideration of different abstraction layers allows optimized management of hardware and / or software resources. Hardware hardware resources are accessed by FMS unit codes, which define FMS "features". These features are called by one or more requests from one or more clients of the FMS flight management system.
    In a development, the method further comprises the step of comparing the determined execute right parameter with one or more predefined execution rights.
    The method comprises a step of determining an execution rights matrix Di of a service Ci by a function Fi as a function of the intrusiveness and / or criticality parameters. When a client commands the execution of a function destined for the digital core, the decoupling interface checks the execution rights
    In a development, the method further comprises a step of executing one or more avionics services and communicating the result to the customer.
    In a development, the method further includes the step of notifying the client of the rejection of his request.
    In a development, a avionics service corresponding to an avionics service selected from an avionics service providing access to the functional heart information system of the FMS, an avionics management or flight plan administration service, an avionics access service to the data of a flight plan or flight path of the aircraft.
    In a development, a criticality level is selected from a plurality of predefined criticality ranges.
    In one development, the plurality of criticality ranges comprising four predefined criticality ranges, which comprise a criticality level X1 strictly greater than the criticality level of the functional core FMS, the criticality level X2 equal to the criticality level of the functional core FMS, the level of criticality X3 strictly lower than the criticality level of the functional heart FMS and the level of criticality X4 much lower than the criticality level of the functional heart FMS.
    The definition of four classes of criticality proves to be advantageous in operational aeronautical practice. In other words, there is an optimum of four clients implementing interactions with external systems to achieve subsets of consistent avionics functionality per client, in terms of criticality, as well as in terms of access rights.
    In a development, an avionics functionality is selected from the avionics functionalities including a Human Machine Interface F1 functionality, an Automatic Aircraft Guidance F2 functionality, a Flight Monitoring and Monitoring and F3 trajectory functionality, a functionality Relation to Air Traffic and F4 Operational Control Centers, a F5 Flying Optimization or Flight Optimization Tool Functionality, F6 Flying Simulation Functionality, Maintenance and Conditioning Functionality F7 operational, a feature of Ground &amp; F8 flight, a feature of F9 Flight Analysis and Flight Recorder.
    In a development, an avionic functionality is accessed and / or executed by one or more user interfaces (or HMIs for "Human Machine Interface") according to a predefined interaction model. An avionics functionality advantageously uses an interaction model executing one or more interfaces (user or HMI in the broad sense) specifically called by an external operator and operating one or more avionic services of the functional core.
    An interaction model realizes a set of principles, rules and properties that govern the operation of a Human Machine Interface. An HMI may be for example a graphical interface, but not only. A HMI can combine different modes of restitution and sound, visual or other sensory interactions (touch, force feedback, Braille, even olfactory, etc.). An HMI can be 2D, 3D, with or without haptic feedback, etc.). An interaction model is usually predefined (that is, determined at the design of the interface). An interaction model generally corresponds to the generalization of a user interface; the various variations of the interaction model correspond in particular to predefined use contexts (ie specific succession of display screens, types of displayed symbols, specific priorities allocated to certain types of information, etc.), which can notably be depending on the flight context. The predefined avionic interaction model according to the invention is chosen from interaction models comprising a human-machine interaction model (generically) and / or an interaction model comprising the automatic guidance of the aircraft ( which may involve a specific interface) and / or on-board monitoring, an ATM-Airlines Operation Center interaction model and / or an interaction model called Simulation-Maintenance-Debugging-Failure Analysis (which corresponds to a specific context as indicated by his name).
    In a development, the intrusiveness and / or criticality parameters are configurable.
    Access rights are associated with each of these operational features. These rights allow or deny the family concerned the use of a subset of the capabilities and the manipulation of a subset of the functional core data. The family of membership of a connected system is configurable information (by the pilot and / or the company and / or a third party avionics system)
    In a development, one or more parameters of intrusiveness and / or criticality depend on the flight context.
    The flight context of the aircraft includes the phases of takeoff, climb, cruise, approach, descent, etc. Advantageously, taking into account the flight context to determine the intrusiveness and / or criticality of the accesses to the avionics core makes it possible to optimize their use and performance.
    The method according to the invention may comprise logical methods or steps making it possible to determine the "flight context" or "current flight context" of the aircraft.
    The flight context at a given moment integrates all the actions taken by the pilots (and in particular the actual steering instructions) and the influence of the external environment on the aircraft. A "flight context" includes, for example, a situation among predefined or pre-categorized situations associated with data such as position, flight phase, waypoints, current procedure (and others). For example, the aircraft can be in the approach phase for landing, in take-off phase, in cruise phase but also in ascending, descending, etc. (a variety of situations can be predefined). Moreover, the current "flight context" can be associated with a multitude of attributes or descriptive parameters (current weather condition, traffic status, pilot status including for example a level of stress as measured by sensors, etc. ).
    A flight context may therefore also include data, for example, filtered by priority and / or based on flight phase data, weather problems, avionics parameters, ATC negotiations, anomalies relating to the flight status, problems related to traffic and / or terrain. Examples of "flight context" include for example contexts such as "cruising / no turbulence / nominal pilot stress" or even "landing phase / turbulence / intense pilot stress". These contexts can be structured according to various models (e.g. hierarchical for example in tree or according to various dependencies, including graphs). Context categories can be defined, in order to synthesize the needs for human-machine interaction (e.g., minimum or maximum interaction delay, minimum and maximum word quantity, etc.). There may also be specific rules in some contexts, such as emergencies or critical situations. Context categories can be static or dynamic (e.g., configurable).
    The method may be implemented in a system comprising means for determining a flight context of the aircraft, said determining means including in particular logic rules, which manipulate values as measured by physical measurement means. In other words, the means for determining the "flight context" include system or "hardware" or physical / tangible means and / or logical means (e.g. logic rules, for example predefined). For example, the physical means include avionic instrumentation literally (radars, probes, etc.) that allow to establish factual measures characterizing the flight. Logic rules represent the set of information processes that interpret (e.g., contextualize) factual measures. Some values can correspond to several contexts and by correlation and / or calculation and / or simulation, it is possible to separate candidate "contexts" by means of these logical rules. A variety of technologies makes it possible to implement these logical rules (formal logic, fuzzy logic, intuitionistic logic, etc.)
    Different regulations of the system according to the invention are possible, in a supervised (for example controlled by an operator) or unsupervised (for example initially parameterized). In one embodiment, one or more learning mechanisms ("machine learning") can regulate access to the avionic core (for example by inhibiting or promoting certain interactions and / or clients). In some embodiments, access control to the FMS avionics core may include active / passive interaction schemes, voting mechanisms (between peers), and so on.
    A computer program product is disclosed, said computer program comprising code instructions for performing one or more of the method steps, when said program is run on a computer.
    There is disclosed a system comprising means for implementing the steps of the method.
    In a development, the system comprises an FMS flight management system and one or more clients of said FMS flight management system.
    In a development, the system comprises at least one electronic flight bag type EFB. Indeed, in a development of the invention, the system for implementing the method comprises at least one equipment of "open world" type. An open world equipment may be for example an electronic flight bag (EFB or tablet). This "open world" type equipment can also be physically outside the cockpit: for example, commercial staff can access certain services through the APIs according to the terms of the invention. In other embodiments, passengers may also access certain services (as well as ground services).
    Figure 3 illustrates aspects of an embodiment of the invention.
    There is disclosed a dialogue device between a flight management system "FMS OPEN" and at least one customer external to said flight management system, including a "decoupling interface" between the flight management system and the customer.
    An "open" FMS client 320 comprises at least one avionic functionality characterized by at least one intrusiveness parameter and a criticality parameter.
    The notion of "intrusion" testifies to a desire to reserve access to physical or logical resources to certain previously designated systems. The notion of intrusion also presupposes the crossing of one or more limits of a predefined system. The term "intrusiveness" refers to this term "intrusion", to which it associates a quantification (e.g., different gradations). In other words, it is not trusted a priori to the different third party systems connected to the flight management system. In one embodiment of the invention, any connected third party system is capable of compromising (or corrupting or causing any other type of failure or failure or overloading) of the avionic core. In one embodiment of the invention, full trust is given to any connected third party system. In intermediate embodiments, the trust granted to the connected third party system is variable; this trust and therefore the associated access rights may notably evolve over time ("time-driven") and / or according to events ("eiænt-driven")
    In mathematics, the value taken by a function at a critical point is called a critical value. A critical point serves as an intermediary for extremum search of a function. In computer science, a critical system is a system whose failure can have serious consequences, including major hardware failures or damage (with an impact on the safety of the aircraft's flight). The notion of "criticality" also introduces a quantification of this critical character by associating different "stages" or "stages" or "attributes" or "levels".
    According to the invention, advantageously in terms of risk management, the crossing of the levels of "criticality" and "intrusiveness" makes it possible to architect an avionics system for safety and improved safety.
    The flight management system ("open") 310 consists of an avionic digital core 311 ("functional heart"), a facade 312 ("OPEN API SERVER"), said facade comprising a list of typical avionics services , that is to say whose structure and functions are known. The decoupling interface 320 comprises an information system 321, a "model and interaction protocols" 322 and an execution platform 323.
    The information system 321 offers i) the storage mechanisms and storage location of the configuration information (general operating modes and options) and / or parameterization (non-volatile functional data), ii) the functional input and output data. / or at the output of the system (volatile functional data), iii) the type and / or the number of connected systems as well as the associated exchange protocols and iv) the physical format for the exchange of information (I / O) between the system or the different connected systems.
    The interaction model 322 and the protocols used by this external operator make it possible to request the operational functions of the system and the support functions (parameterization, downloading, observation, data injection). For example, the user interface may be implemented locally in the avionics system or accessible from another remote system. As a result, several user interfaces are possible simultaneously (or there may be several different instances of the same interface). The decoupling interface 322 calculates an execution rights matrix of an avionic service by a functionality based on the intrusiveness parameters and a criticality parameter. When a customer orders the execution of an avionics function to the digital core, the decoupling interface checks the execution rights. If the rights are granted, the decoupling interface controls the execution of the avionics services by said facade, and possibly notifies the client of the result. If the rights are not granted, the decoupling interface may notify the client of the rejection.
    The functional avionics core 311 implements functional and technical avionics capabilities that are stable, necessary, and sufficient for operational functionality. The functional avionics core of system 311 is the subset of the system that implements a) the functional avionics capabilities necessary to perform so-called "operational" functions (those that render a service operational to an external operator acting on the system, regardless of the process used to act on the system) and b) the avionics technical capabilities necessary to perform the support functions such as parameterization, configuration, supervision, observation and data injection, which are required for the operation of the system. installation, system configuration, startup, but also its debugging, recipe or failure analysis (whether in real or simulated conditions).
    Execution platform 323 includes aspects of hardware (instructions, cache management, physical addressing of memory and I / O resources) and aspects of software (operating system, input / output drivers, logical addressing, etc. ).
    In one embodiment, the method uses an exposure of the functional avionics core 311 of the FMS through one or more APIs 3121 accessible from an API server 312.
    In computer science, a programming interface (often referred to as the API for "Application Programming Interface") is a standardized set of classes, methods, functions, datatypes, and constants that serves as a facade by which software offers services to other software. A programming interface is typically provided by a software library or web service, most often accompanied by a description that specifies how consumer programs can use the features of the provider program. An API can be "private", that is to say intended for a use of computer development carried out internally. An API can be "open" or "public" ("open API" in English): the specifications of the interface can be published i.e. accessible to the public and in particular to third-party developers.
    For the purposes of the invention, an "open API" corresponds to the (at least partial) exposure of a (concrete) avionics function and / or (theoretical) avionics functionality, in the particularly specific context of the avionics, regulated sector ie whose services are certified. In other words, an open API according to the invention is described, accessed, executed and possibly protected in very specific ways and specific to the avionics sector.
    According to the invention, an API (programming interface) for access to the functional core of the FMS can be defined with regard to the functional and technical capabilities of the FMS rather than with regard to the operating mode and operational scenarios.
    In one embodiment, the capabilities of the functional heart FMS are exposed through one or more explicit APIs (i.e., documented, eg, published) and usable by third-party clients.
    According to the embodiments, the documentation or description of the programming interfaces is more or less complete, in a manner specific to the avionics sector. In other words, in some embodiments, the description of the avionics services is complete and exhaustive. In other embodiments, the description or the documentation is only partial (certain unpublished or intentionally encrypted commands make it possible to obtain certain information from the FMS, for example particularly critical information). In one embodiment, the description of the avionics services is available upon request. In one embodiment, the complete description of an avionics service is encrypted, that is to say that the existence of documentation is apparent but that access to its content requires a prior shared secret. In one embodiment, the description and / or existence of a avionics service is concealed (like steganography).
    Regarding the access to the programming interfaces of the avionic services, the permissions or restrictions of access to the different APIs can be specific. Access to a given avionics service can be configurable, for example in terms of tariff, quantity of calls (volumes), quality of service (e.g. priorities). In one embodiment, the accesses can be "free", unlimited in volume and without access restrictions. In other situations, access to certain functions of the FMS may be limited (quantity, quality) by access restrictions (access control, keys, encryption, absolute and / or relative priorities). Some embodiments of the invention may combine the use of "public" type APIs (eg, published) with the use of "private" type APIs (eg certain privileges or privileges may be reserved for internal development or selected aeronautical partners).
    In particular, the life cycle of an API can lead to various developments (e.g. the stability of some APIs can be guaranteed while others may be deprecated "deprecated API").
    In one embodiment, at least one API is open and accessible from another partition or another computer, to ensure the distribution of the different components of the FMS application, including the parts dealing with the information system and the different processes. interaction with the functional heart. In other words, the redundancy management specific to avionics (dual system, triplication, voting mechanism) can be combined with the management of access rights.
    According to the embodiments, different subsets of the functional and technical capabilities of the FMS core can be exposed to the clients through the "APIs" as defined above.
    These functional and technical capabilities of avionics nature include: - Access to the functional heart information system (C1a), namely a) the system configuration data (modes and options of operation), b) the data of parameterization (navigation database, ...), c) the input characteristic data as well as the data and reports consolidated by the functional core. - Access to flight plan data (C1b), 3D trajectory and associated predictions for all flight plans handled by the functional core; - Flight plan administration services (C2a), for example the creation, deletion, replication of flight plans; - Flight plan editing services (C2b), in varying degrees of granularity, from a point of waypoint flight plan to a set of flight plan points such as a navigation procedure or a company route "
    FIG. 4 schematizes examples of degrees of intrusiveness of various functionalities of the flight management system, derived from their degrees of criticality, according to one embodiment of the invention.
    The perimeter of the avionics functionalities of an FMS can vary during the life of the same aircraft. These avionics functionalities involve several connected systems as well as the properties of these connected systems (interface, communication protocol, interaction model). A fortiori, the avionics functionalities of the FMS evolve from one generation of aircraft to another. These functionalities have a specific level of criticality (safety) and require levels of intrusiveness in the functional core that are sometimes very different.
    In one embodiment, the variability of the various functionalities (existing or future) of the functional heart is "confined". The functional heart is then "unique" and "reusable" (which allows significant economies of scale). More generally, the different generations of devices can lead to particular structuring of the criticality / intrusiveness couples.
    The classification of the functions of the flight management system according to their criticality and / or intrusiveness allows a configurable and flexible management.
    For example, to use the capabilities offered by one or more APIs, the privileges per client and more generally the quality of service can be configurable (i.e. configured).
    In one embodiment, the access rights conferred or associated with a client of the FMS may be a function of the operational functionalities concerned. These rights may allow - or not - for the family concerned the use of a subset of the FMS capabilities and the manipulation of a subset of the functional core data of the FMS.
    In general, the home family (determining the access properties) of a given connected system to the FMS flight management system is configurable. Rights or access properties can be static. The access rights can also be dynamic, that is to say, evolving over time and / or according to flight events (for example depending on the flight phase, i.e. flight context). In some embodiments, predefined scenarios at least partially determine the various access rights (e.g. stall, emergency situation, cruise regime, take-off / landing). (Elucubration to verify, delete or modify) The access rights may concern the access to the avionic services and / or the programming interfaces of said avionic services. In other words, access to an avionics service itself and access to the documentation of the same service can be considered independently. For example, a customer may have access to all available avionics services but without the corresponding descriptions in detail (other than strictly necessary for the performance of avionics services). Conversely, a customer can have access to a single avionics service but have a complete knowledge of the perimeter (eg limits for calculation accuracy, load capacity, tolerance for poorly formed requests, the existence of special or emergency orders, etc.)
    Advantageously, the various embodiments of the invention make it possible to obtain distributed, scalable and optimal architectures in terms of development effort and certification of the various functionalities, with regard to the different levels of criticality of the operational functions implemented. In one embodiment, the criticality of the features is understood in the sense of the certification (safety in English). These operational functionalities (involving several systems including the FMS) can be broken down into i) functionalities corresponding to the implementation of functional or functional functional core capabilities ii) functionalities allowing the implementation of the clients implementing the model or models of interaction and communication protocols with the connected system (s), for one or more operational functions.
    Regarding i), the implementation of functional or functional capacity of the functional core is implemented by the functional core and therefore inherits the level of criticality associated with the functional capabilities of the functional core.
    Regarding ii), the implementation of ΓΑΡΙ or Open API clients inherits the criticality level of the operational functionality to be performed. In one embodiment of the invention, customers can therefore have access to dedicated partitions.
    Advantageously, the development costs are potentially lower if the level of criticality is lower than that of the functional core. Certification credits are maintained and implementation costs remain low if no new functional capability becomes required and / or the core functional area is respected.
    FIG. 5 illustrates an embodiment with specific examples of rights of access to the different avionics functions of the FMS.
    In the example, the family F4 (air traffic relations and operational control centers) 501 can edit the flight plan through access to the open APIs 510, while the family F9 (failure analysis and recorder flight) can not.
    FIG. 6 illustrates an example of classification of access rights by operational avionics functionalities. The rights may be: - reading or simple viewing of data (D1 601, "READ ONLY"). In the example provided, this right to read-only data is restricted to FMS capabilities C1a and C1b only; - writing or editing, for example the private flight plan (D2 602, RD, "WRITE" on private data). In the example provided, this editing right is restricted to the capacities C1a, C1b and C2b: - of writing and reading, for example of editing and administration of the public flight plan (D3 603; WRITE "on functional heart data). In the example provided, this right is not associated with any restrictions.
    In one embodiment, each of the clients of ΓΑΡΙ is considered as a basic application implementing the interaction model and the communication protocol between the connected external system (s) and the functional core of the FMS. Each of the customers contributes to one or more operational avionics functions. A quality of QoS service of avionics nature can be defined for each of the customers (or at least part of them). This quality of service makes it possible to define levels of privileges between the clients in the processing of their requests (services, access to the data). The quality of avionics service offered to each customer is a configurable variable.
    In one embodiment, two types of information make it possible to define the field of use of the functional heart in the context of interaction with third party systems: a) the quantum of time allocated, in a fixed manner, to the functional core for the processing of all interactions with the connected systems and b) the maximum number of connected systems per family of operational functionalities.
    In one embodiment, these two types of information make it possible to limit the maximum "envelope" (the perimeter of the field of use) to which the functional core must respond.
    The subset of hardware, software, and I / O data associated with the interactions between each connected system and the functional core is provisioned against both of these pieces of information (the term "provisioning" refers to the contribution of hardware resources adequate, according to an obligation of means or even an obligation of result, ie according to service levels guaranteed or at least quantified, "Service Level Agreements").
    Validation of the functional core, in terms of "behavior" (e.g. set of responses to queries) and in its performance can be obtained with fixed values for both types of information, and for a given execution platform. Certification is generally obtained (and maintained) as long as there is no need to upgrade one of these types of information and / or the reference execution platform.
    Figure 7 illustrates an example of classification of operational avionics functionalities according to their level of criticality (allocation of functions by criticality).
    In one embodiment of the invention, the level of criticality X1 corresponds to a level (strictly) higher than the criticality level of the functional heart FMS; the level of criticality X2 corresponds to a level of criticality equal to (or substantially equal to) that of the functional heart FMS; the criticality level X3 corresponds to a criticality level (strictly) lower than the criticality level of the FMS functional core; the X4 criticality level corresponds to a criticality level much lower than the criticality level of the functional heart FMS.
    For example, the operational avionics functionalities F1 relating to the human machine interface 701 have a level of criticality equal to that of the FMS. The automatic guidance F2 features of the aircraft 702 have a level of criticality X1 higher than that of the FMS. The F4 features in relation to air traffic or operational control centers 703 have a level of X3 criticality lower than that of the FMS. The F6 functionalities have a level of X4 criticality that is much lower than that of the FMS.
    Figure 8 shows an example of correlation between criticality levels and access rights to avionics services.
    In the example, there is a set of four "homogeneous" clients (801, 802, 803, 804) implementing the interactions with the external systems. The four customers can make subsets of homogeneous avionics functionalities, in terms of (i) criticality and (ii) access rights. This number is optimum with respect to the stability of the quality of service attributed per customer, the stability of the DAL (Design Assurance Level) levels, which designates the quality of development of an embedded system, established by the international standard RTCA DO-178) constraining the implementation of the various clients and the stability of the access privileges to the communication interfaces associated with each of the clients and the stability of the configuration and correspondence tables ("mapping" according to the English terminology) I / O between clients and functional core.
    Some groupings can be made ·, the features can be divided into four groups 801, 802, 803 and 804 for example. The first group 801 comprises, for example, the F1 human-machine interface functions associated with an X2 criticality level and a D3 access right. The 802 group includes the functions of automatic guidance of the aircraft and securing the flight. The 803 group includes the exchange functions with ground authority and decision support on board. The 804 group includes debugging and simulation features.
    Figure 9 illustrates some aspects of an embodiment of the method according to the invention.
    Block 910 corresponds to the candidate operational avionics functions according to predefined categories (in the example, nine categories deployed on N external systems). These operational avionics functions can be hosted in avionics systems, and / or in "open" ("open world") systems and / or ground based systems.
    Block 920 corresponds to the open APIs, within the meaning of the invention, providing C1a avionic services for access to the functional heart information system (for example the system configuration data, such as operating modes and options). , parameter data including navigation databases, input characteristic data as well as data and reports consolidated by the functional core), - avionic services C2a (eg flight plan administration services). ), - C2b avionics services (eg flight plan editing), - C1b avionics services (eg access to flight plan data, 3D trajectory and associated predictions for manipulated flight plans) by the functional heart).
    Hardware and software resources are provisioned for the area of use of the functional core.
    Block 930 corresponds to the functional core utilization domain (maximum number of external systems, operational avionics functions, input / output resource provisions for each system depending on the access rights required for the relevant operational function, quantum of fixed time and / or percentage of processor time for external interaction, associated certification credits, etc.)
    Block 940 is the configuration of a client. A customer can group different operational functions (F1 to F9), one or more associated service grades. In one embodiment, the number of systems actually connected is known (for example by function or avionics service).
    Block 950 designates specific applications implementing the interaction model and the protocols with the external systems of each of the operational functions. These applications may for example correspond to a plurality of clients that exploit open APIs in a consistent manner in terms of criticality and / or in terms of privileges or access rights.
    Figure 10 illustrates an example of dynamic process flow for a given architecture.
    In a first step 1010, it is received (or determined) a pilot action on the flight plan from the human-machine interface in the cockpit (F1). In a second step 1020, the avionics capabilities of the functional core are implemented to respond to the operational action (one or more avionics services are requested). In a third step 1030, the functional heart data is retrieved (for example in their standard content C4). In a fourth step 1040, the received data are processed (for example formatted) and then transmitted to the display system present within the cockpit (F1). Finally, in a fifth step 1050, the processed data are transmitted to the Flight Test Data Recorder (F8) recording and analysis system.
    FIG. 11 illustrates examples of steps of the method according to the invention.
    In a first step 1110, the typing of the avionics functionalities by intrusiveness and criticality is performed. In one embodiment, it can be realized via a configuration file 1111 embedded by API, so that a new client can connect without having to reopen the code of ΓΑΡΙ. The sub-steps corresponding to this typing (i.e. of allocation of rights) can be performed in real time.
    Subsequently, the access rights Di to the avionic services are determined 1121. In parallel or successively, the criticality levels Xi relative to the FMS are determined 1122. According to the list of avionic functionalities 1130 present in the aircraft, the typing of features by intrusiveness 1131 and / or by criticality 1132 is determined. In step 1140 the access rights are allocated by avionics functionalities Fi according to the determined intrusiveness, then in step 1150 the number of customer types is determined. All the steps described above can be performed offline ("offline", that is to say during the design of the open digital core and its interface). In step 1160, a request is received or an interaction is detected from one of the connected systems, which wishes to access one or more avionics services. The different access rights are then checked at step 1170, depending on the type of client. If access is allowed, the requested avionics service is executed at step 1181 (or the plurality of avionics services where applicable). Otherwise, if access is not allowed at step 1182, the client is notified of the rejection of his request.
    The present invention can be implemented from hardware and / or software elements. It may be available as a computer program product on a computer readable medium. The support can be electronic, magnetic, optical or electromagnetic. The device implementing one or more of the steps of the method may use one or more dedicated electronic circuits or a general purpose circuit. The technique of the invention can be realized on a reprogrammable calculation machine (a processor or a microcontroller for example) executing a program comprising a sequence of instructions, or on a dedicated calculation machine (for example a set of logic gates). as an FPGA or an ASIC, or any other hardware module). A dedicated circuit can in particular accelerate the performance in access and execution of avionics services. As an example of hardware architecture adapted to implement the invention, a device may comprise a communication bus which is connected to a central processing unit or microprocessor (CPU, acronym for "Central Processing Unit" in English), which processor can be "multi-core" or "many-core" a read-only memory (ROM, acronym for "Read Only Memory" in English) that may include the programs necessary for the implementation of the invention; a random access memory or RAM (Random Access Memory) with registers adapted to record variables and parameters created and modified during the execution of the aforementioned programs; and a communication interface or I / O (I / O acronym for "Input / Output" in English) adapted to transmit and receive data. In the case where the invention is implemented on a reprogrammable calculation machine, the corresponding program (that is to say the instruction sequence) can be stored in or on a removable storage medium (for example a flash memory , an SD card), a mass storage means such as a hard disk (eg SSD) or non-removable, volatile or non-volatile, this storage medium being partially or fully readable by a computer or a processor. The telecommunication network can be 2G, 3G, 4G, Wifi, BLE, fiber optic, proprietary or a combination of these networks. The reference to a computer program that, when executed, performs any of the functions described above, is not limited to an application program running on a single host computer. On the contrary, the terms computer program and software are used here in a general sense to refer to any type of computer code (eg application software, firmware, microcode, or any other form of instruction computer) that can be used to program one or more processors to implement aspects of the techniques described herein. The means or IT resources may be centralized and / or distributed ("cloud computing"), possibly with or according to peer-to-peer and / or virtualization and / or redundancy technologies. The software code may be executed on any suitable processor (for example, a microprocessor) or a processor core or set of processors, whether provided in a single computing device or distributed among a plurality of computing devices.
    权利要求:
    Claims (15)
    [1" id="c-fr-0001]
    claims
    A method for managing avionic data between an FMS flight management system and one or more clients of said FMS, the FMS flight management system comprising physical resources accessible through avionic services Ci (1, n); the execution of one or more avionic services Ci (1, n) determining an avionic functionality Fj (1, m); each avionic functionality Fj (1, m) being associated with an intrusivity parameter l | <and a criticality parameter C | <; the method comprising the steps of: - receiving a request from a client, said request specifying the call to an avionic functionality Fj (1, m); determining a parameter associated with a predefined execution right of an avionic service Ci (1, n), said parameter being a function of the predefined intrusiveness and / or criticality parameters associated with said avionic functionality Fj (1, m) )
    [2" id="c-fr-0002]
    The method of claim 1, further comprising the step of comparing the determined execute right parameter with one or more predefined execution rights.
    [3" id="c-fr-0003]
    The method of claim 2, further comprising a step of executing one or more avionics services and communicating the result to the client.
    [4" id="c-fr-0004]
    The method of claim 2, further comprising the step of notifying the client of the rejection of his request.
    [5" id="c-fr-0005]
    5. Method according to any one of the preceding claims, an avionics service corresponding to a avionics service selected from a avionics service access to the functional core information system of the FMS, an avionics service for managing or administering a flight plan. flight, an avionics service providing access to data of a flight plan or an aircraft trajectory.
    [6" id="c-fr-0006]
    The method of any of the preceding claims, wherein a criticality level is selected from a plurality of predefined criticality ranges.
    [7" id="c-fr-0007]
    7. Method according to claim 6, the plurality of criticality ranges comprising four predefined criticality ranges, which comprise a criticality level X1 strictly greater than the criticality level of the functional heart FMS, the criticality level X2 equal to the criticality level of the functional heart FMS, the criticality level X3 strictly lower than the criticality level of the functional heart FMS and the level of criticality X4 much lower than the criticality level of the functional heart FMS.
    [8" id="c-fr-0008]
    8. A method according to any one of the preceding claims, an avionics functionality being selected from the avionics functionalities comprising a Human Machine Interface F1 functionality, an Automatic Aircraft Guidance F2 functionality, a monitoring and flight monitoring functionality. and the F3 flight path, an Air Traffic Relation and F4 Operational Control Center functionality, a Strategic F5 or F5 Flight Optimization Tools functionality, a F6 Flying Simulation feature, a Functional Maintenance and Conditioning Functionality F7, a Ground Debug &amp; F8 flight, a feature of F9 Flight Analysis and Flight Recorder.
    [9" id="c-fr-0009]
    9. A method according to any one of the preceding claims, an avionic functionality being executed according to a predefined interaction model, the predefined avionic interaction model being chosen from the interaction models comprising a human-machine interaction model, an interaction model comprising the automatic guidance of the aircraft and or the on-board monitoring, an ATM-Airlines Operation Center interaction model and / or an interaction model called Simulation-Maintenance-Debugging-Failure Analysis.
    [10" id="c-fr-0010]
    10. Method according to any one of the preceding claims, the intrusiveness parameters and / or criticality being configurable.
    [11" id="c-fr-0011]
    11. The method of claim 1, one or more parameters of intrusiveness and / or criticality depending on the flight context.
    [12" id="c-fr-0012]
    A computer program product, said computer program comprising code instructions for performing the steps of the method of any one of claims 1 to 11, when said program is run on a computer.
    [13" id="c-fr-0013]
    13. System comprising means for implementing the steps of the method according to any one of claims 1 to 11.
    [14" id="c-fr-0014]
    The system of claim 13 comprising an FMS flight management system and one or more clients of said FMS flight management system.
    [15" id="c-fr-0015]
    15. System according to claim 13 or 14, comprising at least one electronic flight bag type EFB.
    类似技术:
    公开号 | 公开日 | 专利标题
    FR3046273A1|2017-06-30|OPEN ARCHITECTURE FOR FLIGHT MANAGEMENT SYSTEM
    FR3067802A1|2018-12-21|ALTERNATIVE ROAD MANAGEMENT FOR AN AIRCRAFT
    US10762213B2|2020-09-01|Database system threat detection
    FR3055958A1|2018-03-16|DECISION AID FOR THE REVISION OF A FLIGHT PLAN
    FR3067803A1|2018-12-21|SYNCHRONIZATION OF A DUAL AVIONIC AND NON-AVIONIC SYSTEM
    US10546268B2|2020-01-28|Recipient customized delivery paths for unmanned aerial vehicle deliveries
    EP2975362A1|2016-01-20|Performance calculation for an aircraft
    US10889297B2|2021-01-12|Determining a safe driving speed for a vehicle
    FR3030805A1|2016-06-24|QUALITY OF SERVICE OF A FLIGHT MANAGEMENT SYSTEM
    US11164465B2|2021-11-02|Real-time identification and provision of preferred flight parameters
    US9690553B1|2017-06-27|Identifying software dependency relationships
    US20180121877A1|2018-05-03|Recipient customized delivery paths for unmanned aerial vehicle deliveries
    US9923955B2|2018-03-20|Virtual fencing gradient to incrementally validate deployed applications directly in production cloud computing environment
    FR3082829A1|2019-12-27|AIRCRAFT MANAGEMENT
    US20200336542A1|2020-10-22|Blockchain based data transformation
    US11116398B2|2021-09-14|Detection of contagious diseases using unmanned aerial vehicle
    US10386793B2|2019-08-20|Optimizing operations of an electronic system based on the quality of user device inputs
    Grigoropoulos et al.2020|Simulation and digital twin support for managed drone applications
    US11175679B2|2021-11-16|Drone elastic map
    US20210162592A1|2021-06-03|Automated generation of robotic computer program code
    US11030015B2|2021-06-08|Hardware and software resource optimization
    FR3067805A1|2018-12-21|DECISION AID FOR THE CONTROL OF AN AIRCRAFT
    US10776576B2|2020-09-15|Automated mobile device detection
    US11086743B2|2021-08-10|Context based IoT device management
    EP3842962A1|2021-06-30|Method and system for managing data streams for unified governance of a plurality of intensive calculation solutions
    同族专利:
    公开号 | 公开日
    FR3046273B1|2018-10-12|
    US10319240B2|2019-06-11|
    US20170186328A1|2017-06-29|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    FR2916068A1|2007-05-10|2008-11-14|Airbus France Sas|SYSTEM FOR MANAGING RIGHTS OF ACCESS TO AVIONIC APPLICATIONS AND DATA AND METHOD IMPLEMENTED THEREBY|
    FR2841999B1|2002-07-05|2004-09-10|Thales Sa|OBJECT-ORIENTED NETWORKING SYSTEM OF ON-BOARD AERONAUTICAL EQUIPMENT|
    US8395529B2|2009-04-02|2013-03-12|GM Global Technology Operations LLC|Traffic infrastructure indicator on head-up display|
    US8346881B1|2012-05-18|2013-01-01|Google Inc.|Prioritization of incoming communications|
    US9772712B2|2014-03-11|2017-09-26|Textron Innovations, Inc.|Touch screen instrument panel|
    FR3025385B1|2014-09-01|2016-08-12|Thales Sa|METHOD FOR EXECUTING ADAPTIVE REAL-TIME SERVICES, IN PARTICULAR FLIGHT MANAGEMENT, AND REAL-TIME SYSTEM USING SUCH A METHOD|US10496234B2|2016-02-19|2019-12-03|The Boeing Company|Modeling the connection between the software signal path and hardware signal path using routes|
    US10061625B2|2016-03-25|2018-08-28|Google Llc|Navigation application programming interface to accommodate multiple waypoint routing|
    US10169110B2|2016-03-25|2019-01-01|Google Llc|Navigation application programming interface|
    US20190243504A1|2018-02-05|2019-08-08|Honeywell International Inc.|Touch screen controller with data exchange and mining service|
    US10870497B2|2018-02-09|2020-12-22|Honeywell International Inc.|Apparatus and method for selectively enabling vehicle functionality|
    US10991255B2|2018-04-05|2021-04-27|Ge Aviation Systems Llc|Providing an open interface to a flight management system|
    US20200226940A1|2019-01-11|2020-07-16|Honeywell International Inc.|Systems and methods for connected and intelligent flight management system|
    US20200301760A1|2019-03-19|2020-09-24|Honeywell International Inc.|Methods and systems for generating and recommending api mashups|
    US11048389B2|2019-09-16|2021-06-29|Mid-Continent Instrument Co., Inc.|Customizable multi-function display|
    法律状态:
    2016-11-28| PLFP| Fee payment|Year of fee payment: 2 |
    2017-06-30| PLSC| Publication of the preliminary search report|Effective date: 20170630 |
    2017-11-27| PLFP| Fee payment|Year of fee payment: 3 |
    2019-11-28| PLFP| Fee payment|Year of fee payment: 5 |
    2020-11-25| PLFP| Fee payment|Year of fee payment: 6 |
    2021-11-26| PLFP| Fee payment|Year of fee payment: 7 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1502677A|FR3046273B1|2015-12-23|2015-12-23|OPEN ARCHITECTURE FOR FLIGHT MANAGEMENT SYSTEM|
    FR1502677|2015-12-23|FR1502677A| FR3046273B1|2015-12-23|2015-12-23|OPEN ARCHITECTURE FOR FLIGHT MANAGEMENT SYSTEM|
    US15/389,216| US10319240B2|2015-12-23|2016-12-22|Open architecture for flight management system|
    [返回顶部]