Brevet FR2938944A1 — publié le 20100528

PROCEDE ET SYSTEME POUR LA TRANSFORMATION DE COMPOSANTS LOGICIEL CCM EN COMPOSANTS DEPLOYABLES DANS UN ENVIRONNEMENT COMPATIBLE DU STANDARD SCA La présente invention concerne un procédé et un système permettant la transformation d'un composant logiciel normalisé par le standard CCM en un composant déployable dans une infrastructure logicielle compatible du standard SCA. Elle est utilisée dans le cadre d'infrastructures (framework) à composant logiciel embarqué temps-réel notamment pour le domaine de la radio logicielle. L'architecture SCA (Software Communication Architecture) est un standard de référence pour les applications radio-logicielles et devient incontournable dans de nombreux contextes de projets industriels. Cette architecture définit une infrastructure logicielle nommée Core Framework SCA ou CF-SCA qui permet de déployer et de configurer des modules de forme d'onde sur une plate-forme radio. Par souci de clarté, dans la suite du texte, le terme composant SCA désignera un composant logiciel déployable dans une architecture SCA. Le standard LwCCM (� Lightweight CORBA Component Model �) du groupe de standardisation OMG (� Object Management Group �) est un standard générique applicable à de nombreux domaines d'application. Il représente l'état de l'art actuel des approches de développement de logiciels temps-réel et embarqués par assemblage de composants. II repose, en particulier, sur les normes CORBA (� Common Object Request Broker Architecture �) et CCM (� CORBA Component Model �). Par souci de clarté, dans la suite du texte, le terme composant CCM désignera un composant logiciel déployable dans une infrastructure compatible du standard LwCCM. Le standard LwCCM est un sous ensemble du standard CCM (�CORBA 3o Component �) qui définit : • la structure d'un composant comme entité de conception, d'implémentation, de déploiement et d'exécution. • des modes d'interaction prédéfinis. • des mécanismes de déploiement et d'exécution. Deux standards additionnels permettent d'étendre le standard LwCCM : • le standard de qualité de service pour le modèle de composant CCM, QoS pour CCM (� Quality of Service for CORBA Component Model �) permet de définir une interface d'intégration de services techniques additionnels, sous la forme de conteneurs ouverts pour une plus grande flexibilité des composants et une meilleure séparation entre le code métier et le code technique. Ces conteneurs contiennent l'ensemble du code source non fonctionnel. • le standard de service de distribution de données pour le modèle de composant CORBA (en cours de standardisation), DDS pour CCM (� Data Distribution Service for CORBA Component Model �) qui permet de définir et d'implémenter des connecteurs génériques afin de mettre en place des modes de communication spécialisés et de haut niveau entre les composants. Ces trois standards, qui représentent l'état de l'art en informatique des systèmes à base de composants logiciels temps-réels et embarqués, peuvent être utilisés pour compléter le standard SCA (� Software Communication Architecture �) Ils complètent ce dernier en permettant par exemple : • Par le biais des composants logiciels de la norme LwCCM, de concevoir, d'implémenter, de déployer et d'exécuter des modules de forme d'onde radio selon une approche standard et partagée par la communauté logicielle et les fournisseurs de solutions commercialisées pour le grand public. • Par le biais des connecteurs génériques spécifiés par le standard DDS pour CCM, de définir et d'implémenter des mécanismes et des interfaces d'échanges spécialisés pour le monde de la radio logicielle. • Par le biais des conteneurs ouverts (QoS pour CCM), de définir et d'abstraire de manière générique la plateforme d'exécution sous- jacente (matérielle et logicielle) et pouvoir choisir entre une plate-forme compatible du standard SCA ou non. Du point de vue de l'état de l'art et de la pratique en informatique des logiciels temps-réel, l'infrastructure logicielle CF-SCA, présente des limitations: • La définition du modèle de composants SCA est restreinte en ce que: o II n'existe pas de sémantique d'interaction entre les composants SCA: il n'est pas possible de définir de manière générique la sémantique des échanges (données et 1 o comportement) entre des composants SCA implémentant, par exemple, des traitements algorithmiques relatifs à une forme d'onde radio. Cette description est laissée à l'initiative du développeur et prend des formes spécifiques et propriétaires. o Il n'existe pas de séparation formelle entre le code fonctionnel 15 (par exemple du code source implémentant des modules d'algorithmie relative à une forme d'onde radio) et le code non fonctionnel (par exemple, activation, séquencement, gestion de flux, communication..). L'intégration d'aspects non fonctionnels (usage du standard CORBA par exemple) se fait dans le code 20 métier du composant. • Le standard SCA impose l'utilisation d'un bus logiciel de type CORBA pour le déploiement d'applications radio développées sur une infrastructure logicielle conforme dudit standard. Ce point constitue une réponse coûteuse pour des plateformes matérielles limitées en 25 capacité de traitement et mémoire disponible. Par construction, l'approche adoptée par le standard LwCCM n'est pas compatible nativement d'une infrastructure SCA. Un des buts de l'invention est de rendre possible le portage d'un composant 30 logiciel CCM sur une architecture SCA en implémentant les opérations nécessaires à la transformation dudit composant CCM en un nouveau composant compatible du standard SCA. A cet effet, l'invention a pour objet un procédé de transformation d'un composant logiciel défini par le standard � CCM � comportant un conteneur réalisant l'interface externe du composant � Components :: CCMObject �, un exécuteur réalisant le code fonctionnel dudit composant et une entité logicielle permettant la gestion des ressources du composant et réalisant une interface standard � Components :: CCMHome �, en un composant compatible du standard �SCA � comportant au moins une interface externe � CF ::Resource �, caractérisé en ce que ledit procédé comporte au moins les étapes suivantes : Etape 1 : remplacer le conteneur réalisant l'interface �Components CCMObject � définie par le standard � CCM � par un conteneur réalisant l'interface � CF :: Resource � définie par le standard � SCA � - Etape 2 : supprimer l'implémentation de l'interface � Components :: CCMHome � définie par le standard � CCM � Etape 3 : implémenter un composant logiciel exécutant la fonction de fabrique de composants � SCA � permettant d'instancier et de gérer le 15 cycle de vie du nouveau composant SCA généré. Etape 4: implémenter des moyens permettant de rediriger les connexions entre un nouveau composant � SCA � généré et son environnement extérieur vers l'exécuteur du composant � CCM �. 20 Selon un mode de réalisation, les étapes 1 et 2 sont effectuées au moyen d'un générateur adapté réalisant une transformation de la description du composant � CCM � vers la description du nouveau composant � SCA �. Selon un mode de réalisation, la description du composant � CCM � est effectuée en langage IDL3 pour � Interface Description Language 3 �. 25 L'invention a également pour objet un système comportant au moins un processeur principal ,un ou plusieurs processeurs secondaires, une infrastructure logicielle de type � Core Framework � définie par le standard � SCA � exécutée sur le processeur principal ,un ou plusieurs composants 30 � SCA � déployés sur le ou les processeurs secondaires et un ou plusieurs fichiers de description du plan de déploiement desdits composants caractérisé en ce que lesdits composants sont obtenus via les étapes du procédé décrites précédemment. Selon un mode de réalisation, le ou les fichiers de description du plan de déploiement sont obtenus par transformation des fichiers équivalents décrivant le plan de déploiement des composants � CCM �. Selon un mode de réalisation, le processeur sur lequel est déployé le composant logiciel � CCM � est un processeur générique (GPP) ou un processeur de signal numérique (DSP) ou un processeur reconfigurable (FPGA). Selon un mode de réalisation, le composant logiciel � CCM � exécute un module de forme d'onde radio et le système considéré est une plate-forme 1 o radio logicielle. L'invention a également pour objet une utilisation du procédé ou du système décrits précédemment caractérisée en ce que le conteneur réalisant l'interface � CF :: Resource � et l'exécuteur du composant � CCM � sont 15 déployés sur deux processeurs différents. Selon un mode de réalisation, le déploiement des composants � SCA � sur des processeurs secondaires est obtenu via une transformation du ou des fichiers de description du plan de déploiement des composants � CCM �. 20 D'autres caractéristiques apparaitront à la lecture de la description 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écrivant un procédé selon l'invention 25 permettant le déploiement de composants logiciel CCM dans un environnement compatible du standard SCA à partir du plan de déploiement de ces mêmes composants dans un environnement non compatible de ce même standard. La figure 2 ; un synoptique décrivant les moyens mis en oeuvre 30 pour réaliser la transformation d'un composant logiciel CCM en un composant standard SCA via un procédé selon l'invention. La figure 3 ; un synoptique d'un système mettant en oeuvre un procédé selon l'invention. La figure 1 schématise le déploiement d'un ou plusieurs composants logiciel CCM 101 à 103, qui peuvent être des composants de forme d'onde radio, dans un environnement non conforme au standard SCA, par exemple une infrastructure 100 compatible du standard de déploiement et configuration (D&C) ainsi que la transformation opérée pour porter ces mêmes composants logiciel 101 à 103 vers un environnement compatible du standard SCA, par exemple une infrastructure logicielle coeur � Core Framework � 105. La communication entre différents composants CCM se fait via l'utilisation de ports entrant 101a qui peuvent être par exemple des facettes, terme standardisé qui désigne les services fournis au composant, ou de ports sortant 101b qui peuvent être par exemple des réceptacles, terme standardisé qui désigne les services requis par le composant. Un composant logiciel CCM 101 contient un exécuteur 106a sur lequel est développé un code source fonctionnel, par exemple un code source implémentant un traitement de forme d'onde radio. Un but du procédé selon l'invention est de permettre de conserver intact le code fonctionnel développé dans cet exécuteur lors du portage dans un environnement SCA. Le procédé consiste notamment à remplacer les interfaces logicielles standard � Components :: CCMObject � nécessaires au déploiement de composants logiciel CCM sur une infrastructure D&C par des interfaces équivalentes � CF ::Resource � compatibles d'une infrastructure logicielle standard SCA . Les nouvelles interfaces �CF :: Resource � ainsi générées sont représentées sur la figure 1 par les références 106 à 108, elles encapsulent les exécuteurs 106a, 107a et 108a provenant des composants CCM 101, 102 et 103. Le déploiement des composants CCM dans l'infrastructure 100 se fait via un ou plusieurs fichiers de description 104 écrit par exemple, en langage de description XML (langage de balisage extensible) respectant la sémantique d'un plan de déploiement CDP pour � Component Deployment Plan �. Afin de procéder au déploiement des composants SCA obtenus après transformation via le procédé selon l'invention dans l'infrastructure logicielle SCA 105, il faut générer un ou plusieurs fichiers descripteurs nécessaires, par exemple, un fichier descripteur 109 SAD ( Software Application Descriptor) à partir soit d'une approche de type MDE (Mode) Driven Engineering ), soit les générer par transformation des descripteurs de déploiement CCM 104. Les figures 2a et 2b présentent un synoptique détaillant les opérations mises 5 en oeuvre lors de la transformation d'un composant CCM en un composant SCA selon un mode de réalisation. Un composant CCM 102 contient un exécuteur 107a sur lequel est développé le code fonctionnel, un conteneur 201 qui réalise l'interface standard � Components :: CCMObject � et un contexte 203. Le terme 10 contexte faisant référence ici au terme standardisé par la norme LwCCM et correspondant à une entité logicielle réalisant l'interface Contexte, ladite interface permettant de fournir à l'exécuteur CCM toutes les informations de l'environnement extérieur nécessaires à la communication avec d'autres composants. Une entité logicielle 202 qui réalise l'interface � Components 15 CCMHome � permet la gestion du cycle de vie de ce composant. Après transformation par le procédé selon l'invention, le composant résultant comprend toujours l'exécuteur 107a, le contexte 203 et un conteneur 107 qui réalise l'interface � CF :: Resource � dans le nouvel environnement. Une entité logicielle 204 qui réalise l'interface � CF :: ResourceFactory � offre un 20 rôle similaire à l'entité 202 tout en étant compatible du standard SCA. Dans la suite du texte l'acronyme IDL3 fera référence au langage de description de composants utilisé pour décrire un composant CCM, et l'acronyme IDL au langage de description d'interface permettant de décrire les interfaces équivalentes des composants CCM et SCA. 25 Selon un mode de réalisation, la transformation mise en oeuvre par le procédé selon l'invention est effectuée selon plusieurs étapes successives. Une première étape à réaliser consiste à modifier les règles de transformation d'IDL3 vers IDL et le générateur associé de façon à : remplacer l'héritage de l'interface � Components :: CCMObject � 30 par l'héritage de l'interface � CF :: Resource � dans la définition équivalente du composant CCM. inclure les définitions de l'infrastructure � Core Framework � SCA dans lesdites règles. supprimer l'entité logicielle 202 réalisant l'interface 35 � Components :: CCMHome � Une seconde étape consiste à générer une fabrique de composants 204 réalisant l'interface � CF :: ResourceFactory � qui permet de gérer le cycle de vie des composants SCA et qui remplace l'entité logicielle 202 réalisant l'interface � Components :: CCMHome �. Ensuite, à partir de la définition équivalente IDL du composant CCM, le code source du nouveau composant SCA peut être généré. La première étape à réaliser pour construire ce nouveau composant est d'implémenter le conteneur 107 réalisant la nouvelle interface � CF :: io Resource �. Ledit conteneur 107 doit pouvoir communiquer avec d'autres composants distants, il est donc nécessaire de rediriger les requêtes reçues par le composant SCA via ses ports entrants ou sortants vers le composant CCM et inversement selon les étapes suivantes : Ajouter un port sortant SCA 208 (réalisant l'interface � CF :: Port � 15 du standard SCA) équivalent du port sortant CCM 207 utilisé par le composant CCM. Ce port SCA est utilisé par l'infrastructure � Core Framework � pour réaliser les connexions spécifiées dans le fichier descripteur SAD généré (via une opération de type CF::Port::connectPortO) avec les ports d'entrée SCA des autres 20 composants SCA. Ajouter un port entrant SCA 205 équivalent du port entrant CCM existant 206. Ledit port doit réaliser et enregistrer dans le bus logiciel CORBA la même interface IDL que celle du port entrant CCM associé. Il reçoit les requêtes provenant des composants 25 clients distants et les redirigent vers le code fonctionnel de l'exécuteur CCM. Implémenter une connexion 209 entre le port de sortie SCA et le contexte CCM afin de transmettre les requêtes CCM faites en local par l'exécuteur sur le contexte CCM en des requêtes SCA 30 envoyées du port de sortie SCA au port SCA d'entrée du composant SCA appelé. Modifier l'implémentation du contexte CCM 203 utilisé en local par le composant CCM de façon à le faire interagir avec les ports SCA 205 et 208 du composant SCA. Implémenter une opération d'initialisation du conteneur 107 de type LifeCycle :: initialize() en exécutant au moins une opération d'initialisation du contexte 203 de type SessionComponent ::set session_context() fournie par l'exécuteur du composant CCM. Implémenter une opération d'initialisation pour chacun des ports d'entrée et sortie 205 et 208 de type CF :: PortSupplier:: getPortO. Cette opération est paramétrée par l'identifiant name et elle retourne la référence d'objet CORBA du port SCA enregistré dans le bus logiciel CORBA et correspondant à l'identifiant name passé en argument. Implémenter une opération de connexion du port d'entrée SCA 205 créé vers le bus logiciel CORBA, de type CF ::Port ::connectPortO. Cette opération est paramétrée par l'identifiant convection qui correspond à la référence d'objet CORBA du port d'entrée SCA 205 .Elle implémente un transfert de ladite référence au contexte CCM 203 afin de mettre cette référence à disposition de l'exécuteur CCM 107a. Implémenter une opération de configuration du nouveau composant, de type PropertySet ::configurep, en redirigeant les valeurs des paramètres de configuration provenant de l'infrastructure logicielle � Core Framework � SCA vers l'exécuteur du composant CCM en utilisant les accesseurs associés à chacun des paramètres de configuration. Implémenter une opération de type Resource :: start() permettant l'activation du nouveau composant SCA, en commençant par appeler une opération de type CCMObject ::configuration complete() puis une opération de type SessionComponent::ccm_activate() fournies toutes deux par l'exécuteur du composant CCM. Implémenter une opération de type Resource :: stop(), permettant la désactivation du nouveau composant SCA en appelant au moins une opération de type SessionComponent::ccm_passivate() fournie par l'exécuteur du composant CCM. Implémenter une opération de type LifeCycle :: releaseObjectO, permettant la suppression du composant SCA, en appelant au moins une opération de type SessionComponent ::ccm_remove() fournie par l'exécuteur du composant CCM. Implémenter une opération de type PropertySet ::query() en redirigeant les valeurs des paramètres de configuration provenant de l'exécuteur du composant CCM vers le port SCA 205 ou 208 à destination du composant SCA client. Cette redirection peut être effectuée via des appels aux accesseurs associés à chacun des paramètres de configuration. Afin d'éliminer les éléments redondants entre les deux standards, il convient également de supprimer l'implémentation de l'entité logicielle réalisant l'interface � Components :: CCMHome � et de transférer le code source gérant le cycle de vie du composant CCM dans l'entité 204 réalisant l'interface � CF :: ResourceFactory �. Chaque conteneur CCM étant transformé en un conteneur SCA , il en est de même des connexions CCM déclarées dans le plan de déploiement d'origine qui sont transformées en des connexions SCA déclarées dans le fichier de description de déploiement des composants SCA. Dans la phase de déploiement de l'application SCA formée par un ou plusieurs composants SCA obtenus via le procédé de transformation selon l'invention, le code binaire de chacun des composants SCA doit être chargé et exécuté sur chacun des noeuds de la plateforme cible. Chacun des composants SCA effectue l'initialisation de son exécuteur CCM et crée les ports d'entrée et sortie dont il a besoin pour communiquer avec l'extérieur. Les ports d'entrée doivent également être enregistrés auprès du bus logiciel utilisé pour communiquer avec des processeurs distants. Une fois que l'infrastructure logicielle CF-SCA possède la connaissance des différents ports créés par les composants SCA, les connexions entre lesdits composants peuvent être effectuées selon le plan de déploiement de l'application SCA. Enfin la connexion entre les ports SCA et l'exécuteur CCM est assurée par le contexte CCM qui effectue les opérations nécessaires à la redirection des ports SCA vers les ports CCM associés. La figure 3 illustre le déploiement de composants SCA réalisés par le procédé selon l'invention sur différents types de processeurs. Par exemple, un premier composant SCA comprenant un exécuteur CCM 402 et un conteneur 403 est déployé sur un processeur générique (GPP) 401, un second composant SCA comprenant un exécuteur CCM 406 et un conteneur 407 est déployé sur un processeur de signal numérique (DSP) 405, ledit exécuteur 406 réalisant par exemple une fonction associée à une forme d'onde radio. Une autre réalisation possible du procédé selon l'invention consiste à déployer un exécuteur 409 et son conteneur associé 404 sur deux processeurs différents. La communication de l'exécuteur 409 vers son conteneur 404 se fait via l'introduction de fragments de connecteurs locaux qui transforment la requête provenant de l'exécuteur en une requête adaptée au médium de communication existant entre les deux processeurs distants 401 et 408. Cette mise en oeuvre du procédé permet notamment de porter un exécuteur CCM sur un processeur non compatible du standard SCA, par exemple un processeur reconfigurable FPGA, tout en utilisant un conteneur compatible du standard SCA ledit conteneur étant exécuté sur un processeur générique distant 401. Le procédé selon l'invention précédemment décrit offre notamment comme avantage de permettre le développement de modules de traitement relatifs à une forme d'onde radio en utilisant une infrastructure logicielle CCM. La conception des composants peut se faire en utilisant le langage de description d'interface standard IDL3 pour décrire ces mêmes composants ou un modeleur UML qui permet de générer automatiquement la définition équivalente du composant en langage IDL. Le développeur de composants de formes d'onde doit uniquement implémenter le code fonctionnel de son composant dans un environnement de développement LwCCM. Cette implémentation peut rester telle quelle sans modification particulière pour être portée sur différents environnements. Ainsi, les composants peuvent être déployés sur une infrastructure standard LwCCM, cette phase étant intéressante pour la mise au point fonctionnelle des modules de forme d'onde sur des cibles hôtes ou encore si le déploiement doit être fait dans une infrastructure ne supportant pas le standard SCA. Dans un second temps, les composants peuvent être adaptés pour un déploiement sur une infrastructure SCA en générant les conteneurs adaptés à la cible et l'enveloppe à personnalité SCA via le procédé selon l'invention. Un avantage du procédé selon l'invention est de palier aux limitations du standard SCA en offrant un cadre de conception plus riche, un autre avantage résidant dans la portabilité vers des environnements non compatibles du standard SCA. Références [1] Lightweight Corba Component Model (CCM) OMG (Object Management Group) Final Adopted Specification, November 2003 [2] CORBA Component Model Specification version 4.0, OMG [3] Deployment and Configuration of Component-Based Distributed Applications (D&C) OMG, v4.0 [4] Software Communications Architecture Specification V2.2, 200120 ANNEXES Sigle Description (français) Description (anglais) API Interface de programmation Application applicative Programming Interface CCM Modèle de composant CORBA Component CORBA (un standard de Model (an OMG l'OMG) standard) CIF Infrastructure pour Component l'implémentation de Implementation composants Framework CF- Infrastructure Coeur du Core Framework SCA SCA standard SCA CORBA Architecture pour le Common Object développement de Request Broker composants sur un bus Architecture logiciel D&C Spécification pour le Deployment and Déploiement et la Configuration Configuration (un standard specification (an OMG de l'OMG) standard) FPGA Réseau de portes Field Programmable programmables in-situ Gate Array Sigle Description (français) Description (anglais) GPP Processeur générique General Purpose Processor IDL Langage de description Interface Description d'interface Language IDL3 Langage de description Interface Description d'interface Version 3 Language Release 3 LwCCM Version allégée du modèle i Lightweight CCM (an de composant CORBA (un OMG standard) standard de l'OMG) MDE Ingénierie dirigée par les Model Driven modèles Engineering OMG Groupe pour la Object Management standardisation et la Group promotion du modèle Objet ORB Bus logiciel Object request broker SAD Description d'assemblage Software Assembly logiciel Descriptor SCA Architecture logicielle Software Common commune Architecture UML Langage de modélisation Unified Modeling unifié Language Sigle Description (français) Description (anglais) XML Langage de balisage eXtensible Markup extensible Language REVENDICATIONS1. Procédé de transformation d'un composant logiciel (102) défini par le standard � CCM �, comportant un conteneur (201) réalisant l'interface externe du composant � Components :: CCMObject �, un exécuteur (107a) réalisant le code fonctionnel dudit composant et une entité logicielle (202) permettant la gestion des ressources du composant et réalisant une interface standard � Components :: CCMHome �, en un composant compatible du standard � SCA � comportant au moins une io interface externe � CF :: Resource �, caractérisé en ce que ledit procédé comporte au moins les étapes suivantes : Etape 1 : remplacer le conteneur réalisant l'interface �Components :: CCMObject � (201) définie par le standard � CCM � par un conteneur réalisant l'interface � CF :: Resource � (107) définie par le standard 15 � SCA � - Etape 2 : supprimer l'implémentation de l'interface � Components :: CCMHome � (202) définie par le standard � CCM � - Etape 3 : implémenter un composant logiciel exécutant la fonction de fabrique de composants � SCA � (204) permettant d'instancier et de 20 gérer le cycle de vie du nouveau composant SCA généré. - Etape 4: implémenter des moyens permettant de rediriger les connexions entre un nouveau composant � SCA � généré et son environnement extérieur vers l'exécuteur 107a du composant �CCM� 25 2. Procédé selon la revendication 1, caractérisé en ce que les étapes 1 et 2 sont effectuées au moyen d'un générateur adapté réalisant une transformation de la description du composant � CCM � vers la description du nouveau composant � SCA �. 3. Procédé selon la revendication 2, caractérisé en ce que la description du composant � CCM � est effectuée en langage IDL3 pour � Interface Description Language 3 �. 30 4. Système comportant au moins un processeur principal, un ou plusieurs processeurs secondaires, une infrastructure logicielle de type � Core Framework � définie par le standard � SCA � exécutée sur le processeur principal, un ou plusieurs composants � SCA � déployés sur le ou les processeurs secondaires et un ou plusieurs fichiers de description du plan de déploiement desdits composants caractérisé en ce que lesdits composants sont obtenus via les étapes du procédé selon l'une des revendications 1 à 3. 5. Système selon la revendication 4, caractérisé en ce que le ou les fichiers de description du plan de déploiement sont obtenus par transformation des fichiers équivalents décrivant le plan de déploiement des composants � CCM � (102). 6. Système selon les revendications 4 ou 5, caractérisé en ce que le processeur sur lequel est déployé le composant logiciel � CCM � est un processeur générique GPP ou un processeur de signal numérique DSP ou un processeur reconfigurable FPGA. 7. Système selon les revendications 4, 5 ou 6, caractérisé en ce que le composant logiciel � CCM � exécute un module de forme d'onde radio et le système considéré est une plate-forme radio logicielle. 8. Utilisation du procédé selon l'une des revendications 1 à 3 ou du système selon l'une des revendications 4 à 7, caractérisée en ce que le conteneur réalisant l'interface � CF :: Resource � (107) et l'exécuteur (107a) du composant � CCM � sont déployés sur deux processeurs différents. 9. Utilisation du procédé selon l'une des revendications 1 à 3 ou du système selon l'une des revendications 4 à 7, caractérisée en ce que le déploiement des composants � SCA � sur des processeurs secondaires est obtenu via une transformation du ou des fichiers de description du plan de déploiement des composants � CCM �.35