Brevet FR2801118A1 — publié le 20010518

présente invention concerne un procédé de chargement d'applications dans un système embarqué multi-application muni de ressources de traitement de données, le système embarqué correspondant, et le procédé d'exécution d'une application d'un système embarqué correspondant. présente invention concerne plus particulière la réalisation de pare- entre modules partageant le même espace mémoire dans des systèmes embarqués sur des objets portables multi-application utilisant un pseudocode intermédiaire et une machine virtuelle associée. technologie "Java" (marque déposée) introduite par la sociéte "Sun" basée sur un langage de programmation orienté objet "Java" une machine virtuelle associée. Cette technologie a été développée sur stations PC (Personal Computer), appelées ci-après plate-forme "Java" classique, possédant une puissance CPU et une mémoire importante l'ordre méga byte ou mégaoctet. Depuis quelques années, les concepts de la technologie "Java" été repris et adaptés pour f@hctionner sur des systèmes embarqués dans des objets portables, par exemple au format de carte de crédit micromodule SIM incorporant un microprocesseur et appelée communément carte ' puce, ou encore de téléphones portables GSM (Global System Mobile Communication), cartes PCMCIA ou tous autres terminaux portables. Par la suite nous utiliserons le terme carte pour désigner l'un quelconque ces objets portables. La programmation des systèmes embarqués, jusqu ici réalisée en assembleur, est désormais possible dans un langage évolué comme "Java", et permet de faciliter et d'accélérer le développement d'applications clientes. Ce nouveau type de plate-forme spécifique aux systèmes embarqués d'un objet portable, appelé ci-après plate-forme spécifique, constitue un sous-ensemble de la plate-forme classique. Les différences resultent du fait de l'environnement réduit des systèmes embarqués. De manière classique, tel que représenté à la figure 4a, une carte à puce (10) comprend un système d'entrée et de sortie (11) relié au microprocesseur 4), une mémoire volatile RAM (12) (Random Access Memory) une mémoire non volatile constituée par une mémoire morte ROM (1 (Read Only Memory) et une mémoire non volatile programmable (15) constituée d'une flash RAM ou EEPROM (Electrically Erasable Programmable Read Only Memory). L'ensemble de ces éléments est relié au microprocesseur par BUS de liaison. A titre d'exemple, une carte à puce comprend dans le meilleurs des cas, en utilisant les nouveaux composants actuellement existants, une mémoire ROM, une mémoire EEPROM de 32 kilooctets ou kilo bytes, et une mémoire RAM de 2 Kilo Bytes. Dans un système "Java" classique, une application est ecrite sur une station ou PC. Son code source est compilé dans un pseudocode intermédiaire, appelé "Java Byte Code" ou byte code, qui est independant code machine de la plate-forme utilisée. L'application ensuite teléchargée sur la plate-forme cible ou plate-forme "Java" classique. L'application chargée, constituée d'un ensemble de classes dites classes clients dont les méthodes ont été compilées dans le pseudocode, s'appuie les interfaces de programmation applicatives ou Interface pour la Programmation d'Application ou API (Application Programming Interface). Les interfaces de programmation applicatives permettent d'uniformiser l'interface utilisateur, de contrôler un éditeur, un clavier ou une imprimante exemple. La machine virtuelle d'une plate-forme classique comprend un verifieur de pseudocode, un chargeur dynamique de classe, un interpréteur pseudocode qui permet la traduction en code machine et un gestionnaire sécurité. La principale différence entre une machine virtuelle classique et une machine virtuelle d'un système embarqué, appelée machine virtuelle spécifique, est due au fait que la machine virtuelle d'un système embarqué est décomposée en deux parties séparées. Suivant la figure 4b, la machine virtuelle comprend une partie (30) hors de la plate-forme spécifique (40), appelée machine virtuelle hors plate-forme ("off-platform"), comprenant un convertisseur (32), et une partie (41) dans la carte constituant la plate-forme spécifique (40), appelée machine virtuelle embarquée (41) ("on-platform") incluant l'interpréteur de pseudocode. Ainsi, dans le cas d'une plate-forme spécifique, le programme source (21 de l'application est écrit, compilé en pseudocode intermédiaire par un compilateur (22), et vérifié par un vérifieur (31) de pseudocode intermédiaire sur une station (20) classique, puis converti par le convertisseur (32), placé sur la même station (20) ou une autre station. Après un eventuel passage par un signeur (34), l'application est ensuite téléchargée sur la mémoire volatile programmable électriquement et éventuellement effaçable électriquement EEPROM (15) de l'objet portable ou plate-forme spécifique (40). Ce chargement est effectué un chargeur comportant une partie hors plate-forme appelée téléchargeur (33) et une partie sur plate-forme spécifique appelée chargeur (42). Contrairement à ce qui existe sur une plate-forme classique pour une station la machine virtuelle (41) d'une plate-forme spécifique (40), placée memoire ROM avec le système d'exploitation (48) (Operating System) ne peut comporter de vérifieur de pseudocode intermédiaire, celui-ci étant trop lourd pour être stocké et/ou exécuté dans l'objet portable. La plate-forme spécifique (40) ne contient pas non plus de chargeur dynamique de classes. effet, pour le domaine d'application de l'invention, sur la machine virtuelle (30) hors plate- forme, le vérifieur (31) vérifie que les classes compilées sont bien formées et vérifie les violations de langage spécifiques à la description de la plate- forme spécifique. Le convertisseur (32) effectue le travail requis pour le chargement des classes et la résolution des références. convertisseur effectue la liaison statique des classes, il résout les références symboliques aux classes, méthodes et attributs déjà présents sur la carte. II répartit le stockage et crée les structures des données pour représenter les classes, crée les méthodes et attributs statiques ou natifs et initialise les variables statiques. L'environnement d'exécution de la plate-forme spécifique (Runtime Environment ou RE) comprend la machine virtuelle embarques ("on- platform") (41) se limitant à un interpréteur, une plate-forme et les méthodes dites natives (43) ou encore statiques associées. La plate-forme API comprend les API (44) (Application Programming Interface) definissant un ensemble de classes, dites classes système (45), et les conventions d'appel par lesquelles une application accède à l'environnement d'exécution (RE) aux méthodes statiques (43). Les méthodes statiques (43) exécutent les services d'allocation de mémoire, d'entrée et sortie, et cryptographique de la L'interpréteur de la machine virtuelle embarquée de la (41)(on- platform), de support au langage "Java", et lit de façon sequentielle le pseudocode intermédiaire, instruction par instruction. Chaque instruction standard de ce pseudocode intermédiaire est interprétée dans langage du microprocesseur par l'interpréteur puis exécutée par le microprocesseur. En règle générale, les instructions standards du pseudocode intermédiaire permettent de traiter des fonctions évoluées telle que le traitement arithmétique et la manipulations d'objets. La notion d'objet concerne les objets informatiques tels qué listes, tableaux de données ou analogues. Les classes dites clients (46) des applications et les classes systèmes (45) des API sont toutes chargées dans le même espace mémoire et sont gérées par l'intermédiaire d'une table de classe (47). La machine virtuelle (41) est également chargée de gérer les classes et objets et de faire respecter les séparations ou pare-feu entre les applications afin de permettre un partage sécurisé des données, appelées également attributs, variables ou champs (fields). Dans le cas d'un objet portable de type carte à puce, une application d'une plate-forme spécifique peut être activée directement l'environnement d'exécution (RE) lorsqu'une APDU (Application Protocol Data Unit) sélection émise par un service ou terminal est reçue carte. Afin restreindre l'accès aux données entre les parties partageant même espace mémoire, une des méthodes classiques sur une plate-forme classique est basée sur la restriction explicite de visibilité déclarée dans le code source. Suivant la figure 4c, les méthodes (NM1 NM2), respectivement (NM3, NM4), et les attributs (NA1, respectivement (NA3, NA4) sont encapsulées dans des classes (NC13), respectivement (NC12), qyi elles-mêmes font partie de paquetages (Paquetage ), respectivement (Paquetage n) regroupant chacun plusieurs classes. classe peut être publique telle que (NC11 ou NC12) ou privée telle que (NC13) par rapport à un paquetage, ce qui implique, dans le dernier cas, que seules les classes du même paquetage peuvent accéder à cette classe. méthodes (exemple NM2) et les données (exemple NA1) d'une classe (NC13) peuvent être privées par rapport à la classe (NM2, NA1), elle-même privée par rapport au paquetage (Paquetage 1), ou publiques par rapport au paquetage (par exemple NM1, NA2) ou à la classe (par exemple NM4, NA4). Cette restriction de la visibilité permet d'obtenir un accès flexible entre les différents ensembles de paquetages (Paquetage 1, Paquetage n) stockés dans le même espace nom, mais présente quelques inconvénients. La plate-forme classique ou spécifique supporte mal la notion de sous-paquetages. Les classes client d'une application de grande taille doivent être réparties entre différents sous-paquetages qui représentent uniquement pour la machine virtuelle des paquetages différents. Pour partager les ressources entre ces sous-paquetages, ces ressources sont nécessairement déclarées publiques, les rendant ainsi visibles de tout autre paquetage. II est ainsi difficile d'organiser de façon claire le paquetage d'applications différentes pour des applications de grande taille et d'obtenir des pare-feu entre applications. Dans le cas la plate-forme classique, sur une station, le respect de la confidentialité ressources, telle que déclarée dans les programmes sources, repose vérifications dynamiques. Pour effectuer ces vérifications dynamiques, la machine virtuelle doit posséder toutes les informations concernant déclarations de restriction d'accès pour chaque classe, méthode attribut, ce qui ne peut être possible dans le cas de l'espace mémoire disponible sur la machine virtuelle embarquée (onplatform) utilisant pseudocode intermédiaire ou byte code prélié de la machine virtuelle hors plate-forme (offplatform). Dans le cas d'une plate- forme spécifique objçt portable, les restrictions d'accès peuvent se vérifier statiquement lors de la compilation et peuvent être vérifiées à nouveau par le vérifieur de la partie hors plate-forme. II est en effet supposé que ce qui est charge sur la plate-forme spécifique de l'objet portable est correct, car aucune vérification ne peut être effectuée sur la plate-forme spécifique du fait la perte des informations lors de la phase de conversion. De plus n'est pas garanti qu'un paquetage ne puisse pas être étendu ou modifié de nouvelles classes venant de sources étrangères, ce qui peut détruire toute la sécurité basée sur l'utilisation de paquetages privés. Le deuxième moyen procuré par la machine virtuelle d'une plate- forme classique est la notion de séparation des espaces nom. Avec le schéma de liaison dynamique d'une plate-forme classique, les classes peuvent être chargées, à partir de répertoires du système de fichier local, appelé "CIassPath" préalablement déclaré comme constituant l'emplacement des classes systèmes forant la plate-forme API standard, ou à partir d'autres répertoires du système de fichier local ou de serveurs éloignés. Les classes client d'une application, extérieures au "CIassPath", doivent être chargées par un chargeur de classe spécifiquement programmé. Cette caractéristique est particulièrement utilisée pour le chargement des applications "Java" par navigateurs habilités "Java". Ainsi, les applications venant de différentes sources, sont chargées par des chargeurs de classes différents. Pour chaque localisateur, communément appelé URL (Uniform Resource Locator), une instance spécifique de classe "chargeur de classe d'application" est utilisée. Le nom externe d'une classe est l'assemblage + . Quand une classe est chargée, elle est stockée dans une table de classe interne, et une référence relative au chargeur de classe utilisé pour charger cette classe est ajoutée en préfixe du nom de paquetage de la classe. Le nom de la classe est alors Référence du Chargeur de Classe> + + Lors de la résolution d'une référence, la politique habituelle des chargeurs de classe est de rechercher d'abord dans les classes système et en cas d'échec, de rechercher parmi les fichiers de classe présents à l'emplacement où le charger peut charger les classes. Selon ce principe de fonctionnement du chargeur, une application ne peut directement accéder aux classes clients d'une autre application chargée par un chargeur de classes différent. Une application peut accéder à toutes les ressources publiques des classes publiques du CIassPath, mais les classes du CIassPath ne peuvent accéder directement aux classes d'une application bien qu'elles puissent faire référence à des instances de classes clients de l'application en les convertissant en un type public défini dans le "Classpath". Une application ne peut étendre ou modifier des paquetages de classes système du Classpath ou de toutes autres applications chargées par des chargeurs de classes' différents. L'utilisation de la séparation des espaces nom en insérant . référence du chargeur de classe dans le nom de la classe, ajoutée au typage complet fourni par le langage "Java", permet de procurer un pare-feu efficace entre les applications. Le mécanisme inné de séparation de nom d'espace permet facilement le chargement nouvelles applications. Les applications peuvent échanger des objets l'entremise des classes spécifiquement programmées à cette fin localisees dans le "Classpath". Une application peut utiliser un objet venant d'une autre application chargée par un chargeur de classe différent, si objet peut être changé en un type public défini dans le "Classpath". Malheureusement ce mécanisme de séparation de nom, basé une machine virtuelle classique et son processus de liaison dynamique peut être effectué sur une plate-forme spécifique. La liaison dynamique peut être effectuée par la machine virtuelle d'une plate forme spécifique, celle ' nécessitant un espace mémoire permettant le stockage de fichier de classe d'une plate-forme "Java" classique, présentant des références non résolues. Dans une plate-forme spécifique, les classes systèmes des API et les classes clients des applications ne sont pas isolées dans des espaces de nommage particuliers. L'objet de la présente invention est de proposer une solution procurant les avantages de la séparation de nom dans le cadre de systèmes embarqués possédant une machine virtuelle en deux parties, le schéma liaison statique étant effectué par la partie hors plate-forme. Dans le contexte de systèmes embarqués, tels que par exemple terminaux de paiement; mult-application, il est nécessaire d'avoir des pare- feu performants entre les applications "Java" fournies par différentes sources, telles que différents systèmes de paiement (Visa, Mastercard...). peut etre utile de permettre une coopération flexible entre les applications venant des différentes sources. Le système embarqué doit aussi être facilement mis à jour en téléchargeant de nouvelles applications ou nouveaux modules utilitaires ou encore des mises à jour sans perturber applications déjà chargées. Un premier but de l'invention est de proposer un procédé chargement permettant d'obtenir des pare-feu robustes entre applications tout en autorisant une coopération entre les applications et possibilité de faire évoluer les applications ou de charger d'autres applications. but est atteint par le fait que le procédé de chargement d'applications sur un système embarqué selon l'invention comprenant un environnement d'exécution incluant une machine virtuelle comprenant un interpréteur de langage de type pseudocode intermédiaire, interfaces de programmation d'application (API), à partir d'une station laquelle le code source l'application est écrit, compilé en pseudocode par un compilateur, vérifié un vérificateur, converti par un convertisseur et chargé par un chargeur, caractérise en ce que - la conversion comprend la réalisation de la liaison statique d'une pluralité d'ensembles de paquetages destinés à être stockés dans le même espace nom sur le système embarqué, appelés modules, en attribuant un identificateur à chaque module (MID), et un numéro de référence à chaque classe, à chaque méthode et à chaque attribut encapsulés dans les classes i du module, - la référence à une méthode ou un attribut, dans le pseudocode lié d'un module, étant codée sur trois multiplets constitués par un indicateur indiquant la référence à une classe interne ou externe au module, le numéro de la classe et soit le numéro de la méthode soit le numéro de l'attribut, - les modules chargés sont un ou plusieurs modules d'interface de programmation d'application, appelé Module API, comprenant des classes système ou des modules de services correspondant chacun à une application, une référence :à une classe externe étant systématiquement interprétée par la machine ,virtuelle comme une référence à un module d'interface de programmation d'application. Selon une autre pârticularité, le chargement des modules sur le système embarqué comprend la mémorisation d'une part d'au moins un tableau représentation des modules, le numéro associé, par le lieur compris entre 0 et n, à un module constituant l'index dudit module dans le tableau, et d'autre part d'une table mémorisant l'association de l'index du tableau de représentation à l'identificateur (MID) dudit module, ledit tableau et la table étant en mémoire programmable non volatile, une référence externe à un module externe dans le pseudocode étant interprétée par l'interpréteur de la machine virtuelle comme constituant un index d'accès au module équivalent à celui du tableau des modules. Selon une autre particularité, le chargement comprend la mémorisation, pour chaque module, d'un tableau de représentation ses classes, comprenant une référence à l'index de son module et, pour chaque classe, un tableau de représentation des attributs et des méthodes. Selon une autre particularité, les modules sont référencés dans un tableau de modules unique, les classes système sont contenues dans un module API unique, toute référence à une classe externe dans le pseudocode différente de n sera interprétée par la machine virtuelle comme référence audit module@Pl. Selon une autre particularité, les classes étant déclarées publiques, en paquetage privé, les attributs et méthodes étant déclarés protégés, en paquetage privée ou en classe privée, la numérotation des classes s'effectue suivant l'ordre classes publiques puis classes en paquetages privés, la numérotation des attributs ou méthodes est effectuée le convertisseur suivant l'ordre attribut ou méthode public, protégé, en paquetage privé et en classe privée. Selon une autre particularité, les classes système sont contenues dans plusieurs modules API chargeables séparément, le chargeur maintient dans la mémoire non volatité programmable deux tableaux de représentation modules et deux tables d'association MIDIIMi correspondantes, l'un pour modules API et l'autre pour les modules non-API, le chargeur chargeant modules dans l'un des deux tableaux selon la nature du module spécifié dans l'entête de celui-ci, toute référence externe d'un module du tableau de module étant interprétée comme une référence à l'index du module API. Selon une autre particularité, la liaison statique d'un module est effectuée de telle sorte que la référence à une classe externe à un module non API dans pseudocode intermédiaire est un index dans un tableau de l'entête du module, dont chaque entrée est un identificateur (MID) d'un module API référencé, le chargement dudit module sur la plate-forme cible comprenant le remplacement de ladite référence par le numéro de l'index du module obtenu à partir de l'identificateur (MID) de la table d'association modules API. Un autre but de l'invention est de proposer un système embarqué correspondant. Ce est atteint par le fait que le système embarqué selon l'invention, comprenant une machine virtuelle et une plate-forme API incluant interfaces de programmation d'application, une mémoire non volatile fixe, une mémoire non volatile programmable ou modifiable, et une mémoire vive, se caractérise en ce que la mémoire non volatile programmable comprend au moins un module API comprenant des classes système et des modules de services, au moins un tableau de représentation des modules, dans lequel les modules sont indexés et une table associant l'index d'un module du tableau de représentation à l'identificateur dudit module, chaque module comprenant un tableau de représentation classes, dans lequel les classes sont indexées et dans lequel chaque classe présente une référence à l'index de son module, chaque classe comprenant un tableau de représentation des attributs et des méthodes, dans lesquels les attributs et méthodes sont indexés, la référence à une méthode ou attribut étant codée sur au moins trois multiplets correspondant à référence à une classe interne ou externe au module, une référence externe au module constituant l'index du module API dans le tableau de module, numéro de classe correspondant à l'index de la classe dans la table de représentation des classes du module, et un numéro de méthode ou d'attribut correspondant à l'index de la méthode ou de l'attribut dans tableau de représentation des méthodes ou attributs de la classe du module. Selon une autre pdrticularité, le système embarqué comporte moyens de comparaison du premier multiplet des trois multiplets de codage de référence à une méthode ou à un attribut avec une valeur déterminée n pour décider s'agit d'une classe interne ou externe. Selon autre particularité, le système embarqué comprend un module principal comprenant le programme principal du système. Selon une autre particularité, les classes sont indexées suivant l'ordre classes publiques puis classes en paquetages privés, et les attributs ou méthodes suivant l'ordre attribut ou méthode public, protégé, en paquetage prive et en classe privée. Selon autre particularité, la mémoire non volatile programmable comprend plusieurs modules API comprenant des classes système, deux tableaux de représentation des modules, l'un pour les modules API et l'autre pour les modules non-API et le module principal, et deux tables d'association MIDIIMi correspondant chacune à un tableau de représentation modules., Selon autre particularité, le système embarqué comprend une classe gestionnaire d'accès "Access manager" d'un module API comprenant une méthode permettant de créer une instance d'un module de service, par l'intermédiaire module principal, ladite classe présentant une protection lui interdisant d'avoir plus d'une instance. Un autre but de l'invention est de proposer un procédé d'exécution d'une application présente sur un système embarqué multi-application. Ce est atteint par le fait que le procédé d'exécution d'une application d'un système embarqué multi-application, comprenant un environnement d'exécution incluant une machine virtuelle comprenant un interpréteur de langage de type pseudocode intermédiaire, et des interfaces de programmation d'applications (API), se caractérise en ce que, lors de l'exécution pseudocoâe intermédiaire d'un module de service, correspondant une application, référencée dans un tableau de module, la référence à méthode ou un attribut dans le pseudocode, codée sur au moins trois multiplets correspondant à une référence à une classe interne ou externe au module, un numéro de classe et un numéro de méthode ou d'attribut, une référence externe au module est interprétée par la machine virtuelle comme une référence à l'index d'un module API du tableau du ou des modules API. Selon une autre particularité, sur réception d'une demande d'exécution d'un module de service présentant un identificateur, l'environnement d'exécution accède à la classe d'entrée module principal comprenant le programme principal du système, le module principal installe une instance d'une classe spéciale "Access Manager", module gérant l'accès à un module de service et utilise une méthode de cette classe permettant de créer une instance de la classe d'entrée module de service demandée, par l'intermédiaire d'une table d'association de l'identificateur à l'index du module dans un tableau dans lequel le module référencé, l'instance étant retournée par la méthode au programme principal. D'autres particularités et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ci-après faite en reférence aux dessins annexés dans lesquels - la figure 1 représente de façon schématique les différents éléments necessaires pour le chargement d'un objet portable selon un premier mode réalisation; - la figure 2 représente de façon schématique les différents éléments necessaires pour le chargement d'un objet portable selon un deuxième mode de réalisation ; s - la figure 3 représente la représentation interne d'un module ; - la figure 4a représente le schéma classique d'une carte à puce ; - la figure 4b représente le système nécessaire à constitution d'une machine virtuelle embarquée sur une carte à puce selon antérieur; - la figure 4c représente la structure des classes d'une application. Le procédé sera décrit, en liaison avec les figures 1 à de manière non limitative, dans le cas de la mise en oeuvre de l'invention dans un système embarqué, par exemple de type spécifique constitué par une carte à ou un objet portable similaire. La désignation byte ou programme de type byte code recouvre tout pseudocode ou programme intermédiaire. L'objet portable constitue par exemple une carte à puce et présente une structure similaire de celle décrite précédemment en référence aux figures 4a et 4b, et comprend notamment une mémoire RAM, et EEPROM. La plate-forme spécifique (60) et une station classique (80) sont représentées sur la figure 1. La plate-forme spécifique (60) possédé en environnement d'exécution (RE) comprenant des API (62) une machine virtuelle (61) embarquée ("onplatform"). La plate-forme spécifique (60) est représentée sur la figure 1, comme comprenant l'ensemble des mémoires ROM et EEPROM. II est à noter que la plate-forme spécifique (60) désigne plus particulièrement l'environnement d'exécution (RE) les éléments présents en mémoire EEPROM. L'objet portable possède en ROM un systeme d'exploitation (Operating System) (63). Les API (62), présentes en mémoire ROM, constituent les API de base de la plate-forme API, chargées avec la machine virtuelle embarquée pour le fonctionnement de celle-ci partie (90) hors objet portable de la machine virtuelle comprend un vérifieur (91) de pseudocode intermédiaire, un convertisseur (92) et éventuellement un signeur (94). Le signeur délivre une signature pour valider passage par le vérifieur et le convertisseur. Cette signature sera vérifiée l'objet portable au moment du chargement. Le chargement en EEPROM d'applications ou de nouvelles API pour compléter les API de base s'effectue un chargeur qui peut être composé de deux parties, une partie hors objet portable pouvant être installée dans la machine virtuelle hors objet portable (90), appelée téléchargeur (93), et une partie sur la plate- forme spécifique, appelée@chargeur (68). Selon un premier mode de réalisation, la plate-forme spécifique (60) comprend deux modules spéciaux, un module API (65) et un module principal (66). Les autres modules sont appelés modules de services (67). Chaque module correspond à un ensemble de paquetages qui sera stocké dans le même espace nom. La plate forme API désigne les API de base (62) et l'ensemble des classes système qui définissent le module API (65) ou module de la plate-forme .API. Le module principal comprend la classe principale définissant le programme principal. Chaque module excepté le module API (65), possède une classe unique, particulière, appelée "Entry Class", constitue le point d'accès au module. Pour le module principal, cette "Entry Class" est la classe principale (CP), celle qui contient une méthode statique appelée "main". Pour les modules de services, c'est une classe avec seulement un constructeur sans paramètres et implémentant une interface publique spéciale, appelée "service" définie dans la plate- forme Le chargement d'une application correspond au chargement d'un module de service. Chaque module reçoit un identificateur spécifique. Un tel identificateur, qui est appelé MID, peut par exemple être un nombre, une chaîne de caractères, ou un tableau. A titre d'exemple, l'identificateur est une chaîne de caractères. Quand ils sont chargés dans la plate-forme, par des mécanismes de téléchargement distincts de la machine virtuelle de la plate-forme spécifique, les modules reçoivent un nombre, compris entre 0 et n. Ainsi, selon cette convention, n+1 modules au plus peuvent être présents sur plate-forme spécifique. Le téléchargeur (93) de module avec le chargeur (68) maintient, lors du chargement de nouveaux modules de service, un tableau (TRM) (69) de représentation des modules. Le numéro associé à un module est l'index (1M) de ce module dans le tableau. Le chargeur (68) maintient également une table (70) associant l'index (1M) à l'identificateur (MID) de chaque module. Le module API reçoit systématiquement pour index IMo le numéro 0, et le module principal pour -index IMi le numéro 1. L'entête (header) de chaque module comprend un indicateur permettant au chargeur de déterminer la nature du module, "principal", modules "de service" ou module "API". Le chargeur (68) ne peut charger que les modules autorisés à résider sur l'objet portable, c'est à dire uniquement les modules présentant une signature connue de l'objet portable. Le chargeur (68) comporte donc des moyens vérifier la signature d'un module reçu, de la comparer avec la signature connue de l'objet portable et en cas de comparaison négative de bloquer chargement. De manière classique, tel que défini dans l'art anterieur cité précédemment, le programme source (81) d'une application écrit puis compilé un compilateur (82) et ensuite vérifié par le vérifieur ). liaison statique, réalisée dans le convertisseur (92) par un composant dit lieur (linker) du convertisseur, va résoudre des reférences symboliques en attribuant - numéro (NCI) à chaque classe d'un module, - numéro (NM) pour chaque méthode dans une classe - numéro (NA) pour chaque attribut dans une classe. Chacun de ces numéros (NCI, NM, NA) est compris entre 0 et n et peut ainsi être représenté sur un byte ou multiplet. A titre d'exemple, chacun de ces nombres sera compris entre 0 et 255 (n=255). La référence à une méthode un attribut d'une classe sera ainsi codée dans le pseudocode lié des méthodes du module sur deux multiplets (bytes) ou octets. Le pseudocode contiendra ces deux multiplets pour la classe et pour un attribut ou pour une méthode. Suivant la figure 3, la représentation interne d'un module API (65), d'un module principal (66) ou d'un module de service (67), contiendra un tableau (TRC) de représentation de classes; le numéro (NCI) associé par le lieur, hors du système embarqué, à chaque classe est l'index (ICi) de la représentation de cette classe dans le tableau (TRC). Chaque classe présente également une référence à l'index (M) de son module. De la même manière, la représentation de chaque classe contient un tableau des représentations de méthodes (TRMe) et un tableau de représentation des attributs (TRA) appartenant à la classe. Le numéro (NM), associé par le lieur, hors du système embarqué, à chaque méthode est l'index (M), de la représentation de cette méthode dans le tableau (TRMe), et le numéro (NA), associe par le lieur, hors du système embarqué, à chaque attribut est l'index (IAi), la représentation de cet attribut dans le tableau (TRA). titre d'exemple, nous voulons qu'un module puisse référer uniquement à ses propres classes et aux classes systèmes de la plate-forme API, classes système correspondant aux classes du "CIassPath" d'une plate-forme classique. Selon l'invention, pour permettre la distinction entre une référence à une classe interne au module et la reférence à une classe système (ou externe au module), un indicateur interne 1) ou externe (1E) est ajouté à la référence à une méthode ou à un attribut. référence résolue est alors codée sur trois multiplets : Selon une convention posée, pour la valeur n premier multiplet la valeur 255 d'après notre exemple, correspond à une référence interne au module et toute autre valeur pour premier multiplet correspond à une référence externe au module. Le lieur du convertisseur (92) de la machine virtuelle hors objet portable (90), relie en premier le module API (65), qui ne possède pas de références externes dans son pseudocode, et produit une implantation ou agencement, correspondant à un plan de noms symboliques de ses classes et de leurs méthodes et attributs. Lors de la mise en liaison des autres modules, cette implantation sera utilisée pour établir les références externes à des classes systèmes du module API (65). Suivant notre convention des multiplets (bytes) encodant les références, il peut y avoir au plus 256 (n+1) classes dans le module API et 256 classes dans chaque module supplémentaire. Lors de l'exécution d'un module de service, quand la machine virtuelle (61) trouve une référence à une méthode ou un attribut dans le pseudocode, en connaissant la classe où se trouve cette référence, elle peut retrouver directement l'index module concerné, celui-ci correspondant à la référence externe (1E) ou interne (11). Toute référence externe dans le pseudo code d'un module de service sera systématiquement interprétée par la machine virtuelle comme une référence au module API. Un module de service ou le module principal ne peut référer aux classes de tout autre module excepté celles du module API. classes systèmes de ce module API ne peuvent pas référer aux classes module de service ou du module principal. La référence interne à une classe module, correspondant à la valeur n pour le premier multiplet, nécessite aucune connaissance a priori de l'espace nom qui sera attribue module. Le fait de ne pas définir a priori d'espace de nommage fixe lors phase de conversion permet d'accélérer la résolution des références déterminer l'espace de nommage d'un module lors du chargement, postérieurement à la phase de conversion. La machine virtuelle, lors l'interprétation d'une référence à un attribut ou à une méthode dans pseudocode, utilise les trois index ou en cascade. L'espace mémoire du module étant déterminé, l'index détermine l'entrée désirée dans le tableau des classes (TRM) module, puis le dernier index ou donne l'entrée désirée dans tableau des méthodes (TRMe) ou le tableau des attributs (TRA). Le module API comprend une classe spéciale (64), appelée classe gestionnaire d'accès" ou "Access Manager", qui comprend une méthode native (getServicelnstance).dont le rôle est de rendre un objet instance la classe d'entrée du module de service demandé, à partir de l'identificateur (MID) du module. Cette méthode utilise la table (70) d'association MIDllmi pour connaître l'index du module demandé dans le tableau de module (69) puis crée une instance de la classe d'entrée de ce module, instance qui retournée par la méthode. Selon l'invention la classe "Access Manager" (64) est protégée par construction par une méthode consistant à interdire cette classe ait plus d'une instance. Cette méthode (getServicelnstance) appartient au programme principal contenu dans le module principal. module principal qui sera activé en premier à utilisation de l'objet portable crée une instance et une seule de la classe "Access Manager", ce qui lui permet d'utiliser la méthode getServicelnstance, mais interdit à tout autre service créer une autre instance pour utiliser cette méthode. fonctionnement, de la même façon que sur une plate-forme classique, l'environnement d'exécution (RE) accède à la classe d'entrée (EC) du module principal ef active sa méthode d'entree (main). Le module principal, etant le premier activé, procède à l'installation d'une instance de la classe "Access manager" avant que tout autre service fasse, puisque pour activer d'autres services, le module principal doit déja posséder une telle instance la classe accès. simple dispositif permet de reproduire l'effet de protection lié au concept d'espace de nommage d'une plate-forme classique. Le simple fait de charger un module de service dans le tableau modules et que la présence dans le pseudocode de toutes référence externe soit interprétée par la machine virtuelle comme une référence au module API, rend ce module complètement inaccessible directement par autres modules, créant ainsi un pare-feu total. premier mode de réalisation permet d'apporter les avantages de pare- procuré par la séparation des espaces nom dans le contexte d'une machine virtuelle en deux parties. Toutefois ce mode de réalisation se révèle peu flexible et présente deux inconvénients. Premièrement, il empêche toute modification ou extension des classes systèmes avec des modules déjà préliés. architecture "Java" classique permet de modifier et d'étendre les classes la plate-forme API sans avoir d'impact sur les classes déjà compilées de modules supplémentaires. Mais dans le mode de réalisation decrit précédemment, toute modification des classes système, même invisible pour des modules étrangers, modifierait l'agencement de la plate-forme et nécessiterait de modifier le pseudocode prélié de chaque module déja lié avec une version antérieure de l'agencement et en conséquence l'interpréteur. Deuxièmement, les modules préliés sont supposés être portables entre les différentes plates-formes ou terminaux embarqués, ce impose que chacune de ces plates-formes doit avoir le même agencement que la plate-forme API, ce qui interdit l'utilisation de toute extension proprietaire. Afin de remédier partiellement à ces inconvénients, une variante du premier mode de réalisation, consiste à imposer que, dans la numérotation de l'implantation, les classes publiques viennent en premier avant les classes en paquetage privé. De plus, les méthodes publiques ou attributs publics viennent avant ceux qui sont protégés et ceux sont en paquetages privés et en classes privées. Ceci permet d'ajouter librement de nouvelles classes publiques dans le module API (65). La figure 2 représente un deuxième mode de réalisation permettant l'évolution de la plate-forme API. La plate-forme API est constituée de plusieurs modules API (100) pouvant être chargés séparément, au lieu d'être constituée d'un module API unique. Dans ce mode de réalisation, le téléchargeur (93) et machine virtuelle partagent deux tableaux de modules et deux tables d'association MIDlindex au lieu d'un de chaque, un tableau (101) et table d'association (102) pour les modules API et un tableau (103) et table d'association (104) pour les modules non-API, correspondant au module de service (67) et au module principal (66). Chaque module présente dans son entête un indicateur indiquant sa nature "Service" ou "API" permettant au chargeur de charger le module dans le tableau (101) de modules API ou dans le tableau (103) de modules non- API. indicateur est placé dans l'entête du module lors de phase de compilation par le convertisseur. pare-feu constitué par la séparation de l'espace nom présent uniquement entre les modules non-API. Toute référence externe à un module service sera interprétée par l'interpréteur de la machine virtuelle embarquee comme un index du tableau du module API. Les modules non-API seront numérotés de jusqu'à 255 au plus, dans l'exemple où n=255.0 est par exemple l'index module principal (66). Les modules API (100) seront numérotés de 0 à au plus, 0 étant par exemple l'index d'un module dit API primaire, contient toutes les méthodes natives. Conformément à la convention decrite précédemment, ceci permet au plus, 255 (n) modules différents dans plate-forme API. La référence à une méthode ou attribut dans le pseudocode est IEIII> Après réalisation de la liaison par le lieur (92) hors plate-forme, le pseudocode module comporte une entête présentant un tableau de modules référencés utilisé pour lier le module courant. Ce tableau de modules réferencés comprend au plus 255 entrées, chaque entrée correspondant à l'identificateur (MID) d'un module API (100). Le premier multiplet (byte) d'une référence externe dans le pseudocode sera alors un index dans ce tableau. Lors du chargement sur la plate-forme d'un module non API (67, 66), les numéros d'index associés à des modules API (100) seront connus et ainsi chaque premier octet d'une référence externe sera remplacé par le numéro d'index associé au module API référé en utilisant la table (102) d'association MIDIIMi des modules API (1 Ce remplacement est la seule opération de liaison réalisée sur la plate-forme spécifique, par le chargeur (68), la table (102) d'association MIDIIMi étant utilisée uniquement pour réaliser cette opération de liaison. A titre d'exemple, supposons que dans le pseudocode d'un module de service "TEST", nous avons la référence à un numero de méthode 5 du numéro de classe 7 d'un module API dont l'identificateur (MID) est "F00". Supposons plus que "Fb0" est l'identificateur du quatrième module API externe trouve référencé dans le module de service "TEST". La référence dans le pseudocode est alors constituée par les trois valeurs suivantes : 3, 7, Le numéro 3 correspond au quatrième index dans le tableau modules référencés présent dans l'entête du module, venant en tête du pseudocode, la valeur de cette entrée étant l'identificateur (MID) "F00". Supposons que lors du chargement du module API "F00, l'index interne 34 lui été attribué sur la plate-forme cible dans la table d'association (102) des modules API. Alors,.,lé*chargeur (68), à l'aide de la table d'association (1 modifie la référence dans le pseudocode du module de service "TEST' pour devenir: 34, 7, 5 Lors de l'exécution du pseudocode d'un module, une référence externe au module est systématiquement interprétée par la machine virtuelle comme une entrée dans la table de module API. Les modules du tableau de module non API restent invisibles les uns des autres ainsi que par rapport modules API. Ce simple dispositif permet de reproduire l'effet de protection lié au concept d'espace de nommage d'une plate-forme classique. simple fait de charger un module dans le tableau de module non API le rend complètement inaccessible directement par les autres modules, créant ainsi un pare-feu total. Le tableau (101) de modules API comprend un module spécifique (1 appelé module "API Access" qui comprend une méthode native (getServicelnstance) dans une classe "gestionnaire d'accès" ou "Access Manager" dont le rôle est de rendre un objet instance de la classe d'entrée du module de service demandé. Cette méthode utilise la table (1 d'association MIDIIMi pour connaître l'index du module de service demande dans le tableau (103) de modules non-API puis crée une instance de la classe d'entrée de ce module qui est retournée par la méthode au programme principal. La politique de sécurité préconisée est de faire de la classe "Access Manager" une classe protégée dont le constructeur et les méthodes sont déclarées protégées. De plus, le module "API Access" (105) comprend une protection consistant à interdire que la classe "Access Manager" plus d'une instance. Cette méthode est réservée au programme principal contenu dans le module principal (66). Le module principal qui activé en premier crée une instance du module Access manager, ce lui permet d'utiliser la méthode getServicelnstance, mais interdit à tout autre service de créer une autre instance pour utiliser cette méthode. Ainsi module principal pourra créer des instances de services. Plusieurs méthodes peuvent être utilisées pour obtenir cette protection consistant à interdire que la classe "Access manager" n'ait qu'une seule instance. constructeur de la classe peut par exemple bloquer la demande de création d'instance lorsqu'il en existe déjà une et lance une exception de sécurité. En fonctionnement, l'environnement d'exécution (RE) accède à la classe d'entrée du module principal (66) et active sa méthode d'entrée (main). Le module' principal étant le premier activé, procède à l'installation d'une instancëa de la classe "Access Manager" du module Access avant que tout autre service le fasse. Afin de permettre à un module de service d'activer un autre module de service, cette politique stricte de sécurité peut être modifiée en ajoutant à la classe "Access Manager" du module API Access (105) des classes publiques permettant à tout module d'y faire des requêtes. Ces requêtes seront traitées et contrôlées par l'unique instance créée par le module principal. classes publiques comprennent notamment une méthode statique permettant d'obtenir l'unique instance. Un module ayant accès à l'objet instance de la classe "Access Manager" pourra activer un autre module de service et l'utiliser, mais il ne pourra pas référencer directement ses classes, méthodes ou ses attributs sans être repéré par la machine virtuelle, étant donné que foute référence externe dans le pseudocode est une référence interne au module ou une référence externe à un module API. Pour réalisation simple de cette solution, il est nécessaire de ne pas avoir de références circulaires parmi les modules API. En conséquence, la fermeture transitive de la relation "réfère à"("refers to") doit être un ordre strict partiel sur un jeu de modules. II est ainsi possible de concevoir dans le lieur du convertisseur (92) une stratégie simple pour lier produire l'agencement des modules API en traitant en premier éléments minimums non encore liés. II est possible de suivre la même strategie basée sur un ordre partiel pour le téléchargement des modules API, telle sorte que lors téléchargement d'un module M, tous les modules auquel il se réfère aient déjà été téléchargés et qu'un numéro leur aient ete assigné. L'assignation de l'index interne sur la plate-forme cible se fait par le chargeur (68) de module en assignant l'index n-1 à l'API d'ordre n. Un module ne peut référer à un autre API module d'index supérieur. L'utilisation de ce système de double tableau de modules 01, 103) et de table d'association (102, 104), permet de remplacer facilement un module unique par plusieurs modules API changeables séparement. Le remplacement d'un module API unique par plusieurs modules permet d'étendre plate-forme API avec de nouveau modules, sans modifier l'assemblage des modules déjà chargés, sans changer la sécurite offerte par les pare Bien entendu, ces deux modes de réalisation ne sont pas compatibles; les modules doivent être préliés spécifiquement pour l'un ou l'autre modes de réalisation, le pseudocode relatif à un des modes de réalisation étant pas portable sur une plate-forme implémentant l'autre mode realisation. De plus, l'interpréteur de la machine virtuelle diffère d'un mode de réalisation à l'autre. Dans le premier mode de réalisation, la machine virtuelle ne manipule qu'un seul tableau et une table d'association le premier multiplet d'une référence sera interprété par la machine virtuelle comme référence interne pour toute valeur égale à n et comme une référence externe à l'unique module API pour toute valeur différente de n. Dans le second mode de réalisation, la machine virtuelle manipule deux tableaux et deux tables d'association : le premier multiplet d'une référence dans le pseudocode sera interprété par la machine virtuelle comme une référence interne au module pour toute valeur égale à n et toute valeur différente de n sera prise" directement comme index dans le tableau de module Dans les deux modes de réalisation l'interpréteur de la machine virtuelle comprend des moyens de comparaison du premier multiplet des trois multiplets de codage d'une référence à une méthode ou à un attribut avec une valeur déterminée n pour décider s'il s'agit d'une classe interne ou externe au module. La numérotation des modules API peut etre déterminée au moment du chargement pour fixer définitivement et manière très simple les reférences externes dans le pseudocode. Les mêmes mécanismes sont utilisés pour manier deux types de modules, bien que la façon dont ils sont utilisés et la securité procurée soient tout à fait différentes. Tout module peut accéder librement aux modules puisque leurs classes sont des classes systeme. L'utilisation de l'approche modulaire est utilisée avec les modules services pour procurer un pare- rigoureux pour'protéger ces modules de tout acces direct. procédé selon l'invention peut être réalisé sur tous types d'objet portable présentant de faibles ressources, tel que par exemple, 16 Ko de mémoire , 8ko de mémoire EEPROM et 256 k de mémoire RAM. D'autres modifications à la portée de l'homme métier font également partie de l'esprit de l'invention. REVENDICATIONS 1. Procédé de chargement d'applications sur un système embarqué comprenant un environnement d'exécution incluant une machine virtuelle comprenant un interpréteur de langage de type pseudocode intermédiaire, des interfaces de programmation d'application (API), à partir d'une station sur laquelle le code source de l'application est écrit, compilé en pseudocode par un compilateur (82), vérifié par un vérificateur (91), converti par un convertisseur (92), et chargé par un chargeur (93, 68), caractérisé en ce que - la conversion comprend la réalisation de la liaison statique d'une pluralité d'ensembles de paquetages destinés à être stockés dans le même espace nom sur le système embarqué, appelés modules, en attribuant un identificateur à chaque module (MID), et un numéro de référence à chaque classe (NCI), à chaque méthode (NM) et à chaque attribut (NA) encapsules dans les classes du module, - référence à une méthode ou un attribut, dans le pseudocode d'un module, étant codée sur trois multiplets constitués par un indicateur indiquant référence à une classe interne (II) ou externe (1E) au module, numéro la classe (NCI) et soit le numéro de la méthode (NM) soit numéro l'attribut (NA), - modules sont un ou plusieurs modules d'interface programmation d'applicatiôfi comprenant des classes système ou des modules de services correspondant chacun à une application, une référence (1E) à une classe externe étant systématiquement interprétée par la machine virtuelle comme une référence à un module d'interface de programmation d'application. 2. Procédé de chargement d'applications sur un système embarqué selon la revendication 1, caractérisé en ce que le chargement des modules sur le systeme embarqué comprend la mémorisation d'une part d'au moins un tableau (69, 101, 103) de représentation des modules, le numéro (IMi) associé, le lieur compris entre 0 et n, à un module constituant l'index dudit module dans le tableau, et d'autre part d'une table 102, 104) mémorisant l'association de l'index du tableau de représentation à l'identificateur (MID) dudit module, ledit tableau et la table étant en mémoire programmable non volatile, une référence externe (1E) à un module externe dans le pseudocode étant interprétée par l'interpréteur machine virtuelle comme constituant un index d'accès au module équivalent à celui tableau des modules. 3. Procédé de chargement d'applications sur un systeme embarqué selon la revendication 2, caractérisé en ce que le chargement comprend la mémorisation, pour chaque module, d'un tableau de représentation (TRC) ses classes, comprenant une référence à l'index de son module et, pour chaque classe, un tableau de représentation (TRA) des attributs et des méthodes (TRMe). 4. Procédé de chargement d'applications dans système embarqué selon la revendication 2, caractérisé en ce que les modules sont référencés dans un tableau de modules unique, les classes système sont contenues dans un module 1P1 unique, toute référence à une classe externe dans le pseudocode différente de n sera interprétée par la machine virtuelle comme une référence audit module API. 5. Procédé de chargement d'applications dans un système embarqué selon la revendication 4, caractérisé en ce que les classes étant déclarées publiques, ou en paquetage privé, les attributs et méthodes étant déclarés protégés, en paquetage privée ou en classe privée, la numérotation classes s'effectue suivant l'ordre classes publiques puis classes en paquetages privés, la numérotation des attributs ou méthodes effectuée le convertisseur (92) suivant l'ordre attribut ou méthode public, protégé, en paquetage privé et en classe privée. 6. Procédé de chargement d'applications sur un systeme embarqué selon la revendication 2, caractérisé en ce que les classes système sont contenues dans plusieurs modules API chargeables séparément, le chargeur (68) maintient dans la mémoire non volatile programmable deux tableaux de représentation des modules et deux tables d'association MIDllmi correspondantes, pour les modules API et l'autre pour les modules non- API, le chargeur chargeant les modules dans l'un des deux tableaux selon la nature du module specifié dans l'entête de celui-ci, toute référence externe d'un module du tableau de module étant interprétée comme une référence à l'index du module 7. Procède chargement d'applications sur un système embarqué selon la revendication 6, caractérisé en ce que la liaison statique d'un module est effectuée telle sorte que la référence à une classe externe à un module non dans le pseudocode intermédiaire est un index dans un tableau de l'entete module, dont chaque entrée est un identificateur (MID) d'un module référencé, le chargement dudit module sur la plate- forme cible comprenant le remplacement de ladite référence par le numéro de l'index du module obtenu à partir de l'identificateur (MID) de la table d'association MIDIIMi modules API. 8. Système embarqué comprenant une machine virtuelle et une plate-forme API incluant interfaces de programmation d'application, une mémoire non volatile fixe, une mémoire non volatile programmable ou modifiable, et mémoire vive, caractérisé en ce que la mémoire non volatile programmable comprend au moins un module API comprenant des classes système et des modules de services, au moins un tableau de représentation modules (TRM), dans lequel les modules sont indexés et une table (70, associant l'index (1M) d'un module du tableau de représentation a l'identificateur (MID) dudit module, chaque module comprenant un tableau de représentation des classes (TRC), dans lequel les classes sont indexées et dans lequel chaque classe présente une référence à l'index (1M) de son module, chaque classe comprenant un tableau de représentation des attributs (TRA) et des méthodes (TRMe), dans lesquels attributs et méthodes sont indexés, la référence à une méthode ou un attribut étant codée sur au moins trois multiplets (bytes) correspondant à une référence à une classe interne (II) ou externe (1E) au module, une référence externe au module constituant l'index du module API dans le tableau de module, un numéro de classe (NCI) correspondant à l'index de classe dans la table de représentation des classes du module, et un numero de méthode (NM) ou d'attribut (NA) correspondant à l'index de la méthode ou de l'attribut dans le tableau de représentation des methodes ou attributs de la classe du module. 9. Système embarqué selon la revendication 8, caractérise en ce qu'il comporte des moyens de comparaison du premier multiplet trois multiplets codage de référence à une méthode ou à un attribut avec une valeur déterminée n pour décider s'il s'agit d'une classe interne ou externe. 1 Système embarqué selon la revendication 8, caractérise en ce qu'il comprend un module erincipal comprenant le programme principal du système. 1 . Système embarqué selon la revendication 8, caractérise en ce que les classes sont indexéés suivant l'ordre classes publiques puis classes en paquetages privés, et les attributs ou méthodes suivant l'ordre attribut ou méthode public, protégé, en paquetage privé et en classe privée. Système embarqué selon la revendication 11, caractérisé en ce que la memoire non volatile programmable comprend plusieurs modules API comprenant des classes système, deux tableaux de représentation (101, 103) modules, l'un pour les modules API et l'autre pour les modules non- , et le module prinqipal, et deux tables (102, 104) d'association MIDIIMi correspondant chacune à un tableau de représentation des modules. , i 13. Système embarqué selon la revendication 10, caractérisé en ce qu'il comprend une classe gestionnaire d'accès "Access manager" d'un module (105) comprenant une méthode permettant de créer une instance module de service, par l'intermédiaire du module principal, ladite classe présentant une protection lui interdisant d'avoir plus d'une instance. 14. Procédé d'exécution d'une application d'un système embarqué multi-application, comprenant un environnement d'exécution incluant une machine virtuelle comprenant un interpréteur de langage de type pseudocode intermédiaire, et des interfaces de programmation d'application (API), caractérisé en ce que, lors de l'exécution du pseudocode intermédiaire d'un module de service, correspondant ' une application, référencée dans un tableau de module, la référence à méthode ou un attribut dans le pseudocode, codée sur au moins trois multiplets (bytes) correspondant à une référence à une classe interne (II) externe (1E) au module, un numéro de classe (NCI) et un numéro de méthode (NM) ou d'attribut (NA), une référence externe au module est interprétée par la machine virtuelle comme une référence à l'index d'un module API du tableau ou des modules API . 15. Procédé d'exécution d'une application d'un système embarqué multi-application selon la revendication 14, caractérise en ce que, sur réception d'une demande d'exécution d'un module de service présentant un identificateur (MID), l'environnement d'exécution accède a la classe d'entrée module principal comprenant le programme principal du système, le module principal installe `tjne instance d'une classe spéciale "Access Manager" d'un module API, gérant l'accès à un module de service, et utilise une méthode de cette classe permettant de créer une instance de la classe d'entrée du module de service demandée, par l'intermédiaire d'une table d'association de l'identificateur à l'index du module dans un tableau dans lequel le module est référencé, l'instance étant retournée par la méthode au programme principal.