FR 3045879 A1 20170623 FR 1502650 A 20151221 1 PLATEFORME D'EXECUTION AVIONIQUE ET PLATEFORME DE DEVELOPPEMENT PERMETTANT LA CERTIFICATION INDEPENDANTE DE COMPOSANTS LOGICIELS L'invention a pour domaine celui des logiciels avioniques, c'est-à-dire les logiciels applicatifs propres à être exécutés sur une plateforme d'exécution cible du type avionique. La modification d'une partie d'un logiciel avionique nécessite de procéder à une nouvelle certification de l'ensemble de ce logiciel. Il faut en effet s'assurer que la partie modifiée ne vient pas interférer avec ou perturber le bon fonctionnement du reste du logiciel qui n'a pas été modifié. Or, la certification d'un logiciel avionique est une procédure longue et coûteuse. Il est parfois même nécessaire de réaliser des essais en vol pour vérifier le fonctionnement correct du logiciel. De ce fait, l'ajout d'une fonctionnalité dans un logiciel avionique existant ne peut se faire qu'à l'occasion de la mise à disposition d'une nouvelle version certifiée du logiciel. Par ailleurs, les logiciels avioniques sont des logiciels complexes, qui sont développés par plusieurs équipes travaillant en parallèle sur la base de spécifications. Il se peut alors qu'une fonctionnalité secondaire ne soit pas disponible au moment où il est nécessaire de procéder à la certification d'une version du logiciel afin de pouvoir équiper des aéronefs prêts à être livrés. Il faut alors attendre la prochaine version du logiciel qui sera certifiée pour proposer cette fonctionnalité secondaire. Enfin, la version d'un logiciel exécutée à bord d'un avion peut dépendre d'un choix du client. Celui-ci peut souhaiter, au cours de l'exploitation de l'avion, mettre à jour le logiciel embarqué en achetant de nouvelles fonctionnalités ou en faisant évoluer une fonctionnalité existante. Il s'agit donc de certifier toutes les versions sous lesquelles le logiciel est susceptible d'être vendu. Il y a donc, de manière générale, un besoin pour faciliter la certification d'un logiciel avionique. L'invention a donc pour objet de répondre à ce besoin. L'invention a pour objet un logiciel applicatif hébergé sur une plateforme d'exécution cible du type avionique, caractérisé en ce qu'il comporte les composants suivants : - au moins un bloc de traitement , fournissant une fonctionnalité spécifique au logiciel applicatif, le ou chaque bloc de traitement constituant un composant du logiciel applicatif pouvant être certifié de manière indépendante des autres composants du logiciel ; 3045879 2 - un noyau applicatif assurant une orchestration de l'appel de ou de chaque bloc de traitement et/ou des services du système d'exploitation de la plateforme d'exécution cible ; - un conteneur logiciel, qui, sur requête du noyau applicatif, exécute un code 5 binaire présent en mémoire de la plateforme d'exécution cible et associé au bloc de traitement, l'exécution du code binaire étant réalisée de manière cloisonnée spatialement et temporellement, le code source exécuté ne pouvant pas échanger de données avec un autre code binaire d'un autre bloc de traitement du logiciel applicatif ou un service du système d'exploitation sans passer par le noyau applicatif, 10 le logiciel applicatif une fois certifié pouvant être mis à jour en modifiant le code binaire correspondant à un bloc de traitement dès lors que ledit code source a été certifié. Suivant d'autres aspects avantageux de l'invention, le logiciel comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : 15 le noyau applicatif est développé sur la base de spécifications décrivant la version la plus complète du ou de chaque bloc de traitement qu'il est envisagé de développer. le code binaire associé à un bloc de traitement est exécuté en utilisant un ensemble d'exécution défini à partir de la version la plus complète envisagée pour ledit 20 bloc de traitement. l'ensemble de paramètres maximaux comporte :Un paramètre temporel général correspondant au WCET ; Une liste de variables globales relatives aux données d'entrée et aux données de sortie dudit bloc de traitement ; Une liste de variables locales dudit bloc de traitement ; Une taille en octet du code binaire dudit bloc de 25 traitement ; Une taille en octet des variables globales ; Une taille en octet des variables locales. une valeur par défaut est attribuée à une variable globale de l'ensemble de paramètres maximaux d'exécution que le code binaire associé au bloc de traitement considéré et présent dans la mémoire de la plateforme d'exécution cible au moment de 30 l'exécution du logiciel applicatif n'est pas capable de traiter. le noyau applicatif est un automate d'état, chaque état dudit automate correspond à une procédure logicielle qui lance et contrôle une exécution d'une suite ordonnée d'appels à des blocs de traitement du logiciel applicatif et/ou à des services du système d'exploitation de la plateforme d'exécution cible, et chaque transition d'un état dudit automate vers un autre état dudit automate dépendant de valeurs retournées à 3045879 3 l'issue de leur exécution, par les blocs de traitement du logiciel applicatif et les services du système d'exploitation appelés. le noyau applicatif calcule un statut de contexte de l'aéronef à partir de différentes données externes, la transition d'un état initial vers un état final dudit automate 5 dépendant en outre du statut de contexte courant de l'aéronef calculé. L'invention a également pour objet une plateforme d'exécution cible du type avionique, comportant une couche matérielle et une couche logicielle, la couche matérielle comprenant une mémoire et un processeur, la couche logicielle comprenant un système d'exploitation avionique et un logiciel applicatif, caractérisée en ce que ledit 10 logiciel applicatif est conforme au logiciel précédent. L'invention a également pour objet une plateforme de développement, comportant une couche matérielle et une couche logicielle, la couche matérielle comprenant une mémoire et un processeur, la couche logicielle comprenant un système d'exploitation et un logiciel de compilation, caractérisée en ce que la mémoire comporte un code source 15 d'un bloc de traitement d'un logiciel applicatif conforme au logiciel précédent, et le logiciel de compilation est propre à générer un code binaire à partir du code source, le code binaire étant propre à être chargé dans la mémoire d'une plateforme d'exécution cible du type avionique sur laquelle est exécuté ledit logiciel applicatif. De préférence, la mémoire de la plateforme de développement comporte un 20 ensemble de paramètres maximaux d'exécution pour un bloc de traitement dudit logiciel applicatif. L'invention sera mieux comprise à la lecture de la description qui va suivre d'un mode de réalisation particulier, donné uniquement à titre d'exemple illustratif et non limitatif, la description étant faite en se référant aux dessins annexés, sur lesquels : 25 - la figure 1 est une représentation schématique du système électronique mis en oeuvre selon l'invention ; - la figure 2 est une représentation schématique d'un fichier source d'un bloc de traitement du logiciel selon l'invention ; - la figure 3 est une représentation schématique d'un fichier intermédiaire d'un bloc 30 de traitement du logiciel selon l'invention ; et, - la figure 4 est une représentation schématique du procédé d'utilisation du système de la figure 1. 35 3045879 4 PRESENTATION GENERALE De manière générale, les fonctionnalités d'un logiciel applicatif sont réparties entre une pluralité de blocs de traitement indépendants les uns des autres et un noyau applicatif commun. 5 On peut alors ajouter aux différents blocs de traitement constituant un logiciel applicatif existant, hébergé sur une plateforme d'exécution cible, un ou plusieurs blocs de traitement supplémentaire(s), correspondant à une nouvelle fonctionnalité ou une fonctionnalité plus riche, dont on souhaite munir le logiciel applicatif. Le logiciel applicatif possède une structure spécifique garantissant que, les blocs 10 de traitement supplémentaires ayant été certifiés à part, à la suite de la modification du logiciel applicatif par l'ajout des blocs de traitement supplémentaires, il n'est pas nécessaire de certifier à nouveau les blocs de traitement non modifiés, c'est-à-dire les blocs qui étaient déjà présents dans le logiciel applicatifs. Il n'y a donc qu'à certifier indépendamment chaque bloc de traitement et le noyau 15 applicatif. Ceci peut permettre de réduire drastiquement les temps et les coûts de certification et, par conséquent, de faciliter l'introduction de nouvelles fonctionnalités tout au long de la vie et de l'utilisation d'un logiciel applicatif. En effet, lors de la certification du logiciel applicatif modifié, les crédits de 20 certification des blocs de traitement non modifiés pourront être réutilisés tels quels. Par exemple, l'invention pourrait être utilisée pour un logiciel applicatif d'aide au pilotage, qui a déjà acquis la démonstration de conformité aux exigences principales de performances spécifiées par le standard RTCA DO-325 pour le contrôle de la stabilité ou de la trajectoire d'un aéronef. Si l'on souhaite que ce logiciel acquière la conformité à des 25 exigences principales de performances supplémentaires spécifiées par le standard RTCA DO-309 pour l'indication et les alertes d'impact avec le terrain d'un aéronef, il suffit de lui ajouter un ou plusieurs blocs de traitement supplémentaires développés pour réaliser cette fonctionnalité. Ces blocs de traitement ayant été certifiés en tant que tel, il n'est pas besoin de certifier l'ensemble du logiciel applicatif mis à jour. 30 Plus précisément, en se référant à la figure 1, le logiciel applicatif 50 selon l'invention comporte un noyau applicatif 56, un conteneur logiciel 58 et une pluralité de blocs de traitement 51 à 53. 35 Bloc de traitement 3045879 5 Chaque bloc de traitement permet, lors de son exécution, de réaliser une fonctionnalité définie. Les blocs de traitement qu'il est possible d'intégrer au logiciel applicatif sont prédéfinis conformément à des spécifications. Ainsi, le logiciel applicatif comporte N blocs 5 de traitement. Sur la figure 1, N est égale à trois et les blocs de traitement sont référencés 51, 52 et 53. Un bloc de traitement est un composant du logiciel applicatif pouvant être certifié de manière indépendante des autres composants du logiciel, c'est-à-dire des autres blocs de traitement, du noyau applicatif ou du conteneur logiciel. 10 Sur la plateforme d'exécution cible, un bloc de traitement se présente sous la forme d'un code binaire stocké dans la mémoire de cette plateforme et propre à être exécuté par le processeur de cette plateforme. Pour l'obtention de ce code binaire, un code source du bloc de traitement est compilé, au moyen d'un logiciel de compilation exécuté sur une plateforme de 15 développement, distincte de la plateforme d'exécution cible. Le logiciel de compilation utilisé est spécifique, notamment de la plateforme d'exécution cible sur laquelle le code binaire obtenu sera appelé à être exécuté. Le code binaire d'un bloc de traitement est ensuite téléchargé, par des moyens adaptés, depuis la plateforme de développement vers la plateforme d'exécution cible. 20 Sur la plateforme d'exécution cible, le code binaire téléchargé est stocké dans un fichier de configuration présent dans la mémoire de cette plateforme. Le fichier de configuration comporte donc l'ensemble des codes binaires des blocs de traitement actifs. Les versions de chacun de ces blocs de traitement actifs, la version du conteneur logiciel, et la version du noyau applicatif, définissent la version du logiciel 25 applicatif hébergé sur la plateforme d'exécution cible. Lors de l'exécution du logiciel applicatif, le code binaire d'un bloc de traitement appelé est exécuté. Plus précisément, le code binaire est exécuté à l'intérieur du conteneur logiciel. Le conteneur logiciel assure un cloisonnement spatial et temporel de l'exécution 30 du code binaire considéré. Ce cloisonnement logiciel a lieu à l'intérieur de la partition allouée par le système d'exploitation au logiciel applicatif, partition qui assure un partitionnement spatial et temporel des différents logiciels exécutés sur la plateforme d'exécution cible. Afin d'assurer ce cloisonnement, un bloc de traitement exécuté ne peut pas 35 échanger de données avec un autre bloc de traitement du logiciel applicatif ou un service 3045879 6 du système d'exploitation, sans passer par les mécanismes de communication du noyau applicatif. La manière dont un code binaire est exécuté à l'intérieur du conteneur logiciel du logiciel applicatif sera décrite en détail ci-après. 5 Un bloc de traitement ne comporte aucun appel direct à un service du système d'exploitation de la plateforme d'exécution cible. C'est le noyau applicatif qui constitue la seule interface entre tout bloc de traitement et le système d'exploitation. Un bloc de traitement, lorsqu'il est exécuté, réalise un traitement sur des données 10 d'entrée, de manière à délivrer en sortie des données de sortie. Noyau applicatif Le noyau applicatif, 56 sur la figure 1, constitue le composant logiciel principal du logiciel applicatif selon l'invention. 15 De manière générale, le noyau applicatif assure l'orchestration des appels aux différents blocs de traitement et/ou aux services du système d'exploitation de la plateforme cible. Plus précisément, le noyau applicatif assure notamment l'initialisation et l'arrêt du logiciel applicatif, le système d'exploitation démarrant le logiciel applicatif. 20 Lors de l'initialisation du logiciel applicatif, le noyau applicatif accède à un fichier de configuration indiquant la liste des blocs de traitement actifs constituant la version du logiciel applicatif hébergé sur la plateforme d'exécution cible. De concert avec le conteneur logiciel, le noyau applicatif charge le code binaire correspondant à chaque bloc de traitement depuis le fichier de configuration vers la 25 mémoire volatile de la plateforme d'exécution cible, en vue de l'exécution de ces codes binaires par le processeur de cette plateforme. Lors de cette initialisation, le conteneur logiciel vérifie que la mémoire volatile utilisée pour mémoriser les codes binaires ne dépasse pas la taille mémoire prévue à cet effet et indiquée dans un fichier de paramétrage du logiciel applicatif. 30 Le noyau applicatif peut avantageusement être mis en oeuvre sous la forme d'un automate d'état. Chaque état de cet automate correspond à une procédure logicielle qui lance et contrôle l'exécution d'une suite ordonnée d'appels à des blocs de traitement et à des services du système d'exploitation. 3045879 7 La transition d'un état de l'automate vers un autre état de l'automate dépend des valeurs retournées par les blocs de traitement et les services du système d'exploitation de la suite d'appels en cours d'exécution. Avantageusement, le noyau applicatif calcule un statut de contexte de l'aéronef à 5 partir de différentes données externes à la partition dans laquelle le logiciel applicatif est exécuté. La transition d'un état de l'automate vers un autre état de l'automate dépend alors également du statut de contexte courant de l'aéronef ainsi calculé. Lors de l'exécution d'une suite ordonnée d'appels, le noyau applicatif détermine le prochain bloc de traitement à appeler. 10 De concert avec le conteneur logiciel, le noyau applicatif prépare les données d'entrée à transmettre à ce bloc de traitement et il lance l'exécution de ce bloc de traitement sur ces données d'entrée. A l'issue de l'exécution de ce bloc de traitement, le noyau applicatif récupère les données de sortie. 15 De manière similaire, le noyau applicatif appelle les services du système d'exploitation, notamment les services pour les échanges de données avec d'autres partitions de la plateforme d'exécution cible ou avec une interface d'entrée/sortie de la plateforme d'exécution cible, interface au moyen de laquelle la plateforme est connectée à d'autres systèmes de l'aéronef, en particulier des capteurs et des systèmes de 20 contrôle/commande. Comme indiqué ci-dessus, le noyau applicatif fournit l'ensemble des données d'entrée à un bloc de traitement lorsqu'il est appelé pour être exécuté et récupère les données de sortie résultant de l'exécution de ce bloc de traitement. Le noyau applicatif permet la mise à jour du logiciel par l'ajout, la modification ou le 25 retrait de ce bloc de traitement, sans nécessiter une recertification du noyau applicatif. Il faut pour cela anticiper l'ensemble des évolutions possibles de ce bloc de traitement. En revanche, il est à noter que si un bloc de traitement évolue d'une manière qui n'avait pas été prévue à l'avance, il faudra adapter le noyau fonctionnel et le certifier à nouveau. Cependant, les autres blocs de traitement inchangés n'auront pas à être 30 certifiés à nouveau. Le noyau applicatif est développé sur la base des spécifications décrivant le logiciel applicatif et l'ensemble des blocs de traitement qu'il est envisagé, à terme, de développer. De plus, pour chaque bloc de traitement, le noyau applicatif est développé pour pouvoir accueillir la version la plus complète qu'il est prévu de développer pour ce 35 bloc de traitement. 3045879 8 Cette version la plus complète envisagée d'un bloc de traitement permet de définir un ensemble des paramètres maximaux d'exécution : Un paramètre temporel général correspondant au WCET, pour « Worst-Case Execution Time » en anglais, prévu pour le code binaire de la version la plus 5 complète ; Une liste de variables globales relatives aux données d'entrée et de sortie de la version la plus complète ; Une taille maximale en octet du code binaire de cette version la plus complète ; Une taille en octet des variables globales de la version la plus complète; 10 Une taille maximale en octet des variables locales de la version la plus complète. Ainsi, si la version d'un bloc de traitement implantée dans le logiciel applicatif comporte certaines limitations par rapport à la version de ce bloc de traitement la plus complète envisagée, le noyau applicatif transmet quand même l'ensemble des données 15 d'entrée que ce bloc de traitement est susceptible de prendre en compte dans ses évolutions futures, c'est-à-dire l'ensemble des données d'entrée de la version la plus complète de ce bloc de traitement. De manière similaire, si la version d'un bloc de traitement n'est pas actuellement en mesure de déterminer l'ensemble des données de sortie que ce bloc de traitement est 20 susceptible de calculer dans ses évolutions futures, il retourne pourtant l'ensemble des données de sortie de la version la plus complète de ce bloc de traitement. Les données de d'entrée ou de sortie qui ne peuvent pas être utilisées ou calculées par la version du bloc de traitement mise en oeuvre par le logiciel applicatif prennent une valeur par défaut, prédéterminée. 25 Dans le pire cas, si le logiciel applicatif comporte une limitation fonctionnelle, c'est- à-dire si un bloc de traitement particulier n'est pas implanté dans la version du logiciel hébergé sur la plateforme d'exécution cible, ce bloc de traitement est remplacé par un bloc « bouchon » inactif. Pour un tel bloc « bouchon », toutes les données d'entrée et de sortie prennent des valeurs par défaut. 30 La requête d'initialisation d'un bloc de traitement comporte les paramètres maximaux assurant que les ressources matérielles nécessaires à l'exécution de ce bloc de traitement soient affectées en cohérence avec la version la plus complète de ce bloc de traitement, notamment le pire cas d'exécution estimé WCET pour le code binaire de la version la plus complète. De cette manière toutes les versions de ce bloc de traitement, 35 du bloc « bouchon » à la version la plus complète, en passant par les versions 3045879 9 intermédiaires, peuvent être exécutées sans perturber l'exécution des autres blocs de traitement. De la sorte, une fois le logiciel applicatif certifié, toute nouvelle version certifiée d'un bloc de traitement peut être téléchargée sur la plateforme d'exécution cible pour 5 mettre à jour ce logiciel applicatif, sans avoir besoin de certifier à nouveau l'ensemble du logiciel applicatif mis à jour. PRESENTATION DETAILLEE Dispositif 10 Comme représenté sur la figure 1, le système électronique 1 comprend une plateforme de développement 2 non embarquée. La plateforme 2 est, par exemple, un ordinateur. Le système électronique 1 comprend une plateforme d'exécution cible 4, embarquée à bord d'un aéronef, de préférence du type « Avionique Modulaire Intégrée ». 15 La plateforme 4 et la plateforme 2 sont reliées par une liaison 6 de transmission de données. La liaison 6 est de préférence une liaison filaire sécurisée, par exemple conforme à la norme ARINC 664 P7. En variante, la liaison 6 est une liaison non filaire, par exemple une liaison radioélectrique conforme à la norme IEEE 802.11. 20 La plateforme 2 comporte une couche matérielle 26 et une couche logicielle 27. La couche matérielle 26 comporte des moyens de calcul, tels qu'un processeur 20, et des moyens de mémorisation, tels qu'une mémoire 22. Elle comporte en outre une interface d'entrée/sortie, telle qu'une carte 24 de transmission de données sur la liaison 6. La plateforme 4 comporte une couche matérielle 46 et une couche logicielle 47. 25 La couche matérielle 46 comporte des moyens de calcul, tels qu'un processeur 40, et des moyens de mémorisation, tels qu'une mémoire 42. La mémoire 42 comprend un espace de stockage volatil 42A, par exemple du type mémoire vive, et un espace de stockage non volatil 42B, par exemple une mémoire flash. La couche matérielle 46 comporte en outre une interface d'entrée/sortie, telle 30 qu'une carte 44 de transmission de données sur la liaison 6. Les composants de la couche matérielle 46 n'évoluent pas au cours de l'utilisation de la plateforme 4 et des mises à jour du logiciel applicatif selon l'invention. La couche logicielle 47 comporte une couche logicielle bas niveau et une couche logicielle d'application. 3045879 10 La couche logicielle bas niveau comporte un système d'exploitation 48 permettant de virtualiser la couche matérielle 46. Elle forme une interface entre la couche logicielle d'application et la couche matérielle 46. Ce système d'exploitation 48 est un système d'exploitation avionique temps réel. 5 La couche logicielle d'application comporte une pluralité de logiciels, en particulier un logiciel de téléchargement 30 et un logiciel applicatif 50 selon l'invention. Avantageusement, le système d'exploitation 48 de la plateforme 4 assure un partitionnement spatial et temporel de la couche logicielle d'application. Une partition correspond au domaine sur lequel un logiciel peut être exécuté. Il s'agit à la fois d'un 10 domaine spatial, en termes de zones de la mémoire 42 adressables par un logiciel, et d'un domaine temporel, en termes d'intervalles de temps pendant lequel un logiciel est exécuté par le processeur 40. De préférence, le partitionnement spatial et temporel est conforme au standard ARINC 653. En particulier, le logiciel de téléchargement 30 est exécuté sur une première 15 partition dédiée 31, et le logiciel applicatif 50 est exécuté sur une seconde partition 32, distincte de la première. Le logiciel de téléchargement 30 comporte une pluralité d'instructions stockées dans la mémoire 42 et aptes à être exécutées par le processeur 40. Le logiciel de téléchargement 30, lorsqu'il est exécuté, est propre à télécharger, 20 depuis la plateforme de développement 2, des données, notamment un ou plusieurs fichiers intermédiaires associés à des blocs de traitement du logiciel applicatif 50. Le logiciel applicatif 50 comporte un noyau applicatif 56 et un conteneur logiciel 58, ainsi qu'une pluralité de bocs de traitement. Sur la figure 1, trois blocs de traitement 51, 52 et 53 sont représentés. Le noyau applicatif 56, le conteneur logiciel 58 et les blocs 25 de traitement 51, 52 et 53 sont associés à la même partition 32. En revenant sur la description de la plateforme d'exécution 2, la couche logicielle 27 comporte une couche logicielle bas niveau et une couche logicielle d'application. La couche logicielle bas niveau comporte un système d'exploitation 28 permettant de virtualiser la couche matérielle 26. Il forme une interface entre la couche logicielle 30 d'application et la couche matérielle 26. Ce système d'exploitation est un système d'exploitation grand public. La couche logicielle d'application comporte un logiciel 14 de compilation. Le logiciel 14 est propre, lorsqu'il est exécuté, à précompiler puis à compiler un code source de manière à générer un code binaire exécutable sur la plateforme 4. Le logiciel 14 35 permet ainsi d'obtenir le code binaire 85 du bloc de traitement 51 à partir du code source 3045879 11 61 ; le code binaire 86 du bloc de traitement 52 à partir du code source 62 ; et le code binaire 87 du bloc de traitement 53 à partir du code source 63. La couche logicielle d'application comporte un logiciel 10 de génération de code propre à générer un fichier intermédiaire à partir du code source d'un bloc de traitement. 5 Pour cela, le logiciel 10 fait notamment appel au logiciel 14 de compilation pour générer à partir du code source un code binaire, qu'il intègre ensuite dans le fichier intermédiaire. Le logiciel 10 permet ainsi de générer un fichier intermédiaire 81 pour le bloc applicatif 51 à partir du code source 61 ; à générer un fichier intermédiaire 82 pour le bloc applicatif 52 à partir du code source 62 ; et à générer un fichier intermédiaire 83 pour le bloc applicatif 53 10 à partir du code source 63. La couche logicielle d'application de la plateforme 2 comporte un logiciel 16 de téléchargement permettant, en coopération avec le logiciel 30 de téléchargement exécuté sur la plateforme 4 de transférer un fichier intermédiaire de la mémoire 22 de la plateforme 2 vers la mémoire 42 de la plateforme 4. 15 Ainsi, la mémoire 22 stocke, pour chaque bloc de traitement 51, 52, 53 un fichier intermédiaire 81, 82, 83 prêt à être téléchargé sur la plateforme 4 lors d'une mise à jour du logiciel applicatif 50. Plus précisément, comme représenté sur la figure 2, pour, par exemple, le premier 20 bloc de traitement 51, le code source 61 comprend une liste de variables globales 72, une liste de variables locales 73 et une suite d'instructions 74. Les variables globales 72 sont des variables visibles et accessibles au noyau applicatif 56. Elles comportent les variables d'entrée et de sortie du bloc de traitement 51. Les variables locales 73 ne sont en revanche visibles qu'à l'intérieur du code 25 source considéré. Ce sont des variables intermédiaires utilisées lors de l'exécution du code binaire correspondant. La suite d'instruction 74 décrit la fonctionnalité réalisée par le bloc de traitement 52 dans un langage de programmation. Comme représenté sur la figure 3, pour le cas, par exemple, du premier bloc de 30 traitement 51, le fichier intermédiaire 81 comporte un en-tête 71 et le code binaire 85 résultant de la compilation par le logiciel 14 du code source 61. Lors de la compilation, les instructions 74 sont transformées en instructions 94. La suite d'instruction 94 est suivie d'une instruction de fin 95, ajoutée lors de la pré- compilation, propre à retourner une valeur de retour, qui indique si l'exécution du code 3045879 12 binaire s'est effectuée correctement ou si cette exécution a été interrompue suite à la détection d'une erreur. L'en-tête 71 comporte un paramètre temporel général 76 relatif à l'exécution sur la plateforme 4 du bloc de traitement 51 associé. Le paramètre temporel général 76 indique 5 la durée maximale d'exécution du code binaire 85. Ce paramètre temporel est calculé selon des méthodes connues de l'homme du métier. L'en-tête 71 comporte en outre la taille en octets 78 des variables globales 72 et la taille en octets 79 des variables locales 73. Sur la plateforme 4, un fichier intermédiaire, 81, 82 et 83, est stocké dans un 10 fichier de configuration 45 du logiciel applicatif 50, mémorisé dans l'espace de stockage non volatil 42B. Lors de l'exécution du logiciel applicatif 50, le noyau applicatif 56 est propre à accéder, via le système d'exploitation 48, à la couche matérielle 46. Le noyau applicatif 56 est également propre à lire et à extraire, dans l'espace de 15 stockage non volatil 42B, l'adresse du fichier intermédiaire du bloc de traitement à exécuter, par exemple le fichier intermédiaire 81 du premier bloc de traitement 51. Le noyau applicatif 56 est propre à mettre en oeuvre les variables globales pour fournir une base de connaissance au bloc de traitement lorsque celui-ci sera exécuté par le conteneur logiciel 58, et pour accéder aux variables de sortie résultantes de l'exécution 20 de ce bloc de traitement. Le noyau applicatif 56 est propre à élaborer une requête d'initialisation d'un bloc de traitement. Le noyau applicatif 56 est propre en outre à élaborer une requête d'exécution d'un bloc de traitement. 25 Le noyau applicatif 56 est propre à transmettre chaque requête d'initialisation ou d'exécution au conteneur logiciel 58. Chaque requête d'initialisation comprend les données indicatives de l'espace mémoire maximal Emax alloué au bloc de traitement à exécuter, la durée maximale d'exécution Tmax allouée au conteneur logiciel 58 pour exécuter ce bloc de traitement, et 30 l'adresse du fichier intermédiaire correspondant à ce bloc de traitement. Les données indicatives de l'espace mémoire maximal Emax et la durée maximale d'exécution Tmax sont celles correspondant à la version la plus complète du bloc de traitement à exécuter. Les données indicatives de l'espace mémoire maximal Emax alloué à un bloc de 35 traitement comprennent, dans l'espace de stockage volatil 42A, la zone mémoire des 3045879 13 variables globales 72, la zone mémoire des variables locales 73, et la zone mémoire où doit être chargée une copie du code binaire 85 correspondant au bloc de traitement à exécuter. Le conteneur logiciel 58 est propre à interpréter une requête d'initialisation ou 5 d'exécution reçue du noyau applicatif 56. Le conteneur logiciel 58 est propre à accéder à la couche matérielle 46 via le système d'exploitation 48. Il est propre à lire le fichier intermédiaire du bloc de traitement à exécuter, par exemple le fichier intermédiaire 81 du bloc 51. Il est propre à comparer le paramètre temporel général 76 du code binaire 85 à 10 exécuter, figurant dans le fichier intermédiaire 81, avec la durée maximale d'exécution Tmax allouée au conteneur logiciel 58 pour exécuter le bloc de traitement, en l'occurrence le bloc 51. Il est également propre à comparer les informations indicatives de la taille en octets du code binaire 85, de la taille en octets 78 des variables globales 72 et de la taille 15 en octets 79 des variables locales 73 avec les données indicatives de l'espace mémoire maximal Emax alloué au bloc de traitement 51 appelé. Le conteneur logiciel 58 est également propre à transmettre au noyau applicatif 56 un identificateur faisant référence au bloc de traitement initialisé. Le conteneur logiciel 58 est également propre à lire le code binaire stocké dans 20 l'espace de stockage non volatil 42B et à le copier dans l'espace de stockage volatil 42A en vue de son exécution. Par exemple, il copie le code binaire 85 de l'espace de stockage non volatil 42B vers l'espace de stockage volatil 42A. Le conteneur logiciel 58 est également propre à lancer l'exécution de cette copie du code binaire stockée dans l'espace de stockage volatil 42A pour la mise en oeuvre de 25 la fonctionnalité associée. L'homme du métier ayant des compétences normales dans la programmation d'applications pour des plateformes d'exécution modulaires avioniques sait programmer les applications pour utiliser et effectuer les fonctions mentionnées ci-dessus. Par conséquent, les codes de programmation spécifiques de ces applications ne sont pas 30 décrits plus en détail. Fonctionnement En se référant à la figure 4, si l'utilisateur souhaite modifier la fonctionnalité décrite par un bloc de traitement, par exemple le premier bloc de traitement 51, il développe le 3045879 14 code source 61 en conséquence, et charge ce code source 61 modifié sur la plateforme de développement 2. Pour obtenir le fichier intermédiaire 81 (étape 100), au cours d'une étape 100A de pré-compilation du code source 61, le processeur 20 exécute le logiciel 14 de compilation. 5 Au cours de cette étape 100A, le code source 61 est analysé pour vérifier qu'il ne contient aucune référence à des pointeurs, qu'il ne contient aucun appel récursif de fonctions, qu'il ne contient aucune instruction de saut à une adresse donnée (instructions de type « jump » ou « goto »), qu'il ne fait référence à aucune fonction externe au code source 61, et que la taille de la pile des appels de fonctions ne dépasse jamais une valeur 10 fournie en paramètre au logiciel 14. Ces types de vérifications sont connus de l'homme du métier. L'ensemble de ces vérifications permettent de s'assurer que le code source constitue un bloc de traitement au sens de l'invention, c'est-à-dire une portion du logiciel applicatif 50 autonome en termes de certification. Au cours de cette même étape 100A, le logiciel 14 de compilation calcule la taille 15 en octets 78 des variables globales 72, et la taille en octets 79 des variables locales 73. Ces données de taille mémoire sont stockées dans la mémoire 22. Au cours de cette même étape 100A, le logiciel 14 de compilation ajoute une instruction de fin à la suite des instructions 74 du code source 62. Il ajoute également aux instructions 74 des instructions de test de non- 20 dépassement de taille des tableaux mis en oeuvre dans le programme, et des instructions de test de non division par zéro, de telles instructions étant classiquement connues. Ces instructions ajoutées par le logiciel 14, ainsi que les limitations de la suite d'instructions décrites plus haut, garantissent que les instructions n'accèderont pas à une zone mémoire située en dehors de la zone mémoire allouée aux variables globales et 25 locales du bloc de traitement 51. Lors de l'étape 100B de compilation du code source précompilé, le processeur 20 exécute le logiciel 14 de compilation. Celui-ci génère le code binaire 85 à partir du code source précompilé obtenu en sortie de l'étape 100A. Plus particulièrement, le logiciel 14 30 traduit la suite d'instructions du code source précompilé en une suite d'instructions exécutables 94, 95. A l'issue de l'étape 1006, la mémoire 22 stocke le code binaire 85 ainsi obtenu. 3045879 15 Lors d'une étape 100C de génération du fichier intermédiaire 81, le logiciel 10 est exécuté par le processeur 20 de manière à regrouper, dans un unique fichier, l'en-tête 71, et le code binaire 85. A l'issue de l'étape 100C, le code intermédiaire 81 est stocké dans la mémoire 22. 5 Puis, au cours d'une étape 100D, le code source 61 fait alors l'objet d'une nouvelle certification, par exemple selon un standard industriel du domaine aéronautique de type DO-178. 10 Puis une étape 102 de transmission est mise en oeuvre, au cours de laquelle, le fichier intermédiaire 81 est transmis depuis la plateforme de développement 2 vers la plateforme d'exécution cible 4, via la liaison 6. Pour ce faire, le logiciel 16 est mis en oeuvre sur la plateforme 2 et le logiciel 30 est mis en oeuvre sur la plateforme 4 pour télécharger le fichier intermédiaire du bloc de traitement que l'on souhaite mettre à jour, 15 par exemple le fichier 81 du bloc 51. Le logiciel de téléchargement 30 reçoit le fichier intermédiaire 81 et le stocke dans l'espace de stockage non volatil 42B de la mémoire 42 de la plateforme 4. Puis, lorsque le logiciel applicatif 50 est exécuté sur la plateforme 4, une étape 104 20 d'initialisation est réalisée, au cours de laquelle le noyau applicatif 56 demande au conteneur logiciel 58 l'initialisation de chacun des blocs de traitement contenus dans le fichier de configuration 45. Pour le bloc de traitement 51, le noyau applicatif 56 extrait l'adresse du fichier intermédiaire 81 stocké dans l'espace de stockage non volatil 42B. Au cours de cette même étape 104, le noyau applicatif 56 élabore une requête 25 d'initialisation du bloc de traitement 51. Cette requête comprend l'adresse mémoire du fichier intermédiaire 81, les données indicatives de l'espace mémoire maximal Emax alloué au bloc de traitement 51, et la période maximale d'exécution Tmax allouée au conteneur logiciel 58 pour l'exécution du bloc de traitement 51. A l'issue de l'étape 104, le noyau applicatif 56 transmet la requête au conteneur 30 logiciel 58. Au cours d'une étape 106 de traitement d'une requête d'initialisation, le conteneur logiciel 58 requiert un accès à la mémoire 42 auprès du processeur 40. Le conteneur logiciel 58 accède au fichier intermédiaire 81, et extrait les données d'en-tête 71, en 35 particulier le paramètre temporel général 76 et les informations indicatives de la taille en 3045879 16 octets du code binaire 85, les informations indicatives de la taille en octets 78 des variables globales 72, et les informations indicatives de la taille en octets 79 des variables locales 73. Au cours de cette même étape 106, le conteneur logiciel 58 interprète la requête 5 d'initialisation selon un protocole prédéterminé. Ce protocole comprend une première comparaison, entre le paramètre temporel général 76 et la durée maximale d'exécution Tmax allouée au conteneur logiciel 58 pour l'exécution du bloc de traitement 51. Si la valeur du paramètre temporel général 76 est inférieure ou égale à la valeur de la durée maximale d'exécution Tmax, alors la première 10 comparaison est « positive ». Ce protocole comprend en outre une deuxième comparaison, entre les informations indicatives de la taille en octets du code binaire, des variables globales et des variables locales, et les données indicatives de l'espace mémoire maximal Emax alloué au bloc de traitement 51. Si la taille en octets du code binaire, des variables 15 globales et des variables locales est inférieure ou égale à l'espace mémoire maximal Emax alors la deuxième comparaison est « positive ». Si la première ou la deuxième comparaison est « négative », le conteneur logiciel 58 retourne un code d'erreur au noyau applicatif 56. Le procédé se termine alors à l'étape 106. 20 Si, en revanche, les première et deuxième comparaisons sont « positives », le conteneur logiciel 58 copie le code binaire 85 dans une zone indiquée de l'espace de stockage volatil 42A. Cette copie du code binaire 85 respecte le procédé de copie de code binaire imposé par le système d'exploitation 48. Puis, toujours au cours de cette même étape 106, le conteneur logiciel 58 requiert 25 un accès à la mémoire 42 auprès du processeur 40 et stocke, dans l'espace de stockage volatil 42A, l'adresse mémoire de la copie du code binaire 85, l'adresse mémoire du début des variables globales 72 et l'adresse mémoire du début des variables locales 73. Le conteneur logiciel 58 retourne alors au noyau applicatif 56 un identificateur faisant référence au bloc de traitement 51 ainsi chargé en mémoire volatile. 30 Par exemple, l'identificateur retourné correspond à l'adresse mémoire de l'espace de stockage volatil 42A où le conteneur logiciel 58 a stocké le code binaire 85. L'étape 108 de génération d'une requête d'exécution est ensuite mise en oeuvre, au cours de laquelle le noyau applicatif 56 stocke les données d'entrée du bloc de 35 traitement 51 dans la mémoire allouée aux variables globales. 3045879 17 Au cours de cette même étape 108, le noyau applicatif 56 élabore une requête d'exécution du bloc de traitement 51. Cette requête intègre l'identificateur retourné par le conteneur logiciel 58 à l'étape 106. A l'issue de l'étape 108, le noyau applicatif 56 transmet la requête d'exécution au 5 conteneur logiciel 58. Au cours d'une étape suivante 110 de traitement d'une requête d'exécution, le conteneur logiciel 58 interprète la requête d'exécution reçue, puis lance l'exécution de la copie du code binaire 85 stockée dans l'espace de stockage volatil 42A. La fonctionnalité 10 correspondant au bloc de traitement 51 est alors mise en oeuvre au sein de la plateforme 4. A l'issue de cette étape 110, le conteneur logiciel 58 retourne au noyau applicatif 56 une valeur de retour. Si l'exécution du code binaire 85 s'est déroulée correctement, la valeur de retour 15 est la valeur de retour contenue dans l'instruction de fin 95. Sinon, la valeur de retour indique que l'exécution du code binaire 85 ne s'est pas déroulée correctement et indique la nature de l'erreur détectée. Au cours d'une étape suivante 112 de traitement d'un retour d'exécution, le noyau 20 applicatif 56 interprète la valeur de retour reçue, puis accède aux données de sortie du code applicatif 51 qui ont été stockée dans la mémoire allouée aux variables globales lors de l'exécution du code binaire 85. 25 REVENDICATIONS1.- Programme d'ordinateur définissant un logiciel applicatif (50) hébergé sur une plateforme d'exécution cible (4) du type avionique, caractérisé en ce qu'il comporte des instructions de code de programme d'ordinateur qui définissent : - au moins un bloc de traitement (51), fournissant, lorsque ledit programme est exécuté sur la plateforme d'exécution cible, une fonctionnalité spécifique au logiciel applicatif, le ou chaque bloc de traitement constituant un composant du logiciel applicatif pouvant être certifié de manière indépendante des autres composants du logiciel ; - un noyau applicatif (56) assurant, lorsque ledit programme est exécuté sur la plateforme d'exécution cible, une orchestration de l'appel de ou de chaque bloc de traitement (51) et/ou des services du système d'exploitation (48) de la plateforme d'exécution cible (4) ; - un conteneur logiciel (58), qui, lorsque ledit programme est exécuté sur la plateforme d'exécution cible et sur requête du noyau applicatif, exécute un code binaire (85) présent en mémoire (42) de la plateforme d'exécution cible (4) et associé au bloc de traitement (51), l'exécution du code binaire étant réalisée de manière cloisonnée spatialement et temporellement, le code source exécuté ne pouvant pas échanger de données avec un autre code binaire d'un autre bloc de traitement du logiciel applicatif ou un service du système d'exploitation sans passer par le noyau applicatif, le logiciel applicatif une fois certifié pouvant être mis à jour en modifiant le code binaire correspondant à un bloc de traitement dès lors que ledit code source a été certifié. 2.- Programme d'ordinateur selon la revendication 1, dans lequel le noyau applicatif (56) est développé sur la base de spécifications décrivant la version la plus complète du ou de chaque bloc de traitement (51) qu'il est envisagé de développer. 3.- Programme d'ordinateur selon la revendication 2, dans lequel le code binaire (85) associé à un bloc de traitement (51) est exécuté en utilisant un ensemble d'exécution défini à partir de la version la plus complète envisagée pour ledit bloc de traitement. 4.- Programme d'ordinateur selon la revendication 3, dans lequel l'ensemble de paramètres maximaux comporte : - Un paramètre temporel général correspondant au WCET ; 3045879 19 Une liste de variables globales relatives aux données d'entrée et aux données de sortie dudit bloc de traitement ; - Une liste de variables locales dudit bloc de traitement ; - Une taille en octet du code binaire dudit bloc de traitement ; 5 Une taille en octet des variables globales ; - Une taille en octet des variables locales. 5.- Programme d'ordinateur selon la revendication 3 ou la revendication 4, dans lequel une valeur par défaut est attribuée à une variable globale de l'ensemble de 10 paramètres maximaux d'exécution que le code binaire associé au bloc de traitement considéré et présent dans la mémoire de la plateforme d'exécution cible (4) au moment de l'exécution du logiciel applicatif n'est pas capable de traiter. 6.- Programme d'ordinateur selon l'une quelconque des revendications 15 précédentes, dans lequel le noyau applicatif (56) est un automate d'état, chaque état dudit automate correspond à une procédure logicielle qui lance et contrôle une exécution d'une suite ordonnée d'appels à des blocs de traitement (51) du logiciel applicatif et/ou à des services du système d'exploitation de la plateforme d'exécution cible (4), et chaque transition d'un état dudit automate vers un autre état dudit automate dépendant de valeurs 20 retournées à l'issue de leur exécution, par les blocs de traitement du logiciel applicatif et les services du système d'exploitation (48) appelés. 7.- Programme d'ordinateur selon la revendication 6, dans lequel, le noyau applicatif (56) calcule un statut de contexte de l'aéronef à partir de différentes données 25 externes, la transition d'un état initial vers un état final dudit automate dépendant en outre du statut de contexte courant de l'aéronef calculé. 8.- Plateforme d'exécution cible (4) du type avionique, comportant une couche matérielle (46) et une couche logicielle (47), la couche matérielle comprenant une 30 mémoire (42) et un processeur (40), la couche logicielle comprenant un programme d'ordinateur définissant un système d'exploitation (48) avionique et un programme d'ordinateur définissant un logiciel applicatif, la couche matérielle étant configurée par la couche logicielle, caractérisée en ce que ledit programme d'ordinateur définissant un logiciel applicatif (50) est conforme à l'une quelconque des revendications 1 à 7. 35 3045879 20 9.- Plateforme de développement (2), comportant une couche matérielle (26) et une couche logicielle (27), la couche matérielle comprenant une mémoire (22) et un processeur (20), la couche logicielle comprenant un programme d'ordinateur définissant un système d'exploitation (28) et un programme d'ordinateur définissant un logiciel de 5 compilation (14), la couche matérielle étant configurée par la couche logicielle, caractérisée en ce que la mémoire comporte un code source (61) d'un bloc de traitement (51) d'un programme d'ordinateur définissant un logiciel applicatif (50) conforme à l'une quelconque des revendications 1 à 7, et en ce que le programme d'ordinateur définissant un logiciel de compilation est propre, lorsqu'il est exécuté, à générer un code binaire (85) 10 à partir du code source, le code binaire étant propre à être chargé dans la mémoire d'une plateforme d'exécution cible (4) du type avionique sur laquelle est exécuté ledit programme d'ordinateur définissant un logiciel applicatif. 10. Plateforme de développement (2) selon la revendication 9, dont la mémoire 15 (22) comporte un ensemble de paramètres maximaux d'exécution pour un bloc de traitement (51) dudit programme d'ordinateur définissant un logiciel applicatif (50).