FR2923042A1 - Systeme pour le deploiement de composants logiciels sur des unites de calcul limitees en capacite de traitement. - Google Patents
Systeme pour le deploiement de composants logiciels sur des unites de calcul limitees en capacite de traitement. Download PDFInfo
- Publication number
- FR2923042A1 FR2923042A1 FR0707685A FR0707685A FR2923042A1 FR 2923042 A1 FR2923042 A1 FR 2923042A1 FR 0707685 A FR0707685 A FR 0707685A FR 0707685 A FR0707685 A FR 0707685A FR 2923042 A1 FR2923042 A1 FR 2923042A1
- Authority
- FR
- France
- Prior art keywords
- component
- components
- file
- computing unit
- reconfiguration
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title description 18
- 230000008569 process Effects 0.000 title description 3
- 230000006870 function Effects 0.000 claims abstract description 28
- 238000011068 loading method Methods 0.000 claims abstract description 11
- 238000003032 molecular docking Methods 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 21
- 230000004044 response Effects 0.000 description 6
- 238000004891 communication Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000006378 damage Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000008054 signal transmission Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
La présente invention concerne un système (100) comportant une plate-forme logicielle pour le déploiement de composants sur des unités de calcul limitées en capacité de traitement. La plate-forme d'accueil (104) offre à une infrastructure de reconfiguration des moyens de déploiement et d'exécution de composants sur les unités de calcul, lesdits moyens comprenant :▪ un moyen pour charger et/ou décharger le code objet d'un composant sur une unité de calcul,▪ un moyen pour exécuter et/ou arrêter ledit composant,▪ un moyen pour appeler les fonctions dudit composant,▪ un moyen pour connecter et/ou déconnecter un composant déployé avec d'autres composants.L'invention s'applique notamment à la reconfiguration d'équipements à base de calculateurs embarqués contraints du point de vue temps réel, en particulier pour les radios logicielles.
Description
Système pour le déploiement de composants logiciels sur des unités de calcul limitées en capacité de traitement
La présente invention concerne un système comportant une plate-forme logicielle pour le déploiement de composants sur des unités de calcul limitées en capacité de traitement. L'invention s'applique notamment à la reconfiguration d'équipements à base de calculateurs embarqués contraints du point de vue temps réel, en particulier pour les radios logicielles.
Les systèmes de calcul conçus pour s'adapter à de multiples configurations logicielles sont aujourd'hui largement développés. Pour les calculateurs fixes, ces systèmes s'appuient sur des infrastructures de reconfiguration qui utilisent des environnements souvent gourmands en ressources permettant de déployer dynamiquement des composants sur plusieurs unités de calcul. Toutefois, lorsque ces systèmes sont embarqués et soumis à de fortes contraintes temps-réel, des difficultés importantes apparaissent, ces difficultés étant notamment liées aux limites de capacité imposées, tant en mémoire qu'en puissance de calcul. A titre d'exemple, un calculateur intégré dans un terminal de radio logicielle mobile doit, d'une part, pouvoir s'adapter à de nouvelles formes d'onde, donc être conçu à partir d'une architecture ouverte, et d'autre part, pouvoir basculer rapidement d'un mode de communication basé sur une forme d'onde vers un mode de communication basé sur autre une forme d'onde, donc modifier rapidement sa configuration logicielle. Pour répondre à ce problème technique, les systèmes reposent sur des standards tels que le SCA ( Software Communications Architecture ) et LightWeight CCM ( Corba Component Model ). Une infrastructure de reconfiguration, par exemple le Core Framework SCA, interagit avec un environnement d'exécution cible, à travers des interfaces standardisées, telles que ExecutableDevice et Resource pour SCA, afin de déployer et d'exécuter des composants logiciels sur plusieurs unités de calcul. Les infrastructures de reconfiguration actuelles reposent sur des environnements d'exécution cibles basés sur un système d'exploitation suivant la norme POSIX et une architecture intergicielle de type CORBA
2 ( Common Object Request Broker Architecture ). Cependant, l'architecture CORBA n'est pas adaptée aux systèmes embarqués soumis à de fortes contraintes temps-réel. Plusieurs alternatives ont donc été proposées. Des solutions reposant sur l'infrastructure de reconfiguration D&C de l'OMG ( Object Management Group ) ont été développées, mais ces solutions ne permettent pas d'effectuer des éditions de liens dynamiques de code. En outre, elles ne respectent pas le standard SCA. Par ailleurs, des études ont permis de charger dynamiquement du code sur un environnement cible non CORBA, mais un seul composant peut être chargé par unité de calcul, les adresses de connexions de ce composant étant, de plus, fixées à l'avance dans le code objet, ce qui établit un couplage fort entre l'infrastructure de reconfiguration et le composant déployé. Enfin, d'autres études, notamment dans le cadre du programme JTRS ( Joint Tactical Radio System ), ont abouti à la définition d'une couche d'abstraction ou, selon la terminologie anglo-saxonne, une MHAL ( Modem Hardware Abstraction Layer ) pour réaliser un autre environnement d'exécution cible. Cependant, cette MHAL n'offre pas de service de déploiement et ne permet pas d'interopérabilité avec l'intergiciel CORBA.
Un but de l'invention est de proposer un système permettant de reconfigurer un centre de calcul embarqué composé de plusieurs processeurs, parmi lesquels certains ont des capacités de traitement fortement limitées, en déployant et en exécutant sur ces processeurs des composants logiciels aptes à communiquer entre-eux. A cet effet, l'invention a pour objet un système comportant au moins un processeur principal et une ou plusieurs unités de calcul secondaires, une infrastructure de reconfiguration exécutée sur le processeur principal pour déployer et exécuter un ou plusieurs composants logiciels sur au moins une unité de calcul secondaire, caractérisé en ce qu'au moins une unité de calcul secondaire est un processeur limité en capacité de traitement, ledit processeur exécutant une plate-forme d'accueil offrant à l'infrastructure de reconfiguration des moyens de déploiement et d'exécution de composants sur ledit processeur, lesdits moyens comprenant : ^ un moyen pour charger et/ou décharger le code objet d'un composant sur une unité de calcul, ^ un moyen pour exécuter et/ou arrêter ledit composant, ^ un moyen pour appeler les fonctions dudit composant, ^ un moyen pour connecter et/ou déconnecter un composant déployé avec d'autres composants.
Selon un mode de réalisation, l'infrastructure de reconfiguration respecte le standard OMG Software Radio , et les composants déployés via la plate-forme d'accueil réalisent l'interface Resource de ce standard. Selon un mode de réalisation, le ou les processeurs exécutant la plate-forme d'accueil sont des processeurs de signal numérique (DSP). Selon un mode de réalisation, le moyen pour charger et/ou décharger un composant sur une unité de calcul crée un fichier sur l'unité de calcul, le fichier contenant le code objet du composant à charger et une table de symboles de ce code objet afin d'effectuer une édition de liens dynamiques entre la plate-forme d'accueil et ledit composant lors de l'instanciation dudit composant sur une unité de calcul. Selon un mode de réalisation, le moyen pour connecter et/ou déconnecter un premier composant déployé avec d'autres composants déployés fait appel à un service de sérialisation croisée résidant sur l'unité de calcul de déploiement du premier composant.
D'autres caractéristiques apparaîtront à la lecture de la description 25 détaillée donnée à titre d'exemple et non limitative qui suit faite en regard de dessins annexés qui représentent : la figure 1, un synoptique d'un système comportant une plate-forme selon l'invention ; la figure 2, un synoptique illustrant un exemple de déploiement de 30 composants sur une unité de calcul pourvue d'une plate-forme selon l'invention ; la figure 3, une illustration du procédé de déploiement de composants logiciels sur une unité de calcul via une plate-forme selon l'invention ; la figure 4, un diagramme représentant un exemple de procédé de 35 chargement de code exécuté via une plate-forme selon l'invention ; - la figure 5, un diagramme représentant un exemple de procédé de déchargement de code exécuté via une plate-forme selon l'invention ; la figure 6, un diagramme représentant un exemple de procédé de création d'une instance d'un composant déployé via une plate-forme selon l'invention ; la figure 7, un diagramme représentant un exemple de procédé de destruction d'une instance d'un composant déployé via une plate-forme selon l'invention ; la figure 8, un synoptique illustrant des contraintes que doit respecter 10 un composant déployé par la plate-forme selon l'invention, la figure 9, un diagramme représentant les appels aux fonctions du composant déployé via une plate-forme selon l'invention ; la figure 10, un diagramme illustrant le référencement des ports d'un composant par une infrastructure de reconfiguration, via une plate-15 forme selon l'invention ; la figure 11, un diagramme illustrant la mise en connexion, via une plate-forme selon l'invention, d'un premier composant à un autre composant exécuté une même unité de calcul ; la figure 12, un diagramme illustrant la mise en connexion, via une 20 plate-forme selon l'invention, d'un premier composant à un autre composant exécuté sur une unité de calcul différente ; la figure 13, un synoptique résumant les étapes nécessaires à la mise en connexion de plusieurs composants via une plate-forme selon l'invention ; 25 la figure 14, un diagramme illustrant la déconnexion de composants préalablement connectés via la plate-forme selon l'invention.
Par souci de clarté, les mêmes références dans des figures différentes désignent les mêmes éléments. 30 La figure 1 présente un synoptique d'un système comportant une plate-forme selon l'invention, laquelle plate-forme sera désignée par plate-forme gF dans la suite du texte, en référence à la dénomination micro-Framework . La plate-forme F offre à l'infrastructure de reconfiguration, quel 35 que soit l'environnement d'exécution sur lequel elle s'appuie (par exemple CORBA), un support permettant de déployer dynamiquement des composants sur des processeurs limités en capacité de traitement, ces processeurs étant, dans l'exemple, des DSP, acronyme anglo-saxon pour Digital Signal Processors , c'est à dire des processeurs de signal 5 numérique. Le mode de réalisation présenté dans l'exemple s'applique plus particulièrement au cadre défini par le standard SCA et par le standard proche Platform Independant Model & Platform Specific Model for Software Radio Components , ce dernier standard étant plus simplement désigné par OMG Radio Software dans la suite du texte. Aussi, dans l'exemple, les composants respectent l'interface Resource du standard OMG Radio Software . En outre, la plate-forme gF peut être exécutée sur d'autres types de processeurs, tels que les processeurs de type ARM ( Advanced RISC Machines ). Un système 100 comporte un processeur principal 101 et une unité de calcul secondaire 102 limitée en capacité de traitement, ici un DSP 102. L'environnement d'exécution du processeur principal 101 est composé d'une couche matérielle 110a, d'un système d'exploitation 111a, et d'une couche intergicielle 112a (par exemple CORBA). L'environnement d'exécution du DSP 102 comporte une couche matérielle 110b généralement différente de la couche matérielle 110a du processeur principal 101, un système d'exploitation 111b, et une couche intergicielle 112b, ces deux derniers éléments étant également possiblement différents de ceux utilisés sur le processeur principal 101. Ainsi, le processeur principal 101 et le DSP 102 s'appuient sur des environnements d'exécution généralement dissemblables, ces différences étant notamment dues aux rôles différents qui sont attribués à ces processeurs et à leurs capacités inégales. Une infrastructure de reconfiguration 105 présente sur le processeur principal permet de reconfigurer le système en déployant des composants logiciels sur ses unités de calcul, dans l'exemple, sur le processeur principal 101 et sur le DSP 102. Ce déploiement est effectué grâce à une plate-forme F 104 présente sur chacune des unités de calcul secondaires (dans l'exemple, sur le DSP 102), cette plate-forme étant associée à une souche ExeDevice 103 sur le processeur principal 101. Quelque soient les couches intergicielles 112a, 112b utilisées sur les unités de calcul, la plate-forme F 104, détaillée plus loin, est apte à permettre le déploiement de composants logiciels.
Plus précisément, la plate-forme pF peut être mise en oeuvre dans un environnement d'exécution de type quelconque (CORBA ou autre) lorsque cet environnement offre des mécanismes de dialogue avec l'environnement d'exécution de l'infrastructure de reconfiguration. Ces mécanismes de dialogue sont désignés par le terme de connectivité croisée ou CrossConnectivité par la suite. Ainsi, les messages de l'interface ExecutableDevice et Resource sont sérialisés selon le type de connectivité croisée utilisée.
La figure 2 présente un synoptique illustrant un exemple de déploiement de composants au sein du système 100. L'infrastructure de reconfiguration 105 déploie un premier composant logiciel 106a sur le processeur principal 101 et un deuxième composant logiciel 106b sur le DSP 102. Dans l'exemple, la couche intergicielle 112a du processeur principal 101 est CORBA, et la couche intergicielle 112b du DSP 102 est constitué des services résidants de connectivité croisée 107 et de connectivité interne 108, ces services étant détaillés par la suite. Les flèches sur la figure 2 représentent les transmissions de messages au sein du système 100.
Chaque composant à exécuter par une unité de calcul est déployé dynamiquement, dans l'exemple à travers l'interface ExecutableDevice d'OMG Software Radio. Chacun de ces composants réalise l'interface Resource d'OMG Software Radio, et peut se connecter à d'autres composants logiciels ù présents sur la même unité de calcul ou des unités de calcul différentes ù via des ports de connexion, à l'image de ce qu'on trouve dans le modèle de composant CORBA. Pour rappel, la notion de port recouvre toute forme de logiciel prenant en charge l'acheminement des syntaxes métiers propre à un composant en les sérialisant sur des mécanismes de connectivité disponibles. De telles syntaxes métiers sont généralement exprimées dans des langages indépendants du langage de programmation cible utilisé pour la réalisation des composants, ces langages indépendants étant par exemple UML ( Unified Modeling Language ) ou IDL ( Interface Definition Language ).
7 Pour chaque composant déployé, une souche ExeDevice 103 est créée sur l'infrastructure de reconfiguration, cette souche mettant à disposition de l'infrastructure de reconfiguration, les fonctions de l'interface Resource et les ports du composant déployé sur l'unité de calcul. Selon un autre mode de réalisation, une seule souche est créée, cette souche prenant en charge l'ensemble des composants. La plate-forme pF 104 est un logiciel résidant sur le DSP 102 et exécutant les étapes suivantes : i. il charge le code objet d'un premier composant sur le processeur 1 o DSP 102 ; ii. il crée une instance de ce premier composant, des ports d'accès supplémentaires étant créés sur le processeur principal 101 (sur une souche d'accès spécifique à ce composant ou sur une souche d'accès commune à plusieurs composants) ; 15 iii. il connecte des ports du premier composant à des ports d'autres composants déployés, qu'ils soient chargés sur le même DSP que le premier composant ou sur un autre processeur, cet autre processeur pouvant, en outre, exécuter un environnement d'exécution différent de celui exécuté par le DSP 102 hôte du premier composant. 20 Afin de mettre en oeuvre les fonctionnalités suscitées, la plate- forme pF 104 comporte les modules suivants, comme illustré en figure 3 : o un premier module PROC Loader 104a permettant de charger et/ou de décharger le code objet d'un composant sur une unité de calcul ; 25 o un deuxième module PROC ExecutionController 104b permet d'exécuter et/ou de stopper l'exécution d'un composant déployé sur une unité de calcul ; o un troisième module PROC ResourceManager 104c permet d'accéder aux fonctions définies par l'interface Resource, interface 30 décrite, dans l'exemple, par les spécifications du standard OMG Software Radio ; o un quatrième module PROC ConnectionFactory 104d assurant la connexion des ports du composant déployé sur l'unité de calcul, d'une part, avec les ports des composants déployés sur la même unité de calcul, et d'autre part, avec les ports des composants exécutés sur d'autres unités de calcul ; o un cinquième module PROC DeviceManagement 104e assurant la réalisation des commandes allocateCapacity() et deallocateCapacity() du SCA, ainsi que la gestion des erreurs et l'auto-enregistrement auprès de l'infrastructure de reconfiguration 105, autrement dit, l'émission d'un signal par la plate-forme F 104 vers l'infrastructure de reconfiguration 105 lorsque la plate-forme F 104 est prête.
Le procédé de chargement de code d'un composant ResourceComponent sur le DSP 102 est exécuté par le module PROC Loader 104a selon un mode nominal décrit ci-après, en regard de la figure 4. Sur réception d'une requête de chargement 401 émise par la souche ExeDevice 103, la requête étant paramétrée par une taille et une référence de fichier, le module PROC Loader 104a crée un fichier Object File dans la mémoire du DSP 102, afin d'y stocker le code du composant ResourceComponent. II retourne la référence de ce fichier à la souche ExeDevice 103 présente sur le processeur principal 101 (figure 1) exécutant l'infrastructure de reconfiguration 105. Ensuite, 402, le code du composant ResourceComponent est transmis au PROC Loader 104a segment par segment, chacun desdits segments contenant la référence sur le fichier Object File, l'index du segment (commençant dans l'exemple à 0), et, pour le dernier segment, un indicateur de fin. Le code objet du composant est transmis au DSP 102 sous la forme d'un fichier au format BOFF ( Basic Object File Format ), un exemple de ce format étant fourni en annexes. Ce fichier au format BOFF contient, en plus du code objet du composant, les adresses des fonctions du composant à appeler par la plate-forme pF 104. Ce fichier permet donc d'effectuer une édition de liens dynamique au moment de la création d'une instance du composant. L'exemple du format BOFF n'est pas limitatif ; tout format permettant de transmettre le code objet du composant et d'effectuer une édition de liens dynamique à la création du composant peut être employé. Après avoir émis une requête de chargement ou un segment de fichier, la souche ExeDevice 103 attend une réponse d'acquittement du module PROC Loader 104a pendant une durée donnée. Si aucune réponse ne parvient à une requête de chargement pendant cette durée, la souche ExeDevice 103 annule le chargement. Si aucune réponse ne parvient après la transmission d'un segment de fichier, un message d'abandon est émis par la souche ExeDevice 103 vers le module FROC Loader 104a et le chargement est annulé. Par ailleurs, si le module PROC Loader 104a attend un segment de fichier pendant une durée anormalement longue, il doit abandonner le chargement et ne plus émettre de réponse vers la souche ExeDevice 103, même s'il reçoit un segment de fichier ultérieurement. En outre, dans certains cas, la réponse d'acquittement peut traduire un échec, notamment, si la référence du fichier à charger indique que le fichier a déjà été chargé auparavant ou si la création du fichier sur le DSP 102 s'est avérée impossible.
Le procédé de déchargement d'un code de composant comporte l'unique étape 501 suivante, illustrée par la figure 5 : sur réception d'une commande de déchargement, le module PROC Loader 104a supprime le fichier Object File référencé. La référence donnée en paramètre de la commande de déchargement doit être une référence utilisée lors d'une étape de chargement. Après l'étape de déchargement 501, le composant ResourceComponent ne peut plus être exécuté sur le DSP 102 tant qu'il n'a pas été chargé de nouveau.
Le module PROC ExecutionController 104b démarre ou arrête les processus ou les fils d'exécution ù souvent qualifiés par le terme anglo- saxon thread ù d'un composant chargé sur une unité de calcul. La figure 6 illustre le procédé de création d'une instance d'un composant. Sur réception d'une commande 601 de création émise par la souche ExeDevice 103, le module PROC ExecutionController 104b appelle une méthode 602 du composant ResourceComponent chargé 106b, la méthode étant ici getRscComponentO, afin de créer une instance 603 de ce composant et de retourner la référence sur cette instance. Il est à noter que le composant ResourceComponent 106 doit nécessairement implémenter la méthode getRscComponent() . Afin que la plate-forme F ait accès aux méthodes getRscComponent() et termina teRscComponentO, les adresses de ces fonctions sont précisées dans le fichier au format BOFF.
La figure 7 illustre le procédé de destruction d'une instance d'un composant. Sur réception d'une commande 701 de destruction émise par la souche ExeDevice 103, le module PROC ExecutionController 104b appelle une méthode 702 du composant ResourceComponent 106, la méthode étant ici terminateRscComponentO, afin de détruire l'instance 703 de ce composant. Il est à noter que le composant ResourceComponent doit nécessairement implémenter la méthode terminateRscComponentO .
La figure 8 illustre, par un diagramme, des contraintes que doit respecter un composant déployé par la plate-forme F, en particulier dans le cadre OMG Software Radio. Le composant 801 doit, d'une part, pour être cohérent avec le standard OMG Software Radio, réaliser l'interface Resource 802, et d'autre part, implémenter les méthodes de création et de destruction 803 susmentionnées, c'est à dire getRscComponent() et terminateRscComponentO. Dans un autre mode de réalisation hors cadre OMG Software Radio ou SCA, le composant réaliserait d'autres fonctions que celles définies par l'interface Resource.
La figure 9 illustre, par un diagramme, l'exécution de différentes opérations définies par l'interface Resource et implémentées par le composant ResourceComponent. Une commande 801 comprenant un paramètre spécifiant l'identifiant du composant à appeler, est émise par la souche ExeDevice 103 et est reçue par le module PROC ResourceManager 104c, lequel appelle, 802, la fonction correspondante dans le composant en cours d'exécution sur le DSP 102. Dans l'exemple, les opérations de l'interface Resource prises en charge par le module PROC ResourceManager 104c sont notamment les fonctions initializeO, releaseObjectO, configureO, queryO, startO, stop(), ces fonctions étant décrites dans les spécifications du standard OMG Software Radio.
Pour connecter les composants déployés entre-eux, la plate-forme fait appel au service de connectivité croisée 107 résidant sur le DSP 102, ce service pouvant être modélisé comme un sérialiseur croisé Cross-sérialiseur définissant les méthodes suivantes : o SerializerRef createCrossSerializer(ParamCrossSerializer) pour créer un sérialiseur, c'est-à-dire un objet permettant d'envoyer des données ; o deleteCrossSerializer(SerializerRef) pour détruire un sérialiseur créé précédemment ; o invocateSerializer(SerializerRef, Data) pour envoyer des données via le sérialiseur.
Par ailleurs, la plate-forme F 104 définit pour chaque port d'un composant : o une première référence Interna/Channel/d pouvant être utilisée pour 1 o connecter deux composants occupant un même espace mémoire (autrement dit, deux composants déployés sur la même unité de calcul), o une deuxième référence ExternalChannelld véhiculée à travers le service de connectivité croisée 107. Le module PROC ConnectionFactory 104d permet d'exécuter les 15 opérations getProvidedPorts( et connect() définies dans les spécifications du standard OMG Software Radio et permettant respectivement, de charger les références des ports entrants d'un composant et de connecter deux composants entre-eux. Les étapes de mise en connexion de plusieurs composants entre-eux sont détaillées ci-après. 20 La figure 10 illustre, par un diagramme, le référencement des ports d'un composant par l'infrastructure de reconfiguration, via le module PROC ConnectionFactory 104d. Dans un premier temps, une requête MF GetProvidedPortsResource() 1001 est émise par la souche ExeDevice 103 vers le module PROC ConnectionFactory 104d pour demander les ports 25 entrants d'un composant. Cette requête est paramétrée par l'identifiant componentld du composant concerné. Le module PROC ConnectionFactory 104d relaye cette requête en effectuant un appel 1002 à la fonction getProvidedPorts() du composant spécifié par l'identifiant componentld. En retour, le composant fournit au module PROC ConnectionFactory 104d_une 30 structure de données ProvidedPorts contenant les références Interna/Channelld pour chacun de ses ports entrants. Ensuite, le module PROC ConnectionFactory 104d fait appel 1003, via la fonction CreateCrosslnitializerO, aux services de connectivité croisée 107 pour créer un désérialiseur, c'est à dire un canal de communication pour 35 chacune des références sur les ports entrants du composant. Ce canal est, par exemple, un connecteur réseau (ou socket ) paramétré, par une adresse IP, un numéro de port et la référence ExternalChannelld créée par la fonction CreateCrosslnitializerO. Le port entrant est ensuite associé au canal par un appel 1004 à la fonction SubscribelnitializerO, laquelle prend comme paramètre la référence ref du canal créé précédemment et la référence du port entrant Portln. Les désérialiseurs sont supprimés par le module PROC ResourceManager 104c sur réception d'une demande de désallocation releaseObjectO.
La figure 11 illustre par un diagramme la connexion d'un premier composant à un second composant exécuté sur la même unité de calcul. La connexion est effectuée en deux étapes. Dans un premier temps, une requête ConnectPortResource() 1101 est envoyé par la souche ExeDevice 103 vers le module PROC ConnectionFactory 104d. Cette requête est paramétrée par l'identifiant componentld du composant concerné. Dans un deuxième temps, le module PROC ConnectionFactory 104d relaye la requête 1101 par un appel 1102 à la fonction connectPortO du composant spécifié par l'identifiant componentld. Cet appel 1102 à la fonction connectPort() est paramétré par la référence requiredPortld du port sortant du premier composant et par la référence connection du port entrant du second composant. La référence connection du deuxième composant est obtenue grâce à la fonction getProvidedPortsO illustrée dans la figure 10. Dans l'exemple, un troisième paramètre connectionld est un identifiant de la connexion entre ces deux composants.
La figure 12 illustre par un diagramme la mise en connexion d'un premier composant avec un autre composant exécuté sur une unité de calcul différente.
La connexion est effectuée en trois étapes. Dans un premier temps, une requête MF ConnectExternalPort() 1201 est envoyée par la souche ExeDevice 103 vers le module PROC ConnectionFactory 104d. Cette requête est paramétrée par l'identifiant componentld du composant concerné. Dans un deuxième temps, un sérialiseur est créé via la fonction CreateCrossSerializer() en passant en paramètre la référence du port entrant du second composant ainsi que les paramètres de connexions (adresse IP, numéro de port), la référence de ce sérialiseur étant retournée. Dans un troisième temps, le module PROC ConnectionFactory 104d relaye la requête MF ConnectExternalPort() 1201 par un appel 1203 à la fonction connectPortO du composant spécifié par l'identifiant componentld. Cet appel 1203 à la fonction connectPort() est paramétré par la référence requiredPortld du port sortant du premier composant et par la référence serializerdu sérialiseur afin de connecter ce port sortant avec le sérialiseur.
Une réponse d'acquittement du module PROC ConnectionFactory 104d vers la souche ExeDevice 103 indiquant un échec de la connexion survient lorsque la référence du composant est inconnue et/ou lorsque la référence du port spécifié est inconnue.
La figure 13 résume, par un synoptique, les étapes décrites en figures 10, 11 et 12. Un système 1300 comporte une infrastructure de reconfiguration 1303 et deux unités de calcul 1301, 1302 sur lesquelles sont déployés des composants. La première unité de calcul 1301 exécute un premier composant 1311 et un deuxième composant 1312, tandis que la deuxième unité de calcul 1302 exécute un seul et troisième composant 1313. Il est souhaité de connecter le deuxième composant 1312 déployé sur la première unité de calcul 1301 avec les deux autres composants 1311, 1313. Dans un premier temps, un appel à la fonction getProvidedPortsO permet d'obtenir les références des ports entrants du deuxième composant 1312 et de créer un désérialiseur 1332a, 1332b sur la première unité de calcul 1301 pour chacun de ces ports. Dans un deuxième temps, un appel à la fonction ConnectPortResourceO permet au premier composant 1311 de connecter un de ses ports sortant 1321 à un port entrant 1322a du deuxième composant 1312. Il s'agit d'une connexion avec une référence de port entrant de type InternalChannelld. Les messages véhiculés entre le premier 1311 et le deuxième composant 1312 ne sont pas sérialisés, donc le premier désérialiseur 1331 créé pour ce premier port 1322a n'est pas utilisé. Dans un troisième temps, un appel à la fonction MF ConnectExternalO permet au troisième composant 1313, exécuté sur une autre unité de calcul que le deuxième composant 1312, de connecter un de ses ports sortant 1323 à un port entrant 1322b de ce deuxième composant 1312 via un sérialiseur. Ce sérialiseur 1333 est créé sur la deuxième unité de calcul 1302. Il s'agit d'une connexion avec une référence de port entrant de type Externa/Channelld.
La figure 14 illustre les étapes permettant de supprimer les connexions créées avec les fonctions ConnectPortResource() et MF ConnectExternalO.
Sur réception d'une demande de déconnexion MF DisconnectPortResource() 1401 paramétrée par l'identifiant componentld du composant concerné par les déconnexions, le module PROC ConnectionFactory 104d supprime chaque connexion. Si une connexion a été établie avec la commande de connexion externe MF ConnectExternalPort(), le module PROC ConnectionFactory 104d supprime le sérialiseur 1403 correspondant.
Un avantage du système selon l'invention est qu'il permet d'utiliser peu de ressources de mémoire, car il ne repose pas nécessairement sur un intergiciel lourd tel que CORBA. De plus, le système ne nécessite pas de modification de l'infrastructure de reconfiguration et peut être porté sur de multiples environnements d'exécution.
ANNEXES
Fichier BOFF Un fichier au format BOFF est un fichier contenant les informations nécessaires à 5 l'édition de liens dynamique du code pendant son exécution. La table ci-dessous expose la structure générale d'un tel fichier : L'entête est basée sur l'entête d'un fichier COFF (Common object File Format) ; 10 néanmoins, quelques champs y prennent une signification différente. typedef struct { unsigned short f_magic; /* magic number */ unsigned short f_nscns; /* number of sections */ unsigned long f_timdat; /* time & date stamp pointer 15 unsigned long f_symptr; /* file pointer to symtab */ unsigned long f_nsyms; /* number of symtab entries */ unsigned short f_opthdr; /* sizeof(optional hdr) */ unsigned short f_flags; /* flags */ } BOFF_FILHDR; 20 La structure ci-dessus est en début de l'objet.
f magic û nombre magique magic number Ce champ contient une valeur constante commune à tous les fichiers au 25 format BOFF, ce qui permet d'identifier le fichier comme étant au format BOFF.. File Header Optional Information Symbol Table Section 1 Header Section n Header Raw Data for Section 1 Raw Data for Section n String Table f nscns ù nombre de sections Le nombre de sections (et donc d'entêtes de sections) contenues dans ce fichier. f timdat ù pointeur d'heure et de date de création Le pointeur indique l'heure et la date de la création du fichier BOFF.
f svmptr ù pointeur de la table de symboles Le pointeur de la table de symboles. f nsyms ù nombre de symboles dans la table Le nombre de symboles dans la table de symboles.
f opthdr ù taille de l'entête optionnelle 15 Le nombre d'octets supplémentaires suivant l'entête du fichier, avant que la section des symboles commence.
f flags - drapeaux Ces drapeaux fournissent des informations supplémentaires concernant l'état de ce 20 fichier BOFF (fichier exécutable ou fichier objet, codage du fichier 32bits ou non)
Entête optionnelle du fichier BOFF L'entête optionnelle suit immédiatement l'entête du fichier BOFF. La taille de cette entête est stockée dans le champ f_opthdr de l'entête. Ce nombre d'octets doit être 25 lu quelque soit la taille attendue de l'entête optionnelle.
Exemple d'entête de forme d'onde optionnelle : typedef struct { unsigned short magic; /* type of file */ 30 unsigned long f_infosymptr; /* file info pointer char vstamp[10]; /* version stamp */ unsigned long checksum; /* checksum on data of the file */ } WF_OPTHDR;
35 magic ù nombre magique "magic number"10 L'octet de poids fort représente le type de l'entête optionnelle. L'octet de poids faible représente la version du format utilisé
f_infosymptr - pointeur de symbole d'information du fichier vstamp û chaîne de caractère de version L'indicateur de version.
Somme de contrôle - CRC (Cvclic Redundancv Code 10 La somme de contrôle est un CRC calculé avec le polynôme suivant : x16+x12+x5+1 Le calcul démarre à l'entête du premier symbole et se termine à la fin du fichier.
Table de symboles du fichier BOFF 15 Structure de symbole : typedef struct { char symbName[E_SYMNMLEN]; unsigned short s_use; unsigned long e_value; 20 } BOFF_SYMENT; E SYMNMLEN = 20
symbName û le nom du symbole
25 s use û le tvoe de symbole Le type de symbole peut être spécifié ici, mais les valeurs dépendent de l'application qui utilise le fichier. Seules les valeurs comprises entre 0 et 15 sont utilisées pour la définition BOFF.
30 La table ci-dessous donne les significations des valeurs de ce champ pour la version 2.0 de BOFF : 0x00 Réservé 0x01 Symbole externe 0x02 Symbole utilisé interne, normalement non par5 l'application 0x03-OxF Réservé e value û la valeur du symbole Par exemple, si le symbole représente une fonction, il contient l'adresse de la fonction. La signification de la valeur dépend du type du symbole, lequel est 5 uniquement connu de l'utilisateur du fichier ou bien spécifié dans le champ s_use. typedef struct { char s_name[E_SECTNMLEN]; /* section name */ unsigned long s_paddr; /* physical address, aliased s_nlib */ unsigned long s_size; /* section size */ unsigned long s_used; /* section used */ unsigned long s_loaded; /* section loaded */ unsigned long s_scnptr; /* file ptr to raw data for section */ unsigned long s_flags; /* flags */ }SCNHDR; E_SECTNMLEN = 20 Cette structure suit immédiatement une table de symboles dans le fichier BOFF. 20 s name ù nom de section Le nom de la section.
s paddr ù adresse physique du bloc de données Adresse à laquelle le bloc de données doit être chargé en mémoire. Pour les 25 exécutables, ceci est l'adresse absolue dans l'espace de programme. Pour les objets non liés, cette adresse est relative à l'adresse mémoire de l'objet (c'est à dire la première section commence à l'offset zéro).
s vaddr û adresse virtuelle de la section de données 30 Pour cette version, ce champ contient toujours la même valeur que s_paddr.
s size û taille de la section de données Le nombre d'octets de données stockées dans le fichier pour cette section. Entête de section BOFF 10 15 s used ù section de données utilisée
s loaded ù section de données chargée s scnptr ù pointeur de la section de données Adresse de la section de données dans le fichier.
s flacs ù bits de drapeaux Ces drapeaux fournissent des informations supplémentaires pour chaque bloc. Bit Nom Signification 0x0020 STYP_TEXT Si ce drapeau est activé, il indique que cette section ne contient que du code exécutable. 0x0040 STYP_DATA Si ce drapeau est activé, il indique que cette section ne contient que des données initialisées 0x0080 STYP_BSS Si ce drapeau est activé, il indique que cette section ne contient que des données non initialisées et n'a pas de données stockées dans le fichier BOFF. 19
Claims (5)
1. Système distribué (100) comportant au moins un processeur principal (101) et une ou plusieurs unités de calcul secondaires (102), une infrastructure de reconfiguration (105) exécutée sur le processeur principal (101) pour déployer et exécuter un ou plusieurs composants logiciels (106a, 106b) sur au moins une unité de calcul secondaire (102), caractérisé en ce qu'au moins une unité de calcul secondaire est un processeur limité en capacité de traitement, ledit processeur exécutant une plate-forme d'accueil (104) offrant à l'infrastructure de reconfiguration des moyens de déploiement et d'exécution de composants sur ledit processeur, lesdits moyens comprenant: un moyen (104a) pour charger et/ou décharger le code objet d'un composant sur une unité de calcul, ^ un moyen (104b) pour exécuter et/ou arrêter ledit composant, ^ un moyen (104c) pour appeler les fonctions dudit composant, ^ un moyen (104d) pour connecter et/ou déconnecter un composant déployé avec d'autres composants.
2. Système selon la revendication 1, l'infrastructure de reconfiguration (105) respectant le standard OMG Software Radio , caractérisé en ce que, les composants (106a, 106b) déployés via la plate-forme d'accueil (104) réalisent l'interface Resource de ce standard.
3. Système selon l'une des revendications précédentes, caractérisé en ce que le ou les processeurs (102) exécutant la plate-forme d'accueil (104) sont des processeurs de signal numérique (DSP).
4. Système selon l'une des revendications précédentes, caractérisé en ce que le moyen (104a) pour charger et/ou décharger un composant (106b) sur une unité de calcul (102), crée un fichier sur l'unité de calcul (102), le fichier contenant le code objet du composant à charger et une table de symboles de ce code objet afin d'effectuer une édition de liens dynamiques entre la plate-forme d'accueil (104) et ledit composant (106b)lors de l'instanciation dudit composant (106b) sur une unité de calcul (102).
5. Système selon l'une des revendications précédentes, caractérisé en ce que le moyen (104d) pour connecter et/ou déconnecter un premier composant déployé avec d'autres composants déployés fait appel à un service de sérialisation croisée (107) résidant sur l'unité de calcul (102) de déploiement du premier composant.
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0707685A FR2923042B1 (fr) | 2007-10-31 | 2007-10-31 | Systeme pour le deploiement de composants logiciels sur des unites de calcul limitees en capacite de traitement. |
| EP08844106A EP2208134A1 (fr) | 2007-10-31 | 2008-10-30 | Systeme pour le deploiement de composants logiciels sur des unites de calcul limitees en capacite de traitement |
| US12/740,814 US20100325627A1 (en) | 2007-10-31 | 2008-10-30 | System for Deploying Software Components on Computation Units that are Limited in Terms of Processing Capacity |
| CA2704295A CA2704295A1 (fr) | 2007-10-31 | 2008-10-30 | Systeme pour le deploiement de composants logiciels sur des unites de calcul limitees en capacite de traitement |
| PCT/EP2008/064748 WO2009056607A1 (fr) | 2007-10-31 | 2008-10-30 | Systeme pour le deploiement de composants logiciels sur des unites de calcul limitees en capacite de traitement |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0707685A FR2923042B1 (fr) | 2007-10-31 | 2007-10-31 | Systeme pour le deploiement de composants logiciels sur des unites de calcul limitees en capacite de traitement. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2923042A1 true FR2923042A1 (fr) | 2009-05-01 |
| FR2923042B1 FR2923042B1 (fr) | 2010-12-31 |
Family
ID=39580239
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0707685A Active FR2923042B1 (fr) | 2007-10-31 | 2007-10-31 | Systeme pour le deploiement de composants logiciels sur des unites de calcul limitees en capacite de traitement. |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US20100325627A1 (fr) |
| EP (1) | EP2208134A1 (fr) |
| CA (1) | CA2704295A1 (fr) |
| FR (1) | FR2923042B1 (fr) |
| WO (1) | WO2009056607A1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2994753A1 (fr) * | 2012-08-24 | 2014-02-28 | Thales Sa | Procede de mise en oeuvre de transactions decentralisees pour un systeme temps reel embarque a base de composants |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9388414B2 (en) | 2008-10-08 | 2016-07-12 | Trustees Of Dartmouth College | Method for selectively inhibiting ACAT1 in the treatment of neurodegenerative diseases |
| US8584120B2 (en) * | 2009-11-23 | 2013-11-12 | Julian Michael Urbach | Stream-based software application delivery and launching system |
| CN102148800B (zh) * | 2010-02-09 | 2014-06-18 | 中国人民解放军总参谋部第六十一研究所 | 基于面向服务架构的软件无线电系统 |
| DE102011079271A1 (de) * | 2011-07-15 | 2013-01-17 | Siemens Aktiengesellschaft | Verfahren zum softwaremäßigen Laden einer Rechnereinheit einer Unterkomponente einer aus mehreren Komponenten mit unterschiedlichen Unterkomponenten bestehenden Anordnung |
| CN102243596A (zh) * | 2011-08-09 | 2011-11-16 | 复旦大学 | 一种自适应动态代码卸载方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040215700A1 (en) * | 2002-12-26 | 2004-10-28 | Michael Shenfield | System and method for building and execution of platform-neutral generic services' client applications |
| US20050108382A1 (en) * | 2003-11-17 | 2005-05-19 | Sca Technica, Inc. | Lightweight, high performance, remote reconfigurable communications terminal architecture |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| IL160057A0 (en) * | 2001-07-27 | 2004-06-20 | Raytheon Co | Radio system utilizing open systems software support |
| US7404074B2 (en) * | 2002-07-12 | 2008-07-22 | Sca Technica, Inc. | Self-booting software defined radio module |
| EP1680900B1 (fr) * | 2003-10-29 | 2012-05-09 | Nokia Corporation | Moteur de protocole configurable |
-
2007
- 2007-10-31 FR FR0707685A patent/FR2923042B1/fr active Active
-
2008
- 2008-10-30 WO PCT/EP2008/064748 patent/WO2009056607A1/fr active Application Filing
- 2008-10-30 EP EP08844106A patent/EP2208134A1/fr not_active Withdrawn
- 2008-10-30 US US12/740,814 patent/US20100325627A1/en not_active Abandoned
- 2008-10-30 CA CA2704295A patent/CA2704295A1/fr not_active Abandoned
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040215700A1 (en) * | 2002-12-26 | 2004-10-28 | Michael Shenfield | System and method for building and execution of platform-neutral generic services' client applications |
| US20050108382A1 (en) * | 2003-11-17 | 2005-05-19 | Sca Technica, Inc. | Lightweight, high performance, remote reconfigurable communications terminal architecture |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2994753A1 (fr) * | 2012-08-24 | 2014-02-28 | Thales Sa | Procede de mise en oeuvre de transactions decentralisees pour un systeme temps reel embarque a base de composants |
Also Published As
| Publication number | Publication date |
|---|---|
| CA2704295A1 (fr) | 2009-05-07 |
| US20100325627A1 (en) | 2010-12-23 |
| FR2923042B1 (fr) | 2010-12-31 |
| WO2009056607A1 (fr) | 2009-05-07 |
| EP2208134A1 (fr) | 2010-07-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110032392B (zh) | 服务治理方法及装置、存储介质和电子设备 | |
| EP0599706B1 (fr) | Dispositif de traitement de l'information permettant la gestion d'une ressource informatique par un système d'administration | |
| FR2923042A1 (fr) | Systeme pour le deploiement de composants logiciels sur des unites de calcul limitees en capacite de traitement. | |
| CN110389936A (zh) | 一种启动小程序的方法、设备和计算机存储介质 | |
| EP1395962B1 (fr) | Deploiement d'application depuis une carte a puce | |
| FR2947644A1 (fr) | Procede de demarrage d'un dispositif informatique dans un reseau, serveur et reseau de dispositifs informatiques pour sa mise en oeuvre | |
| US20100125640A1 (en) | Traffic Management Apparatus | |
| CN108551481A (zh) | 一种文件上传方法、装置、服务器及存储介质 | |
| EP1415454B1 (fr) | Procede et dispositif de mise en compatibilite de communication sur reseau de terminaux, par exemple pour permettre un dialogue avec une application sur carte a puce | |
| EP1958418B1 (fr) | Entite electronique portable destinee a etablir une communication voix sur ip securisee | |
| CN109150956A (zh) | 一种推送sdk的实现方法、装置、设备和计算机存储介质 | |
| CA2449260A1 (fr) | Systeme et procede pour la distribution dynamique de donnees et/ou de services | |
| FR2765363A1 (fr) | Procede et systeme de controle de l'utilisation d'un logiciel | |
| CN116418791A (zh) | 固件升级方法、固件升级系统、服务器及存储介质 | |
| CN111459819B (zh) | 软件测试方法及装置、电子设备、计算机可读介质 | |
| FR2938944A1 (fr) | Procede et systeme pour la transformation de composants logiciel ccm en composants deployables dans un environnement compatible du standard sca. | |
| FR2826747A1 (fr) | Procede et dispositif de traitement de donnees pour la personnalisation d'une application sur un dispositif communicant portatif, par exemple une carte a puce | |
| EP0599681B1 (fr) | Outil de simulation d'un code de réseau | |
| US20230084856A1 (en) | Integrated view of local and cloud files | |
| CN108304340B (zh) | 基于usb设备的透传方法、装置和系统 | |
| EP1508237B1 (fr) | Protocole de communication entre un module d'application vocale et une plate-forme vocale dans un serveur vocal | |
| WO2006045814A1 (fr) | Systeme d'appel de services locaux d'au moins une application locale a architecture de messagerie classique a partir d'au moins une application distante a architecture de messagerie classique | |
| WO2002008897A1 (fr) | Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant | |
| CN118536114A (zh) | 一种防病毒方法、装置、设备及计算机可读存储介质 | |
| CN113778969A (zh) | 一种日志处理方法和装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 10 |
|
| PLFP | Fee payment |
Year of fee payment: 11 |
|
| PLFP | Fee payment |
Year of fee payment: 12 |
|
| PLFP | Fee payment |
Year of fee payment: 13 |
|
| PLFP | Fee payment |
Year of fee payment: 14 |
|
| PLFP | Fee payment |
Year of fee payment: 15 |
|
| PLFP | Fee payment |
Year of fee payment: 16 |
|
| PLFP | Fee payment |
Year of fee payment: 17 |
|
| PLFP | Fee payment |
Year of fee payment: 18 |