Couverture ElectroniqueS n°127

Pour le temps réel, le langage SDL pose problème car il ne couvre pas certaines caractéristiques essentielles des systèmes déterministes. Pour compenser cette faiblesse, qui freine une diffusion plus large du SDL, PragmaDev propose l'environnement SDL-RT qui intègre le C, mais aussi le langage UML, la grande tendance du moment. Les systèmes temps réel s'appuient sur un système d'exploitation temps réel (RTOS) dont l'élément structurant de base est la tâche. Plusieurs tâches s'exécutent en parallèle pour réaliser une fonction de base, fonctions de base qui sont ensuite regroupées pour réaliser des fonctions plus complexes et ainsi de suite jusqu'à couvrir toute l'application. Il est rapidement apparu que le langage SDL (pour Specification and description language), qui permet d'architecturer son application en regroupant les tâches en blocs fonctionnels qui, eux-mêmes, peuvent être regroupés en blocs de plus haut niveau, est un bon moyen de représenter graphiquement l'architecture de n'importe quel système temps réel. Rappelons que ce langage a été initialement défini par l'Union internationale des télécommunications (ITU-T, International telecom union-Telecommunication standardization sector) pour spécifier les protocoles de télécommunications. L'expérience a montré que ses principes de base pouvaient être étendus à beaucoup d'autres domaines d'application du fait de cette approche fonctionnelle graphique. Dans le cas d'un système temps réel, la définition de l'architecture de l'application se doit d'être complétée par la définition des interfaces entre les différentes fonctions du système. Une interface se définit, d'un point de vue statique, par un format d'échanges basé sur des données structurées et, d'un point de vue dynamique, par l'écriture d'un scénario qui décrit le séquencement des échanges. Pour l'écriture de ces interfaces, le SDL est relativement bien adapté. En effet, les signaux SDL accompagnés de paramètres typés basés sur les données du langage (appelées Types de données abstraits ou ADT, Abstract data types) permettent une description complète d'une interface statique. Le MSC (Message sequence chart, défini dans la même série de standards par l'ITU-T) fournit de son côté une représentation graphique des échanges de données dynamiques entre les entités au sein du modèle SDL, ou avec l'environnement extérieur tel que d'autres modules logiciels ou des drivers (photo A). Autre point important : les systèmes temps réel sont basés sur l'exécution en parallèle de tâches indépendantes. Il est donc important dans ce contexte de ne pas gaspiller du temps CPU lorsqu'une tâche n'a rien à faire. Ceci a conduit la plupart des applications temps réel à se baser sur des machines à états finis, dans lesquelles le principe de base est de se mettre en attente sur un objet du RTOS, comme une file d'attente de messages, dès que la tâche a terminé son action. Ici, les machines à états finis du langage SDL sont parfaites pour représenter graphiquement ce type de comportement. Enfin, depuis sa version 92, le SDL est orienté objet à tous les niveaux de la représentation graphique, ce qui permet de construire des librairies de composants logiciels spécialisés, adaptés au marché du temps réel. UML 2.0 : la tour de Babel ! Une chose est sûre, la pression marketing envahissante d'UML a forcé le SDL à se repositionner en tant que langage de modélisation graphique. La dernière version du SDL SDL 2000, a intégré le « diagramme de classe » UML et préparé le terrain en vue d'une fusion dans l'UML version 2.0. Celui-ci a pour objectif de supporter le MDA (Model driven architecture) qui permet de définir des profils par domaines d'application. On peut d'ores et déjà, faire un point sur les évolutions de ces deux langages. Du côté SDL malgré les engagements initiaux des différents éditeurs, la dernière version du standard n'a été implémentée dans aucun outil. Plus généralement le positionnement du langage vers UML, donc vers moins de précision n'a pas du tout séduit les utilisateurs du SDL. Le SDL-Forum, en juillet dernier a même pour la première fois initié une « task force »pour définir un sous-ensemble du SDL avec pour objectif la simplification du langage. La version 2.0 de SDL-RT a néanmoins intégré le « diagramme de classes » et le « diagramme de déploiement » d'UML, très intéressants dans les développements temps réel car ils complètent parfaitement les représentations SDL tout en garantissant la cohérence entre les différentes vues. De son côté, les grandes avancées qu'apporte la version 2.0 d'UML en cours de validation, reprennent partiellement ce qu'on pouvait trouver en standard depuis de nombreuses années dans le SDL tel que le diagramme d'architecture (structural diagram) et l'intégration du MSC dans le diagramme de séquence (sequence diagram). Mais l'apport majeur de l'UML 2.0 est de pouvoir définir des profils spécifiques par domaine d'application. Le problème est que lorsque la version sera finalisée aucun profil temps réel ne sera défini. Certains grands acteurs industriels doutent même de la standardisation de tels profils pour des raisons d'intérêts stratégiques des éditeurs. Les premiers outils UML 2.0 apparaissent déjà sur le marché, mais alors que l'objectif initial du nouveau standard était de faciliter l'interopérabilité les réalités apparaissent bien différentes. Plus concrètement, on retrouve un métamodèle UML commun à tous les éditeurs et des profils propriétaires par domaine d'application. Ces profils ne sont pas publics et les outils proposent rarement un éditeur de profils. On risque donc fort d'avoir autant de versions d'UML 2.0 que d'éditeurs sur le marché et au bout du compte, les utilisateurs ne gagneront pas beaucoup du fait que ce soit un standard puisque les profils changeront suivant l'outil et que le portage d'un modèle d'un outil vers un autre risque de se transformer en réécriture des modèles. Que les outils soient basés sur le SDL ou l'UML, les éditeurs ont eu une démarche prophétique sur leur langage et se faisaient fort de démontrerà grands renforts de séminaires et d'actions de communication, qu'ils détenaient la vérité. Cela a tellement bien fonctionné qu'il n'est pas rare de rencontrer chez les utilisateurs des fanatiques pourtant compétents, aveuglés par de tels discours (figure 2). La réalité technique ramène finalement ces brebis égarées à la raison mais à quel coût ! Des démarches mieux pensées, telles que le SDL-RT proposent des solutions pragmatiques inspirées des souhaits des utilisateurs finaux et, bien sûr des tendances présentées dans cet article. On retrouve donc, dans la version 2.0 de cet environnement certains diagrammes UML, une grande partie des diagrammes SDL et les langages de programmation C et C++ au sein d'une même représentation homogène (figure 1). L'objectif est d'offrir tous les avantages de ces langages sans leurs inconvénients, le tout dans un format de stockage XML, permettant éventuellement un traitement des modèles sans outils. Mais, hormis le langage de modélisation, c'est bien sûr les qualités de l'outil qui le supporte qui déterminera le choix des utilisateurs, puisque l'objectif d'une équipe de développement temps réel n'est pas d'être conforme à un langage, ce que semblent parfois oublier les éditeurs, mais de produire rapidement du logiciel de qualité. * PragmaDev

SDL et UML : mariage de raison pour la conception des logiciels temps réel

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure

SDL et UML : mariage de raison pour la conception des logiciels temps réel

Dans la même rubrique

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure