EP4619873A1 - Procede et dispositif de controle d'au moins un dispositif embarque dans un aeronef - Google Patents

Procede et dispositif de controle d'au moins un dispositif embarque dans un aeronef

Info

Publication number
EP4619873A1
EP4619873A1 EP23813447.2A EP23813447A EP4619873A1 EP 4619873 A1 EP4619873 A1 EP 4619873A1 EP 23813447 A EP23813447 A EP 23813447A EP 4619873 A1 EP4619873 A1 EP 4619873A1
Authority
EP
European Patent Office
Prior art keywords
core
clt
data
cor2
control
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23813447.2A
Other languages
German (de)
English (en)
Inventor
Olivier AVONDET
Damien LE BAIL
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Safran Electronics and Defense SAS
Original Assignee
Safran Electronics and Defense SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Safran Electronics and Defense SAS filed Critical Safran Electronics and Defense SAS
Publication of EP4619873A1 publication Critical patent/EP4619873A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/167—Interprocessor communication using a common memory, e.g. mailbox

Definitions

  • the present invention relates to the fields of control devices and on-board systems. More particularly, the present invention relates to a device for controlling at least one device on board an aircraft, and an aircraft, a control method, an application method, a set of computer programs and an associated information medium.
  • the present invention finds a particularly advantageous application, although in no way limiting, for the implementation of devices for controlling electric motors for actuating flight controls.
  • a control device e.g. a computer
  • takes as input piloting commands e.g. provided by a stick, or an autopilot
  • data from sensors e.g. an inertia control unit, a Pitot probe
  • actuation motors e.g. an aileron actuator
  • control device uses several software components (i.e. several computer programs) to determine the control signals from the control commands and the measured data.
  • software components respectively implementing specific functions necessary for control, can be produced by different suppliers.
  • operating several programs on the same control device requires solving problems of integration and management of the executions of these different programs.
  • one solution consists of integrating several software components within the same program and executing this program on a dedicated processor, such as a DSP (acronym for the English expression “Digital Signal Processor”, which is translated as “digital signal processor”).
  • DSP digital Signal Processor
  • Such a solution makes it possible to achieve high processing speed while maintaining low complexity of the control device.
  • These advantages are nevertheless counterbalanced by a certain number of disadvantages.
  • the common and complex integration of the software components within the same program must be systematically redone and certified again.
  • an error in the execution of one of the software components can lead to a general malfunction of the control device, a situation which must be absolutely avoided for critical applications, such as aeronautics.
  • the present invention aims to remedy all or part of the disadvantages of the prior art, in particular those explained above.
  • a device for controlling at least one device on board an aircraft based on flight data provided by at least one source device comprising a multi-processor - hearts comprising: a first heart; a second heart (distinct from the first heart); and an inter-core communication interface, the second core being isolated from said at least one embedded device and said at least one source device, and the first core being configured to: provide, via the inter-core communication interface, data input obtained from flight data; obtaining, via the inter-core communication interface, output data; and providing, to said at least one on-board device, control data obtained from the output data.
  • multi-core processor we mean here a processor (e.g. a microprocessor integrated on a single circuit) comprising several processing units (called cores) physically separated and executing computer program instructions.
  • a “core” designates a processing unit (i.e. a set of circuits within a processor) capable of executing computer program instructions.
  • flight data designates data characterizing a flight of the aircraft (ie comprising the different phases of flight such as taxiing, takeoff, cruising, landing , etc.).
  • the flight data may include control data provided by a piloting device (eg manual or automatic) and/or data measured by one or more sensors of the aircraft (eg an inertial unit, a Pitot probe, a temperature sensor).
  • the second core is isolated from the on-board devices to be controlled and from the source devices producing the flight data and cannot communicate with these devices. In other words, the second core does not have an active communication interface external to the processor.
  • the present invention proposes a control device (i.e. a platform) making it possible to execute on the second core a computer program (for example, a software component provided by a third party) in a materially and temporally isolated manner. ment of a program executed on the first core.
  • a control device i.e. a platform
  • a computer program for example, a software component provided by a third party
  • the proposed control device makes it possible to execute: on the first core, a program implementing the control function of the on-board devices; and on the second core, a program implementing a specific algorithm necessary for the control function.
  • the present invention makes it possible to exploit the hardware characteristics of a multi-core processor to physically and temporally separate the executions of several programs within a control device.
  • the proposed control device makes it possible to execute on each of the cores a program with its own time constraints (i.e. temporal isolation between a program executed on the first core and a program executed on the second core).
  • the use of a multi-core processor as proposed makes it possible to achieve a high processing speed (i.e. calculation frequency) while maintaining low complexity.
  • the proximity between the processor cores makes it possible to quickly exchange data between several programs via the inter-core communication interface (e.g. including high-frequency RAM).
  • the control device can thus operate at a high working frequency.
  • the present invention provides a rapid and low complexity control device making it possible to physically and temporally separate the executions of several programs.
  • the proposed control device makes it possible to respond to the constraints specific to embedded systems in terms of complexity, processing speed, size and operational safety.
  • the first core is configured to execute a so-called control program obtaining the flight data (coming from said at least one source device) and providing the control data (auditing at least one on-board device).
  • the second core is configured to execute a so-called application program obtaining the input data (from the first core) and providing the output data (to the first core).
  • program here refers to a computer program comprising instructions executable by at least one core, processor, or computer.
  • control program e.g. produced by a supplier
  • application program e.g. produced by another supplier
  • implements a specific algorithm necessary for the control function e.g. a force law algorithm.
  • this embodiment makes it possible to physically and temporally separate the executions of the control program and the application program.
  • an execution error of the application program does not result in an execution error of the control program.
  • the two programs can be executed at the same time without mutual blocking (i.e. no corruption between these programs), which contributes to improving the operational safety of the control device.
  • the application program does not have an external communication interface and cannot communicate with the source devices producing the flight data and the on-board devices to be controlled. In other words, all of the data exchanged by the application program are communicated via the inter-core communication interface with the control program.
  • This embodiment advantageously makes it possible to independently certify the control program and the application program, the exchanges between these programs being able to be considered as predefined interfaces. Also, the respective developments of these programs are made independent.
  • this embodiment makes it possible to guarantee the confidentiality of their programs to the respective suppliers of the control program and the application program. Thanks to the proposed solution, it is not necessary to have access to the source code of the program application to control on-board devices.
  • the application program can thus be provided in binary form for example.
  • the multi-core processor of the control device is a dual-core digital signal microprocessor comprising the first and the second core.
  • digital signal microprocessor we mean here a processor whose all components are implemented on the same integrated circuit and whose architecture is dedicated to (optimized for) the implementation of digital signal processing functions , more commonly referred to by the acronym DSP.
  • this embodiment advantageously makes it possible to achieve a high processing speed while maintaining low complexity. This results in an improvement in the performance of the proposed control device in terms of cost, size, and energy consumption.
  • the inter-core communication interface comprises: two unidirectional exchange memories; or a bidirectional exchange memory.
  • the exchange memory(s) of the inter-core communication interface may be high-frequency RAMs.
  • This embodiment makes it possible to quickly exchange data between the cores of the processor, and therefore between programs executing respectively on these cores. In this way, this embodiment contributes to providing a control device with high processing speed.
  • the inter-core communication interface comprises means of transmission (e.g. a communication bus) of trigger signals (also called “events”) between the first core and the second core.
  • trigger signals also called “events”
  • This embodiment allows one of the processor cores to trigger the execution of one or more steps on another processor core. This embodiment thus makes it possible to coordinate the execution of different programs executed respectively on different cores.
  • the first and second core communicate via the inter-core communication interface using only the exchange memory(s) and the trigger signal transmission means. More precisely, the second core does not include, according to one embodiment, any active communication interface external to the processor.
  • an aircraft comprising: a control device according to the invention; at least one source device; and at least one on-board device.
  • said at least one source device provides flight data and said at least on-board device is controlled by the control device from the flight data.
  • the proposed aircraft has the advantages described above in connection with the control device according to the invention.
  • said at least one on-board device comprises an electric actuator of a control surface of the aircraft.
  • This embodiment thanks to the use of the proposed control device, makes it possible to implement the flight controls of an aircraft reliably and quickly.
  • said at least one on-board device comprises a digitally controlled inverter.
  • a method for controlling at least one device on board an aircraft based on flight data provided by at least one source device, the control method comprising steps , implemented by a first core of a multi-core processor, of: supplying, via an inter-core communication interface of the multi-core processor, input data obtained from flight data; obtaining, via the inter-core communication interface, output data; and providing, to said at least one on-board device, control data obtained from the output data.
  • the proposed control method has the advantages described above in connection with the control device according to the invention.
  • control method is implemented by the control device according to the invention.
  • the proposed control device makes it possible to execute, temporally and materially separately: on the first core, a control program implementing the control function of the on-board devices; and on the second core, an application program implementing an algorithm necessary for the control function.
  • the control method comprises a step of sending, by the first core to a second core of the processor, a signal triggering a supply by an application program (executed on the second heart) of said output data obtained from said input data. More precisely, this trigger signal is sent via an inter-core communication interface of the multi-core processor.
  • the first core triggers, when necessary, the implementation by the second core of a specific algorithm necessary for the control function (e.g. a force law algorithm implemented by the application program).
  • a specific algorithm necessary for the control function e.g. a force law algorithm implemented by the application program.
  • this embodiment makes it possible to coordinate the executions of different programs executed respectively on different cores of the processor (e.g. the control program executed on the first core and the application program executed on the second core).
  • control method comprises a step of sending, by the first core to the second core, a signal for triggering a start of the application program.
  • this trigger signal is sent via the inter-core communication interface of the multi-core processor.
  • This embodiment allows the first core to start execution of the application program by the second core.
  • control method comprises steps, implemented by the second core to start the application program, of: if the application program is loaded on the second core (i.e. on a memory of the second core ), initialization of configuration data of the application program and triggering of execution by the second core of the application program; and otherwise, loading on the second core (i.e. on a memory of the second core) of the application program and triggering a start of the application program.
  • control method comprises a verification step, implemented by the second core, of a digital signature associated with the application program.
  • this embodiment makes it possible to guarantee the security of the control device and to protect it from potential computer attacks (e.g. a modification of the application program for malicious purposes).
  • control method comprises a step of stopping or resetting the second core, implemented by the second core and triggered by an execution error of the application program.
  • This embodiment makes it possible to process an execution error of the application program and thus contributes to improving the operational safety of the control device.
  • a so-called control computer program comprising instructions for executing the steps, implemented by a first core of a multi-core processor, of a control method according to the invention, when said control program is executed by the first core.
  • control program is executed by the first core of the multi-core processor of a control device according to the invention.
  • a set of computer programs comprising: a control program according to the invention; and at least one other program.
  • Said at least one other program comprises instructions for executing the steps, implemented by a second core of a multi-core processor, of a control method according to the invention, when said at least one other program is executed through the second heart.
  • said at least one other program is executed by the second core of the multi-core processor of a control device according to the invention.
  • an application method is proposed implemented by a second core of a multi-core processor, the second core being isolated in that it communicates only with a first core of the multi-core processor and via an inter-core communication interface, said application method comprising steps of: obtaining, via the inter-core communication interface, input data; obtaining output data from input data; and providing, via the inter-core communication interface, the output data.
  • a computer program comprising instructions for implementing the steps of an application method in accordance with the invention, when the application program is executed. by a second core of a multi-core processor.
  • the application program is in particular executed by the second core of the multi-core processor of a control device according to the invention.
  • a computer-readable information medium comprising: a control program according to the invention; and/or a set of computer programs according to the invention; and/or an application program conforming to the invention.
  • a computer program can be formed from one or more sub-parts stored in the same memory or in separate memories.
  • the program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable shape.
  • an information carrier can be any entity or device capable of storing the program.
  • the support may comprise a storage means, such as a non-volatile memory or ROM, for example a CD-ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a floppy disk or a hard disc.
  • the storage medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by a telecommunications network or by a computer network or by other means.
  • the program according to the invention can in particular be downloaded onto a computer network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in executing the method in question.
  • Figure 1 represents an example of software and hardware architecture of an aircraft according to one embodiment of the invention
  • Figure 2 represents an example of software and hardware architecture of a control device according to one embodiment of the invention
  • Figure 3A and Figure 3B respectively represent an example of software and hardware architecture of an aircraft and steps of a control method according to one embodiment of the invention.
  • Figure 4A and Figure 4B respectively represent an example of software and hardware architecture of an aircraft and steps of a control method according to one embodiment of the invention.
  • Figure 1 represents an example of software and hardware architecture of an aircraft according to one embodiment of the invention.
  • Figure 1 is described below to introduce the present invention and exemplify a particular context of application thereof.
  • the AC aircraft comprises: an APP control device; at least one NAV source device; and at least one ACT on-board device. More precisely, the APP control device is configured to: take as input NAV_DATA flight data produced by said at least one NAV source device; and providing output control data ACT_CMD to control said at least one on-board device ACT.
  • the NAV_DATA flight data may include NAV_CMD control data from a piloting device (automatic or manual) of the AC aircraft. Also, the flight data may include data measured by one or more sensors of the AC aircraft, such as an inertial unit, a Pitot probe, a temperature sensor, etc.
  • the present invention applies, in particular, to the control of electric motors for operating the flight control of an aircraft.
  • the following description of the present invention refers to this particular context, given by way of illustrative example and devoid of any limiting character.
  • embodiments could be considered in which the ACT on-board devices to be controlled comprise one or more digitally controlled inverters.
  • said at least one on-board device ACT to be controlled comprises one or more actuators (eg electrical) for steering the aircraft AC.
  • the control device APP controls one or more steering actuators ACT of the aircraft AC.
  • the APP control device requires the execution of several computer programs (in particular produced by different suppliers) to control the ACT on-board devices.
  • the control device APP requires the execution of a control program PLT_SW and an application program CLT_SW. More precisely, the PLT_SW control program implements the control function and ensures the interface with the NAV source devices and with the ACT on-board devices; and the application program CLT_SW implements a specific algorithm necessary for controlling these ACT devices.
  • the application program CLT_SW can implement a force law algorithm making it possible to determine the instructions to be applied to a control surface of the aircraft AC.
  • the PLT_SW control program obtains, from the NAV source devices, data from an inertial unit and a desired attitude of the AC aircraft. From the inertia data, it determines a current attitude and a speed of the aircraft AC. Then, the control program PLT_SW provides the application program CLT_SW: the current attitude; speed ; and the desired attitude. Using an effort law, the CLT_SW application program determines a degree of inclination to apply to an aileron to achieve the desired attitude as a function of the current attitude and the speed of the aircraft AC. The application program CLT_SW provides the calculated degree of inclination to the control program PLT_SW which then determines an activation time of a rudder actuator to reach this degree of inclination.
  • the present invention proposes an APP control device (i.e. a platform) making it possible to execute any CLT_SW application program in a materially and temporally isolated manner.
  • the application program CLT_SW can be any and is typically provided by a third party entity (for example, delivered by a supplier to the equipment manufacturer implementing the control device). Also, the architecture of the proposed APP control device is independent of the CLT_SW application program.
  • Figure 2 represents an example of software and hardware architecture of a control device according to embodiments of the invention. This figure details the architecture of the APP control device presented with reference to Figure 1.
  • the proposed APP control device comprises a multi-core processor PROC.
  • the APP control device may include any type of components necessary for its operation, such as a power source, connection ports, communication modules, memories, etc.
  • the processor PROC comprises: at least a first core COR1 and a second core COR2; and an ICC inter-core communication interface.
  • each of the cores COR1-COR2 of the multi-core processor PROC can autonomously execute computer program instructions.
  • each of the COR1-COR2 cores can respectively comprise at least one element among: one or more cache memories, an ordinal counter, one or more registers, and one or more calculation units.
  • the PROC processor includes only two COR1-COR2 cores.
  • the PROC processor comprises more than two cores.
  • the processor PROC is a microprocessor (i.e. a processor of which all the components are integrated on the same circuit). More particularly, the PROC processor is a multi-core DSP according to one embodiment. Such a processor has an architecture optimized to implement digital signal processing functions as quickly as possible. The use of a DSP advantageously results in an improvement in the performance of the APP control device in terms of complexity, size, and energy consumption.
  • the PROC processor is a dual-core DSP.
  • the inter-core communication interface ICC comprises: two unidirectional exchange memories MEM1 and MEM2 (e.g. high-frequency RAMs); and EVT_BUS transmission means (e.g. a communication bus) of trigger signals (also called “events”).
  • MEM1 and MEM2 e.g. high-frequency RAMs
  • EVT_BUS transmission means e.g. a communication bus
  • trigger signals also called “events”.
  • the memory MEM1 is used to exchange data from the first core COR1 to the second core COR2, that is to say data written by the first core COR1 on the memory MEM1 and read by the second core COR2.
  • the MEM2 memory is used to exchange data from the second core COR2 to destination of the first core COR1, that is to say data written by the second core COR2 on the memory MEM1 and read by the first core COR1.
  • the MEM1-MEM2 memories allow data to be exchanged between the COR1-COR2 cores.
  • the proximity between the COR1-COR2 cores allows data to be exchanged at a high communication rate between programs running on these cores, thereby helping to provide a fast APP control device.
  • the EVT_BUS transmission means make it possible to exchange trigger signals between the COR1-COR2 cores. Such signals are used to trigger from one of the COR1-COR2 cores the execution of one or more steps on another COR1-COR2 core, which makes it possible to coordinate program executions on the COR1-COR2 cores.
  • the first core COR1 is configured to execute the PLT_SW control program.
  • the PLT_SW control program interfaces with the NAV source devices and the ACT onboard devices to be controlled. More generally, the PLT_SW control program implements the control function (i.e. management of hardware, interfaces, sequencing of the control of on-board devices).
  • the first COR1 core can exchange data with a program executed on the second COR2 core using the MEM1-MEM2 memories of the ICC interface. Also, the first core COR1 can trigger the execution of one or more steps by a program executed on the second core COR2 by sending trigger signals via the EVT_BUS transmission means of the ICC interface. More generally, the first COR1 core is the master of data exchanges and events.
  • the second core COR2 is configured to communicate only with the first core COR1 via the ICC interface.
  • the second COR2 core is configured such that it does not have an active communication interface external to the PROC processor. In this sense, the second COR2 core is isolated from the NAV source devices and the ACT onboard devices to be controlled.
  • the proposed APP control device makes it possible to execute on the second COR2 core any program in material and temporal isolation from the PLT_SW control program executed on the first COR1 core.
  • the proposed APP control device makes it possible to execute a program on each of the COR1-COR2 cores with its own time constraints (ie temporal isolation).
  • the control device APP makes it possible to use different frequency plans between the control program PLT_SW executed on the first core COR1 and a program executed on the second core COR2.
  • an execution error of a program executed on the second COR2 core does not lead to a malfunction of the APP control device.
  • the APP control device also makes it possible to guarantee the confidentiality of a program executed on the second COR2 core.
  • the APP control device makes it possible to achieve a high processing speed (i.e. a calculation frequency) while maintaining low complexity. More generally, the APP control device makes it possible to respond to the specific constraints of embedded systems in terms of complexity, processing speed, size and reliability.
  • Figure 3A and Figure 3B respectively represent an example of software and hardware architecture of an aircraft and steps of a control method according to one embodiment of the invention.
  • Figure 3B illustrates a control method according to one embodiment of the invention implemented by the APP control device of Figure 3A.
  • the first COR1 core of the APP control device is configured to execute the PLT_SW control program and the second COR2 core of the APP control device is configured to execute the CLT_SW application program.
  • the control method comprises at least one of the steps described below. Note that the steps of the proposed control method implemented by the first core COR1 are denoted by S1XX and that the steps implemented by the second core COR2 are denoted S2XX.
  • step S100 the first core COR1 executes the control program PLT_SW comprising instructions for implementing steps S120 to S160 described below.
  • control program PLT_SW can include instructions for carrying out each of the steps S1XX of the control method according to the invention and implemented by the first core COR1, when these instructions are executed by the first core COR1 .
  • the second core COR2 executes the application program CLT_SW comprising instructions for implementing steps S241 to S243 described below.
  • application process all of the steps S241 to S243 implemented by the second core COR2, when it executes the application program CLT_SW.
  • control program PLT_SW and the application program CLT_SW are executed concurrently, that is to say during overlapping periods of time. In other words, steps S100 and S240 are carried out concomitantly.
  • the first core COR1 (i.e. the control program PLT_SW) obtains the NAV_DATA flight data from the NAV source devices.
  • the first core COR1 obtains during this step: data from an inertia control unit; and a piloting command such as a desired attitude of the aircraft AC.
  • step S130 the first core COR1 (i.e. the control program PLT_SW) provides input data IN_CLT to the second core COR2 (i.e. the application program CLT_SW) via the interface ICC.
  • the first core COR1 writes in step S130 the input data IN_CLT to the memory MEM1 of the ICC interface, the input data IN_CLT being obtained from the flight data NAV_DATA.
  • control program PLT_SW can determine a current attitude and a speed of the aircraft AC from inertia data.
  • the input data IN_CLT supplied to the application program CLT_SW can include a current attitude, a speed of the aircraft AC and a desired attitude.
  • step S140 the first core COR1 (i.e. the control program PLT_SW) triggers a supply by the second core COR2 (i.e. by the application program CLT_SW) of output data OUT_CLT. More precisely, the first core COR1 sends in step S140 a trigger signal EVT_TRIG to the second core COR2 via the transmission means EVT_BUS (not shown in Figure 3A) of the ICC interface.
  • the EVT_TRIG signal triggers the implementation of steps S241 to S243 by the second core COR2.
  • step S241 the second core COR2 (ie the application program CLT_SW) obtains the input data IN_CLT coming from the first core COR1 (ie coming from the control program PLT_SW). In fact, the second core COR2 reads in step S241 the input data IN_CLT on the memory MEM1 of the ICC interface. [0117] In step S242, the second core COR2 (The application program CLT_SW) obtains the output data OUT_CLT from the input data IN_CLT.
  • the application program CLT_SW can determine, using a force law, a degree of inclination to be applied to an aileron to achieve a desired attitude of the aircraft AC as a function of his running attitude and his speed.
  • step S243 the second core COR2 (i.e. the application program CLT_SW) provides the output data OUT_CLT to the first core COR1 (i.e. the control program PLT_SW) via the ICC interface.
  • the second core COR2 writes in step S243 the output data OUT_CLT to the memory MEM2 of the ICC interface.
  • step S150 the first core COR1 (i.e. the control program PLT_SW) obtains the output data OUT_CLT coming from the second core COR2 (i.e. coming from the application program CLT_SW) via the interface ICC.
  • the first core COR1 reads in step S150 the output data OUT_CLT from the memory MEM2 of the ICC interface.
  • step S160 the first core COR1 (i.e. the control program PLT_SW) provides, to the on-board devices ACT, the control data ACT_CMD obtained from the output data OUT_CLT.
  • the control program PLT_SW i.e. the control program PLT_SW
  • control program PLT_SW can determine an activation time of a rudder actuator to reach the degree of inclination calculated by the application program CLT_SW.
  • the application program CLT_SW can include at least one initialization service and one periodic service, these services being respectively triggered by trigger signals.
  • steps S241 to S243 can correspond to the performance of the initialization service or the periodic service of the application program CLT_SW.
  • the periodic service of the application program CLT_SW can be triggered, repeatedly over time, by the control program PLT_SW to obtain output data OUT_CLT.
  • the control method may comprise a plurality of iterations of steps S120 to S160 and, correlatively, the application method may comprise a plurality of iterations of steps S241 to S243.
  • Figure 4A and Figure 4B respectively represent an example of software and hardware architecture of an aircraft and steps of a control method according to embodiments of the invention. Precisely, these figures are described below to detail the management of the execution of the application program CLT_SW by the control device APP presented with reference to Figures 3A and 3B.
  • the second core COR2 is configured to execute at least one of the following programs: a BOOT startup program; an LDR loading program; a PRE_LDR initialization program; and an interrupt management program INTRPT (also called interrupt vector).
  • a BOOT startup program a program that specifies the operation of the following programs.
  • an LDR loading program a PRE_LDR initialization program
  • an interrupt management program INTRPT also called interrupt vector.
  • the respective functions of these programs are described below with reference to the steps in Figure 4B.
  • step S100 the first core COR1 executes the control program PLT_SW comprising instructions for implementing steps S120 to S160.
  • the control program PLT_SW further includes instructions for carrying out step SI 10.
  • step SI 10 the first core COR1 (i.e. the control program PLT_CW) triggers a start of the application program CLT_SW.
  • the first core COR1 sends a trigger signal EVT_BOOT to the second core COR2 via the transmission means EVT_BUS (not shown in Figure 3A) of the ICC interface.
  • the EVT_BOOT signal triggers the implementation of step S210 by the second core COR2.
  • step SI 10 the first core COR1 implements steps S120 to S160 as previously described with reference to Figures 3A and 3B.
  • step S210 triggered by reception of the signal EVT_BOOT, the second core COR2 executes the BOOT startup program comprising instructions for implementing steps S211 and S212.
  • step S211 the second COR2 core (i.e. the BOOT startup program) starts and/or initializes the second COR2 core.
  • step S212 the second core COR2 (i.e. the startup program BOOT) selects to trigger the execution of the loading program LDR or the initialization program PRE_LDR depending on the presence of the application program CLT_SW on a memory of the second COR2 core.
  • the startup program BOOT i.e. the startup program BOOT
  • step S212 If (and only if) the application program CLT_SW is loaded (ie recorded, stored) on a memory of the second COR2 core, the second COR2 core (ie the BOOT startup program) triggers in step S212 an execution of the initialization program PRE_LDR. In this case, the control process continues in step S230. [0134] Otherwise, if the application program CLT_SW is not loaded on a memory of the second core COR2, the second core COR2 (ie the startup program BOOT) triggers in step S212 an execution of the loading program LDR. In this case, the control process continues in step S220.
  • step S212 can also be made depending on the version of the application program CLT_SW. According to such an embodiment, if the application program CLT_SW loaded on a memory of the second COR2 core corresponds to an obsolete or earlier version of this program, then the second COR2 core (i.e. the BOOT startup program) triggers in step S212 an execution of the LDR loading program to load an updated version of the CLT_SW application program.
  • the second COR2 core i.e. the BOOT startup program
  • step S220 the second core COR2 executes the LDR loading program comprising instructions for carrying out at least steps S221 and S223.
  • step S221 the second core COR2 (i.e. the loading program LDR) loads or updates the application program CLT_SW on a memory of the second core COR2.
  • the second core COR2 obtains the instructions INS_CLT_SW (e.g. the binary code) of the application program CLT_SW coming from the first core COR1 via the ICC interface.
  • the first core COR1 writes the instructions of the application program CLT_SW in the exchange memory MEM1 of the ICC interface; and the second core COR2 reads the instructions of the application program CLT_SW on the exchange memory MEM1.
  • the LDR loading program further includes instructions for carrying out step S222.
  • step S222 the second core COR2 (i.e. the loading program LDR) verifies a digital signature associated with the application program CLT_SW.
  • the signature of the application program CLT_SW can be generated in the following manner.
  • the provider of the CLT_SW application program has a private key/public key pair and a certificate associating the public key with the provider.
  • the provider applies a hash function to the CLT_SW application program code to obtain a fingerprint, then encrypts this fingerprint with its private key to obtain the signature.
  • the supplier provides the APP control device: the application program code CLT_SW; the associated signature; and its certificate.
  • the control device APP can verify the signature of the application program CLT_SW as follows.
  • the APP control device determines a fingerprint of the CLT_SW application program code and, on the other hand, decrypts the digital signature using the public key of the provider's certificate, then compares the results of these two operations. If the fingerprint calculated by the control device APP corresponds to the decrypted signature, then the signature of the application program CLT_SW is valid.
  • step S222 If (and only if) the result of verification step S222 is positive (i.e. valid signature), the control process continues in step S223. Otherwise (i.e. invalid signature), the second COR2 core is inhibited and will not execute the CLT_SW application program. Indeed, the authentication of the CLT_SW application program fails, this may mean that the CLT_SW application program has been modified by a malicious entity.
  • the control device APP verifies the integrity of the application program CLT_SW and authenticates (i.e. verify the identity) the provider of this program. This advantageously makes it possible to improve the security of the APP control device and protect it from possible computer attacks.
  • step S223 the second core COR2 (i.e. the LDR loading program) triggers a start of the application program.
  • the control process thus continues in step S210.
  • step S230 the second core COR2 executes the PRE_LDR initialization program comprising instructions for implementing at least steps S232 and S233.
  • the PRE_LDR initialization program further comprises instructions for carrying out step S231.
  • step S231 the second core COR2 (i.e. the initialization program PRE_LDR) verifies a digital signature associated with the application program CLT_SW.
  • Step S231 can, for example, be implemented in a manner similar to step S221 described above.
  • step S232 the second core COR2 (i.e. the initialization program PRE_LDR) initializes configuration data (e.g. a configuration table) of the application program CLT_SW.
  • configuration data e.g. a configuration table
  • step S233 the second core COR2 (i.e. the initialization program PRE_LDR) triggers an execution of the application program CLT_SW by the second core COR2.
  • the second core COR2 i.e. the initialization program PRE_LDR
  • step S240 triggered by step S233, the second core COR2 executes the application program CLT_SW and thus implements steps S241 to S243 as described with reference to Figures 3A and 3B.
  • step S250 triggered by an execution error of the application program CLT_SW, the second core COR2 executes the interrupt management program INTRPT comprising instructions for stopping and/or resetting the second core COR2.
  • the proposed solution by exploiting the hardware architecture of the multi-core processor PROC, advantageously makes it possible to dissociate the executions of the control program PLT_SW and the application program CLT_SW.
  • an execution error of the CLT_SW application program does not lead to an execution error of the PLT_SW control program and to a breakdown of the APP control device.
  • the control program PLT_SW can, despite an execution error of the application program CLT_SW, continue to ensure the control function of the on-board devices ACT.
  • the control program PLT_SW can, for example, use a degraded operating mode not requiring the use of the application program CLT_SW, or even trigger an execution of the application program CLT_SW again once the second core COR2 has been reset.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Traffic Control Systems (AREA)

Abstract

La présente invention concerne un dispositif de contrôle (APP) d'au moins un dispositif embarqué (ACT) dans un aéronef (AC) à partir de données de vol (NAV_DATA) fournies par au moins un dispositif source (NAV), ledit dispositif de contrôle (APP) comprenant un processeur multi-cœurs (PROC) comportant : un premier cœur (COR1); un deuxième cœur (COR2); et une interface de communication inter-cœurs (ICC), le deuxième cœur (COR2) étant isolé dudit au moins un dispositif embarqué (ACT) et dudit au moins un dispositif source (NAV), et le premier cœur (COR1) étant configuré pour : fournir (S130), via ladite interface (ICC), des données d'entrée (IN_CLT) obtenues à partir des données de vol (NAV_DATA); obtenir (S150), via ladite interface (ICC), des données de sortie (OUT_CLT); et fournir (S160) des données de contrôle (ACT_CMD) obtenues à partir des données de sortie (OUT_CLT).

Description

Description
Titre : Procédé et dispositif de contrôle d'au moins un dispositif embarqué dans un aéronef
Domaine technique
[0001] La présente invention se rapporte aux domaines des dispositifs de contrôle et des systèmes embarqués. Plus particulièrement, la présente invention concerne un dispositif de contrôle d'au moins un dispositif embarqué dans un aéronef, et un aéronef, un procédé de contrôle, un procédé applicatif, un ensemble de programmes d'ordinateurs et un support d'informations associés. La présente invention trouve une application particulièrement avantageuse, bien que nullement limitative, pour la mise en oeuvre de dispositifs de contrôle de moteurs électriques d'actionnement de commandes de vol.
Technique antérieure
[0002] L'invention se place, à titre d'exemple non-limitatif, dans un contexte selon lequel les commandes de vol d'un aéronef sont réalisées par des moteurs électriques d'actionnement. Dans ce contexte particulier, un dispositif de contrôle (e.g. un calculateur) prend en entrée des commandes de pilotage (e.g. fournies par un manche, ou un autopilote) et des données issues de capteurs (e.g. une centrale à inertie, une sonde Pitot), et fournit en sortie des signaux de contrôle pour les moteurs d'actionnement (e.g. un actionneur d'un aileron).
[0003] Typiquement, un tel dispositif de contrôle exploite plusieurs composants logiciels (i.e. plusieurs programmes d'ordinateurs) pour déterminer les signaux de contrôle à partir des commandes de pilotage et des données mesurées. Ces composants logiciels, mettant en oeuvre respectivement des fonctions spécifiques nécessaires au contrôle, peuvent être produits par des fournisseurs différents. Toutefois, l'exploitation de plusieurs programmes sur un même dispositif de contrôle suppose de résoudre des problèmes d'intégration et de gestion des exécutions de ces différents programmes.
[0004] Dans l'état actuel de la technique, une solution consiste à intégrer au sein d'un même programme plusieurs composants logiciels et d'exécuter ce programme sur un processeur dédié, tel qu'un DSP (acronyme de l'expression anglophone « Digital Signal Processor », dont une traduction est « processeur de signaux numériques »). Une telle solution permet d'atteindre une vitesse de traitement élevée tout en conservant une faible complexité du dispositif de contrôle. Ces avantages sont néanmoins contrebalancés par un certain nombre d'inconvénients. [0005] En effet, à chaque nouvelle version d'un des composants logiciels, l'intégration commune et complexe des composants logiciels au sein du même programme doit être systématiquement refaite et certifiée de nouveau. De surcroît, en utilisant une telle intégration commune, une erreur d'exécution d'un des composants logiciels peut conduire à un dysfonctionnement général du dispositif de contrôle, une situation qui doit être absolument évitée pour les applications critiques, comme l'aéronautique
[0006] Il existe par conséquent un besoin pour un dispositif de contrôle rapide et de faible complexité permettant de dissocier les exécutions de plusieurs programmes.
Exposé de l'invention
[0007] La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l'art antérieur, notamment ceux exposés précédemment.
[0008] Selon un aspect de l'invention, il est proposé un dispositif de contrôle d'au moins un dispositif embarqué dans un aéronef à partir de données de vol fournies par au moins un dispositif source, ledit dispositif de contrôle comprenant un processeur multi-cœurs comportant : un premier cœur ; un deuxième cœur (distinct du premier cœur) ; et une interface de communication inter-cœurs, le deuxième cœur étant isolé dudit au moins un dispositif embarqué et dudit au moins un dispositif source, et le premier cœur étant configuré pour : fournir, via l'interface de communication inter-cœurs, des données d'entrée obtenues à partir des données de vol ; obtenir, via l'interface de communication inter-cœurs, des données de sortie ; et fournir, audit au moins un dispositif embarqué, des données de contrôle obtenues à partir des données de sortie.
[0009] Par « processeur multi-cœur », nous entendons ici un processeur (e.g. un microprocesseur intégré sur un unique circuit) comprenant plusieurs unités de traitement (appelées cœurs) physiquement séparées et exécutant des instructions de programme d'ordinateur.
Corrélativement, un « cœur » désigne une unité de traitement (i.e. un ensemble de circuits au sein d'un processeur) capable d'exécuter des instructions de programme d'ordinateur.
[0010] Dans le contexte de l'invention, le terme « données de vol » désignent des données caractérisant un vol de l'aéronef (i.e. comprenant les différentes phases de vol telles que le roulage, le décollage, la croisière, l'atterrissage, etc.). À titre indicatif, les données de vol peuvent comprendre des données de commande fournies par un dispositif de pilotage (e.g. manuel ou automatique) et/ou des données mesurées par un ou plusieurs capteurs de l'aéronef (e.g. une centrale à inertie, une sonde Pitot, un capteur de température).
[0011] Par ailleurs, il est important de noter que le deuxième cœur est isolé des dispositifs embarqués à contrôler et des dispositifs sources produisant les données de vol et ne peut pas communiquer avec ces dispositifs. Autrement dit, le deuxième cœur ne dispose pas d'interface active de communication externe au processeur.
[0012] Ainsi, la présente invention propose un dispositif de contrôle (i.e. une plateforme) permettant d'exécuter sur le deuxième cœur un programme d'ordinateur (par exemple, un composant logiciel fourni par une entité tierce) de manière isolée matériellement et temporel lement d'un programme exécuté sur le premier cœur.
[0013] En effet, le dispositif de contrôle proposé permet d'exécuter : sur le premier cœur, un programme mettant en œuvre la fonction de contrôle des dispositifs embarqués ; et sur le deuxième cœur, un programme mettant en œuvre un algorithme spécifique nécessaire à la fonction de contrôle. En ce sens, la présente invention permet d'exploiter les caractéristiques matérielles d'un processeur multi-cœur pour séparer physiquement et temporellement les exécutions de plusieurs programmes au sein d'un dispositif de contrôle.
[0014] Grâce à la solution proposée, une erreur d'exécution d'un programme exécuté sur le deuxième cœur ne conduit pas nécessairement à un dysfonctionnement du dispositif de contrôle, le premier cœur étant toujours en mesure de mettre en œuvre la fonction de contrôle. De ce fait, en comparaison aux solutions existantes, la présente invention permet d'améliorer la sûreté de fonctionnement du dispositif de contrôle.
[0015] En outre, le dispositif de contrôle proposé permet d'exécuter sur chacun des cœurs un programme avec ses propres contraintes de temps (i.e. isolation temporelle entre un programme exécuté sur le premier cœur et un programme exécuté sur le deuxième cœur).
[0016] Par ailleurs, l'utilisation d'un processeur multi-cœur tel que proposée permet d'atteindre une vitesse de traitement (i.e. fréquence de calcul) élevée tout en conservant une faible complexité. Notamment, la proximité entre les cœurs du processeur permet d'échanger rapidement des données entre plusieurs programmes via l'interface de communication inter-cœurs (e.g. comprenant des mémoires vives haute-fréquence). Le dispositif de contrôle peut ainsi fonctionner à une fréquence de travail élevée.
[0017] Pour ces raisons, la présente invention fournit un dispositif de contrôle rapide et de faible complexité permettant de séparer matériellement et temporellement les exécutions de plusieurs programmes. Ainsi, le dispositif de contrôle proposé permet de répondre aux contraintes spécifiques des systèmes embarqués en termes de complexité, de vitesse de traitement, de taille et de sûreté de fonctionnement.
[0018] Selon un mode de réalisation, le premier cœur est configuré pour exécuter un programme dit de contrôle obtenant les données de vol (en provenance dudit au moins un dispositif source) et fournissant les données de contrôle (audit au moins un dispositif embarqué). Et, selon ce mode de réalisation, le deuxième cœur est configuré pour exécuter un programme dit applicatif obtenant les données d'entrée (en provenance du premier cœur) et fournissant les données de sorties (au premier cœur).
[0019] Le terme « programme » fait référence ici à un programme d'ordinateur comprenant des instructions exécutables par au moins un cœur, processeur, ou un ordinateur.
[0020] Selon ce mode de réalisation, le programme de contrôle (e.g. produit par un fournisseur) met en œuvre la fonction de contrôle et assure, ainsi, l'interface avec les dispositifs source fournissant les données de vol et avec les dispositifs embarqués à contrôler. Et, le programme applicatif (e.g. produit par un autre fournisseur) lui met en œuvre un algorithme spécifique nécessaire à la fonction de contrôle (e.g. un algorithme de loi d'effort).
[0021] De manière générale, ce mode de réalisation permet de séparer matériellement et temporellement les exécutions du programme de contrôle et du programme applicatif.
[0022] En particulier, une erreur d'exécution du programme applicatif n'entraine pas une erreur d'exécution du programme de contrôle. Les deux programmes pouvant être exécutés en même temps sans blocage mutuel (i.e. aucune corruption entre ces programmes), ce qui contribue à améliorer la sûreté de fonctionnement du dispositif de contrôle.
[0023] Par ailleurs, le programme applicatif ne dispose pas d'interface de communication externe et ne peut communiquer avec les dispositifs sources produisant les données de vol et les dispositifs embarqués à contrôler. Autrement dit, l'ensemble des données échangées par le programme applicatif sont communiquées via l'interface de communication inter-cœurs avec le programme de contrôle.
[0024] Ce mode de réalisation permet avantageusement de certifier de manière indépendante le programme de contrôle et le programme applicatif, les échanges entre ces programmes pouvant être considérés comme des interfaces prédéfinies. Également, les développements respectifs de ces programmes sont rendus indépendants.
[0025] En outre, ce mode de réalisation permet de garantir aux fournisseurs respectifs du programme de contrôle et du programme d'application la confidentialité de leurs programmes. Grâce à la solution proposée, il n'est pas nécessaire d'avoir accès au code source du programme applicatif pour contrôler les dispositifs embarqués. Le programme applicatif peut ainsi être fourni sous forme binaire par exemple.
[0026] Selon un mode de réalisation, le processeur multi-cœur du dispositif de contrôle est un microprocesseur de signal numérique bi-cœur comprenant le premier et le deuxième cœur.
[0027] Par « microprocesseur de signal numérique », nous entendons ici un processeur dont tous les composants sont implémentés sur un même circuit intégré et dont l'architecture est dédiée à (optimisée pour) la mise en œuvre de fonctions de traitement numérique de signaux, plus couramment désigné par l'acronyme DSP.
[0028] En exploitant un DSP bi-cœur optimisé pour le traitement numérique de signaux, ce mode de réalisation permet avantageusement d'atteindre une vitesse de traitement élevée tout en conservant une faible complexité. Il en résulte une amélioration des performances du dispositif de contrôle proposé en termes de coût, de taille, et de consommation énergétique
[0029] Selon un mode de réalisation, l'interface de communication inter-cœurs comprend : deux mémoires d'échange unidirectionnelles ; ou une mémoire d'échange bidirectionnelle.
[0030] À titre indicatif, la ou les mémoires d'échanges de l'interface de communication inter-cœurs peuvent être des mémoires vives haute-fréquence.
[0031] Ce mode de réalisation permet d'échanger rapidement des données entre les cœurs du processeur, et donc entre des programmes s'exécutant respectivement sur ces cœurs. De la sorte, ce mode de réalisation contribue à fournir un dispositif de contrôle dont la vitesse de traitement élevée.
[0032] Selon un mode de réalisation, l'interface de communication inter-cœurs comprend des moyens de transmission (e.g. un bus de communication) de signaux de déclenchement (également dits « événements ») entre le premier cœur et le deuxième cœur.
[0033] Ce mode de réalisation permet à un des cœurs du processeur de déclencher l'exécution d'une ou plusieurs étapes sur un autre cœur du processeur. Ce mode de réalisation permet ainsi de coordonner l'exécution de différents programmes exécutés respectivement sur différents cœurs.
[0034] En particulier, selon un mode de réalisation, le premier et le deuxième cœur communiquent via l'interface de communication inter-cœurs en utilisant uniquement la ou les mémoires d'échanges et les moyens de transmission de signaux de déclenchement. Plus précisément, le deuxième cœur ne comprend, selon un mode de réalisation, aucune interface active de communication externe au processeur. [0035] Selon un autre aspect de l'invention, il est proposé un aéronef comprenant : un dispositif de contrôle conforme à l'invention ; au moins un dispositif source ; et au moins un dispositif embarqué.
[0036] En particulier, ledit au moins un dispositif source fournit des données de vol et ledit au moins dispositif embarqué est contrôlé par le dispositif de contrôle à partir des données de vol.
[0037] L'aéronef proposé dispose des avantages décrits ci-dessus en lien avec le dispositif de contrôle conforme à l'invention.
[0038] Selon un mode de réalisation, ledit au moins un dispositif embarqué comprend un actionneur électrique d'une gouverne de l'aéronef.
[0039] Ce mode de réalisation, grâce à l'utilisation du dispositif de contrôle proposé, permet de mettre en oeuvre les commandes de vol d'un aéronef de manière fiable et rapide.
[0040] Dans le cadre de l'invention, il pourrait également être envisagé d'autre modes de réalisation dans lesquels ledit au moins un dispositif embarqué comprend un onduleur à commande numérique.
[0041] Selon un autre aspect de l'invention, il est proposé un procédé de contrôle d'au moins un dispositif embarqué dans un aéronef à partir de données de vol fournies par au moins un dispositif source, le procédé de contrôle comprenant des étapes, mises en oeuvre par un premier cœur d'un processeur multi-cœur, de : fourniture, via une interface de communication inter-cœurs du processeur multi-cœur, de données d'entrée obtenues à partir des données de vol ; obtention, via l'interface de communication inter-cœurs, de données de sortie ; et fourniture, audit au moins un dispositif embarqué, des données de contrôle obtenues à partir des données de sortie.
[0042] Le procédé de contrôle proposé dispose des avantages décrits ci-dessus en lien avec le dispositif de contrôle conforme à l'invention.
[0043] Selon un mode de réalisation, le procédé de contrôle est mis en œuvre par le dispositif de contrôle conforme à l'invention.
[0044] Nous rappelons ici que le dispositif de contrôle proposé permet d'exécuter, de manière séparée temporel lement et matériellement : sur le premier cœur, un programme de contrôle mettant en œuvre la fonction de contrôle des dispositifs embarqués ; et sur le deuxième cœur, un programme applicatif mettant en œuvre un algorithme nécessaire à la fonction de contrôle. [0045] Selon un mode de réalisation, le procédé de contrôle comprend une étape d'envoi, par le premier cœur à un deuxième cœur du processeur, d'un signal de déclenchement d'une fourniture par un programme applicatif (exécuté sur le deuxième cœur) de dites données de sortie obtenues à partir de dites données d'entrée. Plus précisément, ce signal de déclenchement est envoyé par l'intermédiaire d'une interface de communication inter-cœurs du processeur multi-cœur.
[0046] Selon ce mode de réalisation, le premier cœur déclenche, lorsque cela est nécessaire, la mise en œuvre par le deuxième cœur d'un algorithme spécifique nécessaire à la fonction de contrôle (e.g. un algorithme de loi d'effort mis en œuvre par le programme applicatif). Ainsi, ce mode de réalisation permet d'optimiser l'utilisation des ressources de calcul (i.e. des cœurs du processeur) et la consommation énergétique du dispositif de contrôle.
[0047] Plus généralement, ce mode de réalisation permet de coordonner les exécutions de différents programmes exécutés respectivement sur différents cœurs du processeur (e.g. le programme de contrôle exécuté sur le premier cœur et le programme applicatif exécuté sur le deuxième cœur).
[0048] Selon un mode de réalisation, le procédé de contrôle comprend une étape d'envoi, par le premier cœur au deuxième cœur, d'un signal de déclenchement d'un démarrage du programme applicatif. En particulier, ce signal de déclenchement est envoyé par l'intermédiaire de l'interface de communication inter-cœurs du processeur multi-cœur.
[0049] Ce mode de réalisation permet au premier cœur de démarrer l'exécution par le deuxième cœur du programme applicatif.
[0050] Selon un mode de réalisation, le procédé de contrôle comprend des étapes, mises en œuvre par le deuxième cœur pour démarrer le programme applicatif, de : si le programme applicatif est chargé sur le deuxième cœur (i.e. sur une mémoire du deuxième cœur), initialisation de données de configuration du programme applicatif et déclenchement d'une exécution par le deuxième cœur du programme applicatif ; et sinon, chargement sur le deuxième cœur (i.e. sur une mémoire du deuxième cœur) du programme applicatif et déclenchement d'un démarrage du programme applicatif.
[0051] Il est à noter que la mise en œuvre par le deuxième cœur des étapes décrites ci-dessus pour démarrer le programme applicatif est déclenchée par la réception en provenance du premier cœur d'un signal de déclenchement d'un démarrage du programme applicatif.
[0052] Ce mode de réalisation permet, sans bloquer l'exécution du programme de contrôle sur le premier cœur, de charger (ou mettre à jour) le programme applicatif sur le deuxième cœur et de lancer son exécution. [0053] Selon un mode de réalisation, le procédé de contrôle comprend une étape de vérification, mise en oeuvre par le deuxième cœur, d'une signature numérique associée au programme applicatif.
[0054] Ce mode de réalisation permet de vérifier l'intégrité du programme applicatif et d'authentifier le fournisseur de ce programme. Nous décrivons plus en détails ci-dessous comment la signature peut être générée et vérifiée.
[0055] De manière plus générale, ce mode de réalisation permet de garantir la sécurité du dispositif de contrôle et de protéger celui-ci de potentielles attaques informatiques (e.g. une modification du programme applicatif dans un but malveillant).
[0056] Selon un mode de réalisation, le procédé de contrôle comprend une étape d'arrêt ou de réinitialisation du deuxième cœur, mise en œuvre par le deuxième cœur et déclenchée par une erreur d'exécution du programme applicatif.
[0057] Ce mode de réalisation permet de traiter une erreur d'exécution du programme applicatif et contribue, ainsi, à améliorer la sûreté de fonctionnement du dispositif de contrôle.
[0058] Selon un aspect de l'invention, il est proposé un programme d'ordinateur, dit de contrôle, comprenant des instructions pour exécuter les étapes, mises en œuvre par un premier cœur d'un processeur multi-cœur, d'un procédé de contrôle conforme à l'invention, lorsque ledit programme de contrôle est exécuté par le premier cœur.
[0059] Notamment, le programme de contrôle est exécuté par le premier cœur du processeur multi- cœur d'un dispositif de contrôle conforme à l'invention.
[0060] Selon un aspect de l'invention, il est proposé un ensemble de programmes d'ordinateur comprenant : un programme de contrôle conforme à l'invention ; et au moins un autre programme. Ledit au moins un autre programme comprend des instructions pour exécuter les étapes, mises en œuvre par un deuxième cœur d'un processeur multi-cœur, d'un procédé de contrôle conforme à l'invention, lorsque ledit au moins un autre programme est exécuté par le deuxième cœur.
[0061] En particulier, ledit au moins un autre programme est exécuté par le deuxième cœur du processeur multi-cœur d'un dispositif de contrôle conforme à l'invention.
[0062] Selon un autre aspect de l'invention, il est proposé un procédé applicatif mis en œuvre par un deuxième cœur d'un processeur multi-cœur, le deuxième cœur étant isolé en ce qu'il communique uniquement avec un premier cœur du processeur multi-cœur et via une interface de communication inter-cœurs, ledit procédé applicatif comprenant des étapes de : obtention, via l'interface de communication inter-cœurs, de données d'entrée ; obtention de données de sortie à partir des données d'entrée ; et fourniture, via l'interface de communication inter-cœurs, des données de sortie.
[0063] Selon un autre aspect de l'invention, il est proposé un programme d'ordinateur, dit applicatif, comprenant des instructions pour mettre en œuvre les étapes d'un procédé applicatif conforme à l'invention, lorsque le programme applicatif est exécuté par un deuxième cœur d'un processeur multi-cœur.
[0064] Le programme applicatif est notamment exécuté par le deuxième cœur du processeur multi- cœur d'un dispositif de contrôle conforme à l'invention.
[0065] Selon un aspect de l'invention, il est proposé un support d'informations lisible par ordinateur comprenant : un programme de contrôle conforme à l'invention ; et/ou un ensemble de programmes d'ordinateur conforme à l'invention ; et/ou un programme applicatif conforme à l'invention.
[0066] Dans le contexte de l'invention, un programme d'ordinateur peut être formé d'une ou plusieurs sous-parties stockées dans une même mémoire ou dans des mémoires distinctes. Le programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
[0067] En outre, un support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire non-volatile ou ROM, par exemple un CD-ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette ou un disque dur. D'autre part, le support de stockage peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par un réseau de télécommunication ou par un réseau informatique ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau informatique. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des dessins
[0068] D'autres caractéristiques et avantages de la présente invention ressortiront de la description fournie ci-après, illustrant des modes de réalisation de l'invention donnés à titre d'exemple et dépourvus de tout caractère limitatif, en référence aux dessins ci-joints : [0069] La figure 1 représente un exemple d'architecture logicielle et matérielle d'un aéronef selon un mode de réalisation de l'invention ;
[0070] La figure 2 représente un exemple d'architecture logicielle et matérielle d'un dispositif de contrôle selon un mode de réalisation de l'invention ;
[0071] La figure 3A et la figure 3B représentent respectivement un exemple d'architecture logicielle et matérielle d'un aéronef et des étapes d'un procédé de contrôle selon un mode de réalisation de l'invention ; et
[0072] La figure 4A et la figure 4B représentent respectivement un exemple d'architecture logicielle et matérielle d'un aéronef et des étapes d'un procédé de contrôle selon un mode de réalisation de l'invention.
Description des modes de réalisation
[0073] La figure 1 représente un exemple d'architecture logicielle et matérielle d'un aéronef selon un mode de réalisation de l'invention. En particulier, la figure 1 est décrite ci-après pour introduire la présente invention et exemplifier un contexte particulier d'application de celle-ci.
[0074] Tel qu'illustré sur la figure 1, l'aéronef AC comprend : un dispositif de contrôle APP ; au moins un dispositif source NAV ; et au moins un dispositif embarqué ACT. Plus précisément, le dispositif de contrôle APP est configuré pour : prendre en entrée des données de vol NAV_DATA produites par ledit au moins un dispositif source NAV ; et fournir en sortie des données de contrôle ACT_CMD pour contrôler ledit au moins un dispositif embarqué ACT.
[0075] Les données de vol NAV_DATA peuvent comprendre des données de commande NAV_CMD issues d'un dispositif de pilotage (automatique ou manuel) de l'aéronef AC. Également, les données de vol peuvent comprendre des données mesurées par un ou plusieurs capteurs de l'aéronef AC, tels qu'une centrale à inertie, une sonde Pitot, un capteur de température, etc.
[0076] La présente invention s'applique, en particulier, au contrôle des moteurs électriques d'actionnement de commande de vol d'un aéronef. La description ci-après de la présente invention fait référence à ce contexte particulier, donné à titre d'exemple illustratif et dépourvu de tout caractère limitatif. Notamment, il pourrait être envisagé des modes de réalisation dans lesquels les dispositifs embarqués ACT à contrôler comprennent un ou plusieurs onduleurs à commande numérique.
[0077] Ainsi, selon un mode de réalisation, ledit au moins un dispositif embarqué ACT à contrôler comprend un ou plusieurs actionneurs (e.g. électriques) de gouverne de l'aéronef AC. Par exemple, sur la base de commande de pilotage et/ou de données issues de capteurs, le dispositif de contrôle APP contrôle un ou plusieurs actionneurs ACT de gouverne de l'aéronef AC.
[0078] Il convient de noter que, dans le contexte de l'invention, le dispositif de contrôle APP requiert l'exécution de plusieurs programmes d'ordinateur (notamment produits par des fournisseurs différents) pour contrôler les dispositifs embarqués ACT.
[0079] Tel qu'illustré par la figure 1, le dispositif de contrôle APP requiert l'exécution d'un programme de contrôle PLT_SW et d'un programme applicatif CLT_SW. Plus précisément, le programme de contrôle PLT_SW met en oeuvre la fonction de contrôle et assure l'interface avec les dispositifs source NAV et avec les dispositifs embarqués ACT ; et le programme applicatif CLT_SW met en oeuvre un algorithme spécifique nécessaire au contrôle de ces dispositifs ACT. Par exemple, le programme applicatif CLT_SW peut mettre en oeuvre un algorithme de loi d'effort permettant de déterminer les consignes à appliquer à une gouverne de l'aéronef AC.
[0080] Nous décrivons ici ce dernier exemple plus en détails afin d'illustrer une application de l'invention. Le programme de contrôle PLT_SW obtient, en provenance des dispositifs sources NAV, des données issues d'une centrale à inertie et une attitude souhaitée de l'aéronef AC. À partir des données d'inertie, il détermine une attitude courante et une vitesse de l'aéronef AC. Ensuite, le programme de contrôle PLT_SW fournit au programme applicatif CLT_SW : l'attitude courante ; la vitesse ; et l'attitude souhaitée. En utilisant une loi d'effort, le programme applicatif CLT_SW détermine un degré d'inclinaison à appliquer à un aileron pour réaliser l'attitude souhaitée en fonction de l'attitude courante et de la vitesse de l'aéronef AC. Le programme applicatif CLT_SW fournit le degré d'inclinaison calculé au programme de contrôle PLT_SW qui détermine alors un temps d'activation d'un actionneur de gouverne pour atteindre ce degré d'inclinaison.
[0081] Tel que mentionnée précédemment, la présente invention propose un dispositif de contrôle APP (i.e. une plateforme) permettant d'exécuter un quelconque programme applicatif CLT_SW de manière isolée matériellement et temporellement.
[0082] Le programme applicatif CLT_SW peut être quelconque et est typiquement fourni par une entité tierce (par exemple, livré par un fournisseur à l'équipementier mettant en oeuvre le dispositif de contrôle). Aussi, l'architecture du dispositif de contrôle APP proposé est indépendante du programme applicatif CLT_SW.
[0083] Pour cette raison, nous décrivons tout d'abord l'architecture du dispositif de contrôle APP proposé en référence à la figure 2, puis le fonctionnement du dispositif de contrôle APP proposé en référence aux figures suivantes. [0084] La figure 2 représente un exemple d'architecture logicielle et matérielle d'un dispositif de contrôle selon des modes de réalisation de l'invention. Cette figure détaille l'architecture du dispositif de contrôle APP présenté en référence à la figure 1.
[0085] Tel qu'illustré par la figure 2, le dispositif de contrôle APP proposé comprend un processeur multi-cœur PROC. En outre, le dispositif de contrôle APP peut comprendre tout type de composants nécessaires à son fonctionnement, tels qu'une source d'alimentation, des ports de connexion, des modules de communication, des mémoires, etc.
[0086] Le processeur PROC comprend : au moins un premier cœur COR1 et un deuxième cœur COR2 ; et une interface de communication inter-cœurs ICC.
[0087] Notons que chacun des cœurs COR1-COR2 du processeur multi-cœur PROC peut exécuter de façon autonome des instructions de programme d'ordinateur. À ce titre, chacun des cœurs COR1- COR2 peut respectivement comprendre au moins un élément parmi : une ou plusieurs mémoires caches, un compteur ordinal, un ou plusieurs registres, et une ou plusieurs unités de calcul.
[0088] Selon un mode de réalisation, le processeur PROC comprend uniquement deux cœurs COR1- COR2. Toutefois, dans le cadre de l'invention, d'autre modes de réalisation pourraient être envisagés dans lesquels le processeur PROC comprend plus de deux cœurs.
[0089] Selon un mode de réalisation, le processeur PROC est un microprocesseur (i.e. un processeur dont tous les composants sont intégrés sur un même circuit). Plus particulièrement, le processeur PROC est un DSP multi-cœur selon un mode de réalisation. Un tel processeur présente une architecture optimisée pour mettre en œuvre des fonctions de traitement numérique du signal le plus rapidement possible. Il résulte avantageusement de l'utilisation d'un DSP une amélioration des performances du dispositif de contrôle APP en termes de complexité, de taille, et de consommation énergétique.
[0090] Ainsi, selon un mode de réalisation, le processeur PROC est un DSP bi-cœur.
[0091] L'interface de communication inter-cœurs ICC comprend : deux mémoires d'échanges MEM1 et MEM2 unidirectionnelles (e.g. des mémoires vives haute-fréquence) ; et des moyens de transmission EVT_BUS (e.g. un bus de communication) de signaux de déclenchement (également dits « évènements »).
[0092] La mémoire MEM1 est utilisée pour échanger des données en provenance du premier cœur COR1 à destination du deuxième cœur COR2, c'est-à-dire des données écrites par le premier cœur COR1 sur la mémoire MEM1 et lues par le deuxième cœur COR2. De manière analogue, la mémoire MEM2 est utilisée pour échanger des données en provenance du deuxième cœur COR2 à destination du premier cœur COR1, c'est-à-dire des données écrites par le deuxième cœur COR2 sur la mémoire MEM1 et lues par le premier cœur COR1.
[0093] Les mémoires MEM1-MEM2 permettent d'échanger des données entre les cœurs COR1-COR2. La proximité entre les cœurs COR1-COR2 permet d'échanger avec un débit de communication élevé des données entre des programmes s'exécutant sur ces cœurs, ce qui contribue ainsi à fournir un dispositif de contrôle APP rapide.
[0094] Les moyens de transmission EVT_BUS permettent d'échanger des signaux de déclenchement entre les cœurs COR1-COR2. De tels signaux sont utilisés pour déclencher à partir d'un des cœurs COR1-COR2 l'exécution d'une ou plusieurs étapes sur un autre cœur COR1-COR2, ce qui permet de coordonner les exécutions de programmes sur les cœurs COR1-COR2.
[0095] Le premier cœur COR1 est configuré pour exécuter le programme de contrôle PLT_SW. Tel qu'illustré par la figure 2, le programme de contrôle PLT_SW assure l'interface avec les dispositifs sources NAV et les dispositifs embarqués ACT à contrôler. Plus généralement, le programme de contrôle PLT_SW met en œuvre la fonction de contrôle (i.e. gestion du matériel, des interfaces, du séquencement du contrôle des dispositifs embarqués).
[0096] Le premier cœur COR1 peut échanger des données avec un programme exécuté sur le deuxième cœur COR2 en utilisant les mémoires MEM1-MEM2 de l'interface ICC. Également, le premier cœur COR1 peut déclencher l'exécution d'une ou plusieurs étapes par un programme exécuté sur le deuxième cœur COR2 en envoyant des signaux de déclenchement par l'intermédiaire des moyens de transmission EVT_BUS de l'interface ICC. Plus généralement, le premier cœur COR1 est le maître des échanges de données et des évènements.
[0097] Le deuxième cœur COR2 est configuré pour communiquer uniquement avec le premier cœur COR1 via l'interface ICC. Autrement dit, le deuxième cœur COR2 est configuré de telle sorte qu'il ne dispose pas d'interface active de communication externe au processeur PROC. En ce sens, le deuxième cœur COR2 est isolé des dispositifs sources NAV et des dispositifs embarqués ACT à contrôler.
[0098] Ainsi, le dispositif de contrôle APP proposé permet d'exécuter sur le deuxième cœur COR2 un quelconque programme de manière isolée matériellement et temporel lement du programme de contrôle PLT_SW exécuté sur le premier cœur COR1.
[0099] Les avantages du dispositif de contrôle APP proposé résultent, tel que précédemment décrit, de la séparation physique et temporelle des exécutions de plusieurs programmes.
[0100] Notamment, le dispositif de contrôle APP proposé permet d'exécuter sur chacun des cœurs COR1-COR2 un programme avec ses propres contraintes de temps (i.e. isolation temporelle). Autrement dit, le dispositif de contrôle APP permet d'utiliser des plans fréquentiels différents entre le programme de contrôle PLT_SW exécuté sur le premier cœur COR1 et un programme exécuté sur le deuxième cœur COR2.
[0101] En outre, une erreur d'exécution d'un programme exécuté sur le deuxième cœur COR2 ne conduit pas à un dysfonctionnement du dispositif de contrôle APP. Le dispositif de contrôle APP permet également de garantir la confidentialité d'un programme exécuté sur le deuxième cœur COR2. Avantageusement, il est possible de certifier le dispositif de contrôle APP (avec le programme de contrôle PLT_SW) et indépendamment d'un programme exécuté sur le deuxième cœur COR2, ce qui simplifie nettement la certification en comparaison aux solutions existantes.
[0102] Par ailleurs, le dispositif de contrôle APP permet d'atteindre une vitesse de traitement (i.e. une fréquence de calcul) élevée tout en conservant une faible complexité. Plus généralement, le dispositif de contrôle APP permet de répondre aux contraintes spécifiques des systèmes embarqués en termes de complexité, de vitesse de traitement, de taille et de fiabilité.
[0103] L'architecture du dispositif de contrôle APP étant introduite, nous décrivons ci-après son fonctionnement en référence aux figures suivantes.
[0104] La figure 3A et la figure 3B représentent respectivement un exemple d'architecture logicielle et matérielle d'un aéronef et des étapes d'un procédé de contrôle selon un mode de réalisation de l'invention. La figure 3B illustre un procédé de contrôle selon un mode de réalisation de l'invention mis en œuvre par le dispositif de contrôle APP de la figure 3A.
[0105] Tel qu'illustré par la figure 3A, selon ce mode de réalisation, le premier cœur COR1 du dispositif de contrôle APP est configuré pour exécuter le programme de contrôle PLT_SW et le deuxième cœur COR2 du dispositif de contrôle APP est configuré pour exécuter le programme applicatif CLT_SW.
[0106] Tel qu'illustré par la figure 3B, selon ce mode de réalisation, le procédé de contrôle comprend au moins une des étapes décrites ci-dessous. Notons que les étapes du procédé de contrôle proposé mises en œuvre par le premier cœur COR1 sont dénotées par S1XX et que les étapes mises en œuvre par le deuxième cœur COR2 sont dénotées S2XX.
[0107] À l'étape S100, le premier cœur COR1 exécute le programme de contrôle PLT_SW comprenant des instructions pour mettre en œuvre les étapes S120 à S160 décrites ci-après.
[0108] Plus généralement, le programme de contrôle PLT_SW peut comprendre des instructions pour réaliser chacune des étapes S1XX du procédé de contrôle conforme à l'invention et mises en œuvre par le premier cœur COR1, lorsque ces instructions sont exécutées par le premier cœur COR1. [0109] À l'étape S240, le deuxième cœur COR2 exécute le programme applicatif CLT_SW comprenant des instructions pour mettre en œuvre les étapes S241 à S243 décrites ci-dessous. En particulier, nous désignons par « procédé applicatif » l'ensemble des étapes S241 à S243 mises en œuvre par le deuxième cœur COR2, lorsqu'il exécute le programme applicatif CLT_SW.
[0110] Il convient de souligner que le programme de contrôle PLT_SW et le programme applicatif CLT_SW sont exécutées de manière concurrente, c'est-à-dire au cours de périodes de temps se chevauchant. Autrement dit, les étapes S100 et S240 sont réalisées de manière concomitante.
[0111] La gestion de l'exécution du programme applicatif CLT_SW par le deuxième cœur COR2 (i.e. chargement, lancement, erreur d'exécution) est plus amplement décrite ci-après en référence aux figures 4A et 4B.
[0112] À l'étape S120, le premier cœur COR1 (i.e. le programme de contrôle PLT_SW) obtient les données de vol NAV_DATA issues des dispositifs sources NAV. Par exemple, le premier cœur COR1 obtient lors de cette étape : des données issues d'une centrale à inertie ; et une commande de pilotage telle qu'une attitude souhaitée de l'aéronef AC.
[0113] À l'étape S130, le premier cœur COR1 (i.e. le programme de contrôle PLT_SW) fournit des données d'entrée IN_CLT au deuxième cœur COR2 (i.e. au programme applicatif CLT_SW) par l'intermédiaire de l'interface ICC. En particulier, le premier cœur COR1 écrit à l'étape S130 les données d'entrée IN_CLT sur la mémoire MEM1 de l'interface ICC, les données d'entrée IN_CLT étant obtenues à partir des données de vol NAV_DATA.
[0114] Par exemple, le programme de contrôle PLT_SW peut déterminer une attitude courante et une vitesse de l'aéronef AC à partir des données d'inertie. Ainsi, selon cet exemple, les données d'entrée IN_CLT fournies au programme applicatif CLT_SW peuvent comprendre une attitude courante, une vitesse de l'aéronef AC et une attitude souhaitée.
[0115] À l'étape S140, le premier cœur COR1 (i.e. le programme de contrôle PLT_SW) déclenche une fourniture par le deuxième cœur COR2 (i.e. par le programme applicatif CLT_SW) de données de sortie OUT_CLT. Plus précisément, le premier cœur COR1 envoie à l'étape S140 un signal de déclenchement EVT_TRIG au deuxième cœur COR2 par l'intermédiaire des moyens de transmission EVT_BUS (non représentés sur la figure 3A) de l'interface ICC. Le signal EVT_TRIG déclenche la mise en œuvre des étapes S241 à S243 par le deuxième cœur COR2.
[0116] À l'étape S241, le deuxième cœur COR2 (i.e. le programme applicatif CLT_SW) obtient les données d'entrée IN_CLT en provenance du premier cœur COR1 (i.e. en provenance du programme de contrôle PLT_SW). En fait, le deuxième cœur COR2 lit à l'étape S241 les données d'entrée IN_CLT sur la mémoire MEM1 de l'interface ICC. [0117] À l'étape S242, le deuxième cœur COR2 (Le. le programme applicatif CLT_SW) obtient les données de sorties OUT_CLT à partir des données d'entrée IN_CLT.
[0118] En reprenant l'exemple ci-dessus, le programme applicatif CLT_SW peut déterminer, en utilisant une loi d'effort, un degré d'inclinaison à appliquer à un aileron pour réaliser une attitude souhaitée de l'aéronef AC en fonction de son attitude courante et de sa vitesse.
[0119] À l'étape S243, le deuxième cœur COR2 (i.e. le programme applicatif CLT_SW) fournit les données de sortie OUT_CLT au premier cœur COR1 (i.e. au programme de contrôle PLT_SW) par l'intermédiaire de l'interface ICC. Le deuxième cœur COR2 écrit à l'étape S243 les données de sortie OUT_CLT sur la mémoire MEM2 de l'interface ICC.
[0120] À l'étape S150, le premier cœur COR1 (i.e. le programme de contrôle PLT_SW) obtient les données de sortie OUT_CLT en provenance du deuxième cœur COR2 (i.e. en provenance du programme applicatif CLT_SW) par l'intermédiaire de l'interface ICC. Le premier cœur COR1 lit à l'étape S150 les données de sortie OUT_CLT sur la mémoire MEM2 de l'interface ICC.
[0121] À l'étape S160, le premier cœur COR1 (i.e. le programme de contrôle PLT_SW) fournit, aux dispositifs embarqués ACT, les données de contrôle ACT_CMD obtenues à partir des données de sortie OUT_CLT.
[0122] Considérant l'exemple ci-dessus, le programme de contrôle PLT_SW peut déterminer un temps d'activation d'un actionneur de gouverne pour atteindre le degré d'inclinaison calculé par le programme applicatif CLT_SW.
[0123] Il convient de noter que le programme applicatif CLT_SW peut comprendre au moins un service d'initialisation et un service périodique, ces services étant respectivement déclenchés par des signaux de déclenchement. Ainsi, la mise en œuvre des étapes S241 à S243 peut correspondre à la réalisation du service d'initialisation ou du service périodique du programme applicatif CLT_SW.
[0124] Le service périodique du programme applicatif CLT_SW peut être déclenché, de manière répétée dans le temps, par le programme de contrôle PLT_SW pour obtenir des données de sorties OUT_CLT. Aussi, le procédé de contrôle peut comprendre une pluralité d'itérations des étapes S120 à S160 et, corrélativement, le procédé applicatif peut comprendre une pluralité d'itérations des étapes S241 à S243.
[0125] La figure 4A et la figure 4B représentent respectivement un exemple d'architecture logicielle et matérielle d'un aéronef et des étapes d'un procédé de contrôle selon des modes de réalisation de l'invention. Précisément, ces figures sont décrites ci-après pour détailler la gestion de l'exécution du programme applicatif CLT_SW par le dispositif de contrôle APP présenté en référence aux figures 3A et 3B.
[0126] Tel qu'illustré sur la figure 4A, selon un mode de réalisation, le deuxième cœur COR2 est configuré pour exécuter au moins un des programmes suivants : un programme de démarrage BOOT ; un programme de chargement LDR ; un programme d'initialisation PRE_LDR ; et un programme de gestion d'interruption INTRPT (également dit vecteur d'interruption). Les fonctions respectives de ces programmes sont décrites ci-dessous en référence aux étapes de la figure 4B.
[0127] À l'étape S100, et tel que précédemment décrit, le premier cœur COR1 exécute le programme de contrôle PLT_SW comprenant des instructions pour mettre en œuvre les étapes S120 à S160. Selon le mode de réalisation illustré par les figures 4A et 4B, le programme de contrôle PLT_SW comprend en outre des instructions pour réaliser l'étape SI 10.
[0128] À l'étape SI 10, le premier cœur COR1 (i.e. le programme de contrôle PLT_CW) déclenche un démarrage du programme applicatif CLT_SW. Pour ce faire, le premier cœur COR1 envoie un signal de déclenchement EVT_BOOT au deuxième cœur COR2 par l'intermédiaire des moyens de transmission EVT_BUS (non représentés sur la figure 3A) de l'interface ICC. Le signal EVT_BOOT déclenche la mise en œuvre de l'étape S210 par le deuxième cœur COR2.
[0129] Suite à l'étape SI 10, le premier cœur COR1 met en œuvre les étapes S120 à S160 telles que précédemment décrites en référence aux figures 3A et 3B.
[0130] À l'étape S210, déclenchée par la réception du signal EVT_BOOT, le deuxième cœur COR2 exécute le programme de démarrage BOOT comprenant des instructions pour mettre en œuvre les étapes S211 et S212.
[0131] À l'étape S211, le deuxième cœur COR2 (i.e. le programme de démarrage BOOT) démarre et/ou initialise le deuxième cœur COR2.
[0132] À l'étape S212, le deuxième cœur COR2 (i.e. le programme de démarrage BOOT) sélectionne de déclencher l'exécution du programme de chargement LDR ou du programme d'initialisation PRE_LDR en fonction de la présence du programme applicatif CLT_SW sur une mémoire du deuxième cœur COR2.
[0133] Si (et seulement si) le programme applicatif CLT_SW est chargé (i.e. enregistré, stocké) sur une mémoire du deuxième cœur COR2, le deuxième cœur COR2 (i.e. le programme de démarrage BOOT) déclenche à l'étape S212 une exécution du programme d'initialisation PRE_LDR. Dans ce cas, le procédé de contrôle se poursuit à l'étape S230. [0134] Sinon, si le programme applicatif CLT_SW n'est pas chargé sur une mémoire du deuxième cœur COR2, le deuxième cœur COR2 (i.e. le programme de démarrage BOOT) déclenche à l'étape S212 une exécution du programme de chargement LDR. Dans ce cas, le procédé de contrôle se poursuit à l'étape S220.
[0135] Il convient de noter ici que la sélection réalisée à l'étape S212 peut également être réalisé en fonction de la version du programme applicatif CLT_SW. Selon un tel mode de réalisation, si le programme applicatif CLT_SW chargé sur une mémoire du deuxième cœur COR2 correspond à une version obsolète ou antérieure de ce programme, alors le deuxième cœur COR2 (i.e. le programme de démarrage BOOT) déclenche à l'étape S212 une exécution du programme de chargement LDR pour charger une version à jour du programme applicatif CLT_SW.
[0136] À l'étape S220, le deuxième cœur COR2 exécute le programme de chargement LDR comprenant des instructions pour réaliser au moins les étapes S221 et S223.
[0137] À l'étape S221, le deuxième cœur COR2 (i.e. le programme de chargement LDR) charge ou met à jour le programme applicatif CLT_SW sur une mémoire du deuxième cœur COR2.
[0138] Plus précisément, le deuxième cœur COR2 obtient les instructions INS_CLT_SW (e.g. le code binaire) du programme applicatif CLT_SW en provenance du premier cœur COR1 par l'intermédiaire de l'interface ICC. Ainsi, selon un mode de réalisation, le premier cœur COR1 écrit les instructions du programme applicatif CLT_SW dans la mémoire d'échange MEM1 de l'interface ICC ; et le deuxième cœur COR2 lit les instructions du programme applicatif CLT_SW sur la mémoire d'échange MEM1.
[0139] Selon un mode de réalisation, le programme de chargement LDR comprend en outre des instructions pour réaliser l'étape S222.
[0140] À l'étape S222, le deuxième cœur COR2 (i.e. le programme de chargement LDR) vérifie une signature numérique associée au programme applicatif CLT_SW.
[0141] Par exemple, la signature du programme applicatif CLT_SW peut être générée de la manière suivante. Le fournisseur du programme applicatif CLT_SW dispose d'une paire de clé privé/clé publique et d'un certificat associant la clé publique au fournisseur. Le fournisseur applique une fonction de hachage au code du programme applicatif CLT_SW pour obtenir une empreinte, puis chiffre cette empreinte avec sa clé privée pour obtenir la signature. Le fournisseur fournit au dispositif de contrôle APP : le code du programme applicatif CLT_SW ; la signature associée ; et son certificat.
[0142] Selon cet exemple, le dispositif de contrôle APP peut vérifier la signature du programme applicatif CLT_SW comme suit. Le dispositif de contrôle APP, d'une part, détermine une empreinte du code du programme applicatif CLT_SW et, d'autre part, déchiffre la signature numérique en utilisant la clé publique du certificat du fournisseur, puis compare les résultats de ces deux opérations. Si l'empreinte calculée par le dispositif de contrôle APP correspond à la signature déchiffrée, alors la signature du programme applicatif CLT_SW est valide.
[0143] Si (et seulement si) le résultat de l'étape S222 de vérification est positif (i.e. signature valide), le procédé de contrôle se poursuit à l'étape S223. Sinon (i.e. signature invalide), le deuxième cœur COR2 est inhibé et n'exécutera pas le programme applicatif CLT_SW. En effet, l'authentification du programme applicatif CLT_SW échoue, cela peut signifier que le programme applicatif CLT_SW a été modifié par une entité malveillante.
[0144] Ainsi, en vérifiant la signature du programme applicatif CLT_SW, le dispositif de contrôle APP vérifie l'intégrité du programme applicatif CLT_SW et authentifie (i.e. vérifier l'identité) le fournisseur de ce programme. Cela permet avantageusement d'améliorer la sécurité du dispositif de contrôle APP et de le protéger d'éventuelles attaques informatiques.
[0145] À l'étape S223, le deuxième cœur COR2 (i.e. le programme de chargement LDR) déclenche un démarrage du programme applicatif. Le procédé de contrôle se poursuit ainsi à l'étape S210.
[0146] À l'étape S230, le deuxième cœur COR2 exécute le programme d'initialisation PRE_LDR comprenant des instructions pour mettre en œuvre au moins les étapes S232 et S233.
[0147] Selon un mode de réalisation, le programme d'initialisation PRE_LDR comprend en outre des instructions pour réaliser l'étape S231.
[0148] À l'étape S231, le deuxième cœur COR2 (i.e. le programme d'initialisation PRE_LDR) vérifie une signature numérique associée au programme applicatif CLT_SW. L'étape S231 peut, par exemple, être mise en œuvre de manière similaire à l'étape S221 décrite ci-dessus.
[0149] À l'étape S232, le deuxième cœur COR2 (i.e. le programme d'initialisation PRE_LDR) initialise des données de configuration (e.g. une table de configuration) du programme applicatif CLT_SW.
[0150] À l'étape S233, le deuxième cœur COR2 (i.e. le programme d'initialisation PRE_LDR) déclenche une exécution du programme applicatif CLT_SW par le deuxième cœur COR2.
[0151] À l'étape S240, déclenchée par l'étape S233, le deuxième cœur COR2 exécute le programme applicatif CLT_SW et met ainsi en œuvre les étapes S241 à S243 telles que décrites en référence aux figures 3A et 3B.
[0152] Toutefois, si une erreur d'exécution du programme applicatif CLT_SW se produit, alors le deuxième cœur COR2 déclenche l'exécution du programme de gestion d'interruption INTRPT (i.e. un vecteur d'interruption). [0153] À l'étape S250, déclenchée par une erreur d'exécution du programme applicatif CLT_SW, le deuxième cœur COR2 exécute le programme de gestion d'interruption INTRPT comprenant des instructions pour arrêter et/ou réinitialiser le deuxième cœur COR2.
[0154] La solution proposée, en exploitant l'architecture matérielle du processeur multi-cœur PROC, permet avantageusement de dissocier les exécutions du programme de contrôle PLT_SW et du programme applicatif CLT_SW. Ainsi, une erreur d'exécution du programme applicatif CLT_SW ne conduit pas à une erreur d'exécution du programme de contrôle PLT_SW et à une panne du dispositif de contrôle APP. En effet, le programme de contrôle PLT_SW peut, malgré une erreur d'exécution du programme applicatif CLT_SW, continuer d'assurer la fonction de contrôle des dispositifs embarqués ACT. Pour ce faire, le programme de contrôle PLT_SW peut, par exemple, utiliser un mode de fonctionnement dégradé ne nécessitant pas l'utilisation du programme applicatif CLT_SW, ou encore déclencher à nouveau une exécution du programme applicatif CLT_SW une fois le deuxième cœur COR2 réinitialisé.
[0155] Il est à noter que l'ordre dans lequel s'enchaînent les étapes d'un procédé conforme à l'invention, notamment en référence aux dessins ci-joints, ne constitue qu'un exemple de réalisation dépourvu de tout caractère limitatif, des variantes étant possibles. En particulier, un procédé conforme à l'invention peut comprendre une ou plusieurs itérations des étapes décrites ci-dessus, notamment en référence aux dessins ci-joints.
[0156] Par ailleurs, les signes de référence ne sont pas limitatifs de l'étendue de la protection, leur unique fonction étant de faciliter la compréhension des revendications.
[0157] Un homme du métier comprendra que les modes de réalisation et variantes décrits ci-dessus ne constituent que des exemples non limitatifs de mise en œuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-dessus afin de répondre à un besoin bien particulier.

Claims

Revendications Dispositif de contrôle (APP) d'au moins un dispositif embarqué (ACT) dans un aéronef (AC) à partir de données de vol (NAV_DATA) fournies par au moins un dispositif source (NAV), ledit dispositif de contrôle (APP) comprenant un processeur multi-cœurs (PROC) comportant : un premier cœur (COR1) ; un deuxième cœur (COR2) ; et une interface de communication intercœurs (ICC), le deuxième cœur (COR2) étant isolé dudit au moins un dispositif embarqué (ACT) et dudit au moins un dispositif source (NAV) en ce qu'il est configuré pour communiquer uniquement avec le premier cœur (COR1) et via l'interface de communication inter-cœurs (ICC), le premier cœur (COR1) étant configuré pour exécuter un programme de contrôle (PLT_SW) mettant en œuvre la fonction de contrôle dudit au moins un dispositif embarqué (ACT) et comprenant des instructions pour : fournir (S130), via l'interface de communication inter-cœurs (ICC), des données d'entrée (IN_CLT) obtenues à partir des données de vol (NAV_DATA) ; obtenir (S150), via l'interface de communication inter-cœurs (ICC), des données de sortie (OUT_CLT) ; et fournir (S160), audit au moins un dispositif embarqué (ACT), des données de contrôle (ACT_CMD) obtenues à partir des données de sortie (OUT_CLT), et le deuxième cœur (COR2) étant configuré pour exécuter un programme applicatif (CLT_SW) comprenant des instructions pour : obtenir (S241), via l'interface de communication inter-cœurs (ICC), les données d'entrée (IN_CLT) ; obtenir (S242) les données de sortie (OUT_CLT) à partir des données d'entrée (IN_CLT) ; et fournir (S243), via l'interface de communication inter-cœurs (ICC), les données de sortie (OUT_CLT). Dispositif de contrôle (APP) selon la revendication 1, dans lequel le processeur (PROC) est un microprocesseur de signal numérique bi-cœur comprenant le premier cœur (COR1) et le deuxième cœur (COR2). Dispositif de contrôle (APP) selon l'une des revendications 1 à 2, dans lequel l'interface de communication inter-cœurs (ICC) comprend : deux mémoires d'échange unidirectionnelles (MEM1, MEM2) ; ou une mémoire d'échange bidirectionnelle. 4. Dispositif de contrôle (APP) selon l'une des revendications 1 à 3, dans lequel l'interface de communication inter-cœurs (ICC) comprend des moyens de transmission (EVT_BUS) de signaux de déclenchement (EVT_BOOT, EVT_TRIG) entre le premier (COR1) et le deuxième cœur (COR2).
5. Aéronef (AC) comprenant : un dispositif de contrôle (APP) selon l'une des revendications 1 à 4 ; au moins un dispositif source (NAV) fournissant des données de vol (NAV_DATA) ; et au moins un dispositif embarqué (ACT) contrôlé par le dispositif de contrôle (APP) à partir des données de vol (NAV_DATA).
6. Aéronef (AC) selon la revendication 5, dans lequel ledit au moins un dispositif embarqué (ACT) comprend un actionneur électrique d'une gouverne de l'aéronef (AC).
7. Procédé de contrôle d'au moins un dispositif embarqué (ACT) dans un aéronef (AC) à partir de données de vol (NAV_DATA) fournies par au moins un dispositif source (NAV), le procédé de contrôle étant mis en œuvre par un dispositif de contrôle (APP) selon l'une des revendications 1 à 4, et le procédé de contrôle comprenant des étapes, mises en œuvre par le premier cœur (COR1) du processeur multi-cœurs (PROC) du dispositif de contrôle (APP), de : fourniture (S130), via l'interface de communication inter-cœurs (ICC) du processeur (PROC), de données d'entrée (IN_CLT) obtenues à partir des données de vol (NAV_DATA) ; obtention (S150), via l'interface de communication inter-cœurs (ICC), de données de sortie (OUT_CLT) ; et fourniture (S160), audit au moins un dispositif embarqué (ACT), des données de contrôle (ACT_CMD) obtenues à partir des données de sortie (OUT_CLT).
8. Procédé de contrôle selon la revendication 7, comprenant une étape d'envoi (S140), par le premier cœur (COR1) au deuxième cœur (COR2) du processeur (PROC), d'un signal de déclenchement (EVT_TRIG) d'une fourniture par le programme applicatif (CLT_SW) de dites données de sortie (OUT_CLT) obtenues à partir de dites données d'entrée (IN_CLT).
9. Procédé de contrôle selon la revendication 8, comprenant une étape d'envoi (SI 10), par le premier cœur (COR1) au deuxième cœur (COR2), d'un signal de déclenchement (EVT_BOOT) d'un démarrage du programme applicatif (CLT_SW).
10. Procédé de contrôle selon la revendication 9, comprenant des étapes, mises en œuvre par le deuxième cœur (COR2) pour démarrer le programme applicatif (CLT_SW), de : si le programme applicatif (CLT_SW) est chargé sur le deuxième cœur (COR2), initialisation (S232) de données de configuration du programme applicatif (CLT_SW) et déclenchement (S233) d'une exécution par le deuxième cœur (COR2) du programme applicatif (CLT_SW) ; et sinon, chargement (S221) sur le deuxième cœur (COR2) du programme applicatif (CLT_SW) et déclenchement (S223) d'un démarrage du programme applicatif (CLT_SW). Procédé de contrôle selon l'une des revendications 8 à 10, comprenant une étape de vérification (S222, S231), mise en œuvre par le deuxième cœur (COR2), d'une signature numérique associée au programme applicatif (CLT_SW). Programme d'ordinateur (PLT_SW), dit de contrôle, comprenant des instructions pour exécuter les étapes, mises en œuvre par le premier cœur (COR1) du processeur multi-cœur (PROC) d'un dispositif de contrôle (APP) selon l'une des revendications 1 à 4, d'un procédé de contrôle selon l'une des revendications 7 à 11, lorsque ledit programme de contrôle (PLT_SW) est exécuté par le premier cœur (COR1). Procédé applicatif mis en œuvre par le deuxième cœur (COR2) du processeur multi-cœur (PROC) d'un dispositif de contrôle (APP) selon l'une des revendications 1 à 4, le deuxième cœur (COR2) étant isolé en ce qu'il communique uniquement avec le premier cœur (COR1) du processeur (PROC) et via l'interface de communication inter-cœurs (ICC), ledit procédé applicatif comprenant des étapes de : obtention (S241), via l'interface de communication inter-cœurs (ICC), de données d'entrée (IN_CLT) ; obtention (S242) de données de sortie (OUT_CLT) à partir des données d'entrée (IN_CLT) ; et fourniture (S243), via l'interface de communication inter-cœurs (ICC), des données de sortie (OUT_CLT). Programme d'ordinateur (CLT_SW), dit applicatif, comprenant des instructions pour mettre en œuvre les étapes d'un procédé applicatif selon la revendication 13, lorsque le programme applicatif (CLT_SW) est exécuté par le deuxième cœur (COR2) du processeur multi-cœur (PROC) d'un dispositif de contrôle (APP) selon l'une des revendications 1 à 4.
EP23813447.2A 2022-11-16 2023-11-10 Procede et dispositif de controle d'au moins un dispositif embarque dans un aeronef Pending EP4619873A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2211926A FR3142017B1 (fr) 2022-11-16 2022-11-16 Procédé et dispositif de contrôle d’au moins un dispositif embarqué dans un aéronef
PCT/FR2023/051774 WO2024105327A1 (fr) 2022-11-16 2023-11-10 Procede et dispositif de controle d'au moins un dispositif embarque dans un aeronef

Publications (1)

Publication Number Publication Date
EP4619873A1 true EP4619873A1 (fr) 2025-09-24

Family

ID=85036778

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23813447.2A Pending EP4619873A1 (fr) 2022-11-16 2023-11-10 Procede et dispositif de controle d'au moins un dispositif embarque dans un aeronef

Country Status (3)

Country Link
EP (1) EP4619873A1 (fr)
FR (1) FR3142017B1 (fr)
WO (1) WO2024105327A1 (fr)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10852724B2 (en) * 2018-04-30 2020-12-01 DJI Research LLC Customizable waypoint missions

Also Published As

Publication number Publication date
WO2024105327A1 (fr) 2024-05-23
FR3142017B1 (fr) 2025-03-07
FR3142017A1 (fr) 2024-05-17

Similar Documents

Publication Publication Date Title
US9749335B2 (en) Secure, non-disruptive firmware updating
EP1687717B1 (fr) Demarrage securise d'un appareil electronique a architecture smp
WO2023030854A1 (fr) Sécurisation de nacelles dans un environnement d'orchestration de conteneurs
EP3633495B1 (fr) Procédé de gestion d'une alimentation dvfs et système correspondant
FR3017725A1 (fr) Procede de deploiement d'un ensemble d'application (s) logicielle (s)
FR2948789A1 (fr) Composant logiciel et dispositif pour le traitement automatise de donnees multi-usages, mettant en oeuvre des fonctions ayant besoin de differents niveaux de surete ou limites de responsabilite
FR2936068A1 (fr) Procede et dispositif d'encapsulation d'applications dans un systeme informatique pour aeronef.
FR2937437A1 (fr) Procede de fonctionnement d'un equipement embarque, equipement associe et aeronef comprenant un tel equipement
EP2110742A1 (fr) Dispositif portable et procédé de démarrage externe d'une installation informatique
AU2015358292A1 (en) Computing systems and methods
EP2274701A2 (fr) Systeme et procede de securisation d'un ordinateur comportant un micronoyau
EP2876551A1 (fr) Procédé, programme d'ordinateur et dispositif de configuration ou de maintenance d'un système informatique dans un cluster
US20240370274A1 (en) Operating system startup method, apparatus, and electronic device
US10552168B2 (en) Dynamic microsystem reconfiguration with collaborative verification
EP4220206B1 (fr) Dispositif de chargement de données dans des unités informatiques de traitement depuis une source de données
FR2876197A1 (fr) Procede de gestion flexible d'activites multiples executees sur des plateformes partitionnables d'un systeme a processeurs multiples
EP4619873A1 (fr) Procede et dispositif de controle d'au moins un dispositif embarque dans un aeronef
FR3003366A1 (fr) Procede, dispositif et programme d'ordinateur pour l'installation ou la desinstallation automatique de modules logiciels dans des equipements embarques d'un aeronef
EP3923169B1 (fr) Démarrage sécurisé d'un circuit électronique
CN121637525A (zh) 多小芯片、多加速器封装中系统的保密计算安全管理
EP4298766A1 (fr) Procédé de contrôle d'une grappe de noeuds esclave par une grappe de noeuds maître, dispositifs et programmes d'ordinateurs correspondants
EP2048576B1 (fr) Procédé de mise à jour sécurisée d'un programme à lancement automatique et entité électronique portable le mettant en oeuvre
US11803634B2 (en) Secure preconfigured profile for role-based access control setup
WO2009138641A1 (fr) Procede d'utilisation d'un terminal hote par un dispositif externe connecte au terminal
WO2021023694A1 (fr) Procédé d'écriture dans une zone de données sécurisée d'un calculateur sur bus embarqué de véhicule

Legal Events

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

Free format text: STATUS: UNKNOWN

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

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

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250522

AK Designated contracting states

Kind code of ref document: A1

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)