Modélisations Multi-Aspects & Multi-Perspectives des Lignes de Produits Logiciels

Télécharger le fichier original (Mémoire de fin d’études)

Différences essentielles entre les Systèmes embarqués et les Systèmes informatiques

Compte tenu de la frontière très étroite entre un système embarqué et un système informatique, nous avons jugé utile d‟en apporter les différences les plus significatives dans leurs définitions.
Les systèmes embarqués se différentient essentiellement des systèmes informatiques d‟entreprise (PC, Serveurs…) selon [92] par :
• Le type de réseaux et les types de contraintes matérielles et physiques.
• Le volume de l‟encombrement.
• Les types de périphériques d‟entrée.
• L‟autonomie en énergie.
• La puissance de calcul.
• Le niveau de fiabilité,
• Le débit des flux informationnels véhiculés.
• Le coût.
• Le fonctionnement alterné online/offline,
• La configuration éphémère des éléments réseaux.
• Le poids
Ces contraintes influent sur la conception et l‟architecture des systèmes d‟exploitation et le développement des applications des Systèmes embarqués.
Etant donné que les systèmes embarqués sont dans leur grande majorité des systèmes temps réel, ils doivent respecter des contraintes temporelles fortes. C‟est pour cette raison que l’on y trouve enfoui un système d’exploitation (ou noyau) Temps Réel (en anglais RTOS ou Real Time Operating System)[93],[94].
De plus, le Système embarqué utilise une famille de processeurs différente de celle du PC.
En termes de consommation d‟énergie, il en consomme moins par rapport au PC car cet aspect reste primordial pour le SE. A partir de ce constat, un PC standard peut exécuter tout type d’applications car il est généraliste alors qu’un système embarqué n’exécute qu’une application dédiée et unique. Un système embarqué n’est pas un ordinateur PC bien qu’un PC industriel puisse s’en approcher. En réalité, les ingénieurs de l‟embarqué sont divisés quant à la classification de ces conceptions en systèmes embarqués même si actuellement ces dernières sont discutées en tant que tels parmi ces mêmes concepteurs .Ceci est dû au fait qu‟il n’y a pas de nouveaux domaines supportés par l’industrie des systèmes informatiques pour les conceptions qui se situent entre le système embarqué traditionnel et les systèmes proches des PC à usage général. Le constat des définitions visant à soulever cette ambigüité dans la définition des SE s‟ouvre ainsi sur trois alternatives selon [95]:
1. Se contenter des définitions traditionnelles de l‟embarqué pour définir un SE ;
2. Reformuler les définitions des SE selon leurs évolutions technologiques ;
3. Designer un nouveau domaine , pour les Systèmes Informatiques dans le but d‟inclure les systèmes plus complexes actuellement confus à définir tels que les PDA.
1.2.3 Evolution des Systèmes Embarqués
L‟évolution des Systèmes Embarqués se dirige à grands pas selon [92],[95] vers :
1. Plus de miniaturisation ;
2. Plus d‟intégration sur silicium ;
3. Plus de communications entre :
– Les composants du Système Embarqué,
– Le Système embarqué et son environnement immédiat
– Le système embarqué et son environnement extérieur.
A ce titre, une autre discipline très proche des SE a vu le jour .Elle couvre tout ce qui touche à l’informatique diffuse et à l’électronique associée, c‟est l‟informatique ubiquitaire.

Les domaines de l’embarqué

Les grands secteurs couverts par l’embarqué sont les suivants :
• L‟automobile. Exemple : le système de freinage antiblocage (ABS).
• L‟électronique grand public. Exemples : Le Téléviseur numérique, PDA, les mobiles..
• Les systèmes de contrôle des dispositifs industriels.
Exemples : la robotique et les systèmes de contrôle de fabrication.
• L‟appareillage utilisé en médecine. Exemple : Les Machines de dialyse, scanners,…
• Le réseautage. Exemples : Les routeurs, Les hubs, Les passerelles,…
• L‟informatique de bureau. Exemples : Le fax, photocopieurs, scanners, imprimantes,
• Le Traitement du signal. Exemples : les radars, les sonars, la compression vidéo, …

La Structure type d’un Système Embarqué

En dépit des multiples définitions, selon le contexte, des systèmes embarqués, nous avons retenu dans notre thèse la définition relative à l‟aspect structure.
En d‟autres termes, un Système Embarqué est considéré comme un système électronique essentiellement numérique doté des propriétés suivantes [95]:
• Le Système Embarqué emploie un processeur embarqué ;
• Le Système Embarqué est dédié à une seule fonction.
Il réalise une fonction bien déterminée par l‟exécution d‟une seule application logicielle dédiée et enfouie dans le matériel ;
• Le Système Embarqué a des entrées obligatoires : il est doté d‟une ou de plusieurs entrées multiformes (petit clavier matriciel, boutons poussoirs,…).
• Le Système Embarqué a des Sorties optionnelles.
Les dispositifs de sortie ne sont pas obligatoires et si elles existent, elles restent limitées. Exemple : l’affichage pour une sortie typique est limité. Il peut prendre la forme de diodes de type LED, d‟écran LCD, … .
• Des circuits numériques ou mêmes analogiques (FPGA, ASIC ….. ) peuvent être employés en vue d‟augmenter ses performances et/ou sa fiabilité à travers la mise en œuvre des accélérations matérielles du traitement ; le processeur étant chargé quant à lui d‟apporter la flexibilité à la programmation logicielle.

Les composants clés

A partir de la structure typique du SE, émergent ses composants clés [3], [4] et [96] à savoir :
• Les Transducteurs :
En entrée du système, il peut y avoir un ou deux types de transducteurs analogiques et/ou numériques : les Capteurs et les Senseurs.
– Les Capteurs analogiques.
La communication avec le processeur du Système Embarqué étant numérique, les capteurs analogiques doivent être couplés à des convertisseurs de l‟analogique vers le numérique.
– Les Capteurs numériques (sorties numériques).
Ils sont directement interfacés au processeur car ne nécessitant pas de convertisseurs vers le numérique.
• Les Actionneurs :
Situés en sortie, ils sont de deux types :
– Des Actionneurs généralement analogiques couplés cette fois à l‟inverse des capteurs, selon le cas à des convertisseurs numériques ou analogiques.
– Des Actionneurs numériques qui sont directement interfacés au processeur.
• Le Calculateur :
Le noyau central du système embarqué est composé d‟un calculateur mettant en œuvre un processeur embarqué avec ses périphériques d’Entrées/Sorties. Ce dernier emploie un ensemble de circuits assimilés à un Coprocesseur support au processeur du système embarqué dont l‟objectif principal est de réaliser des accélérations matérielles pour le système.
Ces circuits peuvent être de deux types :
– Des circuits logiques programmables de type FPGA(Field programming Gâte Array) ;
– Des circuits intégrés de type ASIC (Application Specific lntegrated Circuit).

Le fonctionnement typique d’un Système Embarqué

Le fonctionnement type d‟un système embarqué est axé sur les activités suivantes [97], [98] :
• Les règles et les commandes de fonctionnement du système sont alors implantées dans le calculateur.
• Les capteurs collectent les informations à partir de l‟environnement extérieur du SE.
• Les actionneurs exécutent les actions ordonnées par le calculateur.
• Le calculateur donne l‟ordre d‟exécuter les actions et les contrôle également.
• Le calculateur reçoit les informations recensées par les capteurs, les exploite, les traite
puis ordonne et contrôle l‟action des actionneurs.
• L‟environnement extérieur :
Un système embarqué ne fonctionne pas toujours dans des conditions propices. Il doit dans la plus part des cas subir un ensemble d‟environnements défavorables qu‟il doit pouvoir surpasser.
Parmi ces environnements, nous citerons les plus importants qui sont liés :
– Aux variations fréquentes de la température ;
– Aux vibrations et aux chocs ;
– Aux variations et/ou aux coupures d‟alimentation en énergie;
– Aux interférences de radiofréquences ;
– A la corrosion ;
– A l‟infiltration de l‟eau ;
– A l‟exposition au feu ;
– A l‟exposition aux radiations d‟ions ;
Ces environnements de fonctionnement du système embarqué ne peuvent tous être contrôlés.
Il existe même des environnements qui sont incontrôlables.
C‟est pour cette raison que les concepteurs et les fabricants de Systèmes Embarqués sont tenus de bien considérer cet aspect lors de la conception et de la fabrication (Ils prévoient par exemple des parois étanches et ignifuges au système …).

Les Exigences et les Contraintes

Les systèmes embarqués fonctionnent souvent dans des environnements physiques caractérisés le plus souvent par des ressources limitées, au niveau de la mémoire, de l‟énergie (utilisation de batteries et/ou de panneaux solaires voire de piles à combustible) ou aussi des capacités de traitement.
De plus, compte tenues des fortes interactions des logiciels embarqués avec leur environnement, ces derniers sont confrontés à des contraintes de temps réel ou de sûreté de fonctionnement plus ou moins fortes selon le type d‟utilisation du système embarqué.
En matières de contraintes et d‟exigences, les systèmes embarqués doivent selon [92] et [93] :
• Satisfaire des contraintes de temps réel provenant des applications, qui peuvent être aussi bien des contraintes de temps réel souple (par exemple dans le cadre d‟applications multimédia) que des contraintes de temps réel strict (par exemple dans le cadre de protocoles de communication).
• S‟adapter ; à la nature périssable de certaines ressources (énergie) par le fonctionnement ; aux limites du matériel (surchauffe) ; aux capacités de stockage limitées. Ils doivent également intégrer l‟instabilité des systèmes de communication utilisés (déconnexion, bande passante).
• Offrir une puissance de traitement suffisante pour satisfaire les contraintes de temps d‟exécution des applications. Les processeurs utilisés dans les systèmes embarqués sont 2 à 3 décades moins puissants qu’un processeur d’un ordinateur PC.
• Revenir au moindre cout surtout lorsque le système est produit en grande série.
• Etre doté d‟une grande sureté de fonctionnement surtout pour les situations de défaillance qui mettent en péril des vies humaines où des investissements considérables (explosion de la fusée américaine Discovery).
• Ce type de systèmes sont dits « critiques » et ne doivent jamais faillir c.à.d. qu‟ils doivent toujours donner des résultats corrects, pertinents et dans les délais attendus par les utilisateurs que ce soient des machines et/ou des humains.
• Avoir un poids efficient (un juste poids nécessaire au fonctionnement).

Les Contraintes de temps

A cause de la demande toujours croissante de puissance de traitement des applications, la performance globale du système embarqué liée au temps est un critère de conception important.

La performance temporelle

Dans la conception d‟un système embarqué, la performance temporelle (exécution des taches en un temps court voire très court) des dispositifs est une préoccupation constante. C‟est au niveau logiciel que cette performance s‟exprime. En vue d‟obtenir une meilleure performance temporelle, il y a lieu d‟agir sur les algorithmes en vue de réduire leur complexité, ainsi que sur les séquences fréquentes de code en les optimisant (la réutilisabilité).

Les systèmes embarqués temps réel

Beaucoup de systèmes embarqués interagissent directement avec leur environnement via des capteurs/actionneurs ou un réseau de communication sans fil. Ces interactions contraignent les temps de réponse du système embarqué de manière plus ou moins forte selon le domaine d‟applications visé. Ce sont les systèmes temps réel ou plus précisément les systèmes embarqués temps réel [96],[98],[99] dans le sens où la durée de livraison des résultats d‟un calcul fait partie intégrante de la spécification de ce dernier, au même titre que le résultat global. Il existe deux types de Systèmes Embarqués, les Systèmes Embarqués temps réel strict et les Systèmes Embarqués temps réel souple.

Les Systèmes embarqués temps réel strict

Dans les systèmes „temps réel strict‟, ou dur, le non-respect des contraintes de temps du système, le plus souvent exprimées sous la forme d‟échéances de terminaison, constitue une défaillance de l‟application [99]. Dans le cadre d‟applications critiques, telles que par exemple certaines applications dans l‟avionique, une telle défaillance peut avoir des conséquences catastrophiques, telles que la mise en danger de vies humaines ou des pertes financières importantes.
Etant donné les conséquences importantes du non-respect d‟une échéance dans les systèmes temps réel strict, il est fortement recommandé pour de tels systèmes de pouvoir vérifier que toutes les échéances soient toujours respectées avant leur exécution.
Pour cela, des méthodes d‟analyse d‟ordonnançabilité [100],[101] doivent être utilisées afin de procéder à cette vérification.

Les Systèmes embarqués temps réel souple

Dans les systèmes „temps réel souple‟, bien que l‟instant d‟obtention du résultat soit important, la violation des contraintes de temps du système est tolérée même si elle demeure exceptionnelle [99],[100],[101].
Cette tolérance est due au fait que les applications concernées ne relèvent pas du domaine des applications critiques. Les exemples typiques d‟applications ayant des contraintes temps réel souples sont les applications multimédias à flux continus (transmission télévisée en direct… : le système vise au respect des contraintes de temps dans la délivrance des flux de données afin de garantir la qualité des images et du son). Toutefois, les contraintes de temps peuvent être adaptées [99] puisque une dégradation de la qualité des données ne sera que faiblement perçue par l‟utilisateur.

Les contraintes de Consommation énergétique

Une grande majorité des systèmes embarqués (téléphones mobiles,…) est confrontée au problème d‟autonomie d‟énergie. Aussi, afin d‟étendre l‟autonomie de fonctionnement de tels systèmes, deux approches sont actuellement utilisées [101] :
• L‟approche qui vise à augmenter la capacité de stockage des batteries ;
• L‟approche qui vise à réaliser un système embarqué à faible consommation énergétique.
Dans le cadre de cette dernière approche, plusieurs méthodes ont été envisagées qui palpent à la fois le domaine de l‟électronique et du logiciel [101].Elles sont axées sur :
– La conception de composants électroniques consommant le minimum d‟énergie;
– L‟optimisation du logiciel afin de diminuer le coût énergétique de son exécution;
– La conception de stratégies logicielles exploitant au maximum les fonctionnalités du matériel. L‟optimisation du logiciel consiste à privilégier les instructions moins consommatrices d‟énergie. Pour l‟optimisation d‟applications de type protocole réseau sans fil, cette dernière porte sur la réduction du volume des communications afin de diminuer la consommation d‟énergie occasionnées par l‟utilisation du réseau.
De plus, la conception d‟une stratégie logicielle exploitant des fonctionnalités du matériel afin de diminuer la consommation énergétique touche principalement à l‟ordonnancement [100],[101]. Certains processeurs offrent différents modes d‟exécution. Outre le mode d‟exécution nominal, un mode veille permet à la fois d‟endormir à faible coût le processeur et également de le réveiller de manière rapide.

Les contraintes de Mémoire

Dans un grand nombre de systèmes embarqués, la mémoire est une source limitée (dans un téléphone portable, elle est de quelques Mégaoctets), et par conséquent une bonne utilisation de la ressource mémoire est cruciale pour ces systèmes.
Une difficulté supplémentaire dans les systèmes embarqués est que la gestion de la mémoire soit compatible avec les contraintes temps réel des applications, qu‟elles soient souples ou strictes.

La contrainte de tolérance aux fautes

Certains systèmes embarqués doivent pouvoir remplir leurs fonctions malgré la présence de fautes [92], qu‟elles soient d‟origine physique ou humaine. Pour le premier type de faute, il est nécessaire :
1. De détecter les erreurs, par l‟utilisation accrue de méthodes, telles que les codes détecteurs d‟erreurs, les contrôles de vraisemblance ou encore le diagnostic en ligne,
2. D‟effectuer un recouvrement d‟erreurs. Ceci permet au système de continuer à remplir ses fonctions malgré l‟erreur, que ce soit par reprise de son exécution à partir d‟un état sauvegardé au préalable (point de reprise) ou par compensation exploitant la redondance présente dans le système (par exemple la duplication active de tâches).
Les difficultés issues du contexte de l‟embarqué sont relativement liées aux contraintes de temps ainsi qu‟aux ressources limitées de l‟architecture. Ceci a contraint les concepteurs à recourir aux méthodes de tolérance aux fautes utilisables dans un contexte embarqué temps réel. Cependant, dans les systèmes temps réel strict, il est nécessaire d‟intégrer les mécanismes de tolérance aux fautes dans l‟analyse d‟ordonnançabilité du système [100].

L’architecture des Systèmes Embarqués

Du point de vue de l‟ingénierie des systèmes, la conception de l‟architecture des systèmes embarqués a pu être approchée selon plusieurs modèles. Ces derniers sont utilisés pour décrire le cycle de la conception du système embarqué.
L’architecture d’un système embarqué est une abstraction du matériel embarqué, c.à.d. qu’il s’agit d’une généralisation du système qui ne montre pas généralement le détail des informations d‟implémentation telles que le code source du logiciel ou la conception de circuit matériel[96],[100],[101].
Au niveau architectural, les composants matériels et logiciels dans un système embarqué sont plutôt représentés comme une composition d’éléments en interaction.
Ces éléments sont des représentations de matériel et / ou logiciels dont les détails ont été mis en œuvre abstraitement, laissant accès seulement aux informations comportementales et interrelationnelles.
Les Éléments architecturaux peuvent être intégrés en interne au sein du dispositif embarqué, où à l’extérieur du système embarqué et interagir avec les éléments internes .Typiquement, une architecture embarquée comprend [96]:
• Les éléments du système embarqué ;
• Les éléments qui interagissent avec le système embarqué ;
• Les propriétés de chacun des éléments ;
• Les relations interactives entre les éléments.
L‟information de niveau architectural est physiquement représentée sous forme de structures. Une structure est une représentation possible de l‟architecture, contenant les informations sur son propre ensemble d’éléments représentés, ses propriétés et les interrelations entre ses éléments.
Une structure est donc un «instantané» du système en termes de matériel et de logiciel au moment de la conception et / ou de l’exécution du système, pour un environnement particulier et un ensemble donné d’éléments.
Du fait de l‟incapacité pour un «instantané» de capturer toute la complexité d’un système, l‟architecture sera typiquement composée de plus d’une structure.
Toutes les structures à l’intérieur d’une architecture sont intrinsèquement liées les unes aux autres et l‟architecture du dispositif embarqué est la somme de toutes ces structures [96].

Le Modèle architectural du Système Embarqué

Le modèle architectural typique d‟un système Embarqué indique que tous les systèmes embarqués partagent une similitude au plus haut niveau [96], c’est-à-dire qu’ils ont tous au moins une couche matérielle dans laquelle tous les composants (matériel, logiciel système et logiciel d’application) convergent. Typiquement, les couches de ce modèle sont :
– La couche matérielle qui contient tous les principaux composants physiques situés sur une carte embarquée,
– Les couches du système ; et
– Les applications logicielles qui contiennent toutes les logiciels, situés sur / et en cours, de traitement par le système embarqué.
Ce modèle de référence illustré sur la figure 1.2 est typiquement une représentation en couches (modulaire) d’une architecture du système embarquée à partir de laquelle une structure architecturale modulaire peut être dérivée.

L’importance de l’architecture d’un Système Embarqué

Les défis rencontrés lors de la conception de l‟architecture d’un système embarqué sont selon [96]:
• La définition et la capture de la conception du système ;
• Les limitations de coûts ;
• La détermination de l’intégrité du système (fiabilité, sécurité ….) et de la capacité de travailler dans les limites de la fonctionnalité élémentaire disponible (la puissance de traitement, la mémoire, la durée de vie de la batterie, …) ;
• L‟étude de la commercialisation (l‟étude du marché);
• Connaitre toutes les exigences déterministes.
Ainsi, la définition et la compréhension de l’architecture d’un système embarqué deviennent un élément essentiel pour la bonne conception du système. Ceci revient aux avantages qu‟elle offre .Nous citerons dans ce qui suit les plus importants :
1. Chaque système embarqué doit être doté d‟une architecture , même si cette dernière n‟est pas documentée. Ceci est dû au fait que chaque système embarqué est composé d’éléments (matériels et/ou logiciels) en interaction. De plus, la définition de l’architecture doit être réalisée à priori (en début de projet).Ceci évitera au concepteur d’avoir une architecture défectueuse et coûteuse. Parce qu‟une architecture embarquée capte différentes vues qui sont des représentations du système, elle est un outil utile pour comprendre tous les éléments majeurs (Utilité et comportement de chaque composant).
De plus, aucun des éléments au sein d’un système embarqué ne peut fonctionner seul. Il doit toujours interagir avec un autre élément.
A l’extérieur, les caractéristiques visibles des éléments peuvent varier en fonction d’un ensemble différent d’autres éléments.
Sans la connaissance du rôle de la fonctionnalité et de sa performance par rapport aux autres fonctionnalités fournies par chaque élément, il sera difficile de déterminer la façon dont le système se comporterait lorsqu‟il sera soumis à une variété de contraintes dans le monde réel.
2. L’architecture exprime les éléments essentiels d’une conception et les relations qui les lient. Elle peut fournir aux membres du projet de fabrication du Système des informations essentielles quant à savoir si ce dispositif est capable de répondre à leurs besoins et comment il peut être fabriqué avec succès.
Cependant, la maitrise de la conception de l‟architecture impose la convergence de l‟effort d‟une équipe pluridisciplinaire de spécialistes en électronique, en développement informatique et en télécommunication.

Le développement dans l’embarqué

Dans ce qui suit, nous allons donner un aperçu sur les systèmes de développement en matières de langage et de contraintes liées au développement puis nous allons nous étaler sur les principaux modèles de développement et nous terminerons par l‟exposition des techniques les plus significatives en matière de développement des Systèmes Embarqués.

Les Langages et les Contraintes

Nous aborderons dans cette partie , les principaux langages et contraintes de développement ainsi que les systèmes de développements liés aux systèmes embarqués avec un aperçu sur les avantages qu‟ils apportent.

Les Contraintes de développement

Les systèmes embarqués présentent des aspects spécifiques nécessitant des approches adéquates de développement [99]. Ces dernières doivent répondre aux contraintes de développement suivantes :
1. La disponibilité limitée des ressources (mémoire, processeur, moyens de communication.. …….);
2. Les contraintes de temps qui sont souvent imposées.
De telles contraintes ne peuvent être satisfaites que si le logiciel se comporte d‟une façon suffisamment prédictible [93].
Les contraintes temporelles strictes et les processus de perturbations fortement liés qui caractérisent souvent les systèmes embarqués, demandent l’utilisation de techniques de développement adaptées.

Les Systèmes de développement

Le développement de systèmes renfermant des composants informatiques et électroniques en perpétuelle complexité, nécessite des méthodes puissantes et fiables en vue de s’adapter à des contraintes de développement toujours plus critiques [99].
De plus, la mise en réseau et la complexité augmentent alors que le temps de développement à la disposition des développeurs se réduit.
Toutefois, une grande partie du logiciel embarqué est écrite en assembleur ou en C/C++ , java et autres langages similaires.
Des critères, tels que la modularité, la compatibilité, la réutilisation, la facilité de maintenance, la fiabilité et la documentation, ont pris une importance capitale dans les systèmes embarqués souvent développés pour durer.

Les Avantages

Pour les avantages qu‟il apporte (réutilisation, encapsulation, modularité), le modèle orienté objet est de plus en plus utilisé pour le développement des systèmes embarqués.
Basées sur UML comme langage standard de modélisation de systèmes informatiques, des méthodes ont été proposées [100],[101] et [102] en plus de SystemC.
Elles permettent d‟établir la spécification d‟ensemble, la conception générale, et la conception détaillée en sous-modèles décrivant chaque aspect du système (fonctionnel, structurel, comportemental, de traitement; matériel: architectural, de performance, de consommation, temps de réponse, taille mémoire…), indépendamment de sa programmation finale en C, C++ ou Java. Un autre avantage de ces méthodes est l‟outillage automatisé, aux termes de la spécification détaillée, par exemple, où les sous-modèles doivent pouvoir être assemblés et affinés pour l’étape suivante par des outils logiciels automatisés [2].
La même logique est appliquée pour la génération et l‟exécution des tests de validation, qui doivent se définir et s‟exécuter en mode automatique.

Les Modèles de développement des Systèmes Embarqués

Le développement des Systèmes Embarqués peut être basé sur plusieurs modèles. Cependant les deux modèles les plus utilisés lors de la dernière décennie sont :
1. Le modèle en V
2. Le modèle en échelle (CoDesign) ou en Co-conception Hardware/Software (H/S).

Les Premiers Modèles

Les premiers modèles avant l‟avènement du modèle en V sont organisés dans leur majorité en quatre phases selon [102] et [103] :
1. La création de l’architecture ;
2. L‟implémentation de l’architecture ;
3. Le test du système ; et
4. La maintenance du système.

Le modèle en V

Dans ce modèle, le développement est réalisé selon des étapes séquentielles (figure 1.3) dans lesquelles les résultats de l‟une sont versés dans l‟étape suivante [2]. Ces étapes sont :
1. L‟analyse des besoins du produit ;
2. La mise en œuvre de l‟architecture système ;
3. La conception du système ;
4. La mise en œuvre de l‟architecture logicielle ;
5. La conception de l‟application ;
6. Les tests unitaires ;
7. Le test d‟intégration ;
8. L‟intégration finale du système (logicielle et matérielle) ; et
9. La phase d‟utilisation du produit.
L‟inconvénient majeure de ce modèle est l‟obligation de retour-arrière en cas de détection d‟anomalies ou dans l‟une des étapes puis la reprise non pas à partir de l‟étape où l‟anomalie a été détectée mais à partir de celle correspondant à la source de l‟anomalie.
Le modèle permet aux corrections d‟être incorporées dans le processus de développement du fait que toutes les étapes qui suivent cette anomalie soient revues et/ou corrigées. Ceci donne un aspect fastidieux au processus.
Cependant et en dépit de cet inconvénient, ce modèle a été longtemps adopté jusqu‟à l‟avènement du modèle de Co-conception.

Le Modèle en Co-conception Matérielle/Logicielle

Le modèle de conception conjointe ou Co-conception est un modèle plus récent appelé également modèle en échelle dans lequel toutes les étapes relatives au Matériel et au Logiciel sont réalisées chacune d‟un côté de l‟échelle avec possibilité de communication au niveau de chaque étape et donc pendant le processus de développement.
La définition du Co-conception est le résultat d‟un enrichissement progressif dans le temps par les chercheurs du domaine.
La plus ancienne fut donnée par [102] qui le présente comme « un processus de conception des systèmes qui combinent les perspectives du Matériel et du logiciel dès les premières étapes du processus de conception afin d‟exploiter la flexibilité du produit système et une allocation de fonctions efficiente ».
Un enrichissement important de cette définition fut proposé en 1994 par [103].Cette définition insiste sur « la conception simultanée du matériel et du logiciel en vue du bon fonctionnement de l‟implémentation du produit et du meilleur apport prix-qualité-flexibilité ».
[104] quant à lui insiste sur « le contrôle permanent du comportement global du système (matériel et logiciel) tout au long du processus de conception du produit ainsi que sur l‟exploration optimale de l‟espace des solutions à toute étape ».

Table des matières

Introduction générale
I Première partie. État de l‟art
Chapitre 1. Les systèmes Embarqués
1.1 Introduction
1.2 Définitions et Evolutions
1.2.1 Définitions Usuelles
1.2.2 Différences dans les Définitions des Systèmes Embarqués et les Systèmes Informatiques
1.2.3 Evolution des Systèmes Embarqués
1.3 Les Domaines de l‟Embarqué
1.4 La Structure type d’un Système Embarqué
1.4.1 Les Composants Clés
1.4.2 Le Fonctionnement Typique d‟un Système embarqué
1.5 Les Exigences et les Contraintes
1.5.1 Les Contraintes de Temps
1.5.1.1 La Performance Temporelle
1.5.1.2 Les Systèmes Embarqués Temps Réel
a. Les Systèmes Embarqués Temps Réel Strict
b. Les Systèmes Embarqués Temps Réel Souple
1.5.2 Les Contraintes de Consommation Energétique
1.5.3 Les Contraintes de Mémoire
1.5.4 La Contrainte de Tolérance aux Fautes
1.6 L‟architecture des Systèmes Embarqués
1.6.1 Le Modèle Architectural d‟un Système Embarqué
1.6.2 L‟Importance de l’Architecture d’un Système Embarqué
1.7 Le Développement dans l‟Embarqué
1.7.1 Les Langages et les Contraintes
1.7.1.1 Les Contraintes de Développement
1.7.1.2 Les Systèmes de Développement
1.7.1.3 Les Avantages
1.7.2 Les Modèles de Développement des Systèmes Embarqués
1.7.2.1 Les Premiers Modèles
1.7.2.2 Le Modèle en V
1.7.2.3 Le Modèle de Co-Conception Matérielle/Logicielle
1.7.3 Les Techniques de développement des SE dans le contexte des Lignes de Produits
1.7.3.1 La Méthode PuLSE
1.7.3.2 La Méthode KobrA
1.7.3.3 La Méthode FAST
1.7.3.4 La Technique d‟analyse FODA
1.7.3.5 Le Processus RSEB
1.7.3.6 La Méthode FORM
1.7.3.7 Le Processus FeatuRSEB
1.7.3.8 La Méthodologie ConIPF
1.7.3.9 La Méthode PLIT-Daisy
1.8 Conclusion
Chapitre 2. Modélisations en Lignes de Produits Logiciels
2.1 Introduction
2.2 La Ligne de Produits Logiciels Pilier de la Stratégie de réutilisation
2.2.1 Définitions de la Ligne de Produits logiciels
2.2.2 Apports de la stratégie ligne de produits
2.2.2.1 La Réutilisation de Masse
2.2.2.2 La Construction de Familles de Systèmes Logiciels au lieu d‟un Système Unique
2.2.2.3 La Construction des Produits par le Paramétrage à grande échelle
2.2.3 Le Cadre de Développement de l‟Ingénierie des Lignes de Produits Logiciels
2.2.3.1 Le Développement pour la Réutilisation
2.2.3.2 Le Développement par la Réutilisation
2.2.3.3 L‟importance de la Variabilité Logicielle dans l‟Ingénierie des Lignes de Produits
a. L‟importance de l‟Identification et de la Gestion de la Variabilité
b. L‟Etendue de la Variabilité en Temps et en Espace
2.3 Modélisations Multi-Aspects & Multi-Perspectives des Lignes de Produits Logiciels
2.3.1 Aspect Développement d‟une Ligne de Produits
2.3.1.1 Problématique et Modélisations existantes
2.3.1.2 Bilan
2.3.1.3 Positionnement de notre Démarche
2.3.2 Aspect Évolutivité
2.3.2.1 Problématique et Modélisations Existantes
1. Les Approches basées sur l‟Evolution des Modèles de Caractéristiques
2. Les Approches basées sur le role UML pour Modéliser l‟Evolution dans le Diagramme de Classes des Systèmes Uniques
2.3.2.2 Bilan
1. Les Approches ayant discuté la Gestion de l‟Evolution de la Variabilité
2. Les Approches Basées sur le rôle UML pour contrôler l‟Evolution des Objets
3. Constat Commun
2.3.2.3 Positionnement de notre Démarche
2.4 Conclusion
II Deuxième partie. Contributions
Chapitre 3. Un Processus basé sur les métriques pour le Développement d‟une Ligne de Produits Logiciels
3.1 Introduction
3.2 Aperçu de notre Processus
3.3 Le Modèle de Variabilité
3.4 Le Modèle d‟Analyse
3.4.1 Définition de l‟Unité d‟Analyse
3.4.2 Le Sous-Processus d‟Analyse
3.4.2.1 L‟analyse à grains fins
a. Le critère d‟Utilité
b. Le critère de Profondeur
3.4.2.2 L‟analyse à Gros Grains
a. Le critère de Couverture par Niveau Hiérarchique
b. Le critère de Scannérisation
3.4.3 Les Activités d‟Identification et de Configuration
3.4.3.1 L‟Activité d‟Identification
3.4.3.2 L‟Activité de Configuration
3.4.3.3 Exemples de fonctionnement des Activités d‟identification et de configuration..
3.5 Le Modèle de Corrélation
3.5.1 La structure interne du produit dans le modèle de corrélation
3.5.2 Les Métriques du Modèle de corrélation
3.6 Le Modèle de Mapping
3.7 Le Modèle d‟Évaluation
3.7.1 Sous-activité de génération des Métriques et Rapports d‟Evaluation
3.7.2 Sous-activité d‟Optimisation
3.7.2.1 Première Phase
3.7.2.2 Deuxième Phase : L‟Optimisation Globale
3.8 Notre Outil-Support
3.8.1 Agencement des Fonctionnalités
3.8.2 Les Interfaces
3.9 Conclusion
Chapitre 4. Modélisation de l‟Evolutivité de la variabilité à partir de l‟adaptation du rôle UML aux lignes de produits
4.1 Introduction
4.2 Modélisation de l‟Evolutivité
4.2.1 Aperçu de notre Modèle
4.2.2 Les Eléments de notre Modèle
4.2.2.1 Les formalismes du diagramme de classes et les règles associées appliquées aux concepts introduits dans le 1er compartiment
a. Les formalismes
b. Les régles
4.2.2.2 Les formalismes de la machine à états et les règles associées appliqués aux concepts introduits dans le 2eme compartiment
a. Les Formalismes
b. Les règles
4.2.2.3 Formalismes et Mécanismes des Concepts utilisés dans notre Modèle d‟évolution
a. Les Formalismes
b. Les mécanismes
1. Les types de classes f-role
2. Les transformations d‟évolution
3. Identification des partitions variables
4.2.2.4 Les associations
a. L‟Association « role »
1. Définition
2. Sémantique
3. Illustration
b. L‟association « evolution »
1. Définition et Sémantique
2. Illustration
4.2.2.5 Les Scénarios d‟Evolution
a. Les Evolutions Basiques
b. Les Evolutions Complexes
4.2.2.6 L‟Expression des Contraintes de Transition
4.2.2.7 Intégration des Eléments d‟Evolution dans les Méta-Modèles UML
a. Intégration de l‟Association « role »
b. Les Autres Associations introduites au Méta-Modèle
c. Les Mécanismes de Prise en Compte des Scenarios d‟Evolution basiques
d. Intégration de l‟Association « evolution »
e. Intégration de la Machine à Etats
4.3 Conclusion
III Troisième partie. Conclusion Générale et Perspectives
Conclusion générale
Perspectives
Références
Annexes

Télécharger le rapport complet