Les équipements Radio Logicielle militaires utilisant les concepts définis par le Software Defined Radio Forum font désormais face à de nouvelles et nombreuses exigences de la même façon que leurs équivalents civils, parmi lesquelles : - la nécessité de prendre en compte un accroissement continu et important de la complexité et du volume du logiciel embarqué ; la flexibilité introduite par le logiciel permet par exemple une élaboration plus rapide de nouvelles fonctions ou de nouveaux équipements via une intégration accrue de logiciels tiers . - la nécessité d’interopérer avec de nombreux équipements différents et d’implanter de ce fait des formes d’ondes impliquant des contraintes très diverses, notamment d’un point de vue Qualité de Service (optimisation du partage des ressources matérielles en fonction des exigences particulières de délai, débit, etc.), reconfigurabilité (redéploiement du logiciel à l’intérieur de l’équipement). - la nécessité d’exécuter le logiciel sur des plates-formes de fournisseurs différents ou de changer certains composants matériels d’une plate-forme avec le moins de modifications possible du logiciel tout en garantissant la stabilité du fonctionnement de l’équipement ; donc assurer une portabilité optimum. En réponse à ces exigences, le Joint Tactical Radio System (JTRS) du DoD US définit un framework d’architecture logicielle baptisé Software Communication Architecture (SCA) basé entre autres sur les spécifications CORBA de l’Object Management Group (OMG) et les standards POSIX. Ce framework ouvert et orienté composants couvre aussi bien les aspects logiciels que matériels ; il s’inspire du modèle OSI de l’ITU pour l’organisation des formes d’ondes. Actuellement en cours d’évolution, SCA présente des qualités indéniables dont la définition assez complète des principales interfaces logicielles que doivent supporter les applications (« resources ») et les éléments matériels (« devices ») d’une plate-forme de référence dédiée spécifiquement à la Radio Logicielle ; de même la reconfiguration est prise en charge. A contrario il possède aussi des lacunes : la définition des « resources » agrège aussi bien la partie fonctionnelle métier que la partie non fonctionnelle (utilisation de CORBA, de POSIX, implantation des ports) et la notion de port interconnectant l’ensemble des « resources » et des « devices » est insuffisamment formalisée ce qui ne permet pas de garantir la réutilisabilité du logiciel dans des équipements de fournisseurs différents. Enfin la gestion des aspects temps réel et plus globalement de la Qualité de Service est laissée totalement à la charge des fournisseurs de formes d’ondes. Parallèlement au SCA, l’OMG propose la spécification Lightweight CORBA Component Model (Lightweight CCM), une version simplifiée du modèle de Composants Logiciels CORBA (CCM) mieux adaptée aux équipements embarqués. Ses principales qualités sont la simplification des applications et leur portabilité introduites par une séparation explicite et formalisée de la partie fonctionnelle (composants) et de la partie non fonctionnelle (conteneur et services) ainsi qu’une définition précise de types d’interactions entre composants (connecteurs) et de la structure (modèles) des composants. Le déploiement des composants est également spécifié de manière très proche de celui du SCA puisque l’ayant largement inspiré. Cependant malgré ces qualités, Lightweight CCM se positionne plus en tant que socle générique d’élaboration de composants que comme une solution globale à un domaine quel qu’il soit; en effet aucune exigence non fonctionnelle courante d’équipements embarqués n’est prise en compte, rien n’est précisé par exemple quant à la gestion de contraintes temps réel. La démarche présentée est inscrite dans le cadre d’une expérimentation en cours. Elle consiste à tirer partie des qualités respectives des deux initiatives Lightweight CCM et SCA pour proposer plusieurs contributions applicables au domaine de la Radio Logicielle : - la structuration de l’architecture logicielle globale en termes d’une part de séparation des parties fonctionnelles et non fonctionnelles et d’autre part de framework à Composants Logiciels générique intégrant dans un conteneur un ensemble de services (non fonctionnels) tels que la gestion de la Qualité de Service et la gestion de la connexion entre composants (fonctionnels). - l’expérimentation de correspondances permettant d’exprimer à partir d’une architecture fonctionnelle, des composants, des assemblages de composants et des services. - l’enrichissement du framework par la réutilisation ad-hoc de logiciels tiers.