FR2998073A1 - Systeme electronique, plateforme d'execution modulaire embarquee et procede assurant le cloisonnement de regles decisionnelles parametrables - Google Patents

Abstract

Ce système électronique (10) comprend : - au moins une plateforme d'exécution modulaire (14) comportant une couche matérielle (26) et une couche logicielle (28), la couche matérielle (26) comprenant une mémoire (34), la couche logicielle (28) comprenant au moins un code applicatif (36A, 36B), - un dispositif électronique (12) comportant une mémoire (22) apte à stocker des données opérationnelles (53) relatives à la ou chaque plateforme d'exécution modulaire (14). Le dispositif électronique (12) comporte des moyens (18) de génération d'un code intermédiaire (80) à partir desdites données opérationnelles (53) et d'un code source (46) de description d'au moins une règle décisionnelle dans un langage de programmation, le code intermédiaire (80) comprenant une partie (48) interprétable et exécutable. La couche logicielle (28) de la ou chaque plateforme d'exécution modulaire (14) comporte au moins un code de décision (38) couplé audit code applicatif (36A, 36B), ledit code de décision (38) comportant un composant logiciel (92) propre, lorsqu'il est appelé par ledit code applicatif (36A, 36B), à exécuter ladite partie (48) du code intermédiaire (80) reçu du dispositif électronique (12) et stocké dans la mémoire (34) de la couche matérielle (26), pour la mise en œuvre de ladite règle décisionnelle.

Description

Système électronique, plateforme d'exécution modulaire embarquée et procédé assurant le cloisonnement de règles décisionnelles paramétrables La présente invention concerne un système électronique, du type comprenant : - au moins une plateforme d'exécution modulaire comportant une couche matérielle et une couche logicielle, la couche matérielle comprenant une mémoire, la couche logicielle comprenant au moins un code applicatif, - un dispositif électronique propre à être relié à la ou chaque plateforme d'exécution modulaire par une liaison de transmission de données, le dispositif électronique comportant une mémoire apte à stocker des données opérationnelles relatives à la ou chaque plateforme d'exécution modulaire. La présente invention concerne également une plateforme d'exécution modulaire embarquée, telle qu'une plateforme d'exécution modulaire du type « Avionique Modulaire Intégrée », du type comportant une couche matérielle et une couche logicielle, la couche matérielle comprenant une mémoire, la couche logicielle comprenant au moins un code applicatif. L'invention concerne également un procédé de mise en oeuvre d'au moins une règle décisionnelle au sein d'une plateforme d'exécution modulaire. Le domaine de l'invention est celui des systèmes électroniques comprenant des plateformes d'exécution modulaires embarquées, en particulier du type « Avionique Modulaire Intégrée » (IMA pour « Integrated Modular Avionics » en anglais). Avec l'augmentation de la puissance de calcul des processeurs et des capacités mémoire, il est demandé aux plateformes d'exécution embarquées d'intégrer de plus en plus de fonctionnalités, qui étaient autrefois réparties entre plusieurs calculateurs disjoints. Par ailleurs, une plateforme d'exécution embarquée doit répondre à des contraintes temporelles potentiellement fortes, par exemple du type temps réel, imposées par le système dans lequel elle est mise en oeuvre. On connait un système électronique du type précité, comprenant un dispositif électronique et plusieurs plateformes d'exécution modulaire, chaque plateforme étant embarquée à bord d'un aéronef. Chaque plateforme d'exécution modulaire est certifiée avant son installation dans l'aéronef associé. Dans un tel système électronique, la couche logicielle de chaque plateforme d'exécution modulaire comprend plusieurs codes applicatifs. Chaque code applicatif est 35 propre par exemple à accéder à une ou plusieurs ressource(s) matérielle(s) particulière(s), telle(s) que par exemple un contrôleur d'entrée-sortie connecté à une carte d'entrée-sortie périphérique. Les codes applicatifs installés au sein d'une plateforme d'exécution modulaire permettent ainsi à cette plateforme de s'interfacer avec un grand nombre d'équipements périphériques externes de type différent : calculateurs, électroniques de proximité, capteurs, actionneurs, moyens de communication...

Le dispositif électronique comporte des moyens de transmission de code informatique à destination de chaque plateforme d'exécution modulaire. Le dispositif électronique est par exemple un ordinateur non embarqué. Chaque plateforme d'exécution modulaire comprend alors des moyens de téléchargement de code, propres à être reliés aux moyens de transmission de l'ordinateur non embarqué. Un utilisateur peut ainsi télécharger sur chaque plateforme de nouveaux codes applicatifs, et/ou de nouvelles versions des codes applicatifs déjà installés, via l'ordinateur non embarqué. Chaque code applicatif d'une plateforme d'exécution modulaire comporte une partie de code dans laquelle sont programmées une ou plusieurs règles décisionnelles. De telles règles décisionnelles, lorsque leur exécution est demandée par le code applicatif associé, permettent à la plateforme d'exécution modulaire de décider d'une opération à effectuer en fonction d'un ensemble d'informations reçues. Toutefois, lorsque que l'utilisateur souhaite modifier une ou plusieurs règles décisionnelles au sein d'une plateforme d'exécution modulaire, il doit modifier le contenu du ou des code(s) applicatif(s) concernés, puis procéder dans la plateforme au téléchargement d'une nouvelle version mise à jour du ou de ces code(s) applicatif(s). Ceci impose une nouvelle certification aéronautique de l'ensemble de la plateforme, ce qui engendre des surcoûts. Le but de l'invention est donc de proposer un système électronique permettant l'exécution, au sein de la ou chaque plateforme d'exécution modulaire, de règles décisionnelles paramétrables par l'utilisateur, tout en ne nécessitant pas de nouvelle certification aéronautique de l'ensemble de la plateforme en cas de modification de ces règles décisionnelles. A cet effet, l'invention a pour objet un système électronique du type précité, caractérisé en ce que le dispositif électronique comporte des moyens de génération d'un code intermédiaire à partir desdites données opérationnelles et d'un code source de description d'au moins une règle décisionnelle dans un langage de programmation, le code intermédiaire comprenant une partie interprétable et exécutable, et en ce que la couche logicielle de la ou chaque plateforme d'exécution modulaire comporte au moins un code de décision couplé audit code applicatif, ledit code de décision comportant un composant logiciel propre, lorsqu'il est appelé par ledit code applicatif, à exécuter ladite partie du code intermédiaire reçu du dispositif électronique et stocké dans la mémoire de la couche matérielle, pour la mise en oeuvre de ladite règle décisionnelle. Suivant d'autres aspects avantageux de l'invention, le système électronique comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : - les moyens de génération sont propres à compiler le code source afin d'obtenir un macro-code de description de ladite au moins une règle décisionnelle, ledit macrocode comprenant des instructions issues d'une suite d'instructions génériques et formant la partie interprétable et exécutable du code intermédiaire ; - les données opérationnelles comprennent, pour la ou chaque plateforme d'exécution modulaire associée, une pluralité de premiers paramètres temporels, chaque premier paramètre temporel indiquant la durée maximale de lecture, d'interprétation, et d'exécution d'une instruction de la suite d'instructions génériques sur ladite plateforme ; - les moyens de génération comprennent des moyens de calcul, pour la ou chaque plateforme d'exécution modulaire, d'un deuxième paramètre temporel relatif à ladite plateforme, à partir des premiers paramètres temporels associés à ladite plateforme, chaque deuxième paramètre temporel indiquant la durée maximale d'exécution du macrocode sur ladite plateforme ; - la couche logicielle de la ou de chaque plateforme d'exécution modulaire comporte une couche logicielle bas niveau propre à fonctionner en tant que système d'exploitation principal de ladite plateforme, en ce que le code intermédiaire est associé à la ou à chaque plateforme d'exécution modulaire, et en ce que le code intermédiaire comporte en outre une liste de données comprenant des données d'information indicatives de la référence et de la version de la couche matérielle, de la couche logicielle bas niveau et du code de décision de la ou chaque plateforme, ainsi que le ou chaque deuxième paramètre temporel relatif à la ou à une des plateforme (s) ; - le code intermédiaire comporte en outre un en-tête comprenant des informations relatives aux moyens de génération, des informations relatives au code source, et une donnée dont la valeur indique le nombre de types de plateformes d'exécution modulaire de la liste, et en ce que le code intermédiaire comporte également des informations, indicatives de la taille en octets du macro-code, de la taille en octets des variables globales, et de la taille en octets des variables locales ; - la couche matérielle de la ou chaque plateforme d'exécution modulaire est partitionnée spatialement et temporellement, de préférence selon un partitionnement spatial et temporel conforme au standard ARINC 653, le ou chaque code applicatif étant apte à être exécuté sur une partition qui lui est dédiée ; - le ou chaque code applicatif est configuré de sorte à avoir accès à des données indicatives de l'espace mémoire et de la période maximale d'exécution alloués audit code applicatif par le partitionnement, ledit code applicatif étant propre à déterminer, à partir de sa période maximale d'exécution allouée, la durée maximale d'exécution allouée au code de décision associé ; - le ou chaque code applicatif comporte un composant logiciel propre, lorsque ledit code applicatif appelle l'exécution de ladite règle décisionnelle, à requérir cette exécution auprès du composant logiciel du code de décision associé, en émettant une requête adaptée ; - la ou chaque plateforme d'exécution modulaire est une plateforme d'exécution modulaire embarquée, en particulier une plateforme d'exécution modulaire embarquée du type « Avionique Modulaire Intégrée ». L'invention a également pour objet une plateforme d'exécution modulaire embarquée du type précité, caractérisé en ce que la couche logicielle comporte au moins un code de décision couplé audit code applicatif, ledit code de décision comportant un composant logiciel propre, lorsqu'il est appelé par ledit code applicatif, à exécuter une partie exécutable et interprétable d'un code intermédiaire stocké dans la mémoire de la couche matérielle, pour la mise en oeuvre d'au moins une règle décisionnelle.

L'invention a également pour objet un procédé de mise en oeuvre d'au moins une règle décisionnelle au sein d'une plateforme d'exécution modulaire comportant une couche matérielle et une couche logicielle, la couche matérielle comprenant une mémoire, la couche logicielle comprenant au moins un code applicatif et au moins un code de décision couplé audit code applicatif, le procédé étant caractérisé en ce qu'il comporte les étapes suivantes : - la génération, par un dispositif électronique, d'un code intermédiaire à partir de données relatives au dispositif électronique, d'une liste de types de plateformes d'exécution modulaires, de données opérationnelles relatives à la plateforme d'exécution modulaire et d'un code source de description d'au moins une règle décisionnelle dans un langage de programmation, - la transmission à la plateforme d'exécution modulaire du code intermédiaire généré, la mémoire de la couche matérielle stockant le code intermédiaire transmis, - l'élaboration d'une requête d'initialisation de la règle décisionnelle par un composant logiciel du code applicatif, préalablement à la première exécution de cette règle décisionnelle, - l'interprétation de la requête d'initialisation par un composant logiciel du code de décision, selon un protocole prédéterminé, - l'élaboration d'une requête d'exécution de ladite règle décisionnelle par ledit composant logiciel du code applicatif, et - l'exécution, par le composant logiciel du code de décision, d'une partie interprétable et exécutable du code intermédiaire reçu du dispositif électronique et mémorisé dans la couche matérielle de la plateforme d'exécution modulaire, ladite partie interprétable et exécutable étant formée d'un macro-code. Avantageusement, le procédé selon l'invention permet l'exécution, au sein de la ou chaque plateforme d'exécution modulaire, de règles décisionnelles paramétrables par l'utilisateur, tout en garantissant leur durée maximale d'exécution. Avantageusement, le procédé selon l'invention permet en outre de garantir que l'exécution des règles décisionnelles au sein de la ou chaque plateforme d'exécution modulaire n'entrainera pas des accès mémoire en dehors de l'espace mémoire prévu à cet effet dans cette plateforme. Suivant d'autres aspects avantageux de l'invention, le procédé comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : - la couche logicielle de la ou de chaque plateforme d'exécution modulaire comporte une couche logicielle bas niveau propre à fonctionner en tant que système d'exploitation principal de ladite plateforme, en ce que l'étape de génération du code intermédiaire comprend le calcul, par le dispositif électronique, d'un paramètre temporel général relatif à la plateforme d'exécution modulaire, et le regroupement dans le code intermédiaire, par le dispositif électronique, d'un en-tête, du macro-code, de données comprenant ledit paramètre temporel général, de données d'information (indicatives de la référence et de la version de la couche matérielle, de la couche logicielle bas niveau et du code de décision de la plateforme, et d'informations comprenant des informations indicatives de la taille en octets du macro-code et de la taille en octets des variables globales et des variables locales utilisées dans le macro-code ; - la requête d'initialisation élaborée par le composant logiciel du code applicatif comprend une valeur de durée maximale d'exécution du code de décision associé, et en ce que l'étape d'interprétation de la requête d'initialisation comprend la comparaison, par le composant logiciel du code de décision, entre le paramètre temporel général relatif à la plateforme d'exécution modulaire, figurant dans le code intermédiaire, et la durée maximale d'exécution allouée au code de décision ; - la requête d'initialisation élaborée par le composant logiciel du code applicatif comprend l'adresse mémoire du code intermédiaire dans un espace de stockage non volatil de la mémoire de la couche matérielle, et des données indicatives de l'espace mémoire alloué audit code applicatif pour le macro-code et pour les variables globales, en ce que l'étape d'interprétation de la requête d'initialisation comprend la comparaison, par le composant logiciel du code de décision, entre les informations indicatives de la taille en octets du macro-code et des variables globales, ces informations figurant dans le code intermédiaire, et les données indicatives de l'espace mémoire alloué audit code applicatif, en ce que l'étape d'interprétation de la requête d'initialisation comprend la comparaison, par le composant logiciel du code de décision, entre les informations indicatives de la taille en octets des variables locales, figurant dans le code intermédiaire, et des données indicatives de l'espace mémoire alloué au code de décision, et en ce que l'étape d'interprétation de la requête d'initialisation comprend la copie du macro-code depuis l'espace de stockage non volatil de la mémoire vers un espace de stockage volatil de la mémoire ; - l'étape d'interprétation de la requête d'initialisation comprend la comparaison, par le composant logiciel du code de décision, entre des informations relatives au dispositif électronique et aux plateformes d'exécution modulaire, figurant dans l'en-tête du code intermédiaire, et des données caractéristiques du code de décision, figurant dans le code de décision, et la comparaison, par le composant logiciel du code de décision, entre une donnée dont la valeur indique le nombre de types de plateformes d'exécution modulaire, figurant dans l'en-tête du code intermédiaire, et un nombre maximal de plateformes d'exécution modulaire aptes à être traitées par le code de décision au cours d'une durée maximale d'interprétation de la requête d'initialisation, le nombre maximal de plateformes d'exécution modulaire figurant dans le code de décision ; - les données opérationnelles relatives à la plateforme d'exécution modulaire comprennent une pluralité de paramètres temporels élémentaires, chaque paramètre temporel élémentaire indiquant la durée maximale de lecture, d'interprétation, et d'exécution d'une instruction du macro-code sur la plateforme, et en ce que l'étape de génération du code intermédiaire comprend une sous-étape de pré-compilation du code source au cours de laquelle le nombre maximal d'exécutions de chaque instruction du macro-code lors d'une unique exécution dudit macro-code est mémorisé dans le dispositif électronique, le calcul du paramètre temporel général étant effectué à partir de ce nombre maximal d'exécutions et desdits paramètres temporels élémentaires ; Les caractéristiques et avantages de l'invention apparaîtront à la 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 selon l'invention, comprenant un dispositif électronique comportant un code source, et deux plateformes d'exécution modulaires comportant chacune un code intermédiaire, - la figure 2 est une représentation schématique des éléments constitutifs du code source de la figure 1, - la figure 3 est une représentation schématique des éléments constitutifs du code intermédiaire de la figure 1, et - la figure 4 est un organigramme d'un procédé de mise en oeuvre d'au moins une règle décisionnelle au sein d'une plateforme d'exécution modulaire, selon l'invention. L'invention concerne un système électronique 10 comprenant un dispositif électronique 12 et au moins une plateforme d'exécution modulaire 14.

Dans l'exemple de réalisation de la figure 1, le système électronique 10 comprend deux plateformes d'exécution modulaire 14. Chaque plateforme d'exécution modulaire 14, appelée « plateforme » dans la suite du document, est avantageusement embarquée à bord d'un aéronef. Plus particulièrement, chaque plateforme 14 est par exemple une plateforme d'exécution modulaire embarquée du type « Avionique Modulaire Intégrée ».

Les deux plateformes 14 sont associées, dans l'exemple de réalisation, à des types d'aéronefs distincts. Autrement dit, les deux plateformes 14 appartiennent à des types de plateformes distincts. Chaque plateforme 14 est propre à être reliée au dispositif électronique 12 par une liaison 16 de transmission de données. Chaque liaison 16 est de préférence une liaison filaire sécurisée, par exemple conforme à la norme ARINC 664 P7. En variante, chaque liaison 16 est une liaison non filaire, par exemple une liaison radioélectrique conforme à la norme IEEE 802.11. Le dispositif électronique 12 comporte une première unité de traitement d'informations 18 formée, par exemple, d'un premier processeur 20 associé à une première mémoire 22. Le dispositif électronique 12 comporte en outre des moyens 24 de transmission de données, reliés au premier processeur 20. Le dispositif électronique 12 est, par exemple, un ordinateur non embarqué. Chaque plateforme 14, conforme à l'invention, comporte une couche matérielle 26 et une couche logicielle 28. Par la suite, dans un but de simplification, seule la structure d'une des plateformes 14 est détaillée, la structure de l'autre plateforme 14 étant identique.

La couche matérielle 26 comporte une deuxième unité de traitement d'informations 30 formée, par exemple, d'un deuxième processeur 32 associé à une deuxième mémoire 34. La deuxième mémoire 34 comprend un espace de stockage volatil 34A, par exemple du type mémoire vive. La deuxième mémoire 34 comprend également un espace de stockage non volatil 34B, par exemple de type mémoire de masse à semi-conducteurs réinscriptible, également appelée mémoire flash. La couche matérielle 26 est avantageusement partitionnée spatialement et temporellement. Une partition correspond au domaine sur lequel un code applicatif de la couche logicielle peut être exécuté. Il s'agit à la fois d'un domaine spatial, en termes de zones de la mémoire 34 adressable par le code applicatif, et d'un domaine temporel, en termes d'intervalles de temps pendant lequel le code applicatif est exécuté et accède aux ressources de la couche matérielle. Les différentes partitions du système sont disjointes spatialement et temporellement. De préférence, le partitionnement spatial et temporel de la couche matérielle 26 est conforme au standard ARINC 653. La couche logicielle 28 comporte une couche logicielle bas niveau 35A et une couche logicielle d'application 35B. La couche logicielle bas niveau 35A forme une interface entre la couche logicielle d'application 35B et le processeur 32, et fonctionne en tant que système d'exploitation principal de la plateforme 14, pour la virtualisation des composants de la couche matérielle 26 qui n'évoluent pas au cours du développement ou de l'utilisation de la plateforme 14. La couche logicielle d'application 35B comporte au moins un code applicatif et au moins un code de décision couplé audit code applicatif. Dans l'exemple de réalisation de la figure 1, la couche logicielle d'application 35B comporte un premier code applicatif 36A et un second code applicatif 36B. Elle comporte également un code de décision 38, couplé à chaque code applicatif 36A, 36B. Chaque code applicatif 36A, 36B est par exemple généré par un compilateur externe non représenté, puis téléchargé au sein de la couche logicielle d'application 35B.

Le premier code applicatif 36A est associé à une première partition 40A et le second code applicatif 36B est associé à une seconde partition 40B. Le premier code applicatif 36A, respectivement le second code applicatif 36B, est propre à être exécuté sur la première partition 40A, respectivement sur la seconde partition 40B. Dans l'exemple de réalisation, le code de décision 38 est associé à une partition supplémentaire 42, et est propre à être exécuté sur cette partition 42. Les partitions 40A, 40B, 42 sont disjointes entre elles.

En variante non représentée, la couche logicielle d'application 35B comporte autant de codes de décision que de codes applicatifs ayant besoin de faire appel à un code de décision. Chaque code de décision est couplé à un unique code applicatif et est propre à être exécuté sur la même partition que ce code applicatif.

La première mémoire 22 est apte à stocker un logiciel 44 de compilation de code. Le logiciel 44 de compilation de code est propre, lorsqu'il est exécuté par le premier processeur 20, à compiler un code source d'entrée 46 et à ainsi générer un macro-code 48 interprétable et exécutable. Le logiciel 44 de compilation est configuré de sorte à n'insérer aucun octet d'alignement entre les variables déclarées dans le code source 46, lors de la compilation du code source d'entrée 46. La première mémoire 22 est également apte à stocker le code source d'entrée 46, et au moins un fichier 50. Dans l'exemple de réalisation de la figure 1, la première mémoire 22 est apte à stocker deux fichiers 50. La première mémoire 22 est également apte à stocker un premier fichier supplémentaire 51 et un deuxième fichier supplémentaire 52. Chaque fichier 50 est avantageusement pré-implanté dans la première mémoire 22. En variante, chaque fichier 50 est généré par un module externe non représenté, le module externe étant relié, via le premier processeur 20, à la première mémoire 22 du dispositif électronique 12. Chaque fichier 50 comprend des données opérationnelles 53 relatives à un type de plateforme 14. La première mémoire 22 est également apte à stocker un logiciel 54 de calcul, à partir des données opérationnelles 53 relatives à un type de plateforme 14, d'un paramètre temporel général 56 relatif à chaque plateforme 14 de ce type, comme illustré sur la figure 3.

Comme représenté sur la figure 2, le code source 46 est un fichier comprenant un en-tête 58, une liste 60 de variables globales 62, et une liste 64 de variables locales 66. Le code source 46 comprend en outre une suite 68 d'instructions 70 décrivant au moins une règle décisionnelle dans un langage de programmation de type procédural. Dans l'exemple de réalisation, la suite 68 d'instructions 70 décrit une seule règle décisionnelle.

Une telle règle décisionnelle, lorsqu'elle est mise en oeuvre par une application informatique, permet à cette application informatique de décider d'une opération à exécuter en fonction d'un ensemble d'informations reçues. Une telle règle décisionnelle est par exemple une règle permettant à une plateforme contenant plusieurs modules, de décider quels modules doivent être arrêtés lorsqu'une alimentation est défaillante au sein de cette plateforme, en fonction de la criticité des opérations effectuées dans chaque module.

L'en-tête 58 comprend des informations relatives à la référence et à la version du code source 46. Les variables globales 62 sont visibles et accessibles à une application tierce faisant appel au code source 46. Elles sont en particulier propres à être utilisées comme moyen de communication entre chaque code applicatif 36A, 36B et le code de décision 38. Les variables locales 66 ne sont visibles qu'à l'intérieur du code source 46. La suite 68 d'instructions 70 du code source 46 est paramétrable par l'utilisateur. La suite 68 d'instructions 70 ne comporte pas d'instructions faisant appel à des pointeurs.

En outre, dans l'exemple de réalisation, la suite 68 d'instructions 70 ne comporte avantageusement ni définitions de fonctions et/ou de procédures, ni instructions de « saut ». En variante, la suite 68 d'instructions 70 comporte des définitions de fonctions et/ou de procédures, et/ou des instructions de « saut ». Comme représenté sur la figure 3, le macro-code 48 comprend plusieurs instructions génériques 72 décrivant la règle décisionnelle, les instructions génériques 72 comprenant notamment un accès aux variables globales 62. Le macro-code 48 comprend en outre une instruction de fin 73 propre à retourner une valeur de retour. La valeur de retour retournée par l'instruction de fin 73 indique si l'exécution du macro-code 48 s'est effectuée correctement, ou si cette exécution a été interrompue suite à la détection d'une 20 erreur. Les données opérationnelles 53 relatives à un type de plateforme comprennent plusieurs paramètres temporels élémentaires 75, et des données d'information 76, comme illustré sur la figure 1. Chaque paramètre temporel élémentaire 75 indique la durée maximale de lecture, 25 d'interprétation, et d'exécution d'une instruction générique 72 du macro-code 48 sur une plateforme du type associé. Les données d'information 76 comportent par exemple, pour le type de plateforme associé, une donnée indicative de la référence et de la version de la couche matérielle 26 de chaque plateforme de ce type, une donnée indicative de la référence et de la version 30 de la couche logicielle bas niveau 35A de chaque plateforme de ce type, et une donnée indicative de la référence et de la version du code de décision 38 installé au sein de chaque plateforme de ce type. Le premier fichier supplémentaire 51 comporte plusieurs données, chaque donnée indiquant, pour une instruction générique 72 du macro-code 48, le nombre maximal 35 d'exécutions de cette instruction 72 lors d'une unique exécution du macro-code 48.

Le deuxième fichier supplémentaire 52 est formé d'une liste 78. La liste 78 regroupe les références et les versions de l'ensemble des types de plateformes envisagés pour le système électronique 10. Le logiciel de calcul 54 est propre à calculer, pour chaque plateforme 14, le paramètre temporel général 56 associé à cette plateforme, à partir des paramètres temporels élémentaires 75 associés aux plateformes de même type, et des données figurant dans le fichier supplémentaire 51. Chaque paramètre temporel général 56 indique la durée maximale d'exécution du macro-code 48 sur la plateforme 14 associée.

Le premier processeur 20 est propre à générer, à partir du code source 46, de la liste 78 et des données opérationnelles 53, un code intermédiaire 80 associé à l'ensemble des plateformes 14. Le premier processeur 20 est en outre avantageusement propre à déterminer la taille en octets du macro-code 48, la taille en octets des variables globales 62 et la taille en octets des variables locales 66. Le premier processeur 20 est également avantageusement propre à déterminer la référence et la version du logiciel de compilation 44, et la référence et la version du code source 46 contenues dans son en-tête 58. Comme représenté sur la figure 3, le code intermédiaire 80 est un fichier comprenant le macro-code 48, des informations 81 indicatives de la taille en octets du macro-code 48, des informations 82 indicatives de la taille en octets des variables globales 62, et des informations 83 indicatives de la taille en octets des variables locales 66. Le code intermédiaire 80 comprend en outre une liste 84 de données relatives aux plateformes 14, ainsi qu'un en-tête 85.

La liste 84 comprend les données d'information 76 des données opérationnelles 53 relatives à chaque type de plateforme 14, ainsi que le paramètre temporel général 56 relatif à chaque plateforme 14. En complément, la liste 84 comprend une donnée indicative de la référence et de la version de chaque fichier 50. Ceci permet d'améliorer la traçabilité et la maintenance du système électronique 10. L'en-tête 85 comprend la référence et la version du logiciel de compilation 44, la référence et la version du code source 46, et une donnée indicative du nombre de types de plateformes 14 envisagés dans la liste 84, et correspondant au nombre de types de plateformes 14 du système électronique 10. Dans l'exemple de réalisation de la figure 1, la valeur de cette donnée est égale à deux.

Les moyens de transmission 24 sont des moyens d'émission de données électroniques classiquement connus, formés par exemple d'un circuit intégré dédié. Les moyens de transmission 24 sont propres en particulier à transmettre des données comprenant du code informatique. En variante, les moyens de transmission 24 sont réalisés sous forme de composants logiciels, ou encore sous forme de circuits logiques programmables. L'espace de stockage volatil 34A est propre à stocker une copie du macro-code 48, représentée en traits pointillés sur la figure 1. L'espace de stockage non volatil 34B est apte à stocker un logiciel 86 de téléchargement, depuis le dispositif 12, de données électroniques telles que des données comprenant du code informatique. Le logiciel de téléchargement 86 est propre à télécharger, depuis le dispositif 12, des données électroniques comprenant du code informatique. En particulier, le logiciel de téléchargement 86 est propre à télécharger, depuis le dispositif 12, via une des liaisons 16, le code intermédiaire 80. Le premier code applicatif 36A, respectivement le deuxième code applicatif 36B comporte un premier composant logiciel 88A, respectivement un deuxième composant logiciel 88B. Le premier code applicatif 36A, respectivement le deuxième code applicatif 36B, est configuré de sorte à avoir accès à un premier fichier 90A, respectivement à un deuxième fichier 90B, comprenant des données indicatives de l'espace mémoire et de la période maximale d'exécution qui lui sont alloués par le partitionnement. Chaque fichier 90A, 90B est stocké dans l'espace de stockage non volatil 34B, et est par exemple formé d'une table de configuration pré-implantée dans l'espace de stockage non volatil 34B.

Chaque code applicatif 36A, 36B est en effet propre à accéder à la couche matérielle 26. Plus particulièrement, chaque code applicatif 36A, 36B est propre à accéder au deuxième processeur 32 de la deuxième unité de traitement 30. Chaque code applicatif 36A, 36B est en outre propre à déterminer, à partir de sa période maximale d'exécution allouée, la durée maximale d'exécution allouée au code de décision 38. Chaque code applicatif 36A, 36B est également propre à lire et à extraire, dans l'espace de stockage non volatil 34B de la deuxième mémoire 34, l'adresse du code intermédiaire 80, du macro-code 48 et des variables globales 62 stockés dans cet espace de stockage non volatil 34B. Chaque code applicatif 36A, 36B est ainsi propre à mettre en oeuvre les variables globales 62 pour fournir une base de connaissance au code de décision 38.

Le premier code applicatif 36A, respectivement le deuxième code applicatif 36B est également propre à appeler le premier composant logiciel 88A, respectivement le deuxième composant logiciel 88B, pour l'initialisation ou pour l'exécution de la règle décisionnelle.

Le code de décision 38 comporte un troisième composant logiciel 92. Le code de décision 38 est propre à accéder à la couche matérielle 26. Plus particulièrement, le code de décision 38 est propre à accéder au deuxième processeur 32 de la deuxième unité de traitement 30. Le composant logiciel 88A, 88B de chaque code applicatif 36A, 36B est propre à élaborer une requête d'initialisation de la règle décisionnelle. Le composant logiciel 88A, 88B de chaque code applicatif 36A, 36B est propre en outre à élaborer une requête d'exécution de la règle décisionnelle, et à transmettre chaque requête d'initialisation ou d'exécution au troisième composant logiciel 92. Chaque requête d'initialisation élaborée par le composant logiciel 88A, 88B d'un code applicatif 36A, 36B comprend les données indicatives de l'espace mémoire alloué à ce code applicatif 36A, 36B, la durée maximale d'exécution allouée au code de décision 38, et l'adresse mémoire du code intermédiaire 80 stocké dans l'espace de stockage non volatil 34B de la deuxième mémoire 34. En particulier, les données indicatives de l'espace mémoire alloué à un code applicatif 36A, 36B comprennent l'adresse mémoire des variables globales 62 et l'adresse mémoire de l'espace de stockage volatil 34A au sein duquel doit être chargée la copie du macro-code 48. Plus particulièrement, les données indicatives de l'espace mémoire alloué à un code applicatif 36A, 36B comprennent l'adresse mémoire du début des variables globales 62, ainsi que l'adresse mémoire du dernier octet de la dernière variable globale 62 figurant dans le macro-code 48. Ceci permet au code de décision 38 de déterminer la taille théorique en octets des variables globales 62 et de contrôler ainsi, par comparaison, que le compilateur externe ayant généré le code applicatif 36A, 36B n'a pas ajouté d'octets d'alignement entre les variables globales 62. Le troisième composant logiciel 92 est propre à interpréter une requête d'initialisation ou d'exécution de la règle décisionnelle. Plus particulièrement, le troisième composant logiciel 92 est propre à comparer les données d'information 76 figurant dans le code intermédiaire 80 avec les données caractéristiques de la plateforme 14 sur laquelle le composant logiciel 92 est en train de s'exécuter. Le troisième composant logiciel 92 est également propre à comparer le paramètre temporel général 56 de la plateforme 14 associée, lequel paramètre 56 figure dans le code intermédiaire 80, avec la durée maximale d'exécution allouée au code de décision 38. Il est également propre à comparer les informations 81, 82 indicatives de la taille en octets du macro-code 48 et de la taille en octets des variables globales 62 avec les données indicatives de l'espace mémoire alloué au code applicatif 36A, 36B. Il est également propre à comparer les informations 83 indicatives de la taille en octets des variables locales 66 avec les données indicatives de l'espace mémoire alloué au code de décision 38. Le troisième composant logiciel 92 est propre en outre à comparer les données de l'en-tête 85 avec des données caractéristiques du code de décision 38, stockées dans le code de décision 38. Le troisième composant logiciel 92 est également propre à transmettre au composant logiciel 88A, 88B de chaque code applicatif 36A, 36B un identificateur faisant référence à la règle décisionnelle. Le troisième composant logiciel 92 est également propre à lire le macro-code 48 stocké dans l'espace de stockage non volatil 34B de la deuxième mémoire 34, et à le copier dans l'espace de stockage volatil 34A. Le troisième composant logiciel 92 est également propre à lire, à interpréter, et à exécuter cette copie du macro-code 48 stockée dans l'espace de stockage volatil 34A pour la mise en oeuvre de la règle décisionnelle. L'homme du métier ayant des compétences normales dans la programmation d'applications pour des plateformes d'exécution modulaires sait programmer les applications 36A, 36B, 38 précitées pour utiliser et effectuer les fonctions mentionnées ci-dessus. Par conséquent, les codes de programmation spécifiques des codes applicatifs 36A, 36B et du code de décision 38 ne sont pas décrits plus en détail. Le fonctionnement du système électronique 10 va désormais être expliqué à l'aide de la figure 4 représentant un organigramme du procédé de mise en oeuvre d'au moins une règle décisionnelle au sein d'une des plateformes 14. L'homme du métier comprendra bien entendu que le procédé selon l'invention est mis en oeuvre de la même manière dans l'autre plateforme 14 de l'exemple de réalisation de la figure 1, et plus généralement dans chaque plateforme du système électronique 10. Initialement, le code source 46 et les fichiers 50, 52 sont stockés dans la première mémoire 22, et les fichiers 90A, 90B sont stockés dans l'espace de stockage non volatil 34B de la deuxième mémoire 34. Par ailleurs, la plateforme 14 est reliée au dispositif électronique 12 via la liaison filaire sécurisée 16. En outre, l'ensemble du système électronique 10 fait l'objet d'une certification. Dans l'exemple de réalisation avantageux selon lequel chaque plateforme 14 est une plateforme embarquée à bord d'un aéronef, le système électronique 10 est certifié selon une norme aéronautique, par exemple selon la norme RTCA DO-178 (« Software considerations in airborne systems and equipment certification » en anglais).

Lors d'une étape initiale 100, le premier processeur 20 du dispositif électronique 12 génère le code intermédiaire 80 à partir du code source 46, des fichiers 50 relatifs aux types de plateformes 14 et du deuxième fichier supplémentaire 52. Cette étape est illustrée en détail sur la figure 4.

Au cours d'une étape 100A de pré-compilation du code source 46, le premier processeur 20 exécute le logiciel 44 de compilation de code. Le logiciel 44 de compilation remplace alors, dans le code source 46, chaque instruction 70 de boucle par une instruction de saut vers une ligne fixe du code source 46. Au cours de cette même étape 100A, la première mémoire 22 stocke, pour chaque instruction 70 du code source 46, le nombre maximal d'exécutions de cette instruction 70 lors d'une unique exécution du programme décrivant la règle décisionnelle. La première mémoire 22 stocke alors ces différentes données, sous la forme du fichier supplémentaire 51. Au cours de cette même étape 100A, le logiciel de compilation 44 ajoute l'instruction de fin 73 à la suite 68 d'instructions 70 du code source 46. Il ajoute également à cette suite d'instructions des instructions de test de non-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 de compilation 44, ainsi que les limitations de la suite d'instructions 70 décrites plus haut, garantissent que les instructions 70 n'accèdent pas à une zone mémoire située en dehors de la zone mémoire allouée aux variables globales et locales. Au cours d'une étape 100B suivante, pour chacune des plateformes 14 associée à un type de plateformes listé dans le fichier supplémentaire 52, le paramètre temporel général 56 est calculé à l'aide du logiciel de calcul 54, à partir du fichier 50 correspondant et du fichier supplémentaire 51. Plus précisément, le paramètre temporel général 56 est calculé à partir des paramètres temporels élémentaires 75 contenus dans le fichier 50, et des données du fichier supplémentaire 51 indiquant le nombre maximal d'exécutions de chaque instruction du programme. Le paramètre temporel général 56 correspond au temps maximal que mettra le macro-code 48 pour s'exécuter sur la plateforme 14. Autrement dit, le paramètre temporel général 56 correspond au temps que mettra le macro-code 48 pour être entièrement exécuté sur la plateforme 14 lorsque le « pire » chemin d'exécution de ses instructions 72 sera emprunté, du point de vue de la durée d'exécution (WCET pour « Worst-Case Execution Time » en anglais). Le paramètre temporel général 56 est par exemple calculé via la mise en oeuvre, par le logiciel de calcul 54, d'un algorithme classique de calcul de WCET. Un tel algorithme comprend par exemple une étape de transcription du code source 46 sous la forme un graphe orienté acyclique, puis une étape de tri topologique des sommets du graphe, chaque sommet représentant une instruction issue de la pré-compilation 100A du code source, et enfin une étape de calcul itératif, pour chaque sommet du graphe, d'un paramètre temporel intermédiaire relatif à ce graphe, le paramètre temporel général 56 étant pris comme égal à la valeur maximum de tous les paramètres temporels intermédiaires calculés. A l'issue de l'étape 100B, chaque paramètre temporel général 56 associé à une plateforme 14 est stocké dans la première mémoire 22. En parallèle de l'étape 100B, lors d'une étape 100C de compilation du code source 46, le premier processeur 20 exécute le logiciel 44 de compilation de code. Le logiciel 44 de compilation génère alors le macro-code 48 à partir du code source pré-compilé à l'étape 100A. Plus particulièrement, le logiciel 44 de compilation de code traduit la suite d'instructions du code source pré-compilé en une suite d'instructions génériques 72. Les instructions génériques 72 sont indépendantes de la plateforme 14 au sein de laquelle le macro-code 48 sera exécuté. Par exemple, de telles instructions génériques pourraient être : « lecture d'une variable », ou « somme entre deux variables », ou encore « branchement conditionnel selon un booléen ». A l'issue de l'étape 100C, la première mémoire 22 stocke le macro-code 48. Lors d'une étape 100D suivante, le premier processeur 20 regroupe dans un unique fichier 80 l'en-tête 85, les données d'information 76 de chaque fichier 50 associé à un type de plateforme 14 listé dans le fichier supplémentaire 52, les paramètres temporels généraux 56, et le macro-code 48. Le premier processeur 20 détermine en outre la taille en octets du macro-code 48, la taille en octets des variables globales 62 et la taille en octets des variables locales 66, et regroupe ces informations 81, 82, 83 dans le fichier 80. Le premier processeur 20 génère ainsi le code intermédiaire 80. A l'issue de l'étape 100D, le premier processeur 20 transmet le code intermédiaire 80 aux moyens de transmission 24. A l'issue de l'étape 100, une étape suivante 102 est mise en oeuvre. Au cours de cette étape 102, le code intermédiaire 80 est émis par les moyens de transmission 24 à destination de la plateforme 14, via la liaison 16 de transmission de données. A l'issue de l'étape 102, le logiciel de téléchargement 86 de la plateforme 14 reçoit le code intermédiaire 80, et l'espace de stockage non volatil 34B de la plateforme 14 stocke le code intermédiaire 80. Au cours d'une étape suivante 104, un des codes applicatifs 36A, 36B, par exemple le premier code applicatif 36A, requiert un accès à la deuxième mémoire 34 auprès du deuxième processeur 32. Le premier code applicatif 36A accède alors au premier fichier 90A, et extrait les données indicatives de l'espace mémoire et de la période maximale d'exécution qui lui sont alloués par le partitionnement. Le premier code applicatif 36A détermine alors, à partir de sa période maximale d'exécution allouée, la durée maximale d'exécution allouée au code de décision 38. Au cours de cette même étape 104, le premier code applicatif 36A extrait également, dans la deuxième mémoire 34, l'adresse du code intermédiaire 80 stocké dans l'espace de stockage non volatil 34B de cette deuxième mémoire 34. Au cours de cette même étape 104, le premier code applicatif 36A appelle en outre le premier composant logiciel 88A pour l'initialisation de la règle décisionnelle contenue dans le macro-code 48. Au cours de cette même étape 104, le premier composant logiciel 88A élabore une requête d'initialisation de la règle décisionnelle, comprenant l'adresse mémoire du code intermédiaire 80, les données indicatives de l'espace mémoire alloué au premier code applicatif 36A, la durée maximale d'exécution allouée au code de décision 38, et l'adresse mémoire où doit être chargée la copie du macro-code 48 dans l'espace de stockage volatil 34A de la deuxième mémoire 34. A l'issue de l'étape 104, le premier composant logiciel 88A transmet la requête d'initialisation au troisième composant logiciel 92 du code de décision 38. A partir des données indicatives de l'espace mémoire alloué au premier code applicatif 36A, le troisième composant logiciel 92 détermine la taille théorique des variables globales 62. Au cours d'une étape 106 suivante, le code de décision 38 requiert un accès à la deuxième mémoire 34 auprès du deuxième processeur 32. Le code de décision 38 accède alors au code intermédiaire 80, et extrait les données de l'en-tête 85, les données d'information 76, le paramètre temporel général 56 associé à la plateforme 14 et les informations 81 indicatives de la taille en octets du macro-code 48, les informations 82 indicatives de la taille en octets des variables globales 62, et les informations 83 indicatives de la taille en octets des variables locales 66. Au cours de cette même étape 106, le troisième composant logiciel 92 du code de décision 38 interprète la requête d'initialisation selon un protocole prédéterminé. Le protocole d'interprétation de la requête comprend une vérification, par le troisième composant logiciel 92, que la référence et la version de plateforme, figurant dans la donnée d'information 76 correspondante, sont identiques à la référence et à la version de la plateforme 14. Le protocole d'interprétation de la requête comprend également une première comparaison, par le troisième composant logiciel 92, entre le paramètre temporel général 56 et la durée maximale d'exécution allouée au code de décision 38. Si la valeur du paramètre temporel général 56 est inférieure ou égale à la valeur de la durée maximale d'exécution allouée au code de décision 38, alors la première comparaison est « positive ». Le protocole d'interprétation de la requête comprend en outre une deuxième comparaison, par le troisième composant logiciel 92, entre les informations 81, 82, 83 indicatives de la taille en octets du macro-code 48 et de la taille en octets des variables globales 62 et des variables locales 66, et les données indicatives de l'espace mémoire alloué au premier code applicatif 36A. Si la taille en octets du macro-code 48 est inférieure ou égale à la taille en octets de l'espace mémoire dédié alloué au premier code applicatif, si la taille en octets des variables locales 66 est inférieure ou égale à la taille en octets de l'espace mémoire dédié alloué au code d'exécution 38, et si la taille en octets des variables globales 62 est exactement égale à la taille théorique des variables globales 62, alors la deuxième comparaison est « positive ». Le protocole d'interprétation de la requête comprend également une troisième comparaison, par le troisième composant logiciel 92, entre les données de l'en-tête 85 et les données caractéristiques du code de décision 38. En particulier, le troisième composant logiciel 92 compare, au cours de cette troisième comparaison, la valeur de la donnée indicative du nombre de types de plateformes 14, figurant dans l'en-tête 85, avec une valeur maximale de plateformes 14 aptes à être traitées par le code de décision 38 au cours d'une durée maximale d'interprétation de la requête d'initialisation, cette valeur figurant dans le code de décision 38. Le troisième composant logiciel 92 vérifie également, au cours de cette troisième comparaison, que la référence et la version du code de décision 38 est compatible avec la référence et la version du logiciel de compilation 44. Si la valeur de la donnée indicative du nombre de types de plateformes 14, figurant dans l'en-tête 85, est inférieure ou égale à la valeur maximale figurant dans le code de décision 38, et si la référence et la version du logiciel de compilation 44 sont compatibles avec la référence et la version du code de décision 38, alors la troisième comparaison est « positive ». Si les première, deuxième et troisième comparaisons sont « positives », le troisième composant logiciel 92 copie le macro-code 48 dans une zone de l'espace de stockage volatil 34A. Le troisième composant logiciel 92 requiert ensuite, au cours de cette même étape 106, un accès à la deuxième mémoire 34 auprès du deuxième processeur 32. La deuxième mémoire 34 stocke alors l'adresse mémoire de la copie du macro-code 48 dans l'espace de stockage volatil 34A, l'adresse mémoire du début des variables globales 62 dans l'espace de stockage volatil 34A, et l'adresse mémoire du début des variables locales 66 dans l'espace de stockage volatil 34A. Le troisième composant logiciel 92 retourne alors au premier composant logiciel 88A un identificateur faisant référence à la règle décisionnelle. Par exemple, l'identificateur retourné correspond à l'adresse mémoire où le troisième composant logiciel 92 a mémorisé, dans l'espace de stockage volatil 34A, les adresses mémoire du macro-code 48, du début des variables globales 62, et du début des variables locales 66. Une étape suivante 107 est alors mise en oeuvre. Sinon, le troisième composant logiciel 92 retourne un code d'erreur au premier composant logiciel 88A. Le procédé se termine alors à l'étape 106. Au cours de l'étape suivante 107, le premier composant logiciel 88A élabore une requête d'exécution de la règle décisionnelle, comprenant l'identificateur retourné par le troisième composant logiciel 92 lors de l'étape 104. A l'issue de l'étape 107, le premier composant logiciel 88A transmet la requête d'exécution au troisième composant logiciel 92. Au cours d'une étape suivante 110, le troisième composant logiciel 92 interprète la requête d'exécution, puis lit, interprète et exécute la copie du macro-code 48 stockée dans l'espace de stockage volatil 34A de la deuxième mémoire 34. A l'issue de cette étape 110, le troisième composant logiciel 92 retourne au premier composant logiciel 88A une valeur de retour. Si l'exécution du macro-code 48 s'est déroulée correctement, la valeur de retour retournée est la valeur de retour contenue dans l'instruction de fin 73. La règle décisionnelle est alors mise en oeuvre au sein de la plateforme 14. Sinon, la valeur de retour retournée indique que l'exécution ne s'est pas déroulée correctement, et indique également la nature de l'erreur détectée. Si l'utilisateur souhaite modifier la règle décisionnelle décrite par le macro-code 48, il modifie le code source 46 en conséquence, et charge ce code source 46 modifié à l'intérieur de la première mémoire 22. La partie modifiée du code source 46 fait alors l'objet d'une nouvelle certification, par exemple selon une norme aéronautique de type DO-178, et l'étape initiale 100 est ensuite remise en oeuvre. Si l'utilisateur ne souhaite pas modifier la règle décisionnelle décrite par le macrocode 48, l'étape 107 est remise en oeuvre.

On conçoit ainsi que le système électronique 10 selon l'invention permet l'exécution, au sein de chaque plateforme d'exécution modulaire 14, de règles décisionnelles paramétrables par l'utilisateur, tout en ne nécessitant pas de nouvelle certification aéronautique de l'ensemble de la plateforme 14 en cas de modification de ces règles décisionnelles. Lorsque qu'une telle modification survient, seuls les éléments de code associés à la règle décisionnelle modifiée sont certifiés à nouveau. Ceci permet de réduire avantageusement les coûts par rapport aux solutions de l'état antérieur.

Les instructions génériques 72 du macro-code 48 étant indépendantes de la plateforme sur laquelle le macro-code 48 sera exécuté, et les fichiers 50 pré-implantés dans la première mémoire 22 pouvant être générés pour tout type de plateforme, le système électronique 10 selon l'invention fonctionne avantageusement avec tous les types de plateformes d'exécution modulaire envisageables, notamment avec des plateformes embarquées ou non, ou encore avec des plateformes embarquées sur des aéronefs de type différent, et selon toutes les combinaisons possibles entre ces caractéristiques. Bien que les deux plateformes 14 soient associées, dans l'exemple de réalisation, à des types d'aéronefs distincts, l'homme du métier comprendra que les plateformes 14 du système électronique 10 selon l'invention peuvent, ou non, être associées à des types d'aéronefs distincts. Par ailleurs, du fait de la première comparaison effectuée par le troisième composant logiciel 92, le procédé selon l'invention permet de garantir la durée maximale d'exécution des règles décisionnelles au sein de la ou chaque plateforme d'exécution modulaire. En outre, du fait de la deuxième comparaison effectuée par le troisième composant logiciel 92, le procédé selon l'invention permet également de garantir que l'exécution des règles décisionnelles au sein de la ou chaque plateforme d'exécution modulaire n'entrainera pas des accès mémoire en dehors de l'espace mémoire prévu à cet effet dans cette plateforme.

Claims (17)

1. REVENDICATIONS1.- Système électronique (10), comprenant : - au moins une plateforme d'exécution modulaire (14) comportant une couche matérielle (26) et une couche logicielle (28), la couche matérielle (26) comprenant une mémoire (34), la couche logicielle (28) comprenant au moins un code applicatif (36A, 36B), - un dispositif électronique (12) propre à être relié à la ou chaque plateforme d'exécution modulaire (14) par une liaison (16) de transmission de données, le dispositif 10 électronique (12) comportant une mémoire (22) apte à stocker des données opérationnelles (53) relatives à la ou chaque plateforme d'exécution modulaire (14), caractérisé en ce que le dispositif électronique (12) comporte des moyens (18) de génération d'un code intermédiaire (80) à partir desdites données opérationnelles (53) et d'un code source (46) de description d'au moins une règle décisionnelle dans un langage 15 de programmation, le code intermédiaire (80) comprenant une partie (48) interprétable et exécutable, et en ce que la couche logicielle (28) de la ou chaque plateforme d'exécution modulaire (14) comporte au moins un code de décision (38) couplé audit code applicatif (36A, 36B), ledit code de décision (38) comportant un composant logiciel (92) propre, lorsqu'il est appelé par ledit code applicatif (36A, 36B), à exécuter ladite partie (48) du 20 code intermédiaire (80) reçu du dispositif électronique (12) et stocké dans la mémoire (34) de la couche matérielle (26), pour la mise en oeuvre de ladite règle décisionnelle.
2. 2.- Système électronique (10) selon la revendication 1, caractérisé en ce que les moyens de génération (18) sont propres à compiler le code source (46) afin d'obtenir un 25 macro-code (48) de description de ladite au moins une règle décisionnelle, ledit macro- code (48) comprenant des instructions (72) issues d'une suite d'instructions génériques et formant la partie interprétable et exécutable du code intermédiaire (80).
3. 3.- Système électronique (10) selon la revendication 2, caractérisé en ce que les 30 données opérationnelles (53) comprennent, pour la ou chaque plateforme d'exécution modulaire (14) associée, une pluralité de premiers paramètres temporels (75), chaque premier paramètre temporel (75) indiquant la durée maximale de lecture, d'interprétation, et d'exécution d'une instruction (72) de la suite d'instructions génériques sur ladite plateforme (14). 35
4. 4.- Système électronique (10) selon la revendication 3, caractérisé en ce que les moyens de génération (18) comprennent des moyens (20, 54) de calcul, pour la ouchaque plateforme d'exécution modulaire (14), d'un deuxième paramètre temporel (56) relatif à ladite plateforme (14), à partir des premiers paramètres temporels (75) associés à ladite plateforme (14), chaque deuxième paramètre temporel (56) indiquant la durée maximale d'exécution du macro-code (48) sur ladite plateforme (14).
5. 5.- Système électronique (10) selon la revendication 4, caractérisé en ce que la couche logicielle (28) de la ou de chaque plateforme d'exécution modulaire (14) comporte une couche logicielle bas niveau (35A) propre à fonctionner en tant que système d'exploitation principal de ladite plateforme (14), en ce que le code intermédiaire (80) est associé à la ou à chaque plateforme d'exécution modulaire (14), et en ce que le code intermédiaire (80) comporte en outre une liste (84) de données comprenant des données d'information (76) indicatives de la référence et de la version de la couche matérielle (26), de la couche logicielle bas niveau (35A) et du code de décision (38) de la ou chaque plateforme (14), ainsi que le ou chaque deuxième paramètre temporel (56) relatif à la ou à une des plateforme (s) (14).
6. 6.- Système électronique (10) selon la revendication 5, caractérisé en ce que le code intermédiaire (80) comporte en outre un en-tête (85) comprenant des informations relatives aux moyens de génération (18), des informations relatives au code source (46), et une donnée dont la valeur indique le nombre de types de plateformes d'exécution modulaire (14) de la liste (84), et en ce que le code intermédiaire (80) comporte également des informations (81, 82, 83) indicatives de la taille en octets du macro-code (48), de la taille en octets des variables globales (62), et de la taille en octets des variables locales (66).
7. 7.- Système électronique (10) selon l'une quelconque des revendications précédentes, caractérisé en ce que la couche matérielle (26) de la ou chaque plateforme d'exécution modulaire (14) est partitionnée spatialement et temporellement, de préférence selon un partitionnement spatial et temporel conforme au standard ARINC 653, le ou chaque code applicatif (36A, 36B) étant apte à être exécuté sur une partition qui lui est dédiée.
8. 8.- Système électronique (10) selon la revendication 7, caractérisé en ce que le ou chaque code applicatif (36A, 36B) est configuré de sorte à avoir accès à des données indicatives de l'espace mémoire et de la période maximale d'exécution alloués audit code applicatif (36A, 36B) par le partitionnement, ledit code applicatif (36A, 36B) étant propre àdéterminer, à partir de sa période maximale d'exécution allouée, la durée maximale d'exécution allouée au code de décision (38) associé.
9. 9.- Système électronique (10) selon l'une quelconque des revendications précédentes, caractérisé en ce que le ou chaque code applicatif (36A, 36B) comporte un composant logiciel (88A, 88B) propre, lorsque ledit code applicatif (36A, 36B) appelle l'exécution de ladite règle décisionnelle, à requérir cette exécution auprès du composant logiciel (92) du code de décision (38) associé, en émettant une requête adaptée.
10. 10.- Système électronique (10) selon l'une quelconque des revendications précédentes, caractérisé en ce que la ou chaque plateforme d'exécution modulaire (14) est une plateforme d'exécution modulaire embarquée, en particulier une plateforme d'exécution modulaire embarquée du type « Avionique Modulaire Intégrée ».
11. 11.- Plateforme d'exécution modulaire embarquée (14), telle qu'une plateforme d'exécution modulaire du type « Avionique Modulaire Intégrée », la plateforme comportant une couche matérielle (26) et une couche logicielle (28), la couche matérielle (26) comprenant une mémoire (34), la couche logicielle (28) comprenant au moins un code applicatif (36A, 36B), caractérisée en ce que la couche logicielle (28) comporte au moins un code de décision (38) couplé audit code applicatif (36A, 36B), ledit code de décision (38) comportant un composant logiciel (92) propre, lorsqu'il est appelé par ledit code applicatif (36A, 36B), à exécuter une partie (48) exécutable et interprétable d'un code intermédiaire (80) stocké dans la mémoire (34) de la couche matérielle (26), pour la mise en oeuvre d'au moins une règle décisionnelle.
12. 12.- Procédé de mise en oeuvre d'au moins une règle décisionnelle au sein d'une plateforme d'exécution modulaire (14) comportant une couche matérielle (26) et une couche logicielle (28), la couche matérielle (26) comprenant une mémoire (34), la couche logicielle (28) comprenant au moins un code applicatif (36A, 36B) et au moins un code de décision (38) couplé audit code applicatif (36A, 36B), le procédé étant caractérisé en ce qu'il comporte les étapes suivantes : - la génération (100), par un dispositif électronique (12), d'un code intermédiaire (80) à partir de données relatives au dispositif électronique (12), d'une liste (78) de types de plateformes d'exécution modulaires, de données opérationnelles (53) relatives à la plateforme d'exécution modulaire (14) et d'un code source (46) de description d'au moins une règle décisionnelle dans un langage de programmation,- la transmission (102) à la plateforme d'exécution modulaire (14) du code intermédiaire (80) généré, la mémoire (34) de la couche matérielle (26) stockant le code intermédiaire (80) transmis, - l'élaboration (104) d'une requête d'initialisation de la règle décisionnelle par un composant logiciel (88A, 88B) du code applicatif (36A, 36B), préalablement à la première exécution de cette règle décisionnelle, - l'interprétation (106) de la requête d'initialisation par un composant logiciel (92) du code de décision (38), selon un protocole prédéterminé, - l'élaboration (107) d'une requête d'exécution de ladite règle décisionnelle par ledit composant logiciel (88A, 88B) du code applicatif (36A, 36B), et - l'exécution (110), par le composant logiciel' (92) du code de décision (38), d'une partie (48) interprétable et exécutable du code intermédiaire (80) reçu du dispositif électronique (12) et mémorisé dans la couche matérielle (26) de la plateforme d'exécution modulaire (14), ladite partie (48) interprétable et exécutable étant formée d'un macro- code.
13. 13.- Procédé selon la revendication 12, caractérisé en ce que la couche logicielle (28) de la ou de chaque plateforme d'exécution modulaire (14) comporte une couche logicielle bas niveau (35A) propre à fonctionner en tant que système d'exploitation principal de ladite plateforme (14), en ce que l'étape (100) de génération du code intermédiaire (80) comprend le calcul (100B), par le dispositif électronique (12), d'un paramètre temporel général (56) relatif à la plateforme d'exécution modulaire (14), et le regroupement (100D) dans le code intermédiaire (80), par le dispositif électronique (12), d'un en-tête (85), du macro-code (48), de données comprenant ledit paramètre temporel général (56), de données d'information (76) indicatives de la référence et de la version de la couche matérielle (26), de la couche logicielle bas niveau (35A) et du code de décision (38) de la plateforme (14), et d'informations comprenant des informations (81, 82, 83) indicatives de la taille en octets du macro-code (48) et de la taille en octets des variables globales (62) et des variables locales (66) utilisées dans le macro-code (48).
14. 14.- Procédé selon la revendication 13, caractérisé en ce que la requête d'initialisation élaborée par le composant logiciel (88A, 88B) du code applicatif (36A, 36B) comprend une valeur de durée maximale d'exécution du code de décision (48) associé, et en ce que l'étape (106) d'interprétation de la requête d'initialisation comprend la comparaison, par le composant logiciel (92) du code de décision (38), entre le paramètre temporel général (56) relatif à la plateforme d'exécution modulaire (14), figurant dans lecode intermédiaire (80), et la durée maximale d'exécution allouée au code de décision (38).
15. 15.- Procédé selon la revendication 13 ou 14, caractérisé en ce que la requête d'initialisation élaborée par le composant logiciel (88A, 88B) du code applicatif (36A, 36B) comprend l'adresse mémoire du code intermédiaire (80) dans un espace de stockage non volatil (34B) de la mémoire (34) de la couche matérielle (26), et des données indicatives de l'espace mémoire alloué audit code applicatif (36A, 36B) pour le macro-code (48) et pour les variables globales (62), en ce que l'étape (106) d'interprétation de la requête d'initialisation comprend la comparaison, par le composant logiciel (92) du code de décision (38), entre les informations (81, 82) indicatives de la taille en octets du macrocode (48) et des variables globales (62), ces informations (81, 82) figurant dans le code intermédiaire (80), et les données indicatives de l'espace mémoire alloué audit code applicatif (36A, 36B), en ce que l'étape (106) d'interprétation de la requête d'initialisation comprend la comparaison, par le composant logiciel (92) du code de décision (38), entre les informations (83) indicatives de la taille en octets des variables locales (66), figurant dans le code intermédiaire (80), et des données indicatives de l'espace mémoire alloué au code de décision (38), et en ce que l'étape (106) d'interprétation de la requête d'initialisation comprend la copie du macro-code (48) depuis l'espace de stockage non volatil (34B) de la mémoire (34) vers un espace de stockage volatil (34A) de la mémoire (34).
16. 16.- Procédé selon l'une des revendications 13 à 15, caractérisé en ce que l'étape (106) d'interprétation de la requête d'initialisation comprend la comparaison, par le composant logiciel (92) du code de décision (38), entre des informations relatives au dispositif électronique (12) et aux plateformes d'exécution modulaire (14), figurant dans l'en-tête (85) du code intermédiaire (80), et des données caractéristiques du code de décision (38), figurant dans le code de décision (38), et la comparaison, par le composant logiciel (92) du code de décision (38), entre une donnée dont la valeur indique le nombre de types de plateformes d'exécution modulaire (14), figurant dans l'en-tête (85) du code intermédiaire (80), et un nombre maximal de plateformes d'exécution modulaire (14) aptes à être traitées par le code de décision (38) au cours d'une durée maximale d'interprétation de la requête d'initialisation, le nombre maximal de plateformes d'exécution modulaire (14) figurant dans le code de décision (38).35
17. 17.- Procédé selon la revendication l'une des revendications 13 à 16, caractérisé en ce que les données opérationnelles (53) relatives à la plateforme d'exécution modulaire (14) comprennent une pluralité de paramètres temporels élémentaires (75), chaque paramètre temporel élémentaire (75) indiquant la durée maximale de lecture, d'interprétation, et d'exécution d'une instruction (72) du macro-code (48) sur la plateforme (14), et en ce que l'étape (100) de génération du code intermédiaire (80) comprend une sous-étape (100A) de pré-compilation du code source (46) au cours de laquelle le nombre maximal d'exécutions de chaque instruction (72) du macro-code (48) lors d'une unique exécution dudit macro-code (48) est mémorisé dans le dispositif électronique (12), le calcul (100B) du paramètre temporel général (56) étant effectué à partir de ce nombre maximal d'exécutions et desdits paramètres temporels élémentaires (75).