Brevet FR2938945A1 — publié le 20100528

PROCEDE ET SYSTEME POUR L'ENCAPSULATION DE PLUSIEURS COMPOSANTS LOGICIEL COMPATIBLES DU STANDARD CCM DANS UN COMPOSANT LOGICIEL COMPATIBLE DU STANDARD SCA La présente invention concerne un procédé et un système d'encapsulation d'un ou plusieurs composants logiciel normalisés par le standard CCM (Common Object Request Broker Architecture Component Model) en un composant déployable dans une infrastructure logicielle compatible du standard SCA (Software Communication Architecture). 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 et le terme conteneur SCA désignera l'entité logicielle réalisant le code non fonctionnel du composant SCA associé. Le standard LwCCM (� Lightweight CORBA Component Model �) du groupe de standardisation OMG (� Object Management Group �) est un standard générique utilisable par de nombreux domaines d'application. II 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 et qui réalise l'interface standard CCM � Components :: CCMObject�. Le standard LwCCM est un sous ensemble du standard CCM 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. 5 Deux standards additionnels permettent d'étendre 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 10 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 15 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 20 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 25 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 dans le standard 3o DDS pour CCM, la définition et l'implémentation de mécanismes et d'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 : io 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 comportement) entre des composants SCA implémentant, par exemple, des traitements algorithmiques relatifs à une forme 15 d'onde radio. Cette description est laissée à l'initiative du développeur et prend des formes spécifiques et propriétaires, o II n'existe pas de séparation formelle entre le code fonctionnel (par exemple au code source implémentant des modules d'algorithmie relative à une forme d'onde radio) et le code non 20 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 métier du composant. • Le standard SCA impose l'utilisation d'un bus logiciel de type CORBA 25 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 capacité de traitement et mémoire disponible. 30 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'une application CCM comportant un ou plusieurs composants logiciel CCM sur une5 architecture SCA en implémentant les opérations nécessaires à l'encapsulation desdits composants CCM dans un conteneur SCA. A cet effet l'invention a pour objet un procédé d'encapsulation d'une application composée d'un ou plusieurs composants logiciels définis par le standard � CCM � dans un composant déployable dans une infrastructure logicielle ou � Core Framework � définie par une architecture standardisée � SCA �, caractérisé en ce qu'il comporte au moins les étapes suivantes : • Etape 1 : vérifier si le ou lesdits composants � CCM � devant être encapsulés dans un composant � SCA � sont colocalisés sur un même noeud d'exécution, • Etape 2: créer les ports d'entrée et sortie d'un nouveau composant � SCA � et implémenter des moyens adaptés à rediriger les connexions entre ledit composant et d'autres composants � SCA � vers l'application � CCM � interne composée du ou des dits composants � CCM � , • Etape 3 : implémenter le conteneur � SCA � réalisant l'interface standard � CF:: Resource � et encapsulant le ou lesdits composants � CCM �, • Etape 4 : implémenter une fabrique de composants � SCA � (207) permettant d'instancier et de gérer le cycle de vie du nouveau composant � SCA �. Selon un mode de réalisation, la description du ou des composants � CCM � est effectuée en langage � IDL3 � pour � Interface Description Language version 3 �. Selon un mode de réalisation, le déploiement des composants dans une architecture standardisée de type � SCA � est effectué à l'aide d'un générateur implémentant des moyens pour transformer un ou plusieurs fichiers de description du déploiement des composants � CCM � dans l'infrastructure d'origine en un ou plusieurs fichiers de description du déploiement des composants � SCA �. L'invention a aussi 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 � SCA � déployés sur le ou les processeurs secondaires et un ou plusieurs fichier 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écrit 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 � ~o Selon un mode de réalisation, le processeur sur lequel sont déployés les composants 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, les composants logiciel � CCM � exécutent 15 un traitement algorithmique de forme d'onde radio et le système considéré étant une plate-forme 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 l'assemblage de 20 composants � CCM � et le composant � SCA � sont 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 25 � CCM �. 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 : 30 - La figure 1, un synoptique décrivant un procédé selon l'invention permettant le déploiement de plusieurs composants logiciel 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 pour réaliser l'encapsulation d'un ou plusieurs composants logiciel CCM dans un conteneur SCA réalisant l'interface standard � CF :: Resource � 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 du standard SCA, par exemple une infrastructure 100 compatible du standard de déploiement et configuration (D&C) ainsi que l'opération effectué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 � 106. 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 sur lequel est développé le code source fonctionnel, par exemple un code relatif à 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. L'ensemble des composants CCM 101 à 103 considérés peuvent être déclarés sur un même noeud d'exécution, cette information est fournie par un plan de déploiement issu du design de l'application CCM. Le procédé selon l'invention consiste notamment à encapsuler directement lesdits composants 101 à 103 dans un conteneur SCA réalisant l'interface standard �CF :: Resource � afin de permettre un portage sur l'architecture compatible SCA 106. Le conteneur généré est représenté sur la figure 1 par la référence 105, il encapsule les composants CCM 101 à 103. Le déploiement des composants CCM dans l'infrastructure � D&C � 100 se fait via un ou plusieurs fichiers de description 104 écrit, par exemple, en langage de description XML respectant la sémantique d'un plan de déploiement de composants CDP pour � Component Deployment Plan �. Afin de procéder au déploiement de ces mêmes composants CCM dans l'infrastructure logicielle SCA 105, un ou plusieurs fichiers descripteurs 107 nécessaires équivalents sont générés selon une transformation N pour 1 en associant un composant SCA à N composants CCM si ces derniers sont colocalisés sur le même noeud d'exécution. Les figures 2a et 2b présentent un synoptique détaillant les opérations mises en oeuvre lors de l'encapsulation de composants CCM dans un conteneur SCA. Les composants CCM 200 et 203 sont encapsulés respectivement dans les conteneurs SCA 204 et 206. Ce cas d'application correspond, par exemple, à des composants CCM localisés sur des processeurs distincts et ne pouvant pas être regroupés avec des voisins proches de manière à former une application CCM. Les composants 201 et 202 sont, quand à eux, colocalisés sur le même noeud d'exécution et peuvent donc être encapsulés ensemble dans un même conteneur SCA 205. Une fabrique de composants SCA 207 est générée lors du processus d'encapsulation, cette dernière permet d'instancier et de gérer le cycle de vie du nouveau composant SCA créé. Dans la suite du texte l'acronyme IDL3 fera référence au langage de description utilisé pour décrire un composant CCM, et l'acronyme IDL au langage équivalent permettant de décrire un composant SCA. Les étapes nécessaires à l'exécution du procédé selon l'invention, dans un mode de réalisation, sont détaillées par la suite. Au préalable, il convient d'appliquer les règles de transformation du langage IDL3 vers le langage IDL pour chacun des composants CCM 200 à 203 présents dans le plan de déploiement initial. Une première étape consiste à générer le code d'assemblage statique de toutes les instances de composants CCM devant être déployées sur le même noeud de la plateforme cible (par exemple les composants 201 et 202) et encapsulées dans la même instance de composant SCA (par exemple le composant 205). Une deuxième étape consiste à créer un composant SCA 205 par assemblage statique des composants CCM 201 et 202 issus de l'étape précédente et générer son implémentation. Le composant SCA 205 comprend notamment un port d'entrée 208, un port de sortie 209 et un conteneur réalisant l'interface standard � CF :: Resource �. Les ports d'entrée et sortie 208 et 209 créés correspondent aux ports externes 210 et 211 de l'assemblage des deux composants CCM. Le port d'entrée 208 doit réaliser et enregistrer dans le bus logiciel CORBA la même interface IDL que celle du port d'entrée CCM 210 associé. Ledit port 208 reçoit les requêtes provenant d'autres composants SCA et les redirige vers le code fonctionnel du composant CCM via le port d'entrée (par exemple une facette) 210. Le port de sortie 209 réalise l'interface standard SCA � CF :: io Port � et est utilisé par l'infrastructure � Core Framework � pour réaliser les connexions avec les ports d'entrée SCA d'autres composants SCA distants. Ledit port 209 transmet les requêtes provenant de l'application CCM interne via le port de sortie (par exemple un réceptacle) 211 vers les composants SCA visés. 15 Une fois les ports d'entrée/sortie créés, il convient d'implémenter l'interface � CF :: Resource � que doit réaliser le conteneur du composant SCA 205. Cette implémentation se fait, par exemple, selon les étapes suivantes : Implémenter une opération d'initialisation du conteneur 205 de type LifeCycle initialize() en exécutant au moins une opération 20 d'initialisation des instances de composants CCM 201 et 202 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 208 et 209 de type CF :: PortSupplier 25 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 208 30 créé vers le bus logiciel CORBA, de type CF ::Port ::connectPortO. Cette opération est paramétrée par l'identifiant connection qui correspond à la référence d'objet CORBA du port d'entrée SCA 208 .Elle implémente un transfert de ladite référence au composant CCM 201 afin de mettre cette référence à disposition 35 de l'exécuteur de ce même composant, Implémenter une opération de configuration du nouveau composant créé, de type PropertySet ::configure( en redirigeant les paramètres de configuration provenant de l'infrastructure � Core Framework � vers les composants CCM correspondants via une opération de type Set configuration_values() Implémenter une opération de type PropertySet ::query() en retournant les valeurs des paramètres de configuration provenant des composants CCM correspondants vers le port de sortie SCA 209, io 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 15 l'exécuteur du composant CCM et ce pour chaque instance de composant 201 et 202, 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() 20 fournie par l'exécuteur du composant CCM et ce pour chaque instance de composant 201 et 202, 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() 25 fournie par l'exécuteur du composant CCM et ce pour chaque instance de composant 201 et 202. Une dernière étape consiste à générer une implémentation d'une fabrique de composants SCA (� Resource Factory �) 207 qui permet d'instancier et de 30 gérer le cycle de vie dudit composant devant être déployé sur la plateforme cible. 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, 35 un premier composant SCA encapsulant une application CCM comprenant deux composants CCM 402a et 402b et un conteneur 403 est déployé sur un processeur générique (GPP) 401, un second composant SCA encapsulant une application CCM comprenant deux composants CCM 406a et 406b et un conteneur 407 est déployé sur un processeur de signal numérique (DSP) 405, lesdits composants 406a et 406b réalisant par exemple des fonctions associées à une forme d'onde radio. Une autre réalisation possible du procédé selon l'invention consiste à déployer une application CCM comportant deux composants 409a et 409b et son conteneur associé 404 sur deux processeurs différents. La communication des exécuteurs 409a et 409b vers leur 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 développer des 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 permette 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. Enfin, le procédé selon l'invention permet d'optimiser les ressources en charge de calcul et mémoire disponible pour des composants colocalisés sur un même noeud d'exécution, une seule enveloppe SCA étant générée autour d'un assemblage de composants CCM. 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 20 Applications (D&C) OMG, v4.0 [4] Software Communications Architecture Specification V2.2, 2001 ANNEXES Sigle Description (français) Description (anglais) API Interface de programmation applicative Application Programming Interface CCM Modèle de composant CORBA (un standard de l'OMG) CORBA Component Model (an 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 13 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 Lightweight CCM (an de composant CORBA (un OMG standard) standard de I'OMG) MDE Ingénierie dirigée par les Model Driven modèles Engineering 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 XML Langage de balisage eXtensible Markup extensible Language REVENDICATIONS1. Procédé d'encapsulation d'une application composée d'un ou plusieurs composants logiciels (201 à 202) définis par le standard 5 � CCM � dans un composant (205) déployable dans une infrastructure logicielle ou � Core Framework � définie par une architecture standardisée � SCA �, caractérisé en ce qu'il comporte au moins les étapes suivantes : • Etape 1 : vérifier si le ou lesdits composants � CCM � (201 à 202) devant être encapsulés dans un composant � SCA � (205) sont co-localisés sur un même noeud d'exécution, • Etape 2 : créer les ports d'entrée et sortie (208 et 209) d'un nouveau composant � SCA � (205) et implémenter des moyens adaptés à rediriger les connexions entre ledit composant (205) et d'autres composants � SCA � (204 et 206) vers l'application � CCM � interne composée du ou des dits composants � CCM � (201 à 202), • Etape 3 : implémenter le conteneur � SCA � réalisant l'interface standard � CF :: Resource � et encapsulant le ou lesdits composants � CCM � (201 à 202), • Etape 4: implémenter une fabrique de composants � SCA � (207) permettant d'instancier et de gérer le cycle de vie du nouveau composant � SCA � (205). 25 2. Procédé selon la revendication 1, caractérisé en ce que la description du ou des composants � CCM � est effectuée en langage � IDL3 � pour � Interface Description Language version 3�. 30 3. Procédé selon les revendications 1 à 2, caractérisé en ce que le déploiement des composants dans une architecture standardisée de type � SCA � est effectué à l'aide d'un générateur implémentant des moyens pour transformer un ou plusieurs fichiers de description du déploiement des composants � CCM � (201 à 202) dans l'infrastructure d'origine en un 10 15 20ou plusieurs fichiers de description du déploiement des composants � SCA �. 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 sont déployés les composants 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 les composants logiciel � CCM � exécutent un traitement algorithmique de forme d'onde radio et le système considéré étant 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 l'assemblage de composants � CCM � (201 à 202) et le composant � SCA � (205) 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 secondairesest obtenu via une transformation du ou des fichiers de description du plan de déploiement des composants � CCM �.