Brevet FR2818770A1 — publié le 20020628

PROCEDE DE GESTION OPTIMISEE DE L'ALLOCATION DE MEMOIRE D'UN SYSTEME EMBARQUE ET SYSTEME EMBARQUE CORRESPONDANT. L'invention est relative à un procédé de gestion optimisée de l'allocation de mémoire d'un système informatique embarqué, désigné par système embarqué, et au système embarqué correspondant. Les systèmes embarqués actuellement disponibles dans le commerce, tels que notamment les assistants numériques, les cartes à microprocesseur ou micro- contrôleur, les cartes de type PCMCIA, les appareils informatiques portables, encore désignés par "notebook" ou "sub-notebook" en langage anglo-saxon, ont pour caractéristique commune, souvent contradictoire, la réduction de leur dimension et de leur encombrement et l'augmentation de leur fonctionnalité, grâce, notamment, aux progrès constants de la puissance de calcul des microprocesseurs ou micro-contrôleurs intégrés dans ces derniers. Compte tenu de l'évolution précitée, les systèmes embarqués tendent, en fait, à reproduire de la manière la plus fidèle possible les fonctionnalités des micro- ordinateurs, à l'exception toutefois des fonctionnalités offertes par la possibilité de connexion d'appareils ou organes périphériques à ces derniers. Parmi l'un des aspects du mode opératoire des systèmes embarqués qui sont susceptibles de restreindre le rapprochement des fonctionnalités de ces derniers de celles des micro-ordinateurs, celui relatif au mode de gestion de l'espace mémoire disponible apparaît crucial, dans la mesure o, à l'heure actuelle, un tel mode de gestion apparaît réduit à sa plus simple expression. En effet, dans le cas o le système embarqué est constitué par une carte à microprocesseur, encore désignée par carte à puce, ainsi que représenté en figure 1, ce système embarqué référencé 10 comprend de manière classique des circuits d'entrée/sortie, I/O, référencés 12, des ressources de traitement de l'information, référencés 14, constituées par un micro-contrôleur et reliées aux circuits d'entrée/sortie 12. En outre, une mémoire non volatile 18 est prévue, laquelle consiste en une mémoire programmable 18a et en une mémoire de type ROM, ou mémoire de type à accès en lecture seulement 18b. Enfin, une mémoire de travail, mémoire RAM référencée 16, est également prévue. Ces mémoires sont reliées au micro- contrôleur ou microprocesseur 14 par une liaison par BUS. L'ensemble est géré par un système d'exploitation OS, lequel peut être implanté en mémoire non volatile 18. Enfin, dans certains cas, la carte à microprocesseur peut comporter une unité de calcul cryptographique SI, référencée 20, elle-même reliée au microprocesseur 14, et jouant le rôle, en quelque sorte, d'un coprocesseur dédié. Le microprocesseur lui-même peut être remplacé ou complété par des circuits logiques implantés dans une puce à semiconducteur, ces circuits logiques pouvant être des circuits de type ASIC, de l'anglais Application Specific Integrated Circuit. La gestion de la zone mémoire est de manière classique réalisée, pour l'installation d'applications multiples par exemple, par une référence constituée par un pointeur, liant une adresse de début et une adresse de fin de zone mémoire relative à une application. Lors de l'exécution de ces applications, des paquets de données relatives à ces applications sont écrites à des adresses quelconques de cette zone mémoire, le seul critère d'allocation mémoire et d'écriture consistant en un critère d'espace mémoire libre suffisant entre un pointeur de début et un pointeur de fin, pour permettre la mémorisation d'un paquet de données de grandeur déterminée. Dans le cas de procédures d'installation / désinstallation successives d'applications dans la zone mémoire correspondante, des espace mémoires libres sont créés dans lesquels des paquets de code objet, respectivement de données, peuvent être écrits et mémorisés. Un tel processus opératoire conduit à un phénomène d'émiettement, encore désigné par fragmentation, de la zone mémoire considérée. Le phénomène d'émiettement ou de fragmentation précité présente, de même que dans le cas du phénomène de fragmentation de la zone mémoire des disques durs des micro-ordinateurs, de sérieux inconvénients, tels que le ralentissement de l'exécution des applications ou programmes considérés, utilisation non optimisée de l'espace mémoire du système embarqué. La présente invention a pour objet de remédier aux inconvénients précités des systèmes embarqués de l'art antérieur. En conséquence, un objet de la présente invention est la mise en oeuvre d'un procédé de gestion optimisée de l'allocation dynamique de mémoire à une structure de données ou application identifiée par un numéro d'identification et mémorisée sous forme de paquets d'information numérique dans la zone mémoire d'un système embarqué, procédé par lequel la zone mémoire élémentaire est subdivisée en blocs de mémoire élémentaires organisés selon un réseau adressable. Un autre objet de la présente invention est en conséquence la mise en euvre d'un procédé de gestion optimisée de l'allocation dynamique de mémoire dans un système embarqué, dans lequel, grâce à la subdivision de la zone mémoire en blocs de mémoire élémentaires, et à un processus de réarrangement des blocs élémentaires de blocs alloués, le phénomène d'émiettement ou de fragmentation de la zone mémoire du système embarqué est sensiblement supprimé. Un autre objet de la présente invention est en conséquence la mise en ouvre d'un procédé de gestion optimisée de l'allocation dynamique de mémoire dans un système embarqué dans lequel un processus de défragmentation de la zone mémoire de ce dernier permet de supprimer sensiblement tout phénomène d'émiettement après désinstallation d'une application. Le procédé de gestion optimisée de l'allocation dynamique de mémoire à une structure de données identifiée par un numéro d'identification numérique dans la zone mémoire d'un système embarqué, objet de l'invention, est mis en oeuvre à partir de paquets d'information constitués par des paquets de code objet représentatifs de cette structure de données et par des paquets de données relatives à cette structure de données, la zone mémoire étant subdivisée en blocs de mémoire élémentaires adressables. Il consiste à allouer aux paquets de code objet un ensemble de blocs de mémoire élémentaires localisés à des adresses sensiblement contiguës dans une première plage de mémoire dédiée à l'allocation de mémoire de paquets de code objet de cette zone mémoire et à allouer aux paquets de données un autre ensemble de blocs de mémoire s élémentaires dans une deuxième plage de mémoire dédiée à l'allocation de mémoire de paquets de données de cette zone mémoire. Ceci permet d'éviter la fragmentation des première et deuxième plages dédiées, lors d'installations/désinstallations successives de structures de données. Le procédé de gestion optimisée de l'allocation dynamique de mémoire, objet de l'invention, trouve application à tout système embarqué, mais de manière plus particulière aux cartes à microprocesseur ou micro- contrôleur multi-application. Le procédé de gestion optimisée de l'allocation dynamique de mémoire d'un système embarqué et le système embarqué correspondant seront mieux compris à la lecture de la description et à l'observations des dessins ci- après dans lesquels, outre la figure 1 relative à un système embarqué, tel qu'une carte à puce, de l'art antérieur: - la figure 2a représente un organigramme fonctionnel illustratif des étapes permettant la mise en euvre du procédé de gestion optimisée de l'allocation de mémoire d'un système embarqué objet de la présente invention lors d'un processus d'installation d'une application; - la figure 2b représente, à titre illustratif, un organigramme représentatif du détail des étapes de mise en oeuvre du procédé de gestion optimisée de l'allocation de mémoire d'un système embarqué, objet de la présente invention, lors d'un processus d'effacement d'une application; - la figure 2c représente, à titre illustratif, un organigramme fonctionnel d'un mode opératoire particulier non limitatif d'allocation de blocs de mémoire élémentaires permettant la mise en oeuvre du procédé de gestion de l'allocation de mémoire d'un système embarqué, objet de la présente invention; - les figures 3a et 3b représentent, à titre illustratif, un mode de mise en ouvre préférentiel non limitatif du procédé de gestion de l'allocation de mémoire d'un système embarqué, objet de la présente invention, dans lequel un processus de réallocation de blocs de mémoire élémentaires déjà alloués est utilisé - la figure 4 représente, à titre illustratif, un système embarqué, tel qu'une carte à microprocesseur ou micro-contrôleur multi- application, comportant, mémorisées en mémoire non volatile, des structure de données auxquelles des blocs de mémoire élémentaires ont été alloués, grâce à la mise en oeuvre du procédé de gestion optimisée de l'allocation de mémoire d'un système embarqué objet de la présente invention. Une description plus détaillée du procédé de gestion optimisée de l'allocation dynamique de mémoire à une structure de données, objet de la présente invention, sera maintenant donnée en liaison avec la figure 2a et les figures suivantes. La figure 2a représente un organigramme fonctionnel des étapes essentielles permettant la mise en oeuvre du procédé de gestion optimisée de l'allocation dynamique de mémoire à une structure de données dans un système embarqué, conformément à l'objet de la présente invention, lors de l'installation d'une application, cet organigramme fonctionnel correspondant en fait à un diagramme d'état des étapes essentielles précitées. En particulier, on comprend que l'étape S représentée en figure 2a correspond à un état de départ dans lequel une structure de données, constituée par une application, par des données système, le cas échéant par des clés ou des valeurs numériques spécifiques, doit être mémorisée, c'est-à-dire installée dans le cas d'applications par exemple dans la zone mémoire du système embarqué dont la structure correspond à celle précédemment décrite dans la description en liaison avec la figure 1. En particulier, on comprend que chaque structure de données peut avantageusement être identifiée par un numéro d'identification, noté ID Aj o j peut prendre des valeurs comprises entre 1 et n, n indiquant le nombre total de structures de données susceptibles d'être mémorisées dans l'espace mémoire précité. En outre, pour la mise en oeuvre du procédé objet de la présente invention, on indique que l'espace mémoire géré de manière optimisée conformément à ce dernier est avantageusement subdivisé en blocs de mémoire élémentaires, chaque bloc de mémoire élémentaire, noté BL1 avec 1 pouvant varier de 1 = 1 à 1 = L, étant formé par un nombre déterminé d'octets. Dans un mode de réalisation préférentiel non limitatif, on indique que le nombre d'octets constitutifs de chaque bloc BL1 peut être une puissance de 2, afin de faciliter l'adressage de chaque bloc de mémoire élémentaire ainsi que l'adressage dans chaque bloc de mémoire élémentaire ainsi défini. Dans un mode de réalisation donné à titre d'exemple non limitatif, on indique que chaque bloc de mémoire élémentaire peut comporter 256 octets. Enfin, et dans le cadre de la mise en oeuvre du procédé objet de la présente invention, on dispose à l'étape S de départ d'une valeur numérique arbitraire, notée AAAA, laquelle peut être avantageusement utilisée afin de permettre la mise en oeuvre d'un procédé d'allocation dynamique de mémoire par blocs de mémoire élémentaires spécifique, plus particulièrement adapté à la mise en oeuvre du procédé de gestion optimisée de l'allocation dynamique de mémoire, objet de la présente invention, ainsi qu'il sera décrit ultérieurement dans la description. Sur la figure 2a, à l'étape de départ S précitée, on note: [ID_Aj] J l'ensemble des numéros d'identification de structures de données susceptibles d'être installées et gérées conformément au protocole de gestion optimisée d'allocation de mémoire objet de la présente invention; [BLL l'ensemble des blocs de mémoire élémentaires dont on dispose après subdivision de la zone mémoire du système embarqué précédemment cité; QCOjp tout paquet de code objet relatif à une structure de données ou application de numéro d'identification IDAj lors de la procédure d'installation de l'application considérée; QDjp tout paquet de données relatif à la structure de données ou application de même numéro d'identification IDAj au cours de l'installation. D'une manière générale, on indique que lors de l'installation d'une structure de données ou d'une application, les paquets d'information sont constitués par des paquets de code objet précités, représentatifs de cette structure de données, et par des paquets de données relatives à cette structure de données ou à l'application considérée. Cette subdivision en paquets d'information des deux catégories précitées résulte d'une discrimination de fait de ces paquets d'information en fonction de l'étape d'installation réalisée. On comprend en particulier que lors de l'installation du code objet représentatif de la structure de données ou de l'application, les paquets d'information correspondants sont connus en tant que tels. Il en est de même pour ce qui concerne les paquets de données relatives à cette structure de données ou application. Ainsi, la subdivision précitée résulte a priori du processus d'installation de chaque application dans la zone mémoire du système embarqué correspondant. Compte tenu de la subdivision de la zone mémoire précitée en blocs de mémoire élémentaires adressables et de la discrimination de fait, et donc de la subdivision des paquets d'information en paquets de code objet et en paquets de données relatives à cette structure de données, le procédé de gestion optimisée de l'allocation dynamique de mémoire à une structure de données, objet de la présente invention, consiste en une étape A1, ainsi que représenté en figure 2a, à allouer aux paquets de code objet QCOjp pour l'application ou la structure de données correspondante, un ensemble de blocs de mémoire élémentaires, noté [BL,] ces blocs de mémoire élémentaires étant localisés à des adresses sensiblement contiguës dans une première plage de mémoire dédiée à l'allocation de mémoire de paquets de code objet de la zone mémoire considérée. Sur la figure 2a, le processus d'allocation, à l'étape A1, aux paquets de code objet est noté: [BL1]Q EMS1 Dans la relation précédente, on indique que MS1 désigne la première plage de mémoire dédiée à l'allocation de mémoire des paquets de code objet précités. En outre, et de manière non limitative, l'ensemble de blocs de mémoire élémentaires localisés à des adresses sensiblement contiguës dans la première plage de mémoire dédiée est réputé défini par l'adresse de départ 1=1 et par l'adresse d'arrivée QC, QC désignant en fait l'espace mémoire nécessaire en nombre de blocs de mémoire élémentaires pour assurer la mémorisation de l'ensemble des paquets d'informations de code objet QCOjp pour la structure de données ou application correspondante. En outre, le procédé de gestion optimisée de l'allocation dynamique de mémoire à une structure de données, objet de la présente invention, consiste, en une étape A2, à allouer aux paquets de données QDjp un autre ensemble de blocs de mémoire élémentaires, noté L [BL,]L-QD dans une deuxième plage de mémoire dédiée à Il l'allocation de mémoire de paquets de données de la zone mémoire considérée. Sur la figure 2a, à l'étape A2, l'opération d'allocation correspondante est notée selon la relation: L [BL1] L-QDEMS2 En ce qui concerne l'ensemble de blocs de mémoire élémentaires dans la deuxième plage de mémoire dédiée à l'allocation de mémoire de paquets de données, l'adresse de départ est établie de manière non limitative à la valeur L-QD o QD désigne en fait l'espace mémoire nécessaire à la mémorisation de l'ensemble des paquets de données QDjp pour l'application ou la structure de données correspondante. En ce qui concerne les adresses de début et de fin de définition des ensembles de blocs de mémoire élémentaires précités à l'étape A1, respectivement A2, ces données peuvent être arbitraires, pourvu qu'aucun risque de recouvrement ne soit encouru en ce qui concerne les ensembles précités. En outre, ainsi que représenté en figure 2b, pour une opération d'effacement E des paquets de code QCOj, respectivement des paquets de données QDj précédemment mentionnés, le processus de gestion d'allocation de mémoire, objet de la présente invention, peut consister, ainsi que représenté sur la figure précitée, à partir d'une étape d'effacement d'une application ID_Ar, pour l'effacement de paquets de code objet QCOj, en une étape El, en une sous-étape d'effacement des blocs d'indice 1, cette sous-étape, portant la référence El,, étant désignée sur la figure 2b par la relation: E1l ([BL]) MSl et [BL1]=ID Ar alors [BL1]≤AAAA. Par cette opération d'effacement, on comprend que pour tout bloc soumis à effacement, bloc BL1 appartenant à la zone de mémorisation des paquets de code objet MSl, l'ensemble de ces blocs correspondant à l'application soumise à effacement, et donc à l'application référencée ID_Ar, alors, on attribue à chacun des blocs précités BL1 la référence spécifique AAAA précédemment mentionnée dans la description. La sous-étape 1 d'effacement est alors suivie d'une sous-étape 2 de translation de code El2. Cette opération de translation est effectuée pour 1o désignant le premier bloc de code de l'application référencée IDAr et lmax dernier bloc de code de cette même application soumise à effacement. L'opération de translation est alors effectuée sur chaque bloc d'indice lmax+j pour lesquels le numéro de référence est différent de AAAA, cette opération étant notée sur la figure 2b: [BL0+j] = [BLlmax+j] [BLlmax+j] <>AAAA. L'opération de translation précédente consiste en fait à réaliser une translation des blocs d'indice lmax+j vers les blocs d'indice 10+j suivie d'un effacement par attribution de la valeur d'identification AAAA des blocs déplacés. En ce qui concerne l'effacement des paquets de données QDj, une étape d'effacement E2 est représentée en figure 2b, cette opération étant notée, pour tout indice 1 des blocs BL1, avec [BL1] eMS2 et [BL1]=IDAr alors [BL1]≤>AAAA. On comprend ainsi qu'en tout bloc BL1 relatif aux paquets de données QDj est alors affecté la valeur d'identification AAAA précédemment mentionnée dans la description, ce qui permet d'effectuer l'effacement des paquets de données correspondant au bloc précité. On constate en particulier que, pour l'effacement des paquets de données QDj,il n'est pas nécessaire d'effectuer une translation des blocs effacés. En ce qui concerne la mise en oeuvre du procédé de gestion optimisée de l'allocation dynamique de mémoire à une structure de données ou application, objet de la présente invention, on indique qu'il est nécessaire de disposer d'un système de gestion de la zone mémoire précitée permettant de savoir quelles parties de celle-ci sont libres ou utilisées. Bien entendu, un tel système peut consister en un système analogue à celui utilisé pour la gestion des disques durs des micro- ordinateurs, ce système étant connu sous le nom de système de table d'allocation de fichier, encore désigné en vocable anglo- saxon par File Allocation Table, ou FAT. De préférence, mais de manière non limitative, la subdivision de la zone mémoire précitée en blocs adressables peut être réalisée de manière particulièrement avantageuse grâce à la mise en euvre d'un processus d'allocation de mémoire spécifique, lequel sera maintenant décrit de manière non limitative plus détaillée en liaison avec la figure 2c. Ainsi que représenté en figure 2c, on indique que le processus d'allocation dynamique de mémoire par blocs de mémoire élémentaires à une structure de données est mis en euvre à partir d'au moins une instruction d'allocation d'un bloc mémoire élémentaire BL1, opération d'allocation notée A par laquelle, au bloc mémoire élémentaire précité est associée une référence au numéro d'identification de la structure de données ou application considérée, et à partir d'au moins une instruction d'effacement d'un bloc de mémoire élémentaire, instruction correspondant à l'opération E représentée sur la figure 2c. En particulier, l'opération d'allocation A, pour allouer un bloc de mémoire élémentaire, consiste à attribuer à la référence au numéro d'identification associé au bloc de mémoire élémentaire considéré la valeur du numéro d'identification IDAj. Alors que dans les procédés d'allocation de mémoire des systèmes embarqués antérieurs, les zones de mémorisation des structures de données, telles que les applications, comportent une simple référence au numéro d'identification de la structure de données ou application correspondante réalisée sous forme d'un pointeur, pointeur de début de mémorisation de la structure de données ou application et pointeur de fin de mémorisation de la structure de données ou application considérée, l'étape d'allocation A conforme au processus d'allocation précité consiste en fait à attribuer à titre de référence au numéro d'identification de la structure de données ou application, la valeur du numéro d'identification précité à chaque bloc BL1 dans lequel les paquets d'information numérique de code objet ou de données sont mémorisés. On comprend en particulier, ainsi que représenté en figure 2c, que l'attribution de la valeur du numéro d'identification à la référence au numéro d'identification consiste à associer de manière bi-univoque la valeur de ce numéro d'identification au bloc de mémoire élémentaire correspondant BL1, cette opération étant notée: BL1(IDAj). On comprend ainsi que la mise en correspondance bi-univoque précitée peut être réalisée par association à chaque bloc BL1 d'un champ de données représentatif de la valeur du numéro d'identification précité IDAj dans un tableau de gestion de l'allocation dynamique de mémoire de la zone mémoire du système embarqué précité. La structure complète du tableau précité sera donnée ultérieurement dans la description. Conformément à un autre aspect remarquable du processus précité d'allocation dynamique de mémoire par blocs de mémoire élémentaires, on indique, en référence à la figure 2b, que l'étape d'effacement E consiste, pour effacer un bloc de mémoire élémentaire, à attribuer à la référence au numéro d'identification associée au bloc de mémoire élémentaire considéré BL1 une valeur arbitraire en lieu et place du numéro d'identification de la structure de données ou application considérée. Cette valeur arbitraire est bien entendu la valeur AAAA précédemment citée dans la description. Cette valeur arbitraire est distincte de toute valeur de numéro d'identification attribué à une structure de données considérée. En référence à la figure 2c, on note: [IDAr]n1 l'ensemble des numéros d'identification de structures de données déjà installées; ID_Ak le numéro d'identification de la structure de données ou application pour laquelle l'allocation mémoire doit être effectuée, k E [l,n]; Qk l'espace mémoire nécessaire aux paquets d'information numérique, paquets de code objet ou paquets de données auxquels un espace mémoire correspondant doit être alloué. Par ailleurs, on définit un indice r particulier, que l'on note ro, à qui l'on donne la valeur 0. Dans ces conditions, l'opération d'allocation A, ainsi que représenté en figure 2c, peut consister, pour allouer un bloc de mémoire élémentaire donné, noté BL1, au paquet d'information numérique Qk précité, et préalablement à toute étape consistant à attribuer à la référence au numéro d'identification la valeur du numéro d'identification, à vérifier, pour tout bloc de mémoire élémentaire déjà alloué, l'identité de la référence au numéro d'identification et du numéro d'identification de la structure de données correspondante, en une étape AA1. Cette vérification d'identité consiste à effectuer un test consistant à chercher le premier bloc de mémoire BL1 dont le numéro d'identification associé ID_Ar correspond au numéro d'identification IDAk de la structure de données ou application pour laquelle l'allocation doit être effectuée. Le test précité est noté: 3 BL (ID_Ar) avec ID_Ar = ID_Ak ? et r>r0 Sur réponse négative au test AA1, consistant à rechercher le prochain bloc appartenant à l'application dont le numéro d'identification est ID_Ak, une instruction d'allocation d'un bloc de mémoire élémentaire libre est appelé à l'étape AA3, aucun des éventuels blocs de mémoire déjà alloués à l'application dont le numéro d'identification est ID_Ak ne possédant un espace libre suffisant pour contenir le paquet d'informations Qk. Sur la figure 2c, l'appel de l'instruction d'allocation du bloc de mémoire élémentaire suivant est notée: BLa(AAAA) = BLa(ID_Ak) L'instruction d'allocation précitée du bloc élémentaire suivant permet ainsi d'allouer un bloc de mémoire élémentaire d'adresse a, a étant une valeur de décalage quelconque, da E N ensemble des entiers naturels. Le bloc de mémoire élémentaire retenu est bien entendu un bloc élémentaire auquel la valeur arbitraire AAAA a été attribuée précédemment et correspond de ce fait à un bloc effacé, c'est-à-dire à un bloc libre et prêt pour toute opération d'allocation et de mémorisation du paquet d'information Qk correspondant. La réponse positive au test AA1 indique que le bloc de mémoire élémentaire qui vient d'être trouvé est au moins partiellement alloué à la structure de données ou application pour laquelle l'allocation doit être effectuée. Sur réponse positive au test AA1 précité, le procédé d'allocation consiste ensuite à vérifier, en un test AA2, l'existence d'un espace mémoire suffisant restant dans le bloc de mémoire élémentaire courant BL,(IDAj) précité pour mémoriser l'information numérique Qk précédemment mentionnée. Sur la figure 2c, la vérification de l'existence d'un espace mémoire suffisant au test AA2 comprend la mise à la valeur r de l'indice particulier r0 et est notée: LRr = LBr - LOr et Qk courant précité. Sur réponse positive au test de vérification AA2, le paquet d'informationQk nécessitant un espace mémoire inférieur à l'espace mémoire du bloc de mémoire élémentaire courant, au paquet d'information Qk peut être alloué, en une étape AA4, le bloc de mémoire élémentaire courant précité BLl(IDAr) , le paquet d'information numérique Qk pouvant être mémorisé dans la zone mémoire libre du bloc de mémoire élémentaire courant précité. Ainsi, l'étape d'allocation AA4 consiste en une écriture du paquet d'information Qk dans le bloc BL,(ID_Ar) et en une actualisation de la valeur de l'espace mémoire occupé dans le bloc, notée: LOr = LOr+Qk. Sur réponse négative au test de vérification AA2, le bloc courant BL(IDAjo) ne possédant pas assez d'espace libre pour contenir le paquet d'information Qk, il convient de retourner à l'étape AAl afin de rechercher un nouveau bloc dont le numéro d'identification est ID_Ak et n'ayant pas encore été analysé lors de cette allocation. Bien entendu, les étapes d'allocation proprement dites AA3 et AA4 sont suivies d'un retour à l'état de départ S. Dans un mode de réalisation préférentiel non limitatif, on indique que, suite aux étapes d'allocation AA3 et AA4, et donc suite à l'allocation d'un bloc de mémoire élémentaire à une application et bien entendu à la mémorisation par écriture de l'information numérique, c'est-à-dire du paquet d'information Qk par écriture de cette information dans le bloc de mémoire élémentaire alloué, le procédé d'allocation conforme à l'objet de la présente invention peut consister en outre à calculer, en une étape AA5 une valeur de vérification du bloc de mémoire élémentaire alloué, cette opération étant désignée par calcul CKS sur la figure 2c. D'une manière générale, on indique que pour la mise en oeuvre de l'étape AA5, le calcul de la valeur de vérification, encore désigné par check sum en langage anglo-saxon, peut être effectué grâce à des moyens de calcul de valeur de vérification de type classique, ces moyens de calcul pouvant d'ailleurs correspondre au circuit de calcul spécialisé 20 contenu dans les systèmes embarqués de type classique, ainsi que décrit précédemment dans la description. L'étape A55 peut permettre d'appeler une étape AA6 de gestion d'erreur de type classique permettant de souligner un problème d'intégrité des données ou de code mémorisés, pouvant prévoir le blocage du système embarqué. Le processus d'allocation dynamique de mémoire précédemment décrit en liaison avec la figure 2c peut être mis en ouvre de manière préférentielle pour procéder aux étapes d'allocation A1 et/ou A2 de la figure 2a ou 2b. Par la mise en oeuvre du procédé de gestion optimisée de l'allocation dynamique de mémoire à une structure de données ou application, conforme à l'objet de la présente invention, tel que décrit précédemment en liaison avec la figure 2a et le cas échéant 2c, on indique que le fait de mémoriser les paquets de code objet et les paquets de données relatifs à une application ou à une structure de données à des endroits différents permet d'éviter l'émiettement de la zone mémoire lors de l'installation d'applications. En effet, lors de l'installation proprement dite, il n'existe pas vraiment de phénomène d'émiettement ou de fragmentation pour les paquets de données de code, car les paquets de code correspondants sont stockés et mémorisés selon de gros blocs consécutifs, et ceci en une seule fois lors de l'installation. En ce qui concerne le risque d'émiettement ou de fragmentation des paquets de données, une structure de données, telle qu'une application, pouvant créer des données relatives à cette application ou à cette structure de données à n'importe quel instant et de manière beaucoup plus fréquente, celui-ci est toutefois beaucoup plus facile à contrôler du fait que les blocs de données n'ont pas à être stockés consécutivement. Il est donc tout à fait facile de réutiliser un bloc de mémoire élémentaire vide en mémorisant dans ce dernier des paquets de données relatifs à une application. Le fait de séparer les paquets de données des paquets de codes résout donc bien le problème de l'émiettement ou de la fragmentation. Toutefois, il apparaît tout de même des trous, c'est-à-dire des risques de blocs de mémoire élémentaires non occupés dans la première plage de mémoire dédiée à l'allocation de mémoire de paquets de code objet de la zone mémoire considérée. Ce risque apparaît lors de la suppression d'une application par exemple. Pour supprimer totalement ce risque, le procédé de gestion optimisée de l'allocation dynamique de mémoire à une structure de données, conforme à l'objet de la présente invention, met également en oeuvre un processus de défragmentation, lequel sera décrit en liaison avec les figures 3a et 3b. On comprend en effet que suite à la désinstallation d'une application, cette désinstallation se traduit par un effacement des blocs de mémoire élémentaires alloués à cette application désinstallée dans la première plage de mémoire dédiée à l'allocation de mémoire de paquets de code objet. Sur la figure 3a, on a représenté différentes applications, désignées successivement Applet 1, Applet 2, Applet 3 et Applet 4. Les différentes applications dans l'exemple donné correspondent aux valeurs numériques ci-après: Applet 1 150 octets de code, soit 1 bloc 600 octets de données, soit 3 blocs Applet 2 150 octets de code, soit 1 bloc octets de données, soit 1 bloc Applet 3 1100 octets de code, soit 5 blocs octets de données, soit 1 bloc Applet 4 400 octets de code, soit 2 blocs 300 octets de données, soit 2 blocs Les étapes successives d'installation/ désinstallation des applications précitées sont représentées en figure 3b et sont les suivantes: Etape 1 Installation de Applet 1 et installation de Applet 2. Etape 2 Effacement de Applet 1 et réallocation des paquets de code objet restants non désinstallés. Etape 3 Installation de Applet 3. Etape 4 Installation de Applet 4. Sur la figure 3b, l'espace mémoire utilisable est réputé subdivisé en un ensemble de blocs de mémoire élémentaires, d'adresse comprise entre 1 et L, d'adresse de début, respectivement de fin. Les références lc, 2c, 3c et 4c désignent les blocs de mémoire élémentaires alloués aux paquets de code objet des applications Applet 1, Applet 2, Applet 3 et Applet 4 respectivement et les blocs de mémoire élémentaires ld, 2d, 3d et 4d désignent les blocs de mémoire élémentaires alloués aux paquets de données relatives à ces mêmes applications. La réallocation au paquet de code objet restant, c'est-à-dire le paquet 2c suite à l'effacement de l'application Applet 1 à l'étape 2, l'application Applet 2 n'étant pas désinstallée, consiste en fait à réallouer par réarrangement les blocs de mémoire élémentaires alloués au paquet de code objet restant précité. Ainsi, le réarrangement du bloc de mémoire élémentaire occupé par le code objet 2c sur la figure 3b est représenté par la translation T de ce dernier pour passage au bloc de mémoire élémentaire d'adresse de début 1 en fin d'étape 2. Ainsi, la réallocation précitée par réarrangement, et en particulier par translation, permet le réarrangement de tout ensemble de blocs de mémoire élémentaires localisé à des adresses sensiblement contiguës pour combler les blocs de mémoire élémentaires effacés alloués antérieurement à l'application désinstallée. D'une manière générale, ainsi que représenté en figure 3b, la zone mémoire du système embarqué, zone mémoire programmable non volatile, est de préférence adressée selon un champ d'adresses linéaire comportant une adresse de début et une adresse de fin de zone mémoire, ces adresses constituant chacune une adresse d'extrémité. Ces adresses sont notées 1 et L sur la figure 3b. Dans ces conditions, la définition de la première, respectivement de la deuxième plage de mémoire dédiée et l'allocation des paquets de données peuvent être effectuées à partir de l'une, respectivement de l'autre des adresses d'extrémité, ou réciproquement. On comprend bien entendu que le choix de l'adresse de début 1, respectivement de l'adresse de fin L pour assurer l'allocation des blocs de mémoire élémentaires aux paquets de code objet est sans incidence sur la mise en oeuvre du procédé objet de la présente invention. On comprend également qu'en fonction du nombre d'applications installées, la définition explicite de chacune des première et deuxième plages de mémoire dédiées à l'allocation de mémoire de paquets de code objet ou de paquets de données n'est pas nécessaire. En particulier, ce mode opératoire permet d'optimiser l'occupation de la zone mémoire précitée en l'absence de toute définition explicite de la première et de la deuxième plage de mémoire dédiée. Pour assurer un processus de réallocation des blocs de mémoire élémentaires particulièrement aisé, on indique que l'adressage du contenu des blocs de mémoire élémentaires, pour les opérations d'allocation, de réallocation et d'adressage pour la définition de la première et de la deuxième plage de mémoire, est un adressage relatif. Dans ces conditions, l'adressage relatif, dans chaque bloc de mémoire élémentaire, permet sans difficulté le réarrangement des blocs précités par translation d'un nombre voulu de blocs de mémoire élémentaires libérés suite à la déclaration de blocs élémentaires antérieurs et/ou postérieurs comme blocs libres ou effacés. Le fait d'assurer l'allocation des blocs de mémoire élémentaires à partir des adresses d'extrémité, ainsi que mentionné précédemment dans la description, permet d'utiliser l'espace mémoire libre dans les meilleures conditions en l'absence de tout a priori sur la taille du code et des données relatives aux applications. La seule contrainte à respecter est l'absence de recouvrement de la première, respectivement de la deuxième plage mémoire dédiée. Une description plus détaillée d'un système embarqué multi-application spécialement adapté à la mise en euvre du procédé de gestion optimisée de l'allocation mémoire à une structure de données, conforme à l'objet de la présente invention, sera maintenant donnée en liaison avec la figure 4. D'une manière générale, on rappelle que le système embarqué précité comporte un système d'exploitation assurant la gestion des circuits d'entrée/sortie de la mémoire vive et de la mémoire programmable non volatile de ce système d'exploitation par l'intermédiaire du microprocesseur. Ainsi que représenté sur la figure 4 précitée, le système embarqué comprend, dans la zone mémoire programmable non volatile 18a, un tableau de gestion, noté TG, et d'allocation de la zone mémoire par blocs de mémoire élémentaires. Ainsi que mentionné précédemment, ce tableau de gestion TG peut correspondre soit à un fichier de type FAT, soit, au contraire, ainsi que représenté de manière non limitative sur la figure 4, en un tableau comportant pour chaque application ou structure de données, un numéro d'identification IDAk, la valeur de l'espace mémoire occupé noté LIk pour le bloc de mémoire élémentaire correspondant et les valeurs de vérification CKSIa et CKSlb pour le bloc de mémoire élémentaire précité. Sur la figure 4, on a représenté uniquement les champs de données correspondantes pour k=l et k=2, c'est- à-dire pour des blocs relatifs à deux applications distinctes. En particulier, le tableau de gestion TG précité permet d'assurer le processus d'allocation tel que représenté en figure 2c et bien entendu le processus de gestion optimisée de l'allocation dynamique de mémoire conforme à l'objet de la présente invention. Dans ces conditions, la mémoire programmable non volatile 18a peut comporter, à titre d'exemple, les blocs de mémoire élémentaires alloués aux paquets de code objet, respectivement aux paquets de données, selon l'arrangement représenté en figure 4 pour les applications Applet 3, Applet 2 et Applet 4 précédemment mentionnées dans la description après la réalisation de l'étape 4 de la figure 3b. Dans ces conditions, la mémoire programmable non volatile 18a comprend les paquets de code objet représentatifs d'un ensemble d'applications, ces paquets de code objet étant mémorisés dans un ensemble de blocs de mémoire élémentaires localisés à des adresses sensiblement contiguës dans la première plage de mémoire P1 ainsi que des paquets de données relatives à chaque application, ces paquets de données étant mémorisés dans un autre ensemble de blocs de mémoire élémentaires dans une deuxième plage de mémoire P2 dédiée à l'allocation de mémoire des paquets de données. En référence à la figure 4, on note également que, pour une zone mémoire programmable non volatile adressée selon un champ d'adresses linéaire comportant une adresse de début 1 et une adresse de fin L, constituant en fait les adresses d'extrémité précitées, la définition de la première MS1 et de la deuxième MS2 plage de mémoire dédiée est alors effectuée à partir des adresses d'extrémité précitées, la première et la deuxième plage de mémoire MS1, MS2 dédiées étant alors définies selon un premier et un deuxième ensemble disjoints de blocs de mémoire élémentaires, la zone mémoire étant ainsi optimisée du point de vue de l'occupation de celle-ci. REVENDICATIONS 1. Procédé de gestion optimisée de l'allocation dynamique de mémoire à une structure de données, identifiée par un numéro d'identification et mémorisée sous forme de paquets d'information numérique dans la zone mémoire d'un système embarqué, caractérisé en ce que lesdits paquets d'information étant constitués par des paquets de code objet, représentatifs de cette structure de données, et par des paquets de données relatives à cette structure de données et ladite zone mémoire étant subdivisée en blocs de mémoire élémentaires adressables, ce procédé comprend les étapes consistant: - à allouer auxdits paquets de code objet un ensemble de blocs de mémoire élémentaires localisés à des adresses sensiblement contiguës dans une première plage de mémoire dédiée à l'allocation de mémoire de paquets de code objet de ladite zone mémoire; à allouer auxdits paquets de données un autre ensemble de blocs de mémoire élémentaires dans une deuxième plage de mémoire dédiée à l'allocation de mémoire de paquets de données de ladite zone mémoire, ce qui permet d'éviter la fragmentation desdites première et deuxième plages dédiées lors d'installations/ désinstallations successives de structures de données. 2. Procédé selon la revendication 1, caractérisé en ce que, suite à la désinstallation d'une application, cette désinstallation se traduisant par un effacement des blocs de mémoire élémentaires alloués à ladite application désinstallée dans ladite première plage de mémoire dédiée à l'allocation de mémoire de paquets de code objet, celui-ci comprend une étape consistant à effectuer une réallocation par translation auxdits paquets de code objet restants, non désinstallés, d'un ensemble de blocs de mémoire élémentaires localisés à des adresses sensiblement contiguës pour combler les blocs de mémoire élémentaires effacés antérieurement alloués à ladite application désinstallée. 3. Procédé selon la revendication 1, caractérisé en ce que, pour une zone mémoire adressée selon un champ d'adresses linéaire comportant une adresse de début et une adresse de fin de zone mémoire constituant chacune une adresse d'extrémité, la définition de la première respectivement de la deuxième plage de mémoire dédiée et l'allocation des paquets de code objet respectivement des paquets de données sont effectuées à partir de l'une respectivement de l'autre des adresses d'extrémité, ou réciproquement, ce qui permet d'optimiser l'occupation de ladite zone mémoire. 4. Procédé selon la revendication 3, caractérisé en ce que l'adressage du contenu desdits blocs de mémoire élémentaires pour les opérations d'allocation et de réallocation destinées au moins aux paquets de code objet et d'adressage pour la définition de la première et de la deuxième plage de mémoire est un adressage relatif. 5. Système embarqué multi-application comportant un système d'exploitation assurant la gestion des circuits d'entrée/sortie, de la mémoire vive et de la mémoire programmable non volatile de ce système d'exploitation par l'intermédiaire d'un microprocesseur, caractérisé en ce qu'il comprend, mémorisé en zone mémoire programmable non volatile, un tableau de gestion et d'allocation de la zone mémoire par blocs de mémoire élémentaires. 6. Système selon la revendication 5, caractérisé en ce qu'il comprend en outre, mémorisés en zone mémoire programmable non volatile: - des paquets de code objet, représentatifs d'un ensemble d'applications, ces paquets de code objet étant mémorisés dans un ensemble de blocs de mémoire élémentaires localisés à des adresses sensiblement contiguës dans une première plage de mémoire, dédiée à l'allocation de mémoire à des paquets de code objet, de ladite zone mémoire programmable non volatile; - des paquets de données relatifs à chaque application, ces paquets de données étant mémorisés dans un autre ensemble de blocs de mémoire élémentaires dans une deuxième plage de mémoire, dédiée à l'allocation de mémoire à des paquets de données, de ladite zone mémoire programmable non volatile. 7. Système selon la revendication 6, caractérisé en ce que, pour une zone mémoire programmable non volatile adressée selon un champ d'adresses linéaire comportant une adresse de début et une adresse de fin de zone mémoire programmable non volatile, constituant chacune une adresse d'extrémité, la définition de la première respectivement de la deuxième plage de mémoire dédiée est effectuée à partir de l'une, respectivement de l'autre des adresses d'extrémité, ou réciproquement, ce qui permet de définir la première respectivement la deuxième plage de mémoire dédiée selon un premier et un deuxième ensemble disjoints de blocs de mémoire élémentaires et d'optimiser l'occupation de ladite zone mémoire programmable non volatile.