Les exigences de développement d’un système embarqué

De l’ingénierie logiciel à l’ingénierie système

Au niveau de l’ingénierie système, des besoins identiques se sont manifestés pour la maîtrise de la complexité, l’analyse a priori et la qualification. Des démarches de modélisation se sont également développées selon les différents points de vue du système. De part la nature même de l’ingénierie système, différents modèles ont été créés pour certains domaines métiers précis comme la sûreté de fonctionnement, l’analyse de performances ou le dimensionnement, assurant ainsi des possibilités d’analyse. Le nombre de domaines modélisés doit augmenter au niveau système pour améliorer la maîtrise et surtout assurer une cohérence entre domaines. En effet, le contrôle de cohérence entre domaines n’est possible que si tous les domaines possèdent des modèles plus ou moins abstraits mais garantissant des possibilités d’analyse. Un besoin d’unification des définitions apparaît donc, comme en logiciel, pour faciliter le contrôle de cohérence. Pour cela, une ingénierie des modèles doit se développer pour la gestion des modèles et également pour les intégrer dans un processus de réalisation. Ce processus basé sur les modèles doit également garantir une continuité dans les modèles tout au long du processus pour obtenir une cohérence entre différents niveaux d’abstraction conduisant à la réalisation du système.

Modélisation système dirigée par les modèles à THALES : MDSysE Thales, via un programme pilote, travaille sur l’IS dirigée par les modèles depuis 2002. Ces travaux ont conduit à l’élaboration d’une méthodologie « outillée » dédiée : MDSysE. Cette méthodologie organise les différents processus d’ingénierie autour de la construction et de l’exploitation d’un certain nombre de modèles interdépendants qui représentent différents aspects du système à différents niveaux d’abstraction. Les activités d’ingénierie impliquent la construction, l’analyse, et la transformation de modèles du système et la génération automatique de différents éléments du processus à partir de ces modèles. Cette méthodologie « outillée » comprend : La définition précise des produits de modélisation pour la définition du système. L’identification et la fourniture de règles et de techniques de vérification syntaxique. Le support à l’automatisation par la définition et la fourniture de règles de transformation entre modèles et de règles de génération à partir des modèles. L’outillage supportant la méthodologie inclut des assistants et autres éditeurs (« wizards ») étendant le modeleur pour permettre un travail au niveau conceptuel plutôt qu’au niveau langage de modélisation. Certains assistants aident également à la vérification, à la transformation, à la configuration ou à la génération automatique. MDSysE a été construit comme une implémentation générique de l’IS dirigée par les modèles pour Thales, basée sur différentes études conjointes avec les unités dans différents domaines.

La Modélisation multi-vues La modélisation des systèmes intervient de plus en plus pour faciliter la prise de décision lors de la conception système pour effectuer des évaluations de performances et de SdF. Il faut étendre la testabilité des systèmes à la testabilité des modèles nécessaires à l’expression des systèmes.

Modèles pour les Systèmes : Les modèles pour les systèmes, la plupart complexes, impliquent des modèles variés, complexes et utilisent différents formalismes et sémantiques. De plus, suivant les composants ou les aspects que l’on veut tester sur le système, il faut utiliser différents formalismes ou certaines parties du système sans nécessairement intégrer la totalité des connaissances sur le système.

Modélisation multi-vues : L’idée consiste à formaliser un modèle de concepts associé au systèmes complexe s’appuyant sur une modélisation pivot. Le projet PRISME (ONERA) propose un modèle multi-vues pour des systèmes dirigé par des concepts. La mise en ?uvre de cette méthode est réalisée dans un second projet ONERA appelé CARLIT (Coeur Avionique ReconfigurabLe InTégré). Il s’agit d’étudier de nouvelles techniques d’aide à la conception de systèmes avioniques militaires en architecture IMA. La méthodologie consiste à aborder cette question en adoptant un point de vue systémier et en particulier en étudiant une démarche de conception mêlant plusieurs facettes métiers, dont une facette physique.

Meta-Modélisation : On ne peut formaliser ce modèle multi-vues intégrant toutes les composantes du système de manière complète. En revanche, la méta-modélisation issue du monde UML est un bon candidat : possibilité d’exprimer de larges modèles de données pouvant représenter des concepts suivant différents niveaux d’abstraction comme le sous-tend l’approche objet qui reste le coeur d’UML. Cette définition ainsi obtenue reste semi-formelle mais elle permet l’adaptation ou la transformation vers différents formalismes qui eux pourront apporter des réponses sur la testabilité du système.

Approche MDA : L’approche MDA classifie les modèles en 3 familles : modèle indépendant de la plate-forme d’exécution, modèle spécifique à une plate-forme ou modèle d’une plate-forme. Cela permet de concevoir des modèles exprimant les fonctionnalités système indépendamment de toute architecture support. Ensuite, les architectures support sont modélisées et les modèles systèmes peuvent être portés sur les architectures en effectuant des fusions de modèles. Les techniques de fusion de modèles font aujourd’hui l’objet de travaux de recherche de la part de l’ENSIETA. Si le principe de fusion de modèles est bien connu, la mise en ?uvre de règles de fusion automatique reste un problème ouvert dans le cas général. Il doit donc être envisagé d’étudier des techniques d’aide à la fusion, et plus généralement d’aide à la transformation de modèles avec la prise en compte de contextes bien définis, dédiés, dans lesquels s’opèrent les transformations. Ce cadre générique MDA constitue actuellement la référence pour l’ingénierie des modèles (IDM) qui voit le jour après la définition du langage UML. On peut noter d’ailleurs que la conférence internationale UML, qui se déroule alternativement en Europe et aux Etats Unis s’ouvre actuellement au domaine de l’ingénierie des modèles.

Les architectures réparties

Un autre type d’architecture a été développé, depuis plusieurs années dans les systèmes militaires ou automobiles : les architectures réparties. Dans de telles architectures, les fonctions ne sont plus réalisées par un calculateur, mais par un ensemble d’équipements informatiques communicants. On parle alors souvent de “chaîne fonctionnelle” (bien qu’une telle architecture ne constitue pas une chaîne à proprement parler mais un réseau de processus). Une telle répartition est rendue nécessaire souvent par la géographie de l’application, mais aussi par l’utilisation de capteurs et actionneurs offrant localement des capacités informatiques (on parle de capteurs et actionneurs “intelligents”). Il est alors possible de déporter directement sur ces équipements des fonctions d’élaboration de données de haut niveau pour les capteurs, ou des fonctions de commande locale (asservissement par exemple) pour les actionneurs. De même, on observe aujourd’hui une tendance au remplacement de “gros” calculateurs centraux, qui présentent de plus en plus de difficultés de certification en raison de leur complexité interne, par des “grilles” de petits calculateurs plus simples. Ces raisons conduisent à l’émergence d’une classe d’architecture répartie. Se pose alors la question de la sémantique sous-jacente de cette classe d’architecture. Contrairement aux architectures fédérées qui reposent sur un couplage faible, donc asynchrone, entre des fonctions indépendantes, la répartition d’une fonction sur des équipements distants nécessite une synchronisation plus forte entre les différents traitements.

Cette synchronisation peut être apportée soit par les communications elles-mêmes au moyen de mécanismes du type “rendez-vous”, ou par le partage d’une base temporelle commune. On observe que c’est souvent la seconde solution qui est retenue dans les applications critiques, les “rendez-vous” pouvant introduire des points de blocages dangereux en cas de panne. On peut alors parler de systèmes globalement “faiblement synchrones”. On utilise l’adverbe “faiblement” par opposition aux langages synchrones tels que Lustre, Esterel ou Signal qui non seulement supposent l’existence d’une base de temps globale mais reposent également sur l’hypothèse que les temps d’exécution et de communication sont nuls dans ce référentiel temporel commun. Par l’expression “faiblement synchrone”, nous traduisons le fait que ces architectures reposent également sur l’hypothèse d’un référentiel temporal global, mais que les temps de communication dans ce référentiel sont supposés non nuls. En pratique ces architectures sont construites autour de bus à diffusion synchronisant (virtuels ou réels). Ces bus offrent souvent des fonctionnements à trames dans lesquelles s’insère le trafic dans un ordre essentiellement déterministe (au moins pour le trafic critique). L’intérêt de ce type d’architecture est de permettre une gestion quasi synchrone de l’ensemble du système avionique, donc plus déterministe, et par suite d’en réduire la combinatoire.

Les architectures fédérées Le troisième type d’architecture rencontré et que nous avons adopté dans le cadre de cette thèse est dit “fédéré”. Une architecture fédérée est généralement constituée d’un ensemble de sous-systèmes réalisant chacun une fonction embarquée (commandes de vol, pilote automatique . . . ), pilotant des actionneurs, ou élaborant des informations numériques à partir d’informations produites par des capteurs. Ces sous-systèmes sont localisés en divers endroits de l’engin embarquant (un aéronef par exemple), généralement à proximité des capteurs ou des actionneurs, et peuvent être considérés chacun pris séparément comme des sous-systèmes centralisés. En ce sens, une architecture fédérée peut être assimilée à un assemblage de sous-architectures centralisées. D’un point de vue sémantique, les architectures fédérées reposent pour la plupart sur un modèle globalement asynchrone. Les communications entre sous-systèmes sont assurées principalement par des flots de données asynchrones, la plupart du temps périodiques, et sont supportées par des canaux à diffusion et des mécanismes de files d’attentes en entrée de chaque sous-système. C’est le principe général des architectures des avions de transports civils. L’avionique (c’est-à-dire l’ensemble du système informatique embarqué) est décomposée en plusieurs sous-systèmes, chacun ayant une fonction spécifique. On trouve par exemple, le sous-système “centrale anémométrique” qui élabore les paramètres de vol (position, vitesses, accélérations), un sous-système “pilote automatique”, un sous-système de surveillance du domaine de vol, un autre de gestion des alarmes, d’autres pour le contrôle des organes physiques tels que les gouvernes, les moteurs, les réservoirs de fuel . . . .

Chaque sous-système étant répliqué pour des raisons évidentes de sûreté de fonctionnement. En première approximation, ces sous-systèmes forment un graphe de diffusion acyclique dans lequel les noeuds sont les sous-systèmes et les arcs des canaux asynchrones transportant les flots de données (les paramètres de vol, les consignes de guidage, de pilotage, de régulation . . . ). L’intérêt de ce type d’architecture est qu’elle permet naturellement la conception et le développement séparés de chaque sous-système (après une première spécification globale), puis l’évolution de l’architecture par ajouts, transformations ou suppressions de sous-systèmes. Le développement en sera donc plus modulaire, et incrémental. Cette indépendance conceptuelle entre sous-systèmes est intrinsèquement liée à l’hypothèse d’asynchronisme. En revanche, ce même asynchronisme est également synonyme d’explosion combinatoire par le simple entrelacement des comportements de chaque sous-système. Un tel entrelacement n’est pas sans poser quelques difficultés lors de l’analyse du système global. Des différentes architectures que nous avons décrites, nous retiendrons comme sujet d’étude les architectures dites fédérées. Celles-ci offrent l’avantage d’illustrer des problématiques caractéristiques des deux autres tout en les généralisant, puisque l’on peut voir une architecture fédérée comme un ensemble de sous-systèmes centralisés organisés de façon répartie.