Brevet FR3072191A1 — publié le 20190412

Procédé et dispositif de surveillance d'une application logicielle avionique via sa durée d'exécution, programme d'ordinateur et système avionique associés La présente invention concerne un procédé de surveillance d'une application logicielle avionique apte à être exécutée sur une plateforme hébergeant un système d'exploitation, l'application logicielle avionique comportant un ou plusieurs traitements logiciels à exécuter, la plateforme étant destinée à être embarquée à bord d'un aéronef, le procédé étant mis en oeuvre par un dispositif électronique de surveillance. L'invention concerne également un programme d'ordinateur comportant des instructions logicielles qui, lorsqu'elles sont exécutées par un ordinateur, mettent en oeuvre un tel procédé. L'invention concerne également un dispositif électronique de surveillance d'une application logicielle avionique apte à être exécutée sur une plateforme hébergeant un système d'exploitation, l'application logicielle avionique comportant un ou plusieurs traitements logiciels à exécuter, la plateforme étant destinée à être embarquée à bord d'un aéronef. L'invention concerne également un système électronique avionique comprenant une mémoire apte à stocker au moins une application logicielle avionique ; une plateforme apte à exécuter chaque application logicielle avionique, la plateforme hébergeant un système d'exploitation ; et un tel dispositif électronique de surveillance de chaque application logicielle avionique. L'invention concerne le domaine de la qualification des plateformes avioniques embarquées, en particulier de la surveillance du fonctionnement des applications logicielles exécutées sur de telles plateformes avioniques embarquées, notamment pour des plateformes avioniques comportant un ou plusieurs processeurs multi-coeurs. La surveillance est par exemple une surveillance de type Safety Net. L'utilisation de processeurs multi-coeurs apporte une difficulté importante pour la qualification des plateformes. En effet, l'exécution simultanée de plusieurs logiciels sur un même processeur s'accompagne de risques de contentions à cause du partage de ressources communes (bus, mémoire), sans que le comportement du processeur, notamment lorsqu'il est multi-coeurs, puisse être facilement maitrisé. Le terme « contention » désigne toute situation dans laquelle au moins une activité menée par au moins un coeur d'un processeur multi-coeurs subit des retards dans son exécution à cause du parallélisme temporel permis par ce processeur multi-coeurs. 2 L'origine des contentions est généralement l'usage de ressources communes du processeur ou du système d'exploitation, également appelé OS (de l'anglais Operating System) aboutissant à des attentes générant ces retards. L'effet d'une contention est alors un retard sur l'exécution d'une application logicielle hébergée sur un coeur. 5 Un premier exemple de contention est le bus (appelé souvent « interconnect ») reliant les coeurs les uns aux autres qui ne permet pas toujours des transactions simultanées entre coeurs ou entre les coeurs et les périphériques, tels que certaines mémoires cache intégrées ou la mémoire externe. Un autre exemple de contention est l'usage de modules logiciels communs de l'OS 10 installés sur un des coeurs et appelés par l'ensemble de coeurs, potentiellement simultanément. Des appels simultanés à de tels modules logiciels communs provoquent un arbitrage et une mise en attente de certaines demandes afin de sérialiser les traitements logiciels sur le coeur où le module logiciel commun est installé. Un autre exemple de contention est une interruption momentanée de tous les 15 coeurs sur évènement particulier sur un des coeurs afin de gérer un statut cohérent entre tous les coeurs. Lorsque le processeur est en outre un processeur acheté auprès d'un fournisseur, ou processeur COTS (de l'anglais Commercial Off-The-Shelf), il est généralement impossible d'avoir accès au détail de conception des organes internes d'un tel processeur 20 multi-coeurs, et il est donc très difficile, voire impossible de garantir un comportement déterministe du processeur. Le but de l'invention est alors de proposer un procédé et un dispositif de surveillance d'une application logicielle avionique apte à être exécutée sur une plateforme 25 avionique, qui permette de surveiller plus efficacement l'application logicielle. A cet effet, l'invention a pour objet un procédé de surveillance d'une application logicielle avionique apte à être exécutée sur une plateforme hébergeant un système d'exploitation, l'application logicielle avionique comportant un ou plusieurs traitements logiciels à exécuter, la plateforme étant destinée à être embarquée à bord d'un aéronef, le 30 procédé étant mis en oeuvre par un dispositif électronique de surveillance et comprenant les étapes suivantes : - la surveillance de la durée d'exécution de l'application logicielle avionique, via la vérification, à l'expiration d'au moins un délai d'exécution prédéfini, de l'achèvement de l'exécution d'au moins un traitement logiciel de l'application logicielle avionique ; et 35 - la mise à jour d'un statut de l'application logicielle avionique en fonction de la surveillance de la durée d'exécution de l'application logicielle avionique. 3 Avec le procédé de surveillance selon l'invention, la surveillance de la durée d'exécution de l'application logicielle avionique permet alors de détecter un dysfonctionnement de l'application logicielle avionique, correspondant à une situation de contention de l'application logicielle avionique, ou encore à une situation « hors sécurité » 5 impliquant un risque de sécurité de fonctionnement. Suivant d'autres aspects avantageux de l'invention, le procédé de surveillance comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : - l'étape de surveillance de la durée d'exécution comporte la vérification, à 10 l'expiration d'un premier délai d'exécution prédéfini, puis à l'expiration d'un deuxième délai d'exécution prédéfini, de l'achèvement de l'exécution d'au moins un traitement logiciel de l'application logicielle avionique, le deuxième délai d'exécution prédéfini étant strictement supérieur au premier délai d'exécution prédéfini ; - lors de l'étape de mise à jour du statut, le statut de l'application logicielle 15 avionique est positionné à « contention » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique a été détecté après l'expiration du premier délai d'exécution prédéfini et avant l'expiration du deuxième délai d'exécution prédéfini ; - lors de l'étape de mise à jour du statut : 20 + le statut de l'application logicielle avionique est positionné à « normal » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique a été détecté avant l'expiration du ou de chaque délai d'exécution prédéfini ; et + le statut de l'application logicielle avionique est positionné à « hors 25 sécurité » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique n'a pas été détecté après l'expiration du ou de chaque délai d'exécution prédéfini ; - le procédé comprend en outre l'étape suivante : + la surveillance du comportement de l'application logicielle avionique, via 30 la vérification, à l'expiration d'un délai de surveillance prédéfini, de la détection d'au moins un évènement applicatif de l'application logicielle avionique ; la mise à jour du statut de l'application logicielle avionique dépendant alors de la surveillance de la durée d'exécution et de la surveillance du comportement de l'application logicielle avionique ; 35 - lors de l'étape de mise à jour du statut, le statut de l'application logicielle avionique est positionné à « contention » lorsque l'achèvement de l'exécution du ou des 4 traitements logiciels correspondants de l'application logicielle avionique a été détecté après l'expiration du premier délai d'exécution prédéfini et avant l'expiration du deuxième délai d'exécution prédéfini, et lorsque le ou les évènements applicatifs corrects ont été détectés avant l'expiration du délai de surveillance prédéfini ; 5 - lors de l'étape de mise à jour du statut : + le statut de l'application logicielle avionique est positionné à « normal » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique a été détecté avant l'expiration du ou de chaque délai d'exécution prédéfini et lorsque le ou les évènements 10 applicatifs corrects ont été détectés avant l'expiration du délai de surveillance prédéfini ; et + le statut de l'application logicielle avionique est positionné à « hors sécurité » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique n'a pas été détecté après 15 l'expiration du ou de chaque délai d'exécution prédéfini et lorsque le ou les évènements applicatifs corrects ont été détectés avant l'expiration du délai de surveillance prédéfini ; - lors de l'étape de mise à jour du statut, le statut de l'application logicielle avionique est positionné à « hors-contrôle » lorsqu'aucun évènement applicatif n'a été 20 détecté à l'expiration du délai de surveillance prédéfini ou bien lorsque l'évènement applicatif détecté est incorrect ; et - lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique n'a pas été détecté après l'expiration du ou de chaque délai d'exécution prédéfini, et lorsqu'aucun évènement applicatif n'a été 25 détecté à l'expiration du délai de surveillance prédéfini ou bien l'évènement applicatif détecté est incorrect, le statut de l'application logicielle avionique est, lors de l'étape de mise à jour du statut, positionné à « hors sécurité » si chaque délai d'exécution prédéfini est inférieur au délai de surveillance prédéfini et à « hors-contrôle » sinon. Avec le procédé de surveillance selon un deuxième mode de réalisation de 30 l'invention, la surveillance à la fois de la durée d'exécution de l'application logicielle avionique et du comportement de l'application logicielle avionique permet alors de détecter un dysfonctionnement de l'application logicielle avionique, correspondant à une situation de contention de l'application logicielle avionique, à une situation « hors sécurité » impliquant un risque de sécurité de fonctionnement, ou encore à une situation 35 « hors contrôle » où l'application logicielle avionique est considérée comme devenue folle. 5 L'invention a également pour objet un programme d'ordinateur comportant des instructions logicielles qui, lorsqu'elles sont exécutées par un ordinateur, mettent en oeuvre un procédé de surveillance tel que défini ci-dessus. L'invention a également pour objet un dispositif électronique de surveillance d'une 5 application logicielle avionique apte à être exécutée sur une plateforme hébergeant un système d'exploitation, l'application logicielle avionique comportant un ou plusieurs traitements logiciels à exécuter, la plateforme étant destinée à être embarquée à bord d'un aéronef, le dispositif électronique de surveillance comprenant : - un module de surveillance configuré pour surveiller la durée d'exécution de 10 l'application logicielle avionique, via la vérification, à l'expiration d'au moins un délai d'exécution prédéfini, de l'achèvement de l'exécution d'au moins un traitement logiciel de l'application logicielle avionique ; et - un module de mise à jour configuré pour mettre à jour un statut de l'application logicielle avionique en fonction de la surveillance de la durée d'exécution de l'application 15 logicielle avionique. L'invention a également pour objet un système électronique avionique comprenant : - une mémoire apte à stocker au moins une application logicielle avionique ; - une plateforme apte à exécuter chaque application logicielle avionique, la 20 plateforme hébergeant un système d'exploitation ; et - un dispositif électronique de surveillance de chaque application logicielle avionique, le dispositif électronique de surveillance étant tel que défini ci-dessus. Ces caractéristiques et avantages de l'invention apparaîtront plus clairement à la 25 lecture de la description qui va suivre, donnée uniquement à titre d'exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels : - la figure 1 est une représentation schématique d'un système électronique avionique selon l'invention, comprenant une mémoire apte à stocker au moins une application logicielle avionique ; une plateforme apte à exécuter chaque application 30 logicielle avionique, la plateforme comportant des ressources et hébergeant un système d'exploitation ; et un dispositif électronique de surveillance d'une application logicielle avionique ; et - la figure 2 est un organigramme d'un procédé, selon l'invention, de surveillance d'une application logicielle avionique apte à être exécutée sur la plateforme, le procédé 35 étant mis en oeuvre par le dispositif de surveillance de la figure 1 ; 5 6 - la figure 3 est un logigramme du procédé de surveillance, selon un premier mode de réalisation de l'invention ; et - la figure 4 est une vue analogue à celle de la figure 3, selon un deuxième mode de réalisation de l'invention. Sur la figure 1, un système électronique avionique 10, destiné à être embarqué à bord d'un aéronef, comprend une mémoire 12 apte à stocker au moins une application logicielle avionique 14 ; une plateforme 16 apte à exécuter chaque application logicielle avionique 14, la plateforme 16 comportant des ressources 18 et hébergeant un système 10 d'exploitation 20, la plateforme 16 étant reliée d'autres systèmes électroniques avioniques 22 de l'aéronef. Le système électronique avionique 10 comprend en outre, selon l'invention, un dispositif électronique 24 de surveillance d'une application logicielle avionique 14. Sur la figure 1, par souci de simplification du dessin, la mémoire 12 a été 15 représentée à l'extérieur du rectangle symbolisant les ressources 18, ceci afin de faire apparaitre de manière distincte la couche logicielle correspondant aux applications logicielles 14, ainsi que le cas échéant au dispositif de surveillance 24. Néanmoins, l'homme du métier comprendra bien entendu que la mémoire 12 est incluse dans les ressources 18 de la plateforme 16. 20 L'aéronef est de préférence un avion. En variante, l'aéronef est un hélicoptère, ou encore un drone piloté à distance par un pilote. Dans l'exemple de la figure 1, la mémoire 12 est apte à stocker trois applications logicielles avioniques 14 distinctes, et le dispositif électronique de surveillance 24 est alors configuré pour surveiller au moins une application logicielle avionique 14, et de 25 préférence chacune de ces applications logicielles avioniques 14. Chaque application logicielle avionique 14 est destinée à être exécutée par la plateforme 16 et alors conçue pour émettre un ou plusieurs appels à destination du système d'exploitation 20 hébergé par la plateforme 16 et est également configurée pour utiliser des ressources 18 de la plateforme 16. Chaque application logicielle avionique 14 30 comporte un ou plusieurs traitements logiciels à exécuter. Chaque application logicielle avionique 14 est également appelée fonction avionique. Les applications logicielles avioniques 14 remplissent différentes fonctions pour l'accomplissement d'un vol, et sont par exemple installées sur différentes plateformes 16 et utilisent les ressources 18 desdites plateformes 16. 35 Chaque application logicielle avionique 14 exécute des traitements logiciels. Un traitement logiciel désigne un ensemble d'opérations sur des données de l'application 7 logicielle avionique 14 permettant de réaliser des parties d'une fonction avionique, telles qu'une acquisition ou une émission de données, des calculs mathématiques, des traitements logiques, une manipulation de données. Chaque traitement logiciel est également appelé processus, ou encore processus 5 logiciel. Un traitement logiciel est par exemple un processus au sens de la norme ARINC 653. De telles fonctions étant critiques, comme par exemple le système de freinage ou le système de gestion du vol, chaque application logicielle avionique 14 est de préférence surveillée régulièrement par le dispositif électronique de surveillance 24, pendant 10 sensiblement toute la durée d'exécution de l'application logicielle avionique 14 par la plateforme 16. La plateforme 16 est destinée à être embarquée à bord de l'aéronef. La plateforme 16 est, par exemple, une unité de traitement d'informations formée d'une ou plusieurs mémoires associées à un ou plusieurs processeurs. 15 Les ressources 18 de la plateforme 16 sont des éléments physiques ou logiques propres à être mis à disposition de la ou des applications logicielles avioniques 14. Les ressources 18 sont, par exemple, réparties en les catégories suivantes : ressources de type traitement de données (en anglais « processing »), telles qu'un ou plusieurs processeurs ; les ressources de type mémoire ; les ressources de type entrées 20 et sorties ; ressources spécifiques au réseau avionique, telles que des routeurs de communication d'un réseau ARINC664 ; les ressources de type graphique, c'est-à-dire permettant un affichage de données ; et ressources de type mémoire de masse (en anglais « mass memory »). Le système d'exploitation 20 est, par exemple, un système d'exploitation conforme 25 à la norme ARINC 653, ou un système d'exploitation POSIX, ou encore un hyperviseur, ou encore un middleware. L'homme du métier comprendra alors que le système d'exploitation 20 s'entend au sens large, et est, de manière plus générale, un ensemble d'au moins un logiciel de base, conçu pour offrir des services de différents types à chaque application 14. 30 Le dispositif électronique de surveillance 24 est configuré pour surveiller au moins une application logicielle avionique 14 apte à être exécutée sur la plateforme 16, et comprend un premier module de surveillance 26 configuré pour surveiller la durée d'exécution de l'application logicielle avionique 14. Le dispositif électronique de surveillance 24 comprend un module de mise à jour 35 27 configuré pour mettre à jour un statut de l'application logicielle avionique 14 en fonction de la surveillance de la durée d'exécution de l'application logicielle avionique 14. 8 En complément facultatif, selon un deuxième mode de réalisation de l'invention, le dispositif électronique de surveillance 24 comprend en outre un deuxième module de surveillance 28 configuré pour surveiller le comportement de l'application logicielle avionique 14, via la vérification, à l'expiration d'un délai de surveillance prédéfini Tf, de la 5 détection d'au moins un évènement applicatif de l'application logicielle avionique. La mise à jour du statut de l'application logicielle avionique par le module de mise à jour 27 dépend alors de la surveillance de la durée d'exécution et de la surveillance du comportement de l'application logicielle avionique. Dans l'exemple de la figure 1, le dispositif de surveillance 24 est, par exemple 10 distinct de la plateforme 16, et comprend une unité de traitement d'informations 30 formée par exemple d'un processeur 32 associé à une mémoire 34. En variante, pour laquelle le dispositif de surveillance 24 est représenté en trait hachuré sur la figure 1, le dispositif de surveillance 24 est apte à être exécuté directement par la plateforme 16 et à utiliser alors ses ressources 18. Cette variante est un mode de 15 réalisation préférentiel, et le dispositif de surveillance 24 est alors de préférence hébergé en outre dans le système d'exploitation 20 ou bien au sein d'une partition mémoire spécifique de la plateforme 16, cette partition spécifique étant elle-même protégée contre des cyber-attaques, via par exemple un ou plusieurs contrôles d'accès et/ou une protection en intégrité. 20 Dans l'exemple de la figure 1, que le dispositif de surveillance 24 soit distinct de la plateforme 16, ou bien hébergé et exécuté par la plateforme 16, le premier module de surveillance 26 et le module de mise à jour 27, ainsi qu'en complément facultatif le deuxième module de surveillance 28, sont réalisés chacun sous forme d'un logiciel, ou d'une brique logicielle, exécutable par un processeur, tel que le processeur 32 lorsque le 25 dispositif de surveillance 24 est distinct de la plateforme 16. La mémoire 34 du dispositif de surveillance 24 est alors apte à stocker un premier logiciel de surveillance adapté pour surveiller la durée d'exécution de l'application logicielle avionique 14 et un logiciel de mise à jour adapté pour mettre à jour le statut de l'application logicielle avionique 14 en fonction de la surveillance de la durée d'exécution de l'application logicielle avionique 14. En 30 complément facultatif, la mémoire 34 du dispositif de surveillance 24 est également apte à stocker un deuxième logiciel de surveillance adapté pour surveiller le comportement de l'application logicielle avionique 14, la mise à jour du statut dépendant alors de la surveillance de la durée d'exécution et de la surveillance du comportement de l'application logicielle avionique. Le processeur est alors apte à exécuter le premier 35 logiciel de surveillance et le logiciel de mise à jour, ainsi qu'en complément facultatif le deuxième logiciel de surveillance. 9 En variante non représentée, le premier module de surveillance 26 et le module de mise à jour 27, ainsi qu'en complément facultatif le deuxième module de surveillance 28, sont réalisés chacun sous forme d'un composant logique programmable, tel qu'un FPGA (de l'anglais Field Programmable Gate Array), ou encore sous forme d'un circuit intégré 5 dédié, tel qu'un ASIC (de l'anglais Application Specific Integrated Circuit). Lorsque le dispositif de surveillance 24 est réalisé sous forme d'un ou plusieurs logiciels, c'est-à-dire en forme d'un programme d'ordinateur, il est en outre apte à être enregistré sur un support, non représenté, lisible par ordinateur. Le support lisible par ordinateur est, par exemple, un médium adapté à mémoriser des instructions 10 électroniques et capable d'être couplé à un bus d'un système informatique. A titre d'exemple, le support lisible est une disquette ou disque souple, (de la dénomination anglaise Floppy disk), un disque optique, un CD-ROM, un disque magnéto-optique, une mémoire ROM, une mémoire RAM, tout type de mémoire non volatile (par exemple, EPROM, EEPROM, FLASH, NVRAM) une carte magnétique ou une carte optique. Sur le 15 support lisible est alors mémorisé un programme d'ordinateur comprenant des instructions logicielles. Le premier module de surveillance 26 est configuré pour surveiller la durée d'exécution de l'application logicielle avionique 14, via la vérification, à l'expiration d'au moins un délai d'exécution prédéfini T1, T2, de l'achèvement de l'exécution d'au moins un 20 traitement logiciel de l'application logicielle avionique 14. Le premier module de surveillance 26 est de préférence configuré pour surveiller la durée d'exécution de l'application logicielle avionique 14 au regard de deux délais d'exécution prédéfinis distincts, à savoir un premier délai d'exécution prédéfini T1 et un deuxième délai d'exécution prédéfini T2, supérieur au premier délai d'exécution T1. Le 25 premier module de surveillance 26 est configuré pour surveiller la durée d'exécution de l'application logicielle avionique 14, via la vérification, à l'expiration du premier délai d'exécution prédéfini T1, puis à l'expiration du deuxième délai d'exécution prédéfini T2, de l'achèvement de l'exécution d'au moins un traitement logiciel de l'application logicielle avionique 14. 30 La surveillance de la durée d'exécution de l'application logicielle avionique 14 est une surveillance de l'application logicielle avionique 14 dans son ensemble ou bien d'un ou plusieurs traitements logiciels de cette application logicielle avionique 14, tels que des processus selon la norme ARINC 653. Dans le cas d'une surveillance de la durée d'exécution de l'application logicielle avionique 14 dans son ensemble, le premier délai 35 d'exécution prédéfini T1 est par exemple déduit directement du WCET (de l'anglais Worst Case Execution Time) établi lors d'une qualification de l'application logicielle avionique 14. 10 Dans le cas d'une surveillance de la durée d'exécution d'un ou plusieurs traitements logiciels de l'application logicielle avionique 14, le premier délai d'exécution prédéfini T1 est établi en fonction de durées de pire cas d'exécution dudit ou desdits traitements logiciels, en tenant compte des cumuls éventuels de durées d'exécution. 5 La connaissance de ce premier délai d'exécution prédéfini T1 par le dispositif de surveillance 24 se fait, soit par configuration associée à l'application logicielle avionique 14, soit à l'initialisation de l'application logicielle avionique 14. Dans l'exemple d'une plateforme 16 conforme à la norme ARINC 653, la durée d'exécution de chaque processus de l'application logicielle avionique 14 est apte à être 10 surveillée, et un premier délai d'exécution T1 est alors prédéfini pour chaque processus. Le premier délai d'exécution T1 correspond alors à la durée à partir de laquelle le processus doit être achevé du point de vue du temps maximum d'exécution. La détection de l'achèvement de l'exécution de chaque traitement logiciel de l'application logicielle avionique 14 est effectuée par exemple directement via un 15 mécanisme de date limite (de l'anglais deadline) offert pour les processus par le système d'exploitation 20 lorsqu'il est conforme à la norme ARINC 653. En variante, la détection de l'achèvement de l'exécution de chaque traitement logiciel est effectuée via une trace de fin d'exécution fournie par l'application logicielle avionique 14, typiquement via un port dédié dont le système d'exploitation 20 surveille la génération à l'expiration du premier 20 délai d'exécution prédéfini T1. Des exemples de valeurs des premier et deuxième délais d'exécution T1 et T2 sont indiqués ci-après dans l'exemple d'un processeur où sont installées différentes applications logicielles avioniques 14 et pour lequel un cycle temps réel de 50 ms est défini. Lors d'une période de 50 ms, une allocation de 15 ms est faite pour une de ces 25 applications logicielles avioniques 14 ayant défini un temps d'exécution de pire cas de 8 ms. Dans ces conditions, le premier délai d'exécution T1 est par exemple choisi égal à 8 ms et le deuxième délai d'exécution T2 choisi égal à 15 ms (ou entre 8 ms et 15 ms en fonction de l'analyse de la sécurité de l'application logicielle avionique 14 correspondante). 30 Selon le deuxième mode de réalisation de l'invention, le deuxième module de surveillance 28 est configuré pour surveiller le comportement de l'application logicielle avionique 14, via la vérification, à l'expiration d'un délai de surveillance prédéfini Tf, de la détection d'au moins un évènement applicatif de l'application logicielle avionique. Selon ce deuxième mode de réalisation, le module de mise à jour 27 est alors 35 configuré pour mettre à jour le statut de l'application logicielle avionique 14 en fonction à 11 la fois de la surveillance de la durée d'exécution et de la surveillance du comportement de l'application logicielle avionique. Par évènement applicatif, on entend un évènement renseignant sur l'état de l'application logicielle avionique 14, l'évènement étant alors qualifié d'applicatif, un 5 évènement étant de manière général quelque chose d'observable à un instant donné sur la plateforme 16. A titre d'exemple, un évènement est par exemple le fait que les processus selon la norme ARINC 653 de l'application sont terminés avant le délai de surveillance prédéfini Tf, ou encore le fait que l'application logicielle avionique 14 a exécuté une tâche de surveillance particulière et donné une réponse adéquate. Un 10 évènement applicatif dans le cadre de la surveillance du comportement est considéré comme étant naturel, par exemple en cas de fourniture par l'application logicielle avionique 14 de données à des instants connus, ou bien contraint, par exemple en cas d'ajout d'activités permettant de construire une preuve de bonne santé de l'application logicielle avionique 14, typiquement en plaçant au cours de l'exécution de l'application 15 logicielle avionique 14 des calculs dont le résultat est connu afin de vérifier la bonne exécution de l'application logicielle avionique 14 à la fin de son temps imparti. La détermination du délai de surveillance prédéfini Tf dépend par exemple d'analyses de partitionnement et d'une caractérisation faite sur le processeur correspondant de la plateforme 16, le délai de surveillance Tf étant défini comme le délai 20 au-delà de ce qui correspond à une contention, et le dépassement de ce délai de surveillance Tf correspondant alors à une application logicielle avionique 14 hors contrôle. La durée du délai de surveillance prédéfini Tf est du même ordre de grandeur que celle des premier et deuxième délais d'exécution T1 et T2, typiquement comprise entre la durée du premier délai d'exécution T1 et celle du deuxième délai d'exécution T2. Dans le 25 cas où la durée du délai de surveillance prédéfini Tf est supérieure à celle du deuxième délai d'exécution T2, il n'y aura pas de distinction entre une contention aboutissant à un statut « hors sécurité » et une application « hors contrôle » à l'expiration du deuxième délai d'exécution T2. L'homme du métier observera que la détermination des délais T1, T2 et Tf dépend 30 du contexte d'utilisation, des applications logicielles avioniques et de la caractérisation faite sur le processeur correspondant de la plateforme 16, le processeur étant de préférence un processeur multi-coeurs. La manière de déterminer ces seuils n'influence pas le procédé de surveillance objet de l'invention, pour lequel ces seuils sont des paramètres d'entrée. 35 A titre d'exemple de détermination des délais T1, T2 et Tf, à chaque application logicielle avionique 14 installée, qui a fait l'objet d'une qualification séparée, est associée 12 une ou plusieurs valeurs WCET correspondant à des chaines fonctionnelles pour lesquelles des garanties doivent être fournies dans le cadre de la certification. La caractérisation du processeur multi-coeurs faite à partir d'analyses et de mesures dans des conditions théoriques de pire cas permet alors d'obtenir : 5 - un ratio garanti entre une durée d'exécution dans un contexte où un seul coeur est utilisé et une durée d'exécution dans un contexte où l'ensemble des coeurs du processeur est employé dans son domaine d'usage ; - une marge complémentaire, afin de garantir un fonctionnement plus sûr de l'application logicielle avionique 14 (à appliquer par exemple sur les durées de pire cas 10 pour assurer, au moins pour les applications les plus critiques, l'absorption de contentions qui auraient échappé à la démarche de caractérisation) ; et - une marge maximale au-delà de laquelle il sera considéré qu'une durée d'exécution ne résulte plus d'une contention, mais d'une erreur ou d'un plantage de l'application logicielle avionique 14. 15 Pour chaque chaine fonctionnelle surveillée par le dispositif et le procédé de surveillance objets de l'invention, les délais T1, T2 et Tf sont alors par exemple prédéfinis selon les formules suivantes, avec une origine temporelle correspondant au début d'exécution de l'application logicielle avionique 14 dans un créneau (de l'anglais stot) 20 L'homme du métier notera en outre que la caractérisation du processeur peut aboutir à plusieurs jeux de paramètres correspondant à des usages différents du 25 processeur (par exemple, usage « calcul », usage « entrées-sorties », ...), et les délais T1, T2 et Tf sont alors prédéfinis en fonction de ces usages variés. Le fonctionnement du dispositif de surveillance 24 selon l'invention va désormais être expliqué à l'aide de la figure 2 représentant un organigramme du procédé, selon 30 l'invention, de surveillance d'une application logicielle avionique 14 apte à être exécutée sur la plateforme 16, le procédé étant mis en oeuvre par le dispositif électronique de surveillance 24. Lors d'une étape 100, le dispositif de surveillance 24 surveille, via son premier module de surveillance 26, la durée d'exécution de l'application logicielle avionique 14 35 correspondante. Cette étape de surveillance 100 comporte la vérification, à l'expiration temporel alloué : T1 = WCET x ratio garanti (1) T2 = T1 x marge complémentaire (2) Tf = T1 x marge maximale (3) 13 d'au moins un délai d'exécution prédéfini T1, T2, de l'achèvement de l'exécution d'au moins un traitement logiciel de l'application logicielle avionique 14. Cette étape de surveillance 100 comporte une première vérification M1, à l'expiration du premier délai d'exécution prédéfini T1, de l'achèvement de l'exécution d'au 5 moins un traitement logiciel de l'application logicielle avionique 14, comme représenté sur la figure 3. Lorsque l'exécution d'au moins un traitement logiciel de l'application logicielle avionique 14 n'est pas achevée à l'expiration du premier délai d'exécution prédéfini T1, l'étape de surveillance 100 comporte de préférence en outre une deuxième vérification 10 M2, à l'expiration du deuxième délai d'exécution prédéfini T2, de l'achèvement de l'exécution d'au moins un traitement logiciel de l'application logicielle avionique 14. La première vérification M1 vise à diagnostiquer un dépassement du premier délai d'exécution prédéfini T1, pour un ou plusieurs traitements logiciels correspondants ou pour l'application logicielle avionique 14 dans son ensemble, ce dépassement 15 n'impliquant pas un problème de sécurité. L'objectif de la première vérification M1 est de surveiller le temps d'exécution d'une application logicielle avionique 14 par rapport à un temps normal, établi dans le respect de règles de la plateforme, c'est-à-dire par rapport à un domaine d'usage de l'application logicielle avionique 14. La première vérification M1 se fait à l'expiration du 20 premier délai d'exécution prédéfini T1, date à laquelle l'exécution de l'application logicielle avionique 14, ou du ou des traitements logiciels associés surveillés, est normalement achevée, de sorte qu'un dépassement de cette durée d'exécution est interprétable comme une contention, si l'application n'est pas hors contrôle. Le premier délai d'exécution prédéfini T1 prend en compte les effets sur le temps d'exécution identifiés au 25 titre des contentions multi-cceur, généralement présentés dans un guide utilisateur de la plateforme 16 et qualifiés avec la plateforme 16. Si pour un traitement logiciel ou pour l'application logicielle avionique 14 dans son ensemble, le premier délai d'exécution prédéfini T1 est dépassé, le dispositif de surveillance 24 considère alors que l'application logicielle avionique 14 a subi une 30 contention supérieure à la normale, mais qu'elle est apte à fonctionner sainement jusqu'au deuxième délai d'exécution prédéfini T2. En cas de dépassement du premier délai d'exécution prédéfini T1 pour un traitement logiciel ou pour l'application logicielle avionique 14 dans son ensemble, le dispositif de surveillance 24 comptabilise de préférence en outre l'événement via un 35 premier compteur nbM1 dédié, pour générer une action complémentaire prédéfinie si le nombre de ces dépassements dépasse un seuil prédéfini, exprimé par exemple en 14 nombre de contentions observées dans un intervalle de temps prédéfini. L'action complémentaire prédéfinie est typiquement le délestage de la plateforme 16 en arrêtant une application logicielle avionique 14 parmi les applications logicielles avioniques 14 les moins critiques. 5 La deuxième vérification M2 vise à diagnostiquer un dépassement du deuxième délai d'exécution prédéfini T2, pour un ou plusieurs traitements logiciels correspondants ou pour l'application logicielle avionique 14 dans son ensemble, ce dépassement indiquant un risque de sécurité. Comme indiqué précédemment, le deuxième délai d'exécution prédéfini T2 est strictement supérieur au premier délai d'exécution prédéfini 10 T1. L'objectif de la deuxième vérification M2 est de forcer une décision à une date où le dispositif de surveillance 24 ne peut plus attendre la fin d'exécution de l'application logicielle avionique 14 et/ou de ses traitements logiciels correspondants, soit parce que la durée allouée à l'application logicielle avionique 14 est échue, soit parce qu'au-delà de ce 15 deuxième délai d'exécution prédéfini T2, l'application logicielle avionique 14 entre dans un domaine où la sécurité n'est plus garantie. Le deuxième délai d'exécution prédéfini T2 est inférieur ou égal à la durée allouée à l'application logicielle avionique 14 pour son exécution globale. L'homme du métier observera en outre qu'à chaque première vérification M1 n'est 20 pas nécessairement associée une deuxième vérification M2 respective, une même deuxième vérification M2 étant par exemple associée à plusieurs premières vérifications M1. Il est en effet possible de surveiller plusieurs traitements logiciels d'une application logicielle avionique 14, donc d'avoir plusieurs premières vérifications M1 respectives, tout en effectuant une unique deuxième vérification M2 pour l'application logicielle avionique 25 14 dans son ensemble. En variante, lorsque l'application logicielle avionique 14 se décompose en plusieurs traitements logiciels, plusieurs groupes de première et deuxième vérifications Ml, M2 sont définissables. En cas de dépassement du deuxième délai d'exécution prédéfini T2 pour un traitement logiciel ou pour l'application logicielle avionique 14 dans son ensemble, le 30 dispositif de surveillance 24 redémarre l'application logicielle avionique 14. Dans ce cas, le dispositif de surveillance 24 comptabilise de préférence en outre l'événement via un deuxième compteur nbM2 dédié. Selon le deuxième mode de réalisation de l'invention, le dispositif de surveillance 24 surveille en outre, lors de l'étape 110, via son deuxième module de surveillance 28, le 35 comportement de l'application logicielle avionique 14. Cette deuxième étape de surveillance 110 comporte la vérification Ma, à l'expiration du délai de surveillance 15 prédéfini Tf, de la détection d'au moins un évènement applicatif de l'application logicielle avionique 14, comme représenté sur la figure 4. La vérification Ma vise à diagnostiquer un fonctionnement « hors contrôle » de l'application logicielle avionique 14, c'est-à-dire qui n'est pas sain. 5 Selon le deuxième mode de réalisation de l'invention, le but est d'éviter qu'une application logicielle avionique 14 « hors contrôle » déclenche des actions de surveillance précitées au titre de contentions et de manière erronée. En effet, un déclenchement intempestif du dispositif de surveillance 24 pourrait amener à la perte d'applications logicielles avioniques 14 du fait d'un mauvais comportement d'autres applications 10 logicielles avioniques 14, ce qui n'est pas acceptable. Le fonctionnement d'une application logicielle avionique 14 est considéré correct par deuxième module de surveillance 28, par exemple lorsqu'au moins un des évènements suivants est vérifié : les processus selon la norme ARINC 653 de l'application sont terminés avant 15 le délai de surveillance prédéfini Tf, - l'application logicielle avionique 14 a exécuté une tâche de surveillance particulière, significative de sa bonne santé, et donné une réponse adéquate. A titre d'exemple, l'application logicielle avionique 14 doit exécuter une série de calculs dans le temps pour lesquels le résultat est connu, mais n'existe pas dans les 20 variables gérées par l'application logicielle avionique 14. L'annonce du résultat global est fournie au deuxième module de surveillance 28 en temps utile, par exemple dans le cadre du WCET surveillé. Ces calculs peuvent en outre varier d'une période à une autre selon un plan connu de façon à éviter le blocage applicatif sur un résultat bon, sans que l'application logicielle avionique 14 l'ait recalculé à chaque période. 25 Le deuxième module de surveillance 28 considère alors l'application logicielle avionique 14 comme « hors contrôle » si : soit un ou plusieurs traitements logiciels n'ont pas été exécutés avant le délai de surveillance prédéfini Tf, soit l'application logicielle avionique 14 n'a pas fourni la bonne réponse lors de 30 cette deuxième étape de surveillance 110. Lorsque l'application logicielle avionique 14 est considérée « hors contrôle » à l'expiration du délai de surveillance prédéfini Tf, le dispositif de surveillance 24 arrête ladite application logicielle avionique 14 et la redémarre indépendamment des autres surveillances éventuelles. 35 Selon le deuxième mode de réalisation de l'invention, l'homme du métier comprendra que la vérification Ma est corrélée aux première et deuxième vérifications Ml, 16 M2, comme représenté sur la figure 4, puisque la vérification Ma ne peut pas être établie si l'application logicielle avionique 14 n'a pas terminé son activité à cause d'une contention, et inversement la première ou deuxième vérification Ml, M2 ne peut pas être établie si l'application logicielle avionique 14 est hors contrôle, et ne répond alors pas. 5 Le procédé de surveillance comporte, lors de l'étape suivante 120, la mise à jour du statut de l'application logicielle avionique 14. Selon le premier mode de réalisation, visible à la figure 3, la mise à jour 120 du statut de l'application logicielle avionique 14 dépend de la surveillance 100 de la durée d'exécution de l'application logicielle avionique 14. 10 Lors de l'étape de mise à jour du statut 120, le statut de l'application logicielle avionique 14 est, comme représenté par la flèche Al à la figure 3, positionné à « normal » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique 14 a été détecté avant l'expiration du premier délai d'exécution prédéfini T1, c'est-à-dire avant l'expiration de chaque délai d'exécution 15 prédéfini T1, T2, le deuxième délai d'exécution prédéfini T2 étant strictement supérieur au premier délai d'exécution prédéfini T1. Lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique 14 n'a pas été détecté avant l'expiration du premier délai d'exécution prédéfini T1 lors de la première vérification M1, 20 comme représenté par la flèche A2 à la figure 3, le premier module de surveillance 26 effectue la deuxième vérification M2. Lors de l'étape de mise à jour du statut 120, le statut de l'application logicielle avionique 14 est alors positionné à « contention » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique 14 a été 25 détecté après l'expiration du premier délai d'exécution prédéfini T1 et avant l'expiration du deuxième délai d'exécution prédéfini T2, comme représenté par la flèche A3 à la figure 3. Le statut de l'application logicielle avionique 14 est positionné à « hors sécurité » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique 14 n'a pas été détecté après l'expiration du ou de chaque 30 délai d'exécution prédéfini T1, T2, comme représenté par la flèche A4 à la figure 3. Selon le deuxième mode de réalisation, visible à la figure 4, la mise à jour 120 du statut de l'application logicielle avionique 14 dépend à la fois de la surveillance 100 de la durée d'exécution de l'application logicielle avionique 14 et de la surveillance 110 du comportement de l'application logicielle avionique 14. 35 Lors de cette étape de mise à jour du statut 120, le statut de l'application logicielle avionique 14 est, comme représenté par la flèche B1 à la figure 4, positionné à « normal » 17 lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique 14 a été détecté avant l'expiration du premier délai d'exécution prédéfini T1, c'est-à-dire avant l'expiration de chaque délai d'exécution prédéfini T1, T2, et lorsque le ou les évènements applicatifs corrects ont été détectés 5 avant l'expiration du délai de surveillance prédéfini Tf. Lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique 14 n'a pas été détecté avant l'expiration du premier délai d'exécution prédéfini T1 lors de la première vérification M1 et lorsque l'application logicielle avionique 14 n'est pas considérée comme « hors contrôle », 10 le premier module de surveillance 26 effectue la deuxième vérification M2, comme représenté par la flèche B2 à la figure 4. Lors de l'étape de mise à jour du statut 120, le statut de l'application logicielle avionique 14 est positionné à « hors-contrôle » lorsqu'aucun évènement applicatif n'a été détecté à l'expiration du délai de surveillance prédéfini Tf ou bien lorsque l'évènement 15 applicatif détecté est incorrect, comme représenté par la flèche B3 à la figure 4. Le statut de l'application logicielle avionique 14 est positionné à « contention » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique 14 a été détecté après l'expiration du premier délai d'exécution prédéfini T1 et avant l'expiration du deuxième délai d'exécution prédéfini T2, 20 et lorsque le ou les évènements applicatifs corrects ont été détectés avant l'expiration du délai de surveillance prédéfini Tf, comme représenté par la flèche B4 à la figure 4. Le statut de l'application logicielle avionique 14 est positionné à « hors sécurité » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique 14 n'a pas été détecté après l'expiration du ou de chaque 25 délai d'exécution prédéfini T1, T2 et lorsque le ou les évènements applicatifs corrects ont été détectés avant l'expiration du délai de surveillance prédéfini Tf, comme représenté par la flèche B5 à la figure 4. Lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique 14 n'a pas été détecté après 30 l'expiration du ou de chaque délai d'exécution prédéfini T1, T2, et lorsqu'aucun évènement applicatif n'a été détecté à l'expiration du délai de surveillance prédéfini Tf ou bien l'évènement applicatif détecté est incorrect, le statut de l'application logicielle avionique 14 est, lors de l'étape de mise à jour du statut 120, positionné à « hors sécurité » si chaque délai d'exécution prédéfini T1, T2 est inférieur ou égal au délai de 35 surveillance prédéfini Tf, en particulier si le deuxième délai d'exécution prédéfini T2 est 18 inférieur ou égal au délai de surveillance prédéfini Tf, comme représenté par la flèche B5 à la figure 4. Sinon, c'est-à-dire si chaque délai d'exécution prédéfini T1, T2 est supérieur au délai de surveillance prédéfini Tf, en particulier si le deuxième délai d'exécution prédéfini 5 T2 est supérieur au délai de surveillance prédéfini Tf, et que l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique 14 n'a pas été détecté après l'expiration du ou de chaque délai d'exécution prédéfini T1, T2, aucun évènement applicatif n'ayant en outre été détecté à l'expiration du délai de surveillance prédéfini Tf ou bien l'évènement applicatif détecté étant incorrect, le statut de 10 l'application logicielle avionique 14 est alors positionné à « hors-contrôle », comme représenté par la flèche B6 à la figure 4. Le procédé et le dispositif de surveillance 24 selon l'invention permettent alors de déterminer plus précisément le statut de l'application logicielle avionique 14, en fonction de la surveillance de la durée d'exécution de l'application logicielle avionique 14, voire 15 selon le deuxième mode de réalisation en fonction en outre de la surveillance du comportement de l'application logicielle avionique 14. On conçoit ainsi que le procédé et le dispositif de surveillance 24 selon l'invention permettent de surveiller plus efficacement l'application REVENDICATIONS1. Procédé de surveillance d'une application logicielle avionique (14) apte à être exécutée sur une plateforme (16) hébergeant un système d'exploitation (20), l'application logicielle avionique (14) comportant un ou plusieurs traitements logiciels à exécuter, la plateforme (16) étant destinée à être embarquée à bord d'un aéronef, le procédé étant mis en oeuvre par un dispositif électronique de surveillance (24) et comprenant les étapes suivantes : - la surveillance (100) de la durée d'exécution de l'application logicielle avionique (14), via la vérification, à l'expiration d'au moins un délai d'exécution prédéfini (T1, T2), de l'achèvement de l'exécution d'au moins un traitement logiciel de l'application logicielle avionique (14) ; et - la mise à jour (120) d'un statut de l'application logicielle avionique (14) en fonction de la surveillance (100) de la durée d'exécution de l'application logicielle avionique (14). 2. Procédé selon la revendication 1, dans lequel l'étape de surveillance de la durée d'exécution (100) comporte la vérification, à l'expiration d'un premier délai d'exécution prédéfini (T1), puis à l'expiration d'un deuxième délai d'exécution prédéfini (T2), de l'achèvement de l'exécution d'au moins un traitement logiciel de l'application logicielle avionique (14), le deuxième délai d'exécution prédéfini (T2) étant strictement supérieur au premier délai d'exécution prédéfini (T1). 3. Procédé selon la revendication 2, dans lequel, lors de l'étape de mise à jour du statut (120), le statut de l'application logicielle avionique (14) est positionné à « contention » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique (14) a été détecté après l'expiration du premier délai d'exécution prédéfini (T1) et avant l'expiration du deuxième délai d'exécution prédéfini (T2). 4. Procédé selon l'une quelconque des revendications précédentes, dans lequel, lors de l'étape de mise à jour du statut (120) : + le statut de l'application logicielle avionique (14) est positionné à « normal » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique (14) a été détecté avant l'expiration du ou de chaque délai d'exécution prédéfini (T1, T2) ; et 5 20 + le statut de l'application logicielle avionique (14) est positionné à « hors sécurité » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique (14) n'a pas été détecté après l'expiration du ou de chaque délai d'exécution prédéfini (T1, T2). 5. Procédé selon la revendication 1 ou 2, dans lequel le procédé comprend en outre l'étape suivante : - la surveillance (110) du comportement de l'application logicielle avionique (14), via la vérification, à l'expiration d'un délai de surveillance prédéfini (Tf), de la détection 10 d'au moins un évènement applicatif de l'application logicielle avionique (14) ; la mise à jour (120) du statut de l'application logicielle avionique (14) dépendant alors de la surveillance (100) de la durée d'exécution et de la surveillance (110) du comportement de l'application logicielle avionique (14). 15 6. Procédé selon les revendications 2 et 5, dans lequel, lors de l'étape de mise à jour du statut (120), le statut de l'application logicielle avionique (14) est positionné à « contention » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique (14) a été détecté après l'expiration du premier délai d'exécution prédéfini (T1) et avant l'expiration du deuxième délai 20 d'exécution prédéfini (T2), et lorsque le ou les évènements applicatifs corrects ont été détectés avant l'expiration du délai de surveillance prédéfini (Tf). 7. Procédé selon la revendication 5 ou 6, dans lequel, lors de l'étape de mise à jour du statut (120) : 25 + le statut de l'application logicielle avionique (14) est positionné à « normal » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique (14) a été détecté avant l'expiration du ou de chaque délai d'exécution prédéfini (T1, T2) et lorsque le ou les évènements applicatifs corrects ont été détectés avant l'expiration du délai de surveillance prédéfini (Tf) ; et 30 + le statut de l'application logicielle avionique (14) est positionné à « hors sécurité » lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique (14) n'a pas été détecté après l'expiration du ou de chaque délai d'exécution prédéfini (T1, T2) et lorsque le ou les évènements applicatifs corrects ont été détectés avant l'expiration du délai de surveillance 35 prédéfini (Tf). 21 8. Procédé selon l'une quelconque des revendications 5 à 7, dans lequel, lors de l'étape de mise à jour du statut (120), le statut de l'application logicielle avionique (14) est positionné à « hors-contrôle » lorsqu'aucun évènement applicatif n'a été détecté à l'expiration du délai de surveillance prédéfini (Tf) ou bien lorsque l'évènement applicatif 5 détecté est incorrect. 9. Procédé selon l'une quelconque des revendications 5 à 8, dans lequel lorsque l'achèvement de l'exécution du ou des traitements logiciels correspondants de l'application logicielle avionique (14) n'a pas été détecté après l'expiration du ou de 10 chaque délai d'exécution prédéfini (T1, T2), et lorsqu'aucun évènement applicatif n'a été détecté à l'expiration du délai de surveillance prédéfini (Tf) ou bien l'évènement applicatif détecté est incorrect, le statut de l'application logicielle avionique (14) est, lors de l'étape de mise à jour du statut (120), positionné à « hors sécurité » si chaque délai d'exécution prédéfini (T1, T2) est inférieur au délai de surveillance prédéfini (Tf) et à « hors-contrôle » 15 sinon. 10. Programme d'ordinateur comportant des instructions logicielles qui, lorsqu'elles sont exécutées par un ordinateur, mettent en oeuvre un procédé selon l'une quelconque des revendications précédentes. 20 11. Dispositif électronique (24) de surveillance d'une application logicielle avionique (14) apte à être exécutée sur une plateforme (16) hébergeant un système d'exploitation (20), l'application logicielle avionique (14) comportant un ou plusieurs traitements logiciels à exécuter, la plateforme (16) étant destinée à être embarquée à 25 bord d'un aéronef, le dispositif électronique de surveillance (24) comprenant : - un module de surveillance (26) configuré pour surveiller la durée d'exécution de l'application logicielle avionique (14), via la vérification, à l'expiration d'au moins un délai d'exécution prédéfini (T1, T2), de l'achèvement de l'exécution d'au moins un traitement 30 logiciel de l'application logicielle avionique (14) ; et - un module de mise à jour (27) configuré pour mettre à jour un statut de l'application logicielle avionique (14) en fonction de la surveillance de la durée d'exécution de l'application logicielle avionique (14). 35 12. Système électronique avionique (10) comprenant : 22 - une mémoire (12) apte à stocker au moins une application logicielle avionique - une plateforme (16) apte à exécuter chaque application logicielle avionique (14), la plateforme (16) hébergeant un système d'exploitation (20) ; et 5 - un dispositif électronique (24) de surveillance de chaque application logicielle avionique (14), le dispositif électronique de surveillance (24) étant selon la revendication 11. (14) ;