FR3142017A1 - Procédé et dispositif de contrôle d’au moins un dispositif embarqué dans un aéronef - Google Patents

Procédé et dispositif de contrôle d’au moins un dispositif embarqué dans un aéronef Download PDF

Info

Publication number
FR3142017A1
FR3142017A1 FR2211926A FR2211926A FR3142017A1 FR 3142017 A1 FR3142017 A1 FR 3142017A1 FR 2211926 A FR2211926 A FR 2211926A FR 2211926 A FR2211926 A FR 2211926A FR 3142017 A1 FR3142017 A1 FR 3142017A1
Authority
FR
France
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
FR2211926A
Other languages
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
Priority to FR2211926A priority Critical patent/FR3142017A1/fr
Priority to PCT/FR2023/051774 priority patent/WO2024105327A1/fr
Publication of FR3142017A1 publication Critical patent/FR3142017A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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

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). Figure pour l’abrégé : Fig. 2

Description

Procédé et dispositif de contrôle d’au moins un dispositif embarqué dans un aéronef
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 œuvre de dispositifs de contrôle de moteurs électriques d’actionnement de commandes de vol.
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).
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 œuvre 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.
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.
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
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.
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.
S elon 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.
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.
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).
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.
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 temporellement d’un programme exécuté sur le premier cœur.
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.
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 sureté de fonctionnement du dispositif de contrôle.
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).
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.
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.
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).
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.
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).
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.
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.
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.
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.
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.
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.
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.
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
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.
À 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.
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.
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.
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.
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.
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é.
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.
L’aéronef proposé dispose des avantages décrits ci-dessus en lien avec le dispositif de contrôle conforme à l’invention.
Selon un mode de réalisation, ledit au moins un dispositif embarqué comprend un actionneur électrique d’une gouverne de l’aéronef.
Ce mode de réalisation, grâce à l’utilisation du dispositif de contrôle proposé, permet de mettre en œuvre les commandes de vol d’un aéronef de manière fiable et rapide.
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.
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 œuvre 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.
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.
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.
Nous rappelons ici que le dispositif de contrôle proposé permet d’exécuter, de manière séparée temporellement 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.
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.
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.
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).
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.
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.
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.
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.
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.
Selon un mode de réalisation, le procédé de contrôle comprend une étape de vérification, mise en œuvre par le deuxième cœur, d’une signature numérique associée au programme applicatif.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 :
La représente un exemple d’architecture logicielle et matérielle d’un aéronef selon un mode de réalisation de l’invention ;
La 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 ;
La et la 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
La et la 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 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 est décrite ci-après pour introduire la présente invention et exemplifier un contexte particulier d’application de celle-ci.
Tel qu’illustré sur la , 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.
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.
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.
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.
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.
Tel qu’illustré par la , 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 œuvre 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 œuvre un algorithme spécifique nécessaire au contrôle de ces dispositifs ACT. Par exemple, le programme applicatif CLT_SW peut mettre en œuvre un algorithme de loi d’effort permettant de déterminer les consignes à appliquer à une gouverne de l’aéronef AC.
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.
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.
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 œuvre le dispositif de contrôle). Aussi, l'architecture du dispositif de contrôle APP proposé est indépendante du programme applicatif CLT_SW.
Pour cette raison, nous décrivons tout d’abord l'architecture du dispositif de contrôle APP proposé en référence à la , puis le fonctionnement du dispositif de contrôle APP proposé en référence aux figures suivantes.
La 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 .
Tel qu’illustré par la , 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.
Le processeur PROCcomprend : au moins un premier cœur COR1 et un deuxième cœur COR2 ; et une interface de communication inter-cœurs ICC.
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.
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.
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.
Ainsi, selon un mode de réalisation, le processeur PROC est un DSP bi-cœur.
L’interface de communication inter-cœurs ICCcomprend : 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 »).
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.
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.
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.
Le premier cœur COR1est configuré pour exécuter le programme de contrôle PLT_SW. Tel qu’illustré par la , 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).
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.
Le deuxième cœur COR2est 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.
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 temporellement du programme de contrôle PLT_SW exécuté sur le premier cœur COR1.
Les avantages du dispositif de contrôle APPproposé résultent, tel que précédemment décrit, de la séparation physique et temporelle des exécutions de plusieurs programmes.
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.
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.
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é.
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.
La et la 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 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 .
Tel qu’illustré par la , 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.
Tel qu’illustré par la , 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.
À 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.
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.
À 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.
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.
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.
À 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.
À 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.
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.
À 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 ) 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.
À 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.
À l’étape S242, le deuxième cœur COR2 (i.e. le programme applicatif CLT_SW) obtient les données de sorties OUT_CLT à partir des données d’entrée IN_CLT.
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.
À 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.
À 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.
À 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.
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.
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.
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.
La et la 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.
Tel qu’illustré sur la , 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 .
À 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 S110.
À l’étape S110, 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 ) 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.
Suite à l’étape S110, 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.
À 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.
À 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.
À 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.
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.
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.
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.
À 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.
À 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.
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.
Selon un mode de réalisation, le programme de chargement LDR comprend en outre des instructions pour réaliser l’étape S222.
À 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.
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.
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.
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.
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.
À 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.
À 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.
Selon un mode de réalisation, le programme d’initialisation PRE_LDR comprend en outre des instructions pour réaliser l’étape S231.
À 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.
À 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.
À l’étape S23 3, 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.
À 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.
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).
À 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.
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é.
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.
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.
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 (15)

  1. 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 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).
  2. Dispositif de contrôle (APP) selon la revendication 1, dans lequel le premier cœur (COR1) est configuré pour exécuter un programme dit de contrôle (PLT_SW) obtenant les données de vol (NAV_DATA) et fournissant les données de contrôle (ACT_CMD), et le deuxième cœur (COR2) est configuré pour exécuter un programme dit applicatif (CLT_SW) obtenant les données d’entrée (IN_CLT) et fournissant les données de sorties (OUT_CLT).
  3. Dispositif de contrôle (APP) selon la revendication 1 ou 2, 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).
  4. Dispositif de contrôle (APP) selon l’une des revendications 1 à 3, 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.
  5. Dispositif de contrôle (APP) selon l’une des revendications 1 à 4, 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).
  6. Aéronef (AC) comprenant : un dispositif de contrôle (APP) selon l’une des revendications 1 à 5 ; 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).
  7. Aéronef (AC) selon la revendication 6, dans lequel ledit au moins un dispositif embarqué (ACT) comprend un actionneur électrique d’une gouverne de l’aéronef (AC).
  8. 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 comprenant des étapes, mises en œuvre par un premier cœur (COR1) d’un processeur multi-cœur (PROC), de :
    • fourniture (S130), via une 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).
  9. Procédé de contrôle selon la revendication 8, comprenant une étape d’envoi (S140), par le premier cœur (COR1) à un deuxième cœur (COR2) du processeur (PROC), d’un signal de déclenchement (EVT_TRIG) d’une fourniture par un programme applicatif (CLT_SW) de dites données de sortie (OUT_CLT) obtenues à partir de dites données d’entrée (IN_CLT).
  10. Procédé de contrôle selon la revendication 9, comprenant une étape d’envoi (S110), 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).
  11. Procédé de contrôle selon la revendication 10, 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).
  12. Procédé de contrôle selon l’une des revendications 9 à 11, 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).
  13. Programme d’ordinateur (PLT_SW), dit de contrôle, comprenant des instructions pour exécuter les étapes, mises en œuvre par un premier cœur (COR1) d’un processeur multi-cœur (PROC), d’un procédé de contrôle selon l’une des revendications 8 à 12, lorsque ledit programme de contrôle (PLT_SW) est exécuté par le premier cœur (COR1).
  14. Procédé applicatif mis en œuvre par un deuxième cœur (COR2) d’un processeur multi-cœur (PROC), le deuxième cœur (COR2) étant isolé en ce qu’il communique uniquement avec un premier cœur (COR1) du processeur (PROC) et via une 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).
  15. Programme d’ordinateur (CLT_SW), dit applicatif, comprenant des instructions pour mettre en œuvre les étapes d’un procédé applicatif selon la revendication 14, lorsque le programme applicatif (CLT_SW) est exécuté par un deuxième cœur (COR2) d’un processeur multi-cœur (PROC).
FR2211926A 2022-11-16 2022-11-16 Procédé et dispositif de contrôle d’au moins un dispositif embarqué dans un aéronef Pending FR3142017A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR2211926A FR3142017A1 (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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2211926 2022-11-16
FR2211926A FR3142017A1 (fr) 2022-11-16 2022-11-16 Procédé et dispositif de contrôle d’au moins un dispositif embarqué dans un aéronef

Publications (1)

Publication Number Publication Date
FR3142017A1 true FR3142017A1 (fr) 2024-05-17

Family

ID=85036778

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2211926A Pending FR3142017A1 (fr) 2022-11-16 2022-11-16 Procédé et dispositif de contrôle d’au moins un dispositif embarqué dans un aéronef

Country Status (2)

Country Link
FR (1) FR3142017A1 (fr)
WO (1) WO2024105327A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190332105A1 (en) * 2018-04-30 2019-10-31 DJI Research LLC Customizable waypoint missions

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190332105A1 (en) * 2018-04-30 2019-10-31 DJI Research LLC Customizable waypoint missions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
RAN TAO ET AL: "Design and implementation of SOPC partial reconfigurable Dual-core flight", 2019 14TH IEEE INTERNATIONAL CONFERENCE ON ELECTRONIC MEASUREMENT & INSTRUMENTS (ICEMI), IEEE, 1 November 2019 (2019-11-01), pages 1418 - 1427, XP033774737, DOI: 10.1109/ICEMI46757.2019.9101432 *

Also Published As

Publication number Publication date
WO2024105327A1 (fr) 2024-05-23

Similar Documents

Publication Publication Date Title
US9749335B2 (en) Secure, non-disruptive firmware updating
EP2178016B1 (fr) Procédé de fonctionnement d'un équipement embarqué, équipement associé et aéronef comprenant un tel équipement
FR2862397A1 (fr) Demarrage securise d'un appareil electronique a architecture smp
EP2460071A2 (fr) Traitement automatisé de données multi-usages, mettant en oeuvre des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité
FR3103586A1 (fr) Procédé de gestion du fonctionnement d’un système sur puce formant par exemple un microcontrôleur, et système sur puce correspondant
EP2477115A1 (fr) Procédé et dispositif d'encapsulation d'applications dans un systéme informatique pour aéronef
FR2972821A1 (fr) Procede et dispositif d'installation/desinstallation de modules logiciels, avec resolution centralisee de contraintes, dans des equipements d'aeronef
WO2009136080A2 (fr) Systeme et procede de securisation d'un ordinateur comportant un micronoyau
FR2946769A1 (fr) Procede et dispositif de reconfiguration d'avionique.
EP3633495B1 (fr) Procédé de gestion d'une alimentation dvfs et système correspondant
EP1324175B1 (fr) Module de securisation de donnees par chiffrement/dechiffrement et/ou signature/verification de signature
FR3103585A1 (fr) Procédé de gestion de la configuration d’accès à des périphériques et à leurs ressources associées d’un système sur puce formant par exemple un microcontrôleur, et système sur puce correspondant
FR3103584A1 (fr) Procédé de gestion du débogage d’un système sur puce formant par exemple un microcontrôleur, et système sur puce correspondant
FR3142017A1 (fr) Procédé et dispositif de contrôle d’au moins un dispositif embarqué dans un aéronef
FR3045879A1 (fr) Plateforme d'execution avionique et plateforme de developpement permettant la certification independante de composants logiciels
US10552168B2 (en) Dynamic microsystem reconfiguration with collaborative verification
EP2048576B1 (fr) Procédé de mise à jour sécurisée d'un programme à lancement automatique et entité électronique portable le mettant en oeuvre
WO2021023694A1 (fr) Procédé d'écriture dans une zone de données sécurisée d'un calculateur sur bus embarqué de véhicule
FR3069680B1 (fr) Dispositif gestionnaire d'interfaces dans un aeronef
FR2966263A1 (fr) Procede de controle d'un circuit integre, circuit integre et calculateur comportant un circuit integre
US20220269772A1 (en) Secure preconfigured profile for role-based access control setup
EP1526431A1 (fr) Contrôle d'accès à des périphériques d'un microprocesseur
US20240095215A1 (en) Updating edge nodes in distributed computing environments using partitions
US20220286302A1 (en) Information handling system with overlay ownership certificates for ownership chaining
WO2022180323A1 (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

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20240517