Talent.com
Cette offre d'emploi n'est pas disponible dans votre pays.
Sérialisation en temps logique de multiples simulations avioniques temps réel

Sérialisation en temps logique de multiples simulations avioniques temps réel

LIAS-ENSMA, Nouvelle Aquitaine, FR
Il y a plus de 30 jours
Type de contrat
  • Temps plein
Description de poste

Topic description

CONTEXTE ET PROBLÉMATIQUE INDUSTRIELLE

La simulation joue un rôle primordial dans le processus de conception, d’intégration, de vérification et de validation des systèmes critiques, en particulier en avionique. Plusieurs niveaux de simulation sont possibles pour l’avionique. Le premier niveau (SIL – Software-in-the-Loop), purement logiciel et logique, est de type banc de test virtuel (VTB – Virtual Test Bench). Il permet de tester de nouvelles fonctionnalités innovantes dans des conditions nominales. Le SECOND NIVEAU VTB prend en compte les différentes redondances du système et permet de tester le comportement du système face à des situations non nominales (combinaisons de pannes, conditions extérieures éprouvantes pour l’avion, perturbations, pilotage particulier, etc.). Il permet également de rejouer des conditions de panne afin d’analyser les causes et éventuellement de détecter des bugs. Enfin, la simulation HIL (Hardware in the Loop) exécute les sous-systèmes sur l’architecture réelle cible (calculateurs, réseaux, entrées, sorties sur actionneurs réelles), et est de type banc de test hybride (HTB - Hybrid Test Bench) ou physique (PTB – Physical Test Bench). Un PTB est bien souvent unique pour un avion (Avion 0 – Iron Bird). Il peut satisfaire certains tests de certification avion, mais les coûts sont importants, de l’ordre de centaines de millions d’euros pour le développement (d’où son unicité) et plusieurs milliers d’euros par heure d’utilisation. Son fonctionnement temps réel et son coût de fonctionnement limite son utilisation pour simuler toutes les situations anormales envisageables.

Le second niveau VTB, focus de la thèse, est celui qui peut être utilisé pour tester plus largement, quasi exhaustivement, certaines séquences d’événements. Ici exhaustif fait référence à l’état interne des calculateurs vis-à-vis de l’ordre des échanges d’information dans un système avion qui est conçu de façon asynchrone. Aujourd’hui, tous les niveaux de simulations s’exécutent en temps réel. Ainsi, la génération de plusieurs dizaines ou centaines de milliers de simulations de second niveau VTB est exclue. Pourtant, ces simulations permettraient d’anticiper dans le cycle de conception de l’avion la détection d’erreurs (et donc de réduire leur coût de correction). Elles faciliteraient également l’entraînement de modèles d’apprentissage automatique qui pourrait permettre à moyen terme l’émergence de l’utilisation de ces techniques dans le cockpit.

PROBLÉMATIQUES SCIENTIFIQUES

Aujourd’hui, le lancement d’une simulation VTB de second niveau s’effectue par un lancement en parallèle des fonctions nécessaires (p.ex. affichage graphique, fonctions testées, etc.) sur différents cœurs de calculs. Cependant, les taux d’utilisation de ses cœurs sont très variables. Par exemple, pour un ou deux cœurs de CPU chargés à %, les autres peuvent ne pas dépasser les 50 %. La problématique est que l’ensemble de ces cœurs reste utilisé (et donc indisponible) pour toute la durée de la simulation. Ainsi, afin de maximiser le nombre de simulations VTB, l’objectif est de sérialiser une simulation pour minimiser le nombre de cœurs (l’idéal étant un unique cœur) utilisés, quitte à en augmenter la durée. Tous les cœurs utilisés par une simulation doivent être chargés au maximum (optimalement à %) et les autres cœurs ainsi libérés seront utilisés pour pouvoir lancer d’autres simulations en parallèle. La plateforme de simulation de second niveau VTB doit pouvoir être aussi bien locale que dans un cloud. Différents défis sont à relever comme énoncé ci-dessous.

  • PROPRIÉTÉ INTELLECTUELLE  : différents modules de simulation sont fournis sous forme de boîte noire, dont seuls certains paramètres (interfaces d’entrées / sorties, fréquences internes et externes) sont connus. Le contexte est donc celui d’une co-simulation .
  • HÉTÉROGÉNÉITÉ  : divers modules de simulation peuvent requérir divers environnements aussi bien logiciels (système d’exploitation, bibliothèques et versions spécifiques) que matériels (GPU, processeurs particuliers).
  • COMPLEXITÉ  : une simulation est constituée de plusieurs dizaines, voire centaines de modules de simulation, s’échangeant des centaines de milliers de variables. Il convient donc de proposer des solutions de complexité polynomiale.
  • DISTRIBUTION DE FONCTIONS MULTI PÉRIODIQUES COMMUNICANTES  : quelle que soit la plateforme, cloud privé, publique ou plateformes dédiées, les ressources doivent être utilisées au mieux de leurs possibilités. Un scénario peut être vu comme l’exécution de traitements périodiques durant un temps logique donné (exemple  : 60 secondes de simulation nécessitent l’exécution en périodique logique de 60 × 50 instances d’un module de simulation s’exécutant à 20 Hz). Il s’agit donc de placer au mieux plusieurs scénarios sur une plateforme hétérogène (si possible de façon optimale au regard du makespan, c-à-d de la durée totale nécessaire à l’exécution d’un – grand – nombre de scenarios donnés).

PISTES SCIENTIFIQUES

Plusieurs pistes sont ouvertes par l’avènement concomitant de plusieurs théories et technologies.

  • La norme EUROCAE ED-A et la future norme ED-B permettent d’uniformiser les interfaces et les définitions des propriétés temporelles internes des modules de simulation, permettant de s’affranchir en partie des problèmes liés à la co-simulation. De plus, les modules de simulation utilisés en avionique sont généralement peu couplés, et permettent de simuler à l’échelle d’une application s’exécutant périodiquement sur un équipement ;
  • L’utilisation de conteneurs devrait permettre de garantir une indépendance de l’environnement de simulation par rapport à l’hétérogénéité ;
  • Des travaux du laboratoire permettent, de façon statique et sous réserve d’un temps d’exécution connu, de créer des ordonnancements optimaux de systèmes de tâches périodiques sur plateformes hétérogènes en temps polynomial . Il est donc possible de calculer en temps polynomial, sous des hypothèses de durées de préemption et de migration nulles, l’utilisation maximale qui peut être faite d’une plateforme hétérogène par des traitements périodiques. Ces travaux se sont limités aux tâches indépendantes, et il conviendra de les étendre au cas de précédences multi périodiques, en se basant sur un modèle de (SPC – Semaphore Precedence Constraints) proposé par le laboratoire . Ce modèle permettra d’exprimer les décalages possibles entre les différents modules de simulations lors de l’occurrence d’événements.
  • TRAVAUX DE LA THÈSE

    Le ou la doctorante suivra les différentes étapes de la thèse :

  • État de l’art sur la co-simulation distribuée, la simulation dans le cloud, l’ordonnancement multiprocesseur hétérogène, et les précédences multi périodiques, normes et outils autour de la simulation distribuée (ED , HLA, Ptolemy, etc.) ;
  • Prise en main de l’environnement de simulation de second niveau VTB Airbus ;
  • Prise en main des technologies d’orchestration de conteneurs (Docker, Kubernetes, Argo, etc.) et évaluation des délais type de création, destruction, communications entre conteneurs. À noter qu’un stage de travaux préliminaires sur ce point a eu lieu ;
  • Modélisation de problèmes d’ordonnancement de modules de simulation asynchrones communiquant de façon multi périodique. Ici, les hypothèses sont clés dans la complexité du problème. Ainsi, il est probable que la prise en compte de délais liés à la préemption, ou la migration de modules rende le problème NP-difficile au sens fort . Plusieurs modèles seront proposés, du moins réaliste négligeant certains délais (ordonnancement optimal en temps polynomial), à l’insertion d’hypothèses plus réalistes permettant de proposer des heuristiques sous-optimales, mais dont la qualité pourrait être comparée à l’optimale par des méthodes de type ratio de compétitivité . Dans cette modélisation, on identifiera les ordonnanceurs statiques permettant à chaque module de ne pas migrer durant une simulation, par rapport aux ordonnanceurs permettant la migration afin de maximiser l’utilisation des ressources ;
  • Mise en œuvre de la simulation telle qu’obtenue par méthode d’ordonnancement en s’appuyant sur l’aide technique d’un stage ;
  • Choix expérimentaux des paramètres les plus simples (prise en compte des délais de communication, des durées moyennes d’exécution, etc.) permettant d’obtenir une simulation sérialisée représentative de la simulation PTB.
  • Starting date

  • 12-01
  • Funding category

    Cifre

    Funding further details

    Airbus