Les systèmes électroniques embarqués temps réel

Télécharger le fichier pdf d’un mémoire de fin d’études

Le besoin d’une nouvelle méthodologie de conception

Les méthodologies de co-conception actuellement utilisées pour concevoir les systèmes électroniques embarqués ne répondent plus aux exigences et aux challenges qu’impose le développement de systèmes toujours plus complexes. De ce fait, les processus de conception doivent aujourd’hui évoluer pour répondre aux attentes des équipes de conception et donc en améliorer significativement la productivité. Dans [33], les auteurs présentent en quoi consiste la conception des systèmes embarqués et mettent en évidence les challenges à relever.

Les méthodologies de co-conception

Depuis maintenant une décennie, les systèmes électroniques embarqués associent de plus en plus des ressources matérielles et logicielles. De ce fait, des méthodologies de conceptions conjointes sont apparues pour prendre en compte les contraintes que cela implique. La Figure 16 illustre un flot de conception de SoC/SoPC dit « classique » ou « traditionnel », mature et majoritairement utilisé par les industriels.
L’approche préconise un choix architectural du système très en amont dans le flot de développement afin de partitionner le logiciel embarqué et la plate-forme d’exécution. A partir de cette étape, deux flots de développement distincts sont parallèlement utilisés jusqu’à l’intégration. Ces deux flots utilisent des environnements de développement différents (langages de programmation, outils, processus), ce qui rend difficile la communication et la compréhension des préoccupations des équipes de développement logiciel et matériel. Bien que des points de synchronisation existent, des erreurs surviennent souvent trop tard dans le processus de développement. A ce stade, il est souvent complexe de revoir l’architecture du système. Une erreur est d’autant plus coûteuse qu’elle est détectée tardivement dans le processus de développement. De plus, pour les mêmes raisons, la phase d’intégration est un point critique dans le flot de développement.
Les équipes de développement, tant dans le domaine du génie logiciel, que de celui du développement matériel, disposent, bien entendu, aujourd’hui d’outils d’aide à la conception et à l’implémentation, tels que les outils de l’EDA (Electronic Design Automation). De plus, la réutilisation de briques fait partie intégrante de la culture du développement. Cependant, l’implémentation reste majoritairement manuelle : ce qui est aujourd’hui un frein de plus en plus mis en évidence.
Au-delà des limites évidentes exposées précédemment, l’insuffisance, voire l’absence de capitalisation du domaine métier et des éléments développés, est également un manque de la méthodologie « traditionnelle ». Il semble aujourd’hui primordial de combler cette carence.
Arrivés à maturité les environnements de co-conception « traditionnels » sont loin d’avoir résolus toutes les challenges imposés par le développement de systèmes complexes, tels que les systèmes de télécommunications. En effet, aujourd’hui les limites des méthodologies de co-conception sont de plus en plus critiques et il est de plus en plus difficile pour les équipes de conception de relever les défis.

Les challenges à relever

Aujourd’hui, les défis que doivent relever les équipes de conception de systèmes électroniques embarqués, tels que les systèmes de télécommunications, sont de plus en plus nombreux.

La communication

Un des challenges, qui n’est en lui-même pas nouveau, est le problème de communication entre les êtres humains, d’origines et de cultures différentes. Cette difficulté de communication induit un problème de compréhension. Dans le contexte de la conception d’un système électronique embarqué, le problème de communication et de compréhension entre les différents corps de métiers intervenant tout au long du processus ne cesse de prendre de l’ampleur car les systèmes sont de plus en plus hétérogènes. Ce problème de communication est dû à de nombreux paramètres : domaine métier (marketing, système, développeur logiciel, développeur matérielle, intégrateur), langages, outillages.

L’évolution technologique

Les technologies disponibles pour concevoir des systèmes électroniques embarqués ne cessent d’évoluer à grande vitesse. Les équipes de conception doivent sans cesse appréhender ces évolutions. Cependant, comme le dit le proverbe : « le temps, c’est de l’argent ». Effectivement, nous accordons de moins en moins de temps aux équipes de conception pour maitriser une technologie avant l’arrivée de sa remplaçante.

La complexité

Du fait de l’évolution technologique, mais aussi de la demande et de l’exigence du marché, les systèmes embarqués intègrent de plus en plus de fonctionnalités. Pour réaliser ces systèmes, de nombreuses ressources sont nécessaires. L’hétérogénéité des technologies utilisées nécessite une très bonne maîtrise de celles-ci afin de les faire cohabiter dans un même système : ce défi est aujourd’hui toujours plus complexe à relever.

Le temps de mise sur le marché

Dans un monde où la consommation est effrénée et la concurrence toujours plus féroce, le temps est un des éléments capital à prendre en compte dans la réalisation d’un produit. En effet, dès l’apparition de nouvelles normes (technologique et/ou tendancielle), les équipes du marketing ne donnent que peu de temps aux équipes de conception pour développer un nouveau système. Tout ceci se fait dans un souci de mettre sur le marché le dit système avant la concurrence et ainsi avoir une longueur d’avance. Cette contrainte ne laisse pas beaucoup de temps à la compréhension, et la réflexion. C’est pourquoi il est primordial de proposer aux équipes de conception de nouvelles méthodologies et de nouveaux outils afin qu’elles puissent se concentrer sur la valeur ajoutée du système (architecture du système, innovation fonctionnelle, innovation technologie) plutôt que sur l’implémentation en elle-même, sans toutefois négliger cette dernière.

Le coût de conception

Outre le temps, le coût de conception d’un système est un élément décisif dans un monde très concurrentiel, et tout particulièrement dans les télécommunications. Plus le coût de conception sera contrôlé et optimisé, plus le système sera attrayant : prix attractifs et marge sont les termes qui semblent aujourd’hui de plus en plus diriger la vie d’un système. Ce coût de développement dépend non seulement du temps de conception, du coût humain (souvent plus élevé pour des ingénieurs matériel que pour des ingénieurs logiciel), mais également du coût engendré par la méthodologie en elle-même et par les outils utilisés par les équipes. Par exemple, l’utilisation d’une méthodologie unifiée et commune tout au long du processus de développement du système permettrait sans aucun doute de faciliter le dialogue entre les différentes équipes et ainsi accroître la productivité. Ceci permettrait donc de réduire le temps passé à la communication.
Le terme productivité est clairement ici le point central de tous ces défis. Il semble établi qu’il est nécessaire d’améliorer cette productivité de manière significative pour répondre à tous ces challenges. Selon l’ITRS qui regroupe notamment les grands noms du marché des semi-conducteurs, les principaux points à prendre en compte pour améliorer la productivité sont :
• La réutilisation des ressources ;
• La vérification et le test ;
• La plate-forme de conception ;
• L’implémentation fiable ;
• Le processus de conception ;
• Et la pérennité des outils.

Des solutions ESL

La communauté de l’ESL propose, depuis plusieurs années, des solutions aux équipes de conception pour répondre aux challenges présentés précédemment. Nous pouvons notamment citer les techniques suivantes :
• La réutilisation d’IP (Intellectual Property) [34] : technique qui consiste à concevoir un système en utilisant un maximum de composants (logiciels et matériels) déjà existants et en les intégrant. Cette approche suppose une compatibilité des interfaces telle que le propose le standard IP-XACT [35] ;
• La synthèse comportementale ou synthèse de haut niveau [36] : technique qui permet de générer une implémentation HDL d’un modèle fonctionnel décrit avec un langage tel que le C ou le C++ ;
• Platform-based design [37] : technique qui consiste à programmer une plateforme générique selon les spécificités de l’application ; plate-forme générique basée sur des composants programmables et reprogrammables (processeurs, FPGA, DSP, etc.).
Dans [38], les auteurs proposent une classification basée sur la représentation en Y des outils industriels et académiques de la conception ESL.
Bien que de nombreux efforts soient réalisés, comme le montre les techniques présentées ci-dessus, il semble de plus en plus évident pour les différents acteurs de l’EDA et de l’ESL, et plus généralement pour les acteurs du monde des systèmes électroniques embarqués, que pour prendre en compte tous les challenges, il faut tendre vers un environnement de co-conception unifié tout au long du processus de développement. Afin de répondre à toutes ces attentes, plusieurs approches ont vu le jour, notamment des approches basées sur le concept de modèle. L’une de celles-ci est présentée dans ce document.

L’architecture dirigée par les modèles

Avant de parler de modélisation et de méthodologie de conception basée sur les modèles, il nous semble nécessaire de présenter les concepts sous-jacents.

Les éléments de base de l’IDM

Dans le domaine de l’ingénierie, la réalisation d’un système, assimilable à un objet quelqu’en soit sa complexité, passe par une bonne compréhension de celui-ci à toutes les étapes du cycle de conception. Pour une meilleure compréhension du système, une représentation de celui-ci est effectuée à chaque étape du développement du système. Cette représentation est plus ou moins abstraite et simplifiée : nous parlons de modélisation. En fonction des besoins de chaque équipe qui intervienne tout au long du cycle de conception, un modèle représente certaines caractéristiques du système. Ce modèle fait abstraction des éléments d’implémentation. En effet, les équipes du marketing n’ont pas les mêmes besoins de connaissances du système que les équipes systèmes ou que les équipes de développement de la plate-forme matérielle. L’une des approches qui met en œuvre la modélisation d’un système est l’IDM (Ingénierie Dirigée par les Modèles) [39] utilisée dans le domaine du développement logiciel. Cette approche est dédiée au domaine du logiciel et ne peut s’appliquer directement dans le cadre d’un développement de co-conception.
Sous l’impulsion de l’OMG (Object Management Group), l’approche MDA (Model Driven Architecture ou Architecture Dirigée par les modèles) [40], dérivée de l’IDM, est apparue plus adaptée à la co-conception. L’approche MDA utilise les mêmes éléments de base que l’IDM. Avant de présenter les concepts de l’approche de modélisation préconisés par le MDA il est important de définir les éléments de base sur lesquels s’appuie cette approche :
• le méta-modèle ;
• le modèle ;
• la transformation de modèle.

Le modèle

Un modèle correspond à une représentation abstraite de la réalité. De plus, le modèle permet une représentation textuelle et/ou graphique formalisée ou non. Dans le cadre de l’IDM et du MDA le modèle se base sur des concepts formalisés (nous le verrons par la suite). Cependant, le concept de modèle n’est pas nouveau en soi. Comme le précise JeanMarie FAVRE, archéologue à l’Université Joseph Fourrier de Grenoble, ce concept de modèle n’est pas nouveau. Les personnes à l’origine de l’IDM n’ont pas réinventé la roue, ils n’ont fait que remettre au goût du jour un concept qui remonte à plusieurs millénaires, au temps de l’alphabet ougaritique cunéiforme [41]. Toutefois, le modèle est ici défini et appliqué au domaine de l’ingénierie.

Le méta-modèle

Comme pour écrire un texte, le français est régi par une grammaire, il faut utiliser un langage de modélisation pour décrire un modèle dont les concepts et la sémantique sont définis par une grammaire. Cette dernière est appelée dans le monde de la modélisation le méta-modèle. Partant de ce fait, tout modèle doit être conforme à un méta-modèle. De plus l’IDM préconise de modéliser un système à différents niveaux d’abstraction selon le besoin et les équipes à qui celui-ci est destiné. Il va de soi qu’un modèle manipulé par les équipes systèmes ne sera pas aussi détaillé qu’un modèle du même système manipulé par les équipes de développement logiciel et matériel. En effet, ces derniers n’ont pas les mêmes préoccupations. Il n’y a pas clairement de niveau d’abstraction défini, toutefois on retrouve régulièrement dans la littérature 4 couches d’abstraction représentées par la Figure 17.
Le niveau M0 représente la réalité, le système réel physique. Ce dernier est représenté par un premier niveau d’abstraite M1 qui est le modèle. Le modèle du système réel utilise une syntaxe pour modéliser celui-ci. Cette syntaxe est le méta-modèle au niveau M2. Le méta-modèle est lui-même un modèle qui doit être conforme à une syntaxe. Le niveau M3, intitulé méta-méta-modèle, est le langage qui permet de décrire le méta-modèle. Il pourrait en être ainsi de manière infinie mais dans la pratique il est considéré qu’un métaméta-modèle est conforme à lui-même.

Table des matières

Introduction
Des systèmes embarqués à la radio logicielle
1.1 Les systèmes électroniques embarqués temps réel
1.1.1 L’environnement de fonctionnement
1.1.2 L’autonomie
1.1.3 Les ressources
1.1.4 Les caractéristiques temporelles
1.2 Les systèmes de radiocommunications
1.2.1 Définition
1.2.2 Un système de transmission sans-fil MIMO
1.3 La radio logicielle
1.3.1 Définition
1.3.2 Un système radio logicielle restreinte
1.4 Conclusion
Un besoin de nouvelles méthodologies
2.1 Le besoin d’une nouvelle méthodologie de conception
2.1.1 Les méthodologies de co-conception
2.1.2 Les challenges à relever
2.1.3 Des solutions ESL
2.2 L’architecture dirigée par les modèles
2.2.1 Les éléments de base de l’IDM
2.2.2 Les éléments de base du MDA
2.2.3 UML : un langage de modélisation orienté objet
2.2.4 Les modèles du MDA
2.3 Etat des lieux des méthodologies proposées
2.3.1 Les approches non-MDA
2.3.2 Les approches MDA
2.3.3 Synthèse
2.4 Conclusion
Une méthodologie basée sur les modèles
3.1 La méthodologie MOPCOM
3.1.1 Le profil MARTE
3.1.2 MOPCOM : un raffinement du MDA
3.1.3 Génération de code
3.1.4 Les outils associés
3.2 Le niveau de modélisation EML
3.2.1 Organisation du niveau EML
3.2.2 Définition du niveau EML
3.2.3 Validation du niveau EML
3.2.4 Les éléments de MARTE utilisés au niveau EML
3.2.5 Les contraintes de développement
3.2.6 Des métriques d’évaluation
3.3 Mise en œuvre et évaluation de la méthodologie
3.3.1 Le niveau AML
3.3.2 Le niveau EML
3.3.3 Le niveau DML
3.3.4 Analyses et évaluation de la méthodologie proposée
3.4 Conclusion
Génération de code/mise en œuvre matérielle
4.1 Génération de code UML vers HDL
4.1.1 Code matériel ou langage de description matériel : définition
4.1.2 Mise en œuvre de la génération de code dans MOPCOM
4.2 Synthèse de haut niveau
4.2.1 Les origines de la synthèse de haut niveau
4.2.2 Couplage d’un outil HLS avec la méthodologie MOPCOM
4.2.3 Mise en œuvre et résultats de synthèse de haut niveau
4.2.4 Conclusion
4.3 Intégration et validation
4.3.1 Intégration
4.3.2 Validation
4.4 Conclusion
Modélisation des systèmes reconfigurables
5.1 Un besoin de flexibilité
5.1.1 Un système reconfigurable
5.1.2 Un gestionnaire de reconfiguration
5.2 Une modélisation des systèmes embarqués reconfigurables
5.2.1 Quelques propositions
5.2.2 Une extension de la méthodologie MOPCOM
5.2.3 Modélisation d’un système RLR à l’aide de MOPCOM
5.2.4 Des limitations
5.3 Une simulation SystemC
5.3.1 La librairie SystemC
5.3.2 Modélisation d’un système reconfigurable en SystemC
5.3.3 Simulation d’un système de radio logicielle restreinte
5.4 Conclusion
Conclusion générale
Annexe 1 : Décomposition QR selon Gram-Schmidt
Annexe 2 : Contraintes de modélisation du niveau EML de MOPCOM
Liste des figures
Liste des tableaux
Contributions de l’auteur
Bibliographie

Télécharger le rapport complet