Plusieurs langages dédiés aux systèmes embarqués existent ainsi que des gé- nérateurs de code qui exploitent les modèles exprimés dans ces langages. La plupart de ces générateurs de code sont commerciaux. Nous citons ici une liste non exhaustive de ces langages et des outils associés.
3.4.1
Real Time Workshop-Embedded Coder
Simulink dispose d’un générateur de code pour les modèles Simulink por- tant le nom de Real Time Workshop-Embedded Coder (RTW-EC) [Cod] qui est l’extension de Real Time Workshop (RTW) [Wor] pour les systèmes embar- qués. Ces outils prennent en entrée des modèles Simulink et génèrent un code source en langage C ou C++.
GeneAuto se distingue de RTW-EC par les différences majeures suivantes : – une architecture flexible ouverte : possibilité de modifier, supprimer et ajouter des transformations, notamment l’ajout de règles d’optimisation spécifiques à chaque utilisateur, ainsi que l’ajout de nouveaux blocs avec des règles de typage et de génération de code spécifiques à chaque utili- sateur ;
– un outil libre, ce qui permet de rajouter des extensions pour considérer d’autres langages source ou cible ;
– qualifiable en intégrant les méthodes formelles : RTW-EC peut être qua- lifié selon les normes de qualification DO-178, IEC 61508 et ISO 26262, en s’appuyant sur des tests du code généré pour assurer qu’il se com- porte comme le modèle considéré. Cette qualification s’appuie donc sur un processus de développement particulier et sur des tests dont la cou- verture est partielle. De plus, aucune vérification formelle n’est réalisée sur le générateur de code ou sur ses composants.
Principalement, le générateur de code GeneAuto représente un sous- ensemble des configurations possibles qu’offrent les générateurs de code Real Time Workshop (RTW) et Embedded Coder (RTW-EC). Plus particulière- ment, GeneAuto se focalise sur la transformation des modèles d’entrée en C. D’autres restrictions viennent s’ajouter à la configuration de GeneAuto du fait qu’il considère un sous-ensemble sûr du langage de modélisation.
3.4.2
Target Link
Target Link de DSpace [DSp] est un autre générateur de code pour les mo- dèles Simulink/Stateflow. Il est dédié à la modélisation et la génération de code pour l’industrie automobile. Dans un premier temps, les modèles Simu- link/Stateflow importés par Target Link sont traduits dans le langage de modélisation propre à cet outil, puis les modèles obtenus sont raffinés et simu- lés avant de générer le code C dans un second temps. Le principal avantage de Target Link est le lien étroit avec le domaine des transports.
En terme de qualification Target Link n’est actuellement pas qualifié et n’ex- ploite pas de méthodes formelles.
3.4.3
Scicos C
Scicos est un outil développé au sein du projet Metalau à l’INRIA. Il est uti- lisé pour la modélisation graphique et la simulation de systèmes dynamiques. Plusieurs domaines d’application sont actuellement supportés par Scicos, no- tamment le traitement de signal, le contrôle et commande, l’ordonnancement, ainsi que l’étude des systèmes biologiques. Le générateur de code Scicos C produit du code C pour tout modèle écrit en Scicos et Scicos Modelica. Ce générateur de code utilise le même ordonnancement que le simulateur de Sci- coset fait appel aux mêmes procédures C utilisées pour les blocs. Ceci assure
la compatibilité entre le code C généré et les résultats obtenus par le simu- lateur de Scicos. De nouvelles extensions ont visé la génération de modèles basé composant pour des circuits électriques et hydrauliques en utilisant le lan- gage Modelica2. Cependant, tous les blocs du modèle sont considérés comme des sous-systèmes Function_Call Subsystem ce qui limite les optimisa- tions possibles du code généré. Il est également à noter que le générateur de code Scicos C n’est pas qualifié et ne s’appuie pas sur des méthodes formelles.
3.4.4
Langages et outils synchrones
L’approche synchrone vise à écrire des programmes concurrents déterministes. Les spécifications et les programmes sont écrits de façon à simplifier le pro- cessus de vérification de certaines propriétés. Plusieurs langages existent dont certains sont qualifiés de déclaratifs, reposant sur le principe des réseaux de Kahn [Kah74], comme Lustre [HCRP91], Lucid Synchrone [CP00] et Si-
gnal [bGJ91], et d’autres sont qualifiés de langages impératifs comme Este-
rel[BG92].
3.4.4.1 Lustre
Lustre [HCRP91] est un langage de flots de données synchrones où chaque variable du programme représente un flot qui est une suite infinie de valeurs. En Lustre, les objets de base sont le signal et le nœud. Un signal représente un flot de données infini. Un nœud représente l’unité de modularité et définit une fonction (le langage Lustre est fonctionnel) qui exprime une contrainte entre ses entrées et ses sorties. Il comporte, d’une part, une interface compo- sée de signaux d’entrée et de sortie et, d’autre part, d’un ensemble d’équations et de variables locales. Un programme Lustre est donc un ensemble d’équa- tions structurées sous la forme de nœuds et qui définissent les valeurs des variables à chaque instant. Lucid Synchrone est une extension fonctionnelle de Lustre [CP00].
Une version industrielle du langage Lustre est mise en œuvre dans l’outil Scade (Safety Critical Application Development Environment)3. Scade est un outil de modélisation, de simulation, de vérification de modèle et de généra- tion de code pour les systèmes embarqués critiques. Outre l’aspect complet de l’outil, Scade 6/Kcg [Dor08] est le seul générateur de code commercial qua- lifié selon les normes DO-178B niveau A. Cette qualification s’appuie sur son processus de développement conforme au standard et sur des plans de tests.
La nature synchrone de Scade 6/Kcg permet de maîtriser la concurrence inhérente aux modèles flots de données et la synchronisation entre les flots. Toutefois, les outils actuellement disponibles ont certaines limites en terme d’ergonomie et de fonctionnalités et le langage est moins riche et souple que Simulink. En particulier, il ne permet pas de construire des modèles conti- nus. Les utilisateurs ont tendance à préférer Simulink/Stateflow pour la modélisation de leurs applications. C’est pourquoi Esterel a offert une pas- serelle de Simulink/Stateflow vers Scade afin de bénéficier de la spéci- fication formelle de Lustre et simplifier la tâche de vérification. Plusieurs études académiques sur la correspondance entre les deux langages ont été réa- lisées [CCM+03,PAA+03].
2https ://www.modelica.org/
Cependant, l’expérience industrielle montre qu’une modélisation avec un outil intermédiaire complique les activités de vérification. Des activités sup- plémentaires sur les modèles Simulink/Stateflow s’avèrent nécessaires une fois de plus. Scade utilise des méthodes formelles pour la spécification et la vérification du langage d’entrée, mais n’inclut pas de vérification formelle ga- rantissant que le générateur de code traduit correctement le modèle d’entrée.
3.4.4.2 Signal
Signal [bGJ91] est un langage de modélisation pour les applications temps réel Gals (Globally Asynchronous, Locally Synchronous). Il offre l’opportunité de spécifier les circuits à différents niveaux d’abstraction. Signal fait partie de la famille des langages synchrones. Il est proche de Lustre en considérant les signaux à la place des flots pour une spécification polychrone (horloges multiples). La différence la plus importante est que le calcul d’horloge sur les signaux de Signal est relationnel alors que celui de Lustre sur les flots est fonctionnel. Des travaux ont été menés au sujet de l’utilisation de l’assistant de preuve Coq dans la spécification des programmes Signal [KNT00]. Cela permet d’augmenter la confiance sur les systèmes spécifiés en Signal par une preuve de correction des modèles vis-à-vis des exigences utilisateurs.
Ploychrony [GTL02] est un outil basé sur le langage Signal permettant de fournir un cadre formel pour la validation des transformations de modèles polychrones, et ceci de la spécification jusqu’à l’implantation. De plus, il se concentre sur la vérification formelle des modèles. Une version commerciale utilisant le même principe des horloges de Signal est Sildex RT-Builder4.
3.4.4.3 Esterel
Esterel [BG92] est un langage de programmation synchrone qui se focalise principalement sur la représentation de flots de contrôle dans les systèmes réactifs. Un programme Esterel consiste en plusieurs processus concurrents structurés dans des modules. Des versions récentes du compilateur Esterel, notamment depuis Esterel V5, génèrent du code C. Cependant, l’outil n’est pas qualifié. L’outil Polis 5 est un environnement de conception et de simu- lation des systèmes embarqués où les représentations logicielle et matérielle sont combinées. Il exploite le principe des machines à états finis pour la spé- cification et accepte plusieurs langages de spécification dont Esterel pour les composants synchrones. Il se focalise sur la vérification de la conception.
3.4.4.4 Syndex
L’outil Syndex 6 fournit un environnement de développement pour les sys- tèmes embarqués temps réel distribués, basé sur des formalismes de graphe avec une sémantique synchrone. Les aspects fonctionnels d’un système sont dé- crits de façon algorithmique, représentant les exécutions par un graphe de flots de données. La partie algorithmique décrit les langages synchrones (Signal et Lustre) sous la forme d’un graphe. La méthodologie AAA permet de spéci- fier l’architecture physique sur laquelle l’algorithme doit être implanté. L’ar- chitecture est un graphe. Les nœuds représentent des supports de communica-
4http ://www.geensoft.com/
5http ://embedded.eecs.berkeley.edu/Respep/Research/hsc
tion ou encore des opérateurs, tandis que les arcs représentent les connexions entre les opérateurs et les supports. Les travaux autour de la génération de code [RBN+03] ne semble pas s’intéresser à la certification du générateur de code. De plus, le générateur de code utilise la vérification formelle plutôt dans le cycle de développement, au niveau de la spécification, ce qui ne garantit pas la correction du générateur de code lui-même.
3.4.4.5 Flots de Données Synchrones (Sdf)
Sdf [LM87] est un cas particulier des graphes flots de données. Il est à l’ori- gine conçu pour programmer les applications de traitement de signal (Digital Signal Processing). Un Sdf est composé d’un ensemble de nœuds, représentant les exécutions, reliés par des arcs, représentant les dépendances de données. Les arcs représentent des flots infinis de valeurs, tout comme pour les langages synchrones, et les nœuds sont des exécutions infinies. Des outils ont été déve- loppés en exploitant les flots de données synchrones. Nous citons par exemple Ptolemy7 [A.L01]. C’est un environnement de spécification, de simulation et de génération de code. Les spécification consistent en des blocs fonctionnels interconnectés entre eux. Le concepteur peut choisir un modèle d’exécution pour un bloc donné. Par exemple, l’évolution des blocs peut être exprimée sous forme d’automates ou de flots de données synchrones. Ptolemy exploite la logique temporelle pour vérifier que le code généré est conforme à la spéci- fication.
3.4.5
Langages de description d’architecture
Les langages de description d’architecture (adl) ajoutent une couche de des- cription de la structure du système (logique et physique) par rapport aux lan- gages synchrones. Le langage de description d’architecture se focalise sur la modélisation des différentes interactions entre les composants haut-niveau du système modélisé. Il existe des adl qui s’appuient sur des spécifications for- melles tels que Wright et Rapide, mais ils ne sont en général pas dédiés pour une intégration dans une démarche de génération de code.
3.4.5.1 Aadl
Aadl, Architecture Analysis and Design Language [FGH06], est un langage de description d’architecture (adl) destiné à la modélisation de l’architecture à la fois logicielle et matérielle d’un système embarqué. La spécification d’un système en Aadl consiste en un ensemble de composants qui interagissent via les ports de leurs interfaces. Les composants peuvent être des composants logi- ciels sous forme de threads ou matériels comme les processeurs. Les connexions peuvent quant à elles être immédiates ou retardées comme dans les outils de développement embarqué et temps réel. Les connexions peuvent décrire des flots de données ou de contrôle. Aadl dispose d’une sémantique précise pour l’ordonnancement, la communication et la synchronisation entre les activités. Aadl permet de générer un système fonctionnel à partir de sa description. Plu- sieurs outils exploitent cette sémantique pour vérifier formellement que l’archi- tecture modélisée satisfait les exigences temporelles du système. Des travaux récents, notamment dans le projet Ocarina8, visent à intégrer Simulink dans
7http ://ptolemy.eecs.berkeley.edu/
Aadl afin de bénéficier du cadre de modélisation du premier et d’exploiter les aspects formels du second.
3.4.5.2 Uml
Uml, le Langage de Modélisation Unifié [uml07], consiste en un ensemble de notations graphiques pour la création de modèles abstraits d’un système donné. La sémantique d’Uml est pauvre, mais peut cependant être raffinée par la définition de profils spécifiques à un domaine. Il s’agit par exemple du pro- fil Uml Marte [mar07] pour la modélisation et l’analyse des systèmes temps réel embarqués. Ce profil contient principalement le langage de spécification de contraintes d’horloges Ccsl [And09] (Clock Constraint Specification Language) pour spécifier les propriétés temps réel. Plusieurs outils ont été développés pour générer du code à partir de Uml. Par exemple, UModel9est utilisé pour la rétro-ingénierie mais n’est pas conçu pour décrire le contenu des fonctions et n’utilise pas de méthodes formelles. Des travaux récents de J-P. Talpin et al. concernent la génération de spécifications exécutables à partir de contraintes Ccsl de Marte [YTB+11].