Etat de l’art de la conception de systèmes à base d’électronique

ETAT DE L’ART DE LA CONCEPTION DE SYSTEMES A BASE D’ELECTRONIQUE

Les outils de CAO sont devenus des appuis incontournables pour les ingénieurs et les scientifiques, au moment d’exécuter tous types de projets, particulièrement ceux dont la complexité et le temps de développement sont importants. En accord avec l’importance de la CAO dans notre sujet, nous avons conduit, pendant toute la durée de la thèse, une veille technologique des outils disponibles sur le marché et des techniques émergentes des laboratoires de recherche et autres organismes universitaires. Malheureusement, nous n’avons pas eu la possibilité de tout tester et nos analyses ne pourront qu’être fortement influencées par les standards et les tendances d’utilisation au niveau de l’industrie et de la recherche.

Notre intérêt porte sur la recherche de méthodes et d’outils pour intervenir dans les étapes initiales de la conception. Nos travaux de recherche visent plus particulièrement, la création de modèles de haut-niveau permettant d’initier une démarche de conception descendante, c’est à dire, de réaliser la liaison entre les spécifications et les modèles les plus en amont du processus de conception. Pour cette raison, nous ne nous étendrons pas sur les outils utilisés au niveau physique des composants comme les outils « propriétaires » de SILVACO et les autres outils spécialisés dans le routage, tels que PCB d’OrCAD, pas plus que ceux dédiés à la simulation physique à base d’éléments finis. Pour ce chapitre d’analyse et de synthèse de l’existant, nous avons classé les outils selon trois champs d’application : la conception électronique en général, la conception de haut-niveau des systèmes à base d’électronique et la gestion de l’information des projets de conception système.

La problématique de la conception système 

Aujourd’hui, concevoir un nouveau produit revient à imaginer la description, à l’aide d’outils informatiques, d’une réalisation matérielle possible de ce produit à partir de ses spécifications textuelles.

La qualité de conception d’un produit est caractérisée par le niveau des performances que l’on tente de fournir et de garantir : fonctionnalités, sûreté de fonctionnement, consommation énergétique, dimensionnements…, ou des performances que l’on évalue par anticipation : la fiabilité par exemple. Nous comprenons, compte tenu de la multiplicité des performances et des critères, que des solutions nombreuses peuvent être trouvées pour chaque produit, d’autant plus nombreuses que les contraintes sont lâches. Les exigences de conformité aux besoins du marché et le resserrement des objectifs « cible » réduisent considérablement cette variabilité des solutions possibles. D’autres facteurs sont réducteurs. En particulier, la réutilisation de sous-ensembles déjà conçus et validés. On en comprend l’intérêt dans la réduction des délais de conception, dans la sûreté de conception, dans la mesure où le sous-ensemble a déjà été validé (expérimenté) et sauvegardé en tant que module de propriété intellectuelle (IP). Il y a aussi des inconvénients évidents dans « l’alourdissement » du produit où l’on doit rechercher des optimisations globales en même temps que la compatibilité indispensable du sous-ensemble réutilisé avec les autres contraintes du produit.

Le chemin de la conception descendante

Tout produit a un « cœur fonctionnel » de base ou une « technologie de base » qui détermine son originalité et sa valeur. Cela a conduit historiquement à une démarche apparemment naturelle de type « bottom-up » où il s’agit de construire, autour de cet élément central, les autres fonctionnalités ou autres technologies permettant de le valoriser. Cette pratique aurait toute sa valeur dans un contexte ou la bonne idée, originale et efficace, peut faire la différence. Actuellement, le concepteur dispose de toute une quantité de composants et de technologies qui tendent à privilégier une «innovation de conception » faite de bons choix en terme de fonctions, de technologies d’interfaçage ou d’assemblage. Ainsi, cette évidence privilégie une démarche « Top-down », partant des spécifications, des composants et des technologies disponibles pour proposer le produit le plus adapté possible. Il n’est pas très utile de rentrer dans le débat trop philosophique sur les approches « Bottom-Up» et « TopDown ». Pour être constructif, il vaut mieux parler de « Meet in the Middle » qui allie l’avantage des deux dans une démarche globalement descendante comportant des boucles d’ascendance. Une démarche descendante va partir des spécifications pour arriver, au terme du processus de conception descente, à une représentation informatisée du produit visé que nous appelons le « prototype virtuel». Cette représentation doit être complète pour donner accès, par le calcul, à toutes les performances que nous avons déjà énoncées : fonctionnalités, sûreté de fonctionnement, influences environnementales, fiabilité… Cela implique :
• que tous les constituants du produit soient représentés par des modèles précis,
• que les paramètres de ces modèles soient reliés aux facteurs de définition ou d’influence pour permettre les calculs prévisionnels.

Pour cela, il faut que les technologies et les fonctionnements soient parfaitement maîtrisées pour que puissent être communiqués les modèles conformes aux fournitures pressenties.

Nous distinguons ainsi deux niveaux de conception parfaitement communicants :
• la conception amont, qui apportera une représentation fonctionnelle puis architecturale du « système-produit ».
• le prototypage virtuel qui apporte une représentation virtuelle d’une réalité du produit potentiel.

Ceci détermine trois interfaces ou étapes de transformation :
• l’interface pour le passage des spécifications (cahier des charges) à la conception amont.
• l’interface entre la conception amont et le prototypage virtuel
• l’interface prototypage virtuel – conception produit. Celle-ci peut comporter d’autres étapes intermédiaires.

Pour accélérer le processus du prototypage virtuel vers la matérialisation, il faut que le descriptif comporte, de manière précise, la représentation matérielle de chaque constituant et des interfaces physiques pour en dégager une architecture concrète et des modes de connexion. Une représentation matérielle globale peut alors être construite. Cette représentation peut être mise au point par la simulation de toutes les performances influençables par la démarche de matérialisation, d’intégration ou d’assemblage : simulation électronique, thermique, mécanique, etc. Sur ces représentations, pourront être greffés des calculs estimatifs de fiabilité et d’évolution temporelle sous contraintes diverses, si les représentations intègrent bien les effets d’influence environnementaux et fonctionnels.

Historique et tendances

Etant donné l’importance de l’aspect informatique de notre démarche, il est tout naturel de faire le point sur la place des outils logiciels dans la conception système. Historiquement, nous pouvons constater, dans l’évolution chronologique des outils informatiques, que ceux-ci participent de plus au processus de conception système. D’une simple aide complémentaire à la fin des années quatrevingts, nous sommes arrivés à des supports de modélisations les plus complexes de projets complets.

Dans ce contexte, nous considérons comme stratégique le fait de conduire le travail de recherche en conception de systèmes à base d’électronique avec l’ambition de faire cohabiter, dans le même environnement de simulation, des constituants numériques, algorithmiques et analogiques pluridisciplinaires.

Conception Système et Co-design

A l’origine de nos réflexions, l’idée était d’explorer les techniques de codesign et co-simulation du matériel et logiciel. Aujourd’hui, nous sommes amenés à réfléchir sur le positionnement des méthodes et outils dans une approche plus générale système. Afin de comprendre le problème dans son contexte réel, nous avons analysé (avec l’appui de la Société AIRBUS France) l’approche courante de conception des systèmes avioniques. La Figure 1-2 synthétise cette approche. Nous pouvons constater que la démarche n’est pas franchement descendante, que le « codesign » n’est pas encore appliqué et que la co-simulation est uniquement utilisée après la définition des architectures, dans les phases finales du processus. Le partitionnement matériel/logiciel est établi par expertise, dès les premières étapes, de la conception. L’implémentation du logiciel est donc fortement reliée aux architectures retenues a priori. Cette pratique est liée aux systèmes avioniques qui sont de type « matériel dominant » dans des applications où, la réussite et le temps d’exécution sont des les facteurs critiques. Dans ces systèmes, une grande partie de l’architecture est conçue sur hardware et la partie software est rajoutée aux modèles matériels validés. L’ensemble est vérifié en fin de processus en utilisant des outils de co-simulation.

Dans cette analyse, l’application d’une démarche descendante, nécessite un processus permettant d’arriver au moment crucial du partitionnement matériel/logiciel à une représentation virtuelle exécutable de la structure de conception. A ce niveau de conception, cette représentation virtuelle exécutable aura une autre utilité pour le concepteur. Avant même la prise en compte des compromis liés aux choix technologiques, elle pourra tester la validité fonctionnelle du système. La simulation du prototype dans les étapes amont permettra aussi de détecter les points faibles par rapport aux performances attendues et de détecter les fonctionnalités qui pourraient être optimisées au sein du projet. Le processus de codesign électronique (avec la co-vérification et la co-simulation comprises) a lieu à partir de la description comportementale des éléments du système. La Figure 1-3 illustre notre interprétation de l’approche, le principe est de concevoir le matériel et le logiciel de façon simultanée, à partir de la définition des spécifications validées, bien avant de proposer des solutions de type partitions matériel / logiciel. Dans ce contexte, la cible de nos travaux se situe à l’intérieur du carré rouge pointillé (indiqué par le *) du schéma de la Figure 1-3. Notamment entre les étapes de spécification et les instances de partition et d’arbitrage logiciel/matériel. Notre intention est de développer une méthode permettant d’engager ces étapes avec la certitude que conceptuellement et fonctionnellement le système à implémenter est correct. Aujourd’hui, les communautés électronique et l’informatique ont développé leurs outils spécifiques. Pour définir des outils de conception de haut-niveau il est alors naturel de chercher à « uniformiser » les concepts des outils produits par les deux communautés.

Table des matières

Introduction Génèrale
Chapitre 1
1. Etat de l’art de la conception de systèmes à base d’électronique
1.1 Introduction
1.2 La problématique de la conception système
1.2.1 Le chemin de la conception descendante
1.2.2 Historique et tendances
1.2.3 Conception Système et Co-design
1.3 La conception électronique
1.3.1 Simulation électronique analogique
1.3.2 La simulation mixte
1.3.2.1 SABER
1.3.2.2 Verilog AMS
1.3.2.3 VHDL-AMS
1.3.3 Le codesign matériel / logiciel
1.3.3.1 La conception basée sur le langage C
1.3.3.2 Les outils de haut-niveau
1.4 Les méthodes pour la conception logicielle
1.4.1 SADT et SA/RT des méthodologies à l’origine de la réflexion système
1.4.2 UML : le langage unifié de modélisation
1.5 Autres approches métiers et mixtes
1.6 Les approches « fédératrices » pour la conception système de haut niveau
1.6.1 UML 2.0 : la solution de demain pour l’ingénierie des systèmes ?
1.6.2 SysML
1.7 La réutilisation et la gestion de l’information
1.7.1 XML « Extensible Markup Language »
1.7.2 Les modules de Propriété Intellectuelle
1.8 Bilan : les outils, les langages et la conception système
1.9 Conclusion
Chapitre 2
2. HiLeS, un formalisme pour la Conception Système de Haut-Niveau
2.1 Introduction
2.2 Historique de la démarche HiLeS
2.3 Les spécifications de HiLeS
2.4 HiLeS : proposition d’un formalisme
2.4.1 Les blocs
2.4.2 Le modèle de commande
2.4.3 Les canaux
2.4.4 La gestion du temps et l’intégration de l’information et de la commande
2.4.5 La définition des hiérarchies
2.4.6 La représentation finale HiLeS
2.4.7 Les représentations associées
2.4.8 Une étape vers le prototypage virtuel : la compatibilité VHDL-AMS
2.5 Une procédure de conception et de vérification « pas à pas »
2.6 Capture et interprétation de spécifications
2.6.1 De l’expression des besoins à une spécification exécutable
2.6.2 Représentation et vérification de l’interprétation des besoins
2.6.3 Recommandations sur les développements ultérieurs
2.7 Une proposition pour la gestion de l’information
2.8 Positionnement des propositions HiLeS dans le contexte technique général
2.9 Mise en œuvre de l’outil HiLeS Designer
2.9.1 Les fonctionnalités de HiLeS Designer 0
2.9.1.1 L’outil de gestion hiérarchique « Top-Down »
2.9.1.2 L’outil d’édition et de gestion des blocs
2.9.1.3 Le gestionnaire d’architectures à expressions multiples
2.9.1.4 L’encapsulation : un outil d’agrégation et de regroupement
2.9.1.5 Gestionnaire de réseaux de Petri
2.9.1.6 Compatibilité VHDL-AMS
2.9.1.7 Complementary Data Files (CDF)
2.9.1.8 Structure des fichiers d’un projet HiLeS Designer 0
2.10 Conclusion
Chapitre 3
3. Une plate-forme de conception amont
3.1 Introduction
3.2 Plates-formes et modes d’utilisation
3.3 Le passage des spécifications à un modèle formel
3.3.1 La représentation élémentaire HiLeS
3.3.2 La relation aux représentations UML
3.4 Passerelle HiLeS Designer – TINA
3.4.1 Extraction du réseau de contrôle
3.4.2 Génération du fichier Netlist
3.4.3 Exécution de TINA à partir de HiLeS Designer
3.4.4 Les observateurs de propriétés
3.5 Passerelle HiLeS Designer vers VHDL-AMS
3.5.1 Traduction des blocs HiLeS en VHDL-AMS
3.5.1.1 L’interprétation du niveau zéro
3.5.1.2 Interprétation des blocs structurels
3.5.1.3 Interprétation des blocs fonctionnels
3.5.1.4 Interprétation des canaux
3.5.1.5 Problème : Les bibliothèques du projet
3.5.2 Traduction des réseaux de Petri
3.5.2.1 Une première tentative : le langage CONPAR
3.5.2.2 L’approche par composants
3.5.3 Connexion des modèles équivalents des blocs et des réseaux de Petri
3.6 Validation, vérification et certification
3.6.1 Le niveau « validation »
3.6.2 Le niveau « Vérification »
3.6.3 Le niveau de certification
3.6.4 Perspectives dans ce domaine
3.7 Les insuffisances de la démarche en l’état
3.8 Une nouvelle phase de développement : HiLeS 1
3.9 Conclusion
Chapitre 4
4. Illustration sur deux exemples d’application
4.1 Introduction
4.2 L’exemple du calculateur ECP, « ECAM Control Panel »
4.2.1 Description spécifique de l’ECP
4.2.2 Inventaire des fonctions
4.2.3 Description descendante du système sous HiLeS Designer 0
4.2.4 Conclusions de la première étude
4.3 Projet pilote : Le cœur de calcul, une structure d’accueil d’algorithmes pour des applications avioniques
4.3.1 Description générale du système : ces spécifications
4.3.1.1 Exigences explicites dans les spécifications
4.3.1.2 Les fonctions principales du cœur de calcul
4.3.2 Entrées et sorties du système
4.3.3 Interprétation des spécifications : fonctionnement du système
4.3.4 Description du projet sous HiLeS Designer 0
4.3.4.1 Niveau 0 : Définition de l’environnement du système
4.3.4.2 Niveau –1. Définition des états principaux
4.3.4.3 Niveau –2. Modélisation de l’application embarquée
4.3.4.4 Niveau –2. Modélisation des fonctions de base
4.3.5 Perspectives
4.4 Conclusion
5. Conclusions

Lire le rapport complet