• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The system executes services by a so-called "server" application for at least one so-called "client" application. A preliminary step (30) establishes for each service (S (i)) a list of calculation parameters (Param (i, j)) able to vary in a given domain, said adjustable, as well as calculation time information and quality of said service according to the value of said parameters. At the request of a client for a given service, the method adjusts (32) the value of the adjustable calculation parameters according to a given constraint, the service being executed (33) using the adjusted values of said parameters.
    公开号:FR3025385A1
    申请号:FR1401937
    申请日:2014-09-01
    公开日:2016-03-04
    发明作者:Francois Coulmeau；Frederic Sanchez；Laurent Castet；Laurent Deweerdt
    申请人:Thales SA；
    IPC主号:
    专利说明:

    [0001] BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an adaptive real-time execution method, particularly to flight management. BACKGROUND OF THE INVENTION It also relates to a real-time system implementing such a method. The invention applies in particular in embedded systems and more particularly in avionics systems.
    [0002] Each real-time avionics system is architected and developed to meet performance requirements (including failure rate and quality of service) in a defined job environment. Each system, connected to other systems consumes data and services made available by other systems and produces service data for other systems. These interactions are usually statically fixed during the development of the overall "system of systems" architecture, that is to say when allocating operational functions to physical systems. Thus, it is common in the avionics world to have several dozen systems that meet all the functions of the aircraft. Typically the aircraft operations are allocated to the systems according to a logical structure, defined in the normative document of the Association ATA (Air Transport Association). The aircraft architecture is therefore declined in collaborative avionics systems, each with a specific function, and interactions with other systems to make the operational service expected. The various functions are distributed over several physical computers, according to aircraft manufacturers' choices, to guarantee mission performance. Embedded systems are qualified, with a demonstrated level of performance, for a given environment. The interactions between systems are defined a priori during the development of the aircraft architecture, and the systems are developed and adjusted to meet the strict need for interaction. If we take the point of view "client-server" where a set of 35 systems called "customers" make requests to a particular system 3025385 2 said "server", the problem is to guarantee customers the quality of service in terms of accuracy and response time, or even other performance criteria they expect. The problem is thus to make the quality of service more configurable seen by a client so that he does not have to use all the time on a worse case, a case that does not necessarily interest him. One problem is that adding a new client to a given system results in a very expensive requalification. It is necessary to demonstrate again the performance of the operational performance of the entire "server" system, even when no new service is expected by the "server" system. This constrains the evolution of aircraft operations. There is therefore a need to be able to allow the addition of new connections and new customers to a real-time "server" system, guaranteeing them, in all cases, a response time corresponding to the expectations of the client system, even if it is necessary to adapt the quality of service on that response time, and to provide improved quality of service later. A second need is to guarantee the proper functioning of the overall system which does not degrade its performance and does not give rise to software or hardware modifications of the server. The addition of a new client or connection would only result in a qualification of the client in question and a demonstration that the network performance remains in compliance with the required requirements. An object of the invention is in particular to meet this need. For this purpose, the subject of the invention is a method of real-time execution of services by a so-called "server" application for at least one so-called "client" application, a preliminary step establishing for each service a list of calculation parameters capable of vary in a given domain, said adjustable, as well as calculation time and quality information of said service according to the value of said parameters, at the request of a client for a given service said method adjusts the value of the adjustable calculation parameters in according to a given constraint, the service being executed using the adjusted values of said parameters. Said given constraint implies for example a maximum duration of response time to said request, or the use of a set of non-adjustable calculation parameters. Said constraint is provided to the server by said client.
    [0003] In a particular embodiment, for each service, the adjustable parameters are classified by priority, in case of necessary adjustment of the parameters to respond to said given constraint: the highest priority parameter is first of all adjusted and the execution time of said service being calculated; if the adjustment of said highest priority parameter does not make it possible to respond to the given constraint, even at the limit of its range of variation, the following priority parameter is adjusted, the value of the highest priority parameter remaining frozen. in abutment of its range of variation; And so on, in order of priority until the constraint is satisfied or until all the adjustable parameters have been abutted in their respective range of variation. In another possible embodiment, for each service, the adjustable parameters are classified by priority, in case of necessary adjustment of the parameters to respond to said given constraint: the highest priority parameter is first adjusted to a first target value within its range of variation and the execution time of said service being calculated; if the adjustment of said highest priority parameter does not make it possible to respond to the given constraint, even at the abutment of said first target value, the next priority parameter is adjusted to a second target value inside. its variation domain, the value of the highest priority parameter remaining fixed in abutment of the first target value; and so on, in order of priority until the constraint is met or until all the adjustable parameters have been stopped, if the adjustment is not sufficient after all the target values have been reached. stop, new target values internal to the ranges of variations of said parameters being defined. The parameters of a subset of said list are for example first adjusted.
    [0004] Such a list of adjustable parameters is for example established by said client. Said variation domains of said parameters are for example determined by said client. In one possible embodiment, at least one intermediate result of execution of said service is calculated with its quality being serviced. Said intermediate result is for example notified to said client. The complete execution of said service is for example carried out after said intermediate calculation. In another possible embodiment, several successive intermediate results are for example calculated, with parameters less and less adjusted to each calculation, until the complete calculation of the execution of said service without adjustment of said parameters, a parameter less and less adjusted being a parameter whose value is moving further and further away from the value for responding to said given constraint. The parameters of said list are, for example, adjusted each time a new request is received. Execution of said request is for example refused if its execution with said adjustable parameters does not make it possible to respond to said given constraint. Information is, for example, transmitted to said client if the execution of said request with said adjustable parameters does not make it possible to respond to said given constraint. The subject of the invention is also a real-time system implementing the method according to any one of the preceding claims, comprising at least one physical module where the server is located, characterized in that the clients are external applications implanted in said physical module, said clients communicating with the server via a memory internal to the module. The clients are for example external applications distributed in other physical modules and communicating with the server via a network protocol, the server running for example a flight management application.
    [0005] Other features and advantages of the invention will become apparent from the following description with reference to the accompanying drawings which show: FIG. 1, a presentation of the functional architecture of a management system on board flight; Figures 2a and 2b, operating characteristics of real-time systems; Figure 3, various possible steps for carrying out the method according to the invention; Figure 4, an exemplary embodiment of a first step; Figure 5, the possible sub-steps of the second step; Figure 6, the possible sub-steps of the second step; Figure 7 is an example of a physical representation of the clients in the case of application to an FMS system; Figure 1 shows the functional architecture of an onboard flight management system, called FMS (Flight Management System). This standard architecture, well known, meets the ARINC 702A standard. One of the functions of the FMS is to locate the aircraft using its sensors 171 (inertial units, GPS, radio beacons in particular). This function is performed by a location function LOC NAV 170. The system comprises the following functions and components: An FPLN flight function 110, to capture the geographical elements constituting the skeleton of the route to be followed (departure and departure procedure). arrival, crossing points ...); A NAVDB 130 navigation database, for constructing geographic routes and procedures from data included in the bases (points, tags, interception or altitude bequests ...); A performance database, PRF DB 150, containing the aerodynamic and engine parameters of the aircraft. A lateral trajectory function TRAJ, 120: to construct a continuous trajectory from the points of the flight plan, respecting aircraft performance and confinement constraints (RNP); Prediction function PRED, 140: to build an optimized vertical profile on the lateral trajectory; A guiding function, GUID 200, for guiding the aircraft in its 3D trajectory in the lateral and vertical planes, while optimizing the speed; DATALINK digital data link, 180 to communicate with the control centers 181 and the other aircraft From the geographical information contained in the navigation database 130, the pilot can build his route, called the flight plan and including the list waypoints called "waypoints", function provided by the flight plan function 110. The FMS can manage several 10 flight plans. One of them, known as "Active" in ARINC 702A, refers to the flight plan on which the airplane is guided. There are work flight plans, sometimes called "secondary flight plans" or "inactive", as well as transient flight plans. The function 120 calculates the lateral trajectory as a function of the geometry between the points of passage, commonly called LEG, and / or the altitude and speed conditions which are used for the calculation of the turn radius. In this lateral trajectory, the FMS optimizes a vertical trajectory, in altitude and in speed, passing through possible constraints of altitude, speed, time, using a modeling of the aerodynamic and motor performances contained in the data base. 150. Knowing the location of the aircraft and the 3D trajectory, the FMS can enslave the aircraft on this trajectory, this servocontrol being performed by the guidance function 200. All the information entered or calculated by the FMS is grouped together on display screens or other HMIs 10. The communication with the ground, in particular with the airline and the air traffic control, is carried out by the digital data link 180. In the terminology FMS, the term "revision" is used. to characterize a data insertion, modification or erasure of the FMS system, the word edit being also used. 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 heart of the FM business.
    [0006] 3025385 This system can also host part of the "Location" and "Guidance". To ensure its mission, the FMS is connected to many other computers (a hundred).
    [0007] 5 Two large customers usually interact with the FMS system - the human machine interface (HMI) which allows operators (crew) to interact with the FMS - the CMU interface (for Communication Management Unit) which allows a ground operator (airline, air traffic control) to interact with the FMS: This CMU calculator is a client of the FMS data and can request the modification of the mission (ie insert "revisions" in the FMS) By "interaction" is meant "request" sent to the FMS, with an expected return, as opposed to the "information" which consists of third party systems subscribing to data periodically or eventally transmitted by the FMS. . Future operations in the aircraft will however require third-party systems to interact with the FMS, namely: 20 - Using existing public services - Using existing private services - Using new services to implement in the FMS We can quote for example: - Initialization of the FMS flight plan by an external computer (25 tactile tablet, Ipad®, EFB for "Electronic Flight Bag") - Integration of the "flight plan" of the FMS with the "rolling plan" of the computer of taxiing (called ANF for Airport Navigation Function, AOF for Airport Onboard Function or TAXI or AMM for Airport Moving MAp) 30 - Optimization of the mission, called by a ground client (company tool for example) or board (tablet, EFB) via FMS 3025385 8 - Updating the FMS software (in particular its 28-day cycle Navigation databases) by third party equipment (tablet, maintenance tool, EFB) - Used FMS queries by a traffic monitoring system 5, weather to filter alerts, or confirm them, or optimize lateral and vertical adjustments (eg: avoidance of a mobile cloud mass detected by a Weather Radar) o The traffic monitoring system is known by the acronym TCAS (Traffic Collision Avoidance System) or Traffic Computer 10 o The ground surveillance system is known by the acronym TAWS (Terrain Avoidance Warning System) or GPWS (Ground Proximity Warning System) o The weather monitoring system is known by the acronym WxR (Weather Radar) 15 - Using FMS requests to help trigger events on a third-party system (eg: Changing the radio frequency by the RMS (Radio Management System) ) when approaching a point of change of region. - Verification of conformity of the lateral and / or vertical trajectory 20 calculated by the FMS, compared to digitized aeronautical charts provided to the crew (stored in a tablet, an EFB for example) - Use of the FMS system to know predictions on a given time horizon according to modes of flight flight 25 (guidance) and airplane status defined (eg: Autopilot wishing to know the average rate of climb on 2000 feet of altitude change with 1 engine down; of fuel wanting to compare average consumption with FMS consumption predictions ...) 30 - Interactions with FWS (Flight Warning System) to present verification results, propose automated DO LIST launches, directly modify FMS states on confirmation breakdowns. 3025385 9 - Passengers connected via their cabin interface (IFE for In Flight Entertainment), wishing to know the predictions in time, speed for their destination - Use of the FMS via an AID (Domain Interaction Agent) or a 5 IHS (Human Interface System ) which concentrates and organizes exchanges between computers. Thus, a dozen new customers are likely to interact with the FMS (EFB, WIMS, TCAS, TAWS, WxR, PA, FQMS, IFE), in short most of the 10 systems of different ATAs. In the future, it is possible that even more customers want to interact with "flight management". However, we do not know a priori the rate of the requests of the different systems, nor the time when the request will be requested, nor the volume of data that this represents.
    [0008] If a new system connects, we do not know a priori its intentions (type of requests, periodicity) The method according to the invention, described later, allows to be able to position itself in front of an unknown number of requests arriving at random times, while ensuring a response in the time allotted to each, with reduced accuracy / reliability by adjusting the service parameters. The invention is described for an avionics system, but it is applicable to any embedded real-time system architecture.
    [0009] Figures 2a and 2b show operating characteristics of these systems. FIG. 2a shows a frame executed by each processor of a computer, this frame being known by the term MIF according to the English expression "Minor Frame". More particularly, each processor executes its code over successive time slots, these slots being MIFs. Each MIF is divided statically or dynamically, according to the technologies, into time partitions, that is, time slots 20 on which a function 3025385 10 is executed. In the example of FIG. 2a, the MIF comprises N slots P1, P2, P3 PN. This technology is widely deployed on so-called IMA ("Integrated Modular Avionics") modules in aeronautics. It makes it possible to host on a single physical computer several functions resulting in gains in mass and electrical power. In most embedded real-time systems, partitioning is static to ensure the determinism of overall system response times. In the same way, the IMA modules allocate, in a static manner in general, the physical memories RAM and ROM that will be used by each function. This makes it possible to segregate the various functions that run within the same module and better control the problem of faults. Figure 2b illustrates the real-time execution of a real-time function at a partition of a MIF. FIG. 2b represents a succession of treatments 22 classified by priorities, the processing As2 being able to execute before the processing As1 but being able to be interrupted by As1 taking control because its priority is higher, and likewise for Asi-1 compared to in Asi. In general, the system begins by executing the so-called "cyclic" processing 21 of the function. These are processes that must be executed at each MIF without being interrupted, such processing including input and output management or the calculation of information that must be refreshed at each cycle. These treatments have a higher priority because you have to guarantee that they will have time to run all the time.
    [0010] These are in fact tasks like the others, but they have generally been associated with high priority to ensure that they pass before the other treatments. After the cyclic processing 21, come the asynchronous processing 22. In real time, these are processes that run on request (events, periodic alarm ...). Events are typically generated by the peripheral systems connected to the main system. They are ordered by treatment priority. Thus, in FIG. 2b, a succession of asynchronous processes 21 is shown, the event As1 being followed by the event As2, which is followed by the event As3 and so on until the last event Asn. If we note P (Asi) the priority of an event, it comes: 3025385 11 P (As1)> P (As2)> P (As3)> P (Asn). If the first As1 processing requires all the calculation time remaining on the MIF, the other treatments can not run at best on the next MIF. If the sum of the cyclic 21 and asynchronous processing 22 to be executed does not exceed the duration of the MIF, there remains some free time 29 which is called IDLE. The response times perceived by the outside of the system, that is to say perceived by the peripheral systems or by the human, for a given overall treatment, are therefore proportional to the number of MIFs necessary to execute the whole of the system. treatment. Thus on an MIF of 80 ms where the cyclic processing takes 30 ms, if a processing requires 1 second of processor time to execute its computation, it will need at best 20 MIF to finish it, 20 MIF corresponding to 20 x 50 ms = 1 second where 50 ms is the time remaining in a MIF after the 30 ms cyclic process. The response time will therefore be 20 x 80 ms = 1.6 seconds. If the treatment competes with other higher priority asynchronous processing, the number of MIFs needed increases and therefore the response time perceived by the outside. This shows, in particular, that the difficulty for industrialists in the field to build a real-time architecture is to schedule the processing on priority tasks adapted to take all the response times of the required treatments, taking into account the competition. treatments with a probability of compliance. In general, the systems must ensure that they hold their performance requirements 100% of the time, in "single event", that is, without overlaying competing events. And we measure the probability that this is no longer the case in competing "multi-events", this probability having to be as low as possible. It can thus be required that the system be sized to hold all the response times in 99% of the time. This probability may also be different between the treatments according to their criticality, that is to say according to their impact on the overall performance of the operation. When we know the number of clients that can request asynchronous processing, the maximum frequency of their requests and the CPU time of computation corresponding to the processing of requests by the server, there are 3025385 12 techniques known to the state of the art. to create and schedule the real-time tasks of a given resource, in order to meet these response time requirements with the required probability. On the other hand, when the number of clients is a priori unknown, that the rate of their queries is unknown a priori, as is the case in an open multi-client open architecture, there is the problem of being able to guarantee the customers a maximum of positive answers. In fact, it is undesirable for congestion to result in "rejections" of requests that are too numerous.
    [0011] In addition, clients that make requests to the server do not necessarily all need the same quality of service. For example, some clients may want a precision on a higher or lower algorithm, a computational depth on a different integration or optimization, or a search on elements of a more or less comprehensive database. The quality of service may also be named afterwards by the term QoS. The invention advantageously uses a calculating time estimator for each service, this estimator modeling the impact on the calculation time of at least one adjustable parameter used by the service. It is thus possible to determine, with a number of services waiting in the stack, the scheduling that maximizes the number of responses to the customers by also maximizing the level of quality of service to each client, knowing the system in its field of use. .
    [0012] The invention consists in particular in determining the adjustment of the parameter or parameters, making it possible to obtain a so-called service life Ts '', which is compatible with the response time expected by the customer. It thus makes it possible to estimate the deadline by which the server can respond to the client, knowing this duration Tservice, and knowing the average duration 30 CPU of a unitary treatment among the services offered and the state of the current request stack. treatment and waiting. This makes it possible to have adjustment strategies to several parameters (multi-parameters) and to several requests (multi-requests), minimizing the number of rejected requests.
    [0013] Figure 3 shows the possible steps of the method according to the invention. A preliminary step 30 performs the establishment of the adjustable parameters and their ranges of variation. This preliminary step can be done "off line".
    [0014] In this step, the execution time of each service proposed by the server is calculated. We will note later S (i) the order service i, i ranging from 1 to Nb_services, where Nb_services is the number of services. The execution time is in particular a function of the parameters related to the service, a parameter related to the service S (i) being denoted param (i, j), j varying from 1 to NP (i), where 10 NP (i) is the number of parameters related to the service S (i). To calculate this execution time, the method may for example carry out a measurement campaign of the calculation times of the system, on a set of representative scenarios or using a performance model of the server system. For each service S (i), there are input processing chains corresponding to this service. A processing chain between a trigger event E (i) and an expected output 0 (i) is denoted by {(E (i), 0 (i)}. The method determines a variation domain for each param (i, j) between two terminals Min (param (i, j)) and Max (param (i, j)), where: Min (param (i, j)) corresponds to the worst possible degradation of the server performances, allowing to gain the most computation time Max (param (i, j)) corresponds to the absence of degradation, this is the value of the nominal parameter of computation The execution time depends on the parameter values between these parameters. According to the invention, an adjustable parameter is a parameter capable of varying between the terminals of its variation domain, the variation of the parameter influencing the calculation time and the server performance, these performances corresponding for example to the accuracy and / or the reliability of calculations Here are some examples of parameters for: - integration calculations numerical ration; 35 - floating-point calculations; A linearization of the calculations for nonlinear functions; database consulting calculations; trajectory calculations; this list is not exhaustive.
    [0015] 5 For numerical integration calculations: o Parameters are not integration and the order of the method for the integrated computation: the numerical integrations being carried out by a discretization of the problem, the size of the integration step influences 10 directly on the calculation time, as well as the order of the chosen method (a Runge-Kutta of order 4 costs more than a method of Newton of order 2 for example); ^ The greater the integration step, the more the accuracy / reliability of the calculation is degraded; 15 ^ The lower the order of the method, the more the accuracy / reliability of the calculation is degraded; o Another parameter is the number of iterations for iterative computations: the numerical optimizations mostly use iterative methods where the process approaches the optimal solution step by step, until reaching a stop criterion according to the precision expected. The method can play on the maximum number of iterations; ^ The lower the maximum number of iterations, the more the accuracy / reliability of the calculation is degraded; O Another parameter is the number of elements calculated: the digital integrations of a trajectory typically start from a state x0 to wait for a final state xf by calculating the command u (t) along the time. If the calculation stops at an intermediate point u (t_int), the calculation time is decreased; For example, on a trajectory calculation, a client may only need integration on the few elements in front of the initial state. The time / fuel predictions of a GPS or a flight management system may interest a customer over a few tens of kilometers for example; ^ The lower the computation depth, the less the client has elements on the complete trajectory; For floating-point calculations, the method can use 16-bit or 32-bit calculations instead of 64-bit, the mantissa is a parameter: o The lower the mantissa of the float, the more accurate / reliable the calculation is. degraded; For the linearization of the computations for nonlinear functions: the process can replace the functions by their development limited to a given order (the order acting on the precision), this order being a parameter: o The lower the order, the faster the calculation, the more the accuracy / reliability is degraded; For database query calculations: o Another parameter, the expected accuracy of the result when interpolating in a database; The more precision is released on the stopping criterion, the faster the interpolation but the more the accuracy / reliability is degraded; o The size of the list returned by the lookup service is also a parameter; 25 ^ for example for a GPS service asking to return all the elements having a given characteristic (service stations in particular): the method can limit the number of elements returned starting from the position of the vehicle ^ for a trajectory management system aircraft, all 30 VOR / DME radionavigation beacons around the aircraft: the method may limit the number of elements returned from the position of the aircraft, or from the position of a point that consult the crew (eg around the airport of destination etc ...) ^ The more the list is limited, and the less the customer has elements of choice in return for the service.
    [0016] 5 For the calculations of ground trajectory, one can quote: o The use of a more or less simple model, for example an ellipsoid of the GPS model known under the acronym WGS84 more greedy than a spherical approximation of the terrestrial geoid, him - 10 even more greedy than a local Mercator projection (flattening of the geoid); ^ The simpler the modeling, the more the accuracy / reliability is degraded; o The trajectory algorithms calculating the continuous "thread" of the ground track, the method according to the invention can use "transitions between straight lines" with constant radius turns, or even eliminate the turns of the calculation (the trajectory becomes class CO); ^ The simpler the modeling, the more the accuracy / reliability is degraded; The method is applicable to other domains, as long as they use adjustable parameters that affect the quality of the calculation obtained, particularly in terms of accuracy, reliability or calculation time as in the examples above.
    [0017] The measurement campaign calculates the end-to-end response times of a chain of treatments, also called the functional chain, by varying the parameters according to two options: Option 1: Only one parameter is varied, the others being fixed, and thus gradually builds a performance model linking response time and accuracy / reliability (compared with a calculation using the "nominal" parameters); Option 2: random draws are carried out on the adjustable parameters, in number large enough to have the properties of the law of large numbers (Monte-Carlo algorithm for example).
    [0018] Thus, for each string {E (i), 0 (i)), there is available, for example in a database embedded in the system hosting the clients and the server: an estimation of the calculation time, or duration of the corresponding service S (i) 10, T se'icegnparam (i., 1),..., param (i, Np (i))) of an associated quality of service with respect to the optimum quality, in terms of which concerns in particular the precision, the reliability or the depth of computation.
    [0019] The method can therefore at any time: calculate the calculation time estimate from a set of adjusted parameters; conversely, calculating a set of adjusted parameters to hold a given objective calculation time Tobj (S (i)), the calculation being able to give several solutions, possibly selectable by the client according to priority rules. Returning to FIG. 3, the preliminary step 30 is followed by a first step 31, in which the request stack is initialized and the adjustable parameters are loaded. FIG. 4 illustrates this first step 31 which comprises three substeps 41, 42, 43. In a first substep 41, the request stack is initialized to zero, it is empty.
    [0020] In a second substep 42, the method loads a table of adjustable parameters, possibly several tables, with: their field of use; the calculation time according to the adjustable parameter values, according to the preliminary step 30.
    [0021] In a first embodiment, the server is the only repository of the adjustments table and uses it to adjust the parameters according to requests S (i) of the clients and in particular imposed constraints. This implementation has the particular advantage that customers do not need to implement logic to adjust the parameters. They possibly provide their expected response time Trep (i) that the server will transform into calculation time Tobj (i), on which it will make the adjustments via the execution rules of the following substep 43. In another mode of possible realization, the client has a view of the table 10 adjustments and solicits the server by providing either a Trep response time (i) or a list of adjustable and non-adjustable parameters: if Trep time (i) is provided, the server determines the parameters to be adjusted according to the rules established in the next substep 43; if a list of adjustable and non-adjustable parameters is provided in addition to the response time Trep (i), the server determines the parameters to be adjusted according to rules called A3 or A4 which are defined in the next substep 43; if a list of adjustable and non-adjustable parameters is provided without Trep (i) response time requirement, the server determines the parameters to be adjusted according to rules AO to A4 of the following sub-step 43, by setting its own goal of time, in order to satisfy several customers. This embodiment has the particular advantage that customers have better control over the parameters on which they wish to act and those they wish to preserve. In the next substep 43, the third substep, the method determines the execution rules for adjusting the parameters. In a possible implementation known as "AO", the rule is such that the adjustable parameters are classified by priority between them. For each service S (i), a priority table of parameters P (i, kp), p varying from 1 to N is defined such that: P (i, k1)> P (i, k2)>> P ( i, kN) - When an adjustment is necessary, the method acts first on param (i, k1), and determines the processing time Tservice (S (ff), param (i, 1) ,. .., param (i, kl), ..., param (i, Np (i))) corresponding to the computation time objective Tobj (S (i)); If the adjustment of parameter param (i, k1) is not sufficient, that is to say, even at the minimum value Min (Param (i, k1), the required calculation time is greater to the objective, then the method acts on the parameter param (i, k2), the parameter Param (i, k1) being fixed at its minimum value; o And so on, until the objective Tobj ( S (i)) is reached or that all the parameters have been stopped at their 10 Min (Param (i, j) by the process, An advantage here is the simplicity and determinism of the solution with respect to the clients. Another possible implementation called "A1, according to another rule the parameters are adjusted as and when (compared to the implementation 15 AO, this alternative discretizes the range of parameters): - When an adjustment is necessary, the process acts first on param (i, k1) up to a target value V_cible (i, k1) between Max (Param (i, k1)) and Min (Param (i, k1)), and determines the time of t 20 Tservice (Saparam (i, 1), ..., param (i, k1), ..., param (i, Np (i))) corresponding to the computation time objective Tobj ( Yes)) ; If the adjustment of parameter param (i, k1) is not sufficient, the method acts on param (i, k2) up to its limit V_cible (i, k2); o and so on, until the objective Tobj (S (i)) is reached or all the parameters have been set to their target V (i, ki) by the method; - If the adjustment of the parameters is not sufficient, the process starts again by defining new target values V_Target (i, ki); o At the end of the end, the values V_target can be found all the way to their minimum; An advantage is in particular a more progressive and better distributed action on all the parameters, all of which contribute to the effort of reducing the computing time. In another possible implementation called "A2", according to another rule, a the subset of the parameters is adjusted first before acting on another subset of parameters, a solution that combines the AO implementation and the Al implementation: One advantage is that this alternative A2, which is more flexible, makes it possible to preserve the most important parameters for the client, by acting first on the others, while avoiding the abrupt degradation of an adjustment parameter In another possible implementation, called "A3", the parameters to be adjusted and the parameters to be preserved are chosen by the customer, according to one of the modes "AO", "Al" or "A2" (the customer optionally chooses the mode, as well as the parameters). An advantage of this alternative, more flexible still, is that it allows the customer to adjust his requests to preserve the parameters that interest him. In another possible implementation known as "A4", according to another rule, the parameters to be adjusted as well as the adjustment terminals (maximum target values Max (V_Target)) are chosen by the client according to one of the "AO" modes, "Al", "A2" or "A3". This alternative has the advantage that it is the most flexible for customers: It allows the customer to adjust his requests at best.
    [0022] Other alternatives are possible, mixing client needs and server constraints. Any other combination is possible, without this limiting the scope of the invention. With respect to the dynamic adjustment, a so-called "Dl" execution rule may allow the method to dynamically adjust the parameters that have been calculated for the services in progress, to allow insertion of a new service.
    [0023] An alternative known as "D2" can prohibit the dynamic adjustment so that once the list of adjustable parameters has been calculated, the process does not modify it. Regarding the acceptance and / or rejection of requests, an alternative rule called "R1" may reject any request whose objective response time can not be held. In an alternative called "R2", the method can reject a request if the adjustable or non-adjustable parameters requested by the client do not meet the target time set by the server.
    [0024] In an alternative rule called "R3", the method does not reject a request but warns the client if the adjustable / non-adjustable parameters or the objective response time can not be maintained. Regarding the progressive aspect of quality of service, in a possible implementation called "Q1", the method carries out a complete calculation if necessary (i.e. without adjustment), after an intermediate calculation. In another possible implementation, called "Q2", the method performs several successive intermediate calculations with a quality of service which increases each time, that is to say with less and less adjusted parameters, up to the calculation. complete without adjustment of parameters. For these different alternatives "Ai", the method, in a possible implementation, chooses as an adjustable parameter a client "timeout", that is to say a response time expected by the client: 25 If the value of the "timeout" is 0, so there is no timeout if the server does not have time to execute to respond to the basic response time, in which case the method rejects the request according to one of the alternatives "Ri" above; If the value is finite, given in milliseconds, the basic response time is ignored and the input value is checked against the accept or reject command, according to an alternative "Ri"; 3025385 22 - If the value is infinite, the process waits for the processing to be completed regardless of the processing time. Returning to FIG. 3, in a second step 32, the method performs the processing of the incoming requests with the determination of the adjustable parameters. FIG. 5 illustrates the possible sub-steps for this second step 32. A first substep 51 consists of recovering a new request R (Ci) coming from a client Ci 50.
    [0025] The request is supported in a second substep 52 if the system knows how to handle it in the given time, that is, if the necessary computing time Tservice (Snparam (i, 1), .., p aram (i, kj),., p aram (i, Np (i))) to process the request is compatible with the objective response time Tobj (i), after application of the execution rules of the first step 31 of the process.
    [0026] With respect to robustness, if the request stack is full, a rejection notification with the status 'Full Stack' is performed. In an alternative, the method again dynamically determines the parameter adjustments of all the requests present in the stack, each time a new request is received. This degrades the QoS of services already present in the stack, and the dynamic determination process for each service stops when the service reaches its stop in response time. In a "multi-resource" (ie, multiprocessor) alternative, this dispatch task is executed on one of the resources, which allocates the requests to different resources, depending on the load of said resources. Thus, if a resource i is busy processing requests, and it can not absorb a new request in its stack without guarantee of response within the given time, the supervisor is addressed to a less busy resource (if it exists) .
    [0027] In a third substep 53, the result of the second substep 52 is switched: either to the request stack via a substep 54; Or - to a substep 55 of the rejection notification, for example when the deadline requested by the new client is not compatible with the cumulative duration of the treatments already present and accepted in the stack.
    [0028] This sub-step 55 is a protocol service with the client to return a status 'Refusal' of its request Ri and possibly a sub-status (treatment too long, penalty cell for example) according to the rules "R1", "R2" or "R3" of the first step 31 of the process. In the "R3" case, it is not a refusal status that is sent, but an estimate of the time required to respond to the client. The other substep 54 sends a write request to the "request stack". She writes therefore in the pile in particular: - the service S (i) to execute; The parameters param (i, ki) to be adjusted and the adjustment values of said parameters; In the multi-resource alternative, the stack can be managed only by the resource that oversees all requests. Advantageously, a local copy of the stack 39 on all the resources, or a pooling of the stack 39 between the resources can be performed to avoid the problems of robustness, for example a case of supervision resource which breaks down.
    [0029] Return to Figure 3 which shows the possible steps of the method according to the invention. In a third step 33, the request processing of the stack 39 is performed. In this third step 33, for each resource, the different requests of the stack 39 of the requests are executed. This step 33 may be interrupted at any time by the second step 32 if a client 30 wishes to integrate a new request. FIG. 6 illustrates the possible sub-steps for the implementation of this third step 33 of the method according to the invention.
    [0030] In a first substep 61, the method first checks whether a request is stacked in the request stack 39. If this is the case, this request becomes the new request to be executed. If it is not the case, the process puts this step 61 on hold. This same substep 61 performs the calculation of the corresponding service S (i) using the adjusted parameters of the substep 55 of the second process step 32. A comparison is made in a second substep 62. More precisely, the precision and the reliability calculated in the first substep 61 are compared with the objective of accuracy and reliability, the degradation being known via the parameter table: if the calculation could be carried out to completion, without adjustment of the parameters, the calculation is said to be complete and the client is notified of the result via a sub-step 66; in the opposite case, the calculation is said to be "intermediate", and the client is notified via a substep 63. This substep 63 is followed by a substep 64 where it is determined whether a calculation complement is necessary: if the objective of precision and reliability requested by the client is reached, the calculation is considered complete and the process returns to the first substep 61 to start the next calculation from the request which is executed in the stack 39, or waiting if there is no stacked request in the stack; if the goal of accuracy and reliability is not achieved, the full calculation is started in a next substep 65. This calculation is performed on a possibly lower real-time priority task that can be pushed back in time to let the higher priority calculations in the stack. This substep 65 is followed by substep 66 of the complete calculation notification to the client.
    [0031] In another possible embodiment, the complete calculation is started in the process, before the calculations remaining to be made in the stack, to finish responding to the client. FIG. 7 shows an example of a physical representation of the clients in the case of application to an FMS system, of the type particularly that described in FIG. 1. The server is a flight management application. The system comprises for example two physical modules 111, 112 forming the physical resources each including a server. In this example, the server is a flight management application.
    [0032] Since the system is redundant, the two physical resources perform the same functions. The identified and known clients 1, 2, 3 are housed in the physical modules 111, 112, physical modules of the FMS. The external clients, not identified beforehand, can be applications that are hosted in the physical modules 111, 112 hosting the server, or applications distributed in the airplane in other physical modules 113, 114, 115. example of Figure 7, three external clients A, B, C are hosted in the physical module 111, and two external clients A and B are hosted in the physical module 112. For this purpose, the customers A, B, C have by For example, RAMs internal to the modules as physical resources, client codes A, B, C being copied to the internal RAMs of the module to which they are connected (111 for A, B, C and 112 for A, B). Other external clients D, E, F, G communicate with the physical modules via an AFDX link, access is through the standardized protocols, ARINC 653, in the example of Figure 7. The 20 customers can be among the following applications: an HMI, an integrated IHS, an AID a CMU a TCAS a TAWS 25 a WIMS or a WxR an EFB a tablet a FQMS a PA 30 a FWS an IFE these applications having been presented during the description of the FMS system in Figure 1. Other client applications are of course possible. Three major service families can be defined to rank all FMS services according to AEEC ARINC 702A.
    [0033] A first family includes the geographic data consultation services 130 (navigation data and dynamic magnetic variation), allowing customers to search for geographical information or magnetic declination on a point of the globe. For this family, the 5 adjustable parameters can be the following: the number of elements returned; the type of priority elements (beacons, airports, crossing points ...); the search space (area or search volume around an element); search countries filtering ICAO codes; A second family includes aircraft characteristic performance (or performance) services involving side-path 120 and prediction 140 and performance database 150, which includes: o aircraft characteristic terminals (eg min and max masses, certified altitude cap, etc.), take-off and landing speeds (so-called characteristic speeds), flight envelope calculations (max. stall, roll max ...); the adjustable parameters being in particular the precision of the calculation and the number of iterations; 25 o integration calculations according to selected aircraft modes (X-foot climb with constant thrust, descent with a determined air gradient and fixed speed, imposed angle turn, etc.), package calculations (for some FMS, simplified performance can be defined in the performance database 150, where the required accuracy is lower); the adjustable parameters being in particular: the integration step sizes; 3025385 27 - the number of iterations; - the calculation or not of corner transitions on the lateral trajectory; the test or not of flight envelope limits (saturation); - the format of the floats; linearization of the functions mainly used (trigonometric functions for example).
    [0034] A third family comprises the services "flight management": o consultation of the state of the aircraft (position, speed, states of the systems connected to the FMS, as the state engines, the modes 15 engaged in autopilot, etc ... ^ the adjustable parameters being in particular the number of parameters; o consultation and modification of flight plan and trajectory 5D; ^ the adjustable parameters being the same as for the 20 services of consultation of the performances of the aircraft; consultation and modification of flight initialization data (capture of take-off speeds, cruising altitude, expected weather, fuel consumption modes, etc.); the adjustable parameters being the same as for the 25 aircraft performance consulting services, the method applies for example in cases where the server is an application among the following applications: an FMS 30 an IHM, an integrated IHS, u n AID a CMU 3025385 28 a TCAS - a TAWS a WIMS or a WxR - an EFB 5 - a tablet a FQMS - a PA - a FWS an IFE 10 - a rolling application These applications were presented during the description of the system FMS of Figure 1. To these application, we can add an application is a taxi application (TAXI). The clients may be any of the previous applications other than the server, as well as any other application. The invention also applies to an FMS device where the server is an application among: - the navigation database NAV DB, 130; PRF performance database DB, 150; the FPLN flight function, 110; the lateral trajectory function TRAJ, 120; prediction function PRED, 140; the guiding function GUID, 200; Location LOC LOC NAV, 170; the DATA LINK digital data link, 180; the human-machine interface HMI. Clients can be any of these applications other than the server, as well as any application.
    [0035] The invention has the particular advantages that it allows, via the creation of intermediate calculations with adjusted parameters: to minimize the refusal rate of customer requests; allocate computing time to third-party customers, even a small one, in a guaranteed way; to always be able to give a prior answer of acceptance or refusal of assumption of responsibility of a request, accompanied by a statute on the precision and the reliability which will result from the computation. The invention also has the advantage that it allows, via the notion of execution rules, to obtain a good compromise between the flexibility left to the client 10 to manage its requests and the performances in computing time of the server. The method according to the invention also advantageously allows a client to have a return on the time required to perform a calculation when it has fixed a certain number of parameters to preserve and that it fixed the adjustments for the parameters to be adjusted . 15
    权利要求:
    Claims (20)
    [0001]
    REVENDICATIONS1. Method for real-time execution of services by a so-called "server" application for at least one so-called "client" application, characterized in that a preliminary step (30) establishing for each service (S (i)) a list of parameters of calculation (Param (i, j)) able to vary in a given domain, said adjustable, as well as calculation time and quality information of said service according to the value of said parameters, on request (51) of a client ( 50) for a given service said method adjusts (52) the value of the adjustable calculation parameters according to a given constraint, the service being executed (33) using the adjusted values of said parameters.
    [0002]
    2. Method according to claim 1, characterized in that said given constraint implies a maximum duration of response time to said request.
    [0003]
    3. Method according to any one of the preceding claims, characterized in that said given constraint involves the use of a set of non-adjustable calculation parameters.
    [0004]
    4. Method according to any one of the preceding claims, characterized in that said constraint is supplied to the server by said client.
    [0005]
    5. Method according to any one of the preceding claims, characterized in that, for each service S (i), the adjustable parameters are classified by priority (P (i, kp)), in case of necessary adjustment of the parameters. to respond to said given constraint: - the highest priority parameter (P (i, k1)) is first adjusted and the execution time of said service being calculated 25 - if the adjustment of said highest priority parameter high ((P (i, k1)) does not respond to the given constraint, even at the stop of its range of variation, the next priority parameter (P (i, k2)) is adjusted, the value of the parameter of highest priority ((P (i, k1)) remaining frozen in abutment of its range of variation; 3025385 31 and so on, in order of priority (P (i, kp)) to meet the constraint or until all the adjustable parameters have been stopped in their respective range of variation.
    [0006]
    6. Method according to any one of claims 1 to 4, characterized in that, for each service S (i), the adjustable parameters are classified by priority (P (i, kp)), in case of necessary adjustment. parameters to respond to said given constraint: - the highest priority parameter (P (i, k1)) is first adjusted to a first target value (V_target (i, k1)) within its variation domain and the execution time of said service being calculated; if the adjustment of said highest priority parameter (P (i, k1)) does not make it possible to respond to the given constraint, even at the abutment of said first target value (V_target (i, k1)), the parameter next priority (P (i, k2)) is adjusted to a second target value (target V (i, k2) within its range of variation, the value of the highest priority parameter ((P (i, k1)) remaining fixed in abutment of the first target value (V_cible (i, k1)), and so on, in order of priority (P (i, kp)) up to respond to the constraint or until that all the adjustable parameters have been stopped, if the adjustment is not sufficient after having reached all the target values (V_cible (i, kp)) in abutment, new internal target values to the domains of variations said parameters being defined.
    [0007]
    7. Method according to any one of claims 5 or 6, characterized in that the parameters of a subset of said list are first adjusted.
    [0008]
    8. Method according to any one of the preceding claims, characterized in that said list of adjustable parameters is established by said client.
    [0009]
    9. Method according to any one of the preceding claims, characterized in that said ranges of variation of said parameters are determined by said client. 3025385 32
    [0010]
    10. Method according to any one of the preceding claims, characterized in that at least one intermediate result of execution of said service is calculated with its quality is service.
    [0011]
    11. The method of claim 10, characterized in that said intermediate result is notified (63) to said client.
    [0012]
    12. Method according to any one of claims 10 or 11, characterized in that the complete execution (65) of said service is performed after said intermediate calculation.
    [0013]
    13. The method as claimed in claim 10, wherein a plurality of successive intermediate results are calculated, with parameters less and less adjusted to each calculation, until the complete calculation of said service without adjustment is completed. said parameters, a less and less adjusted parameter being a parameter whose value is moving further and further away from the value for responding to said given constraint.
    [0014]
    14. Method according to any one of the preceding claims, characterized in that the parameters of said list are adjusted at each new request reception (51).
    [0015]
    15. Method according to any one of the preceding claims, characterized in that the execution of said request is refused (55) if its execution with said adjustable parameters does not make it possible to respond to said given constraint.
    [0016]
    16. Method according to any one of the preceding claims, characterized in that information is transmitted to said client if the execution of said request with said adjustable parameters does not respond to said given constraint.
    [0017]
    17. Real-time system implementing the method according to any one of the preceding claims, comprising at least one physical module (111) where the server is located, characterized in that the clients are external applications implanted in said physical module. said clients communicating with the server via an internal memory module. 3025385 33
    [0018]
    18. System according to claim 17, characterized in that the clients are external applications distributed in other physical modules (113, 114, 115) and communicating with the server via a network protocol.
    [0019]
    19. System according to any one of claims 17 or 18, characterized in that the server is a flight management application.
    [0020]
    20. System according to claim 19, characterized in that the customers belong to the following list of applications: a HMI an IHS 10 an AID a CMU a TCAS a TAWS a WIMS 15 a WxR an EFB - a FQMS a PA a FWS 20 - an IFE - a rolling application. 25
    类似技术:
    公开号 | 公开日 | 专利标题
    EP2945062A1|2015-11-18|Method for performing services in real time, in particular flight management and real-time system implementing such a method
    EP2991274B1|2017-02-01|Method for performing services in adaptive real time, in particular flight management and real-time system implementing such a method
    FR3055958A1|2018-03-16|DECISION AID FOR THE REVISION OF A FLIGHT PLAN
    FR3025920A1|2016-03-18|METHOD FOR REAL-TIME CALCULATION OF A PLANNED TRACK, IN PARTICULAR A FLIGHT PLAN, COMBINING A MISSION, AND A SYSTEM FOR MANAGING SUCH A TRAJECTORY
    US10237685B2|2019-03-19|Cognitive geofencing
    FR3013831A1|2015-05-29|AVIONIC SYSTEM OF AN AIRCRAFT
    FR3030805A1|2016-06-24|QUALITY OF SERVICE OF A FLIGHT MANAGEMENT SYSTEM
    US20180293687A1|2018-10-11|Ridesharing management for autonomous vehicles
    US10889297B2|2021-01-12|Determining a safe driving speed for a vehicle
    EP3712762A1|2020-09-23|Methods and systems for generating and recommending api mashups
    FR3038750A1|2017-01-13|METHOD FOR INTEGRATING A NEW NAVIGATION SERVICE IN AN OPEN AIR ARCHITECTURE OPEN ARCHITECTURE SYSTEM OF A CLIENT-SERVER TYPE, IN PARTICULAR A FIM MANUFACTURING SERVICE
    US20180160263A1|2018-06-07|Cognitive Geofencing
    FR3067801A1|2018-12-21|METHOD AND SYSTEM FOR AIDING THE FLIGHT MANAGEMENT OF AN AIRCRAFT IN TERMS OF OPTIMIZATION OF THE OPERATIONAL COSTS OF THE AIRCRAFT
    FR3082829A1|2019-12-27|AIRCRAFT MANAGEMENT
    FR3035534A1|2016-10-28|METHOD AND SYSTEM FOR COMMUNICATING AND SHARING INFORMATION FOR AIRCRAFT
    FR3031806A1|2016-07-22|METHOD FOR AIDING NAVIGATION ACCORDING TO WEATHER CONDITIONS
    FR3038751A1|2017-01-13|METHOD FOR INTEGRATING A CONSTRAINED ROAD OPTIMIZATION APPLICATION IN AN OPEN ARCHITECTURE AIRCRAFT SYSTEM OF CLIENT-TYPE SERVER
    US20200164881A1|2020-05-28|Vehicle passing controller
    US10855753B2|2020-12-01|Distributed computing of vehicle data by selecting a computation resource of a remote server that satisfies a selection policy for meeting resource requirements according to capability information
    FR3003971A1|2014-10-03|METHOD AND DEVICE FOR CALCULATING PREDICTIONS ON A FLIGHT PLAN OF AN AIRCRAFT
    US10760915B2|2020-09-01|Synchronizing nodes at a meeting point
    US11284293B2|2022-03-22|Location-based telecommunication prioritization
    US20220028282A1|2022-01-27|Data analysis of drone and aviation airspace for generating drone flight path
    US20220068125A1|2022-03-03|Autonomous vehicle management based on object detection
    US20210256576A1|2021-08-19|Utilizing a directional filter for a geotemporal destination mode of a dynamic transportation matching system
    同族专利:
    公开号 | 公开日
    US10104012B2|2018-10-16|
    EP2991274B1|2017-02-01|
    EP2991274A1|2016-03-02|
    FR3025385B1|2016-08-12|
    CA2902315A1|2016-03-01|
    US20160065497A1|2016-03-03|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US20070263541A1|2006-05-11|2007-11-15|Computer Associates Think, Inc.|Automatic correlation of service level agreement and operating level agreement|
    FR2920236A1|2007-08-20|2009-02-27|Airbus France Sas|METHOD AND DEVICE FOR TRANSMITTING GEOGRAPHIC DATA ON AN AIRCRAFT|
    EP2270664A2|2009-06-30|2011-01-05|Sap Ag|Integrated performance and load testing tool for application servers|
    US8484643B2|2003-03-31|2013-07-09|Fujitsu Limited|CPU usage time counting method and job control system using this CPU usage time|
    US9065739B2|2004-02-03|2015-06-23|Nokia Technologies Oy|Method and apparatus for providing end-to-end quality of service |
    US7624208B2|2005-01-14|2009-11-24|International Business Machines Corporation|Method, system, and computer program for managing a queuing system|
    FR2939505B1|2008-12-09|2011-02-11|Thales Sa|FLIGHT MANAGEMENT SYSTEM WITH LATERAL FLIGHT PLAN OPTIMIZATION|
    US8380850B1|2011-03-22|2013-02-19|Amazon Technologies, Inc.|System and method for damping overload state oscillations|
    FR3021108B1|2014-05-16|2016-05-06|Thales Sa|METHOD FOR REAL-TIME SERVICE EXECUTION, IN PARTICULAR FLIGHT MANAGEMENT, AND REAL-TIME SYSTEM USING SUCH A METHOD|FR3046273B1|2015-12-23|2018-10-12|Thales|OPEN ARCHITECTURE FOR FLIGHT MANAGEMENT SYSTEM|
    US10281586B2|2016-04-07|2019-05-07|Thales USA, Inc.|Transmission data for flight check|
    US10147330B2|2017-03-31|2018-12-04|The Boeing Company|Aircraft flight path holding pattern system and method|
    US10778805B2|2017-07-18|2020-09-15|International Business Machines Corporation|Identifying application preemptive requests|
    US10797945B2|2017-11-10|2020-10-06|Honeywell International Inc.|Methods are provided for flight management services in a cloud environment|
    US10991255B2|2018-04-05|2021-04-27|Ge Aviation Systems Llc|Providing an open interface to a flight management system|
    法律状态:
    2015-08-25| PLFP| Fee payment|Year of fee payment: 2 |
    2016-03-04| PLSC| Publication of the preliminary search report|Effective date: 20160304 |
    2016-08-26| PLFP| Fee payment|Year of fee payment: 3 |
    2017-08-29| PLFP| Fee payment|Year of fee payment: 4 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1401937A|FR3025385B1|2014-09-01|2014-09-01|METHOD FOR EXECUTING ADAPTIVE REAL-TIME SERVICES, IN PARTICULAR FLIGHT MANAGEMENT, AND REAL-TIME SYSTEM USING SUCH A METHOD|FR1401937A| FR3025385B1|2014-09-01|2014-09-01|METHOD FOR EXECUTING ADAPTIVE REAL-TIME SERVICES, IN PARTICULAR FLIGHT MANAGEMENT, AND REAL-TIME SYSTEM USING SUCH A METHOD|
    EP15182164.2A| EP2991274B1|2014-09-01|2015-08-24|Method for performing services in adaptive real time, in particular flight management and real-time system implementing such a method|
    CA2902315A| CA2902315A1|2014-09-01|2015-08-27|Adaptive method for the execution of services in real time, notably of flight management and real time system using such a method|
    US14/842,253| US10104012B2|2014-09-01|2015-09-01|Adaptive method for the execution of services in real time, notably of flight management and real time system using such a method|
    [返回顶部]