Cours Applications mobiles et embarquées

Dr Mvogo Joseph / Dr Bonde Lossan

Objectifs du cours

L’objectif de ce cours est d’introduire l’apprenant à l’étude des systèmes embarqués et à l’utilisation
de la plate-forme Android pour le développement des applications mobiles. L’étudiant apprendra à
identifier les spécificités d’un système embarqué, sa conception ainsi que ses applications. Au terme
du cours, l’apprenant doit:
 Pouvoir définir un système embarqué,
 Enumérer les différents types de systèmes embarqués et leurs applications,
 Décrire et expliquer l’architecture d’un système embarqué,
 Cerner les problématiques de conception des systèmes embarqués,
 Développer avec Android des applications pour des périphériques mobiles, plus
particulièrement le téléphone mobile,
 Déployer une application développée avec Android sur un téléphone compatible Android.

Organisation du cours

Le cours est organisé en deux parties. La première présente de façon générale les systèmes
embarqués. La seconde est constituée d’un ensemble de travaux pratiques (TPs) portant sur le
développement avec Android et l’environnement de développement Eclipse. Le plan détaillé du
cours se présente comme suit :
Partie #1 Généralités sur les systèmes embarqués
Chapitre 1 Introduction aux systèmes embarqués
Chapitre 2 Architecture d’un système embarqué
Chapitre 3 Conception des systèmes embarqués
Partie #2 Développement d’applications mobiles avec Android
TP N°1 Installation et configuration de l’environnement de développement
TP N°2 Fondamentaux du développement avec Android
TP N°3 Utilisation des outils de Google APIs
TP N°4 Mini Projet :

Références bibliographiques
Ouvrages (Livres)
[L01] Arnold S. Berger, Embedded Systems Design: An Introduction to Processes, Tools, & Techniques, CMP
Books, 2002
Webographie (ressources tirées du Web)
[W01] Samia Bouzefrane, Introduction aux Systèmes Temps Réel, http://cedric.cnam.fr/~bouzefra/
[W02] www.technologuepro.com, Cours Systèmes Embarqués, Introduction,
http://www.technologuepro.com/cours-systemes-embarques/cours-systemes-embarquesintroduction.htm
[W04] www-igm.univ-mlv.fr, Architecture d’un système embarqué, http://www-
igm.univmlv.fr/~dr/XPOSE2002/SE/architecture.html
[W05] Ramzi BOULKROUNE, Les systems embarqués,
http://www.memoireonline.com/05/12/5830/Les-systemes-embarques.html
[W06] Richard Grisel et Nacer Abouchi, Les systèmes embarqués - Introduction,
http://richard.grisel.free.fr/Master_OSM/2_Introduction_Embedded_systems.pdf
[W07] Jean-Luc Dekeyser, ARCHITECTURE EMBARQUÉE ET PROCESSEURS RISC,
http://www.lifl.fr/~dekeyser/M1AEV/cours%202013/aev11.pdf
Partie #1 Généralités sur les systèmes embarqués

La première partie du cours porte sur un enseignement théorique sur les systèmes embarqués.
Cet enseignement est divisé en quatre chapitres. Le premier chapitre définit ce qu’est un système
embarqué, ce qui le différencie des autres systèmes (non embarqués). Il présente également la
classification des systèmes embarqués ainsi que les différentes utilisations (applications) de ces
systèmes. Enfin, il se termine par la présentation de l’évolution des systèmes embarqués et de la
spécificité dans la conception et l’implémentation des systèmes embarqués.
Le chapitre 2 décrit et explique l’architecture d’un système embarqué. Cette description fait
également ressortir les contraintes à prendre en compte dans la détermination des constituants
matériels et logiciel pour satisfaire aux performances attendues du système.

Le dernier chapitre est orienté la conception et implémentation des systèmes embarqués.

3
Chapitre 1 Introduction aux systèmes embarqués

Les systèmes embarqués sont beaucoup plus présents qu'il n'y paraît. On les trouve actuellement
partout: à la maison, au bureau, dans la voiture, dans les industries, à l'hôpital, dans les appareils
militaires électroniques, etc. Le nombre, le type et la complexité des services demandés sont sans
cesse croissants. Les systèmes embarqués sont alors nombreux et d'une complexité croissante qui
demande de nouvelles approches de conception, utilisant des outils de développement haut niveau
et des compromis hardware/software, plutôt que des approches bas niveau (assembleur, logique). Le
marché des systèmes embarqués est de loin supérieur à celui des PC et architectures clients/serveurs
réunis.

1.1 Définitions
Il est difficile de définir ce qu’est un système embarqué. Pratiquement tout calculateur en dehors de
l'ordinateur est un système embarqué.

Un système embarqué est un système autonome à microprocesseur (microcontrôleur) dédié à une

tâche bien précise et évoluant dans un environnement souvent très contraignant (espace et
consommation). Le système est dit embarqué parce qu’il se trouve encapsulé dans un dispositif ou un
appareil qu'il contrôle, surveille, ou fait fonctionner. Le terme système enfoui est souvent utilisé pour
désigner un système embarqué.

Comparé à un système non embarqué, un système embarqué n'a pas d’entrées/sorties classiques
(clavier, écran ou souris) clairement distinguables.

Un système embarqué est l’union d’un système électronique (matériel/hardware) et d’un système
informatique (logiciel/software) intimement liés et formant un tout.

Les systèmes embarqués utilisent généralement des microprocesseurs à basse consommation

d'énergie ou des microcontrôleurs dont la partie logicielle est en partie ou entièrement programmée
dans le matériel ; généralement, ils sont en mémoire dans une mémoire morte (ROM, EPROM,
EEPROM, FLASH, etc.) et non sur un disque dur.

Un système embarqué (embedded system ou système enfoui) est un système informatique dans
lequel le processeur/calculateur est englobé dans un système plus large et où le logiciel est
entièrement dédié à une application donnée. Ex. : sonde spatiale, terminal GSM, carte à puce.

Nous pouvons continuer à donner plusieurs autres définitions de systèmes embarqués, définitions
qui vont plus ou moins exprimer les mêmes idées et concepts en des termes plus ou moins
accessibles. Pour mieux percevoir ce qu’est un système embarqué, [L01, pages XVIII à XXVI] nous
propose une liste de quelques éléments qui différencient les systèmes embarqués des autres
systèmes :

1. Les systèmes embarqués sont dédiés à des tâches biens spécifiques: Les PCs ordinaires sont
des instruments génériques de calcul, contrairement aux systèmes embarqués qui ont des
tâches bien spécifiques. D’ailleurs, les systèmes embarqués sont souvent appelés des
processeurs dédiés.

4
 2. Les systèmes embarqués sont en général sensibles aux coûts : Dans la conception des
systèmes embarqués, le choix du microprocesseur, des cartes et autres est effectué de
manière à optimiser le coût du système.
3. Les systèmes embarqués sont souvent soumis à des contraintes de temps réel : Les
systèmes embarqués sont souvent soumis à deux types de contraintes temps réel :
a. Les contraintes temps réel dur ou critique : le non-respect des contraintes
temporelles entraîne la faute du système et les conséquences sont graves, voire
catastrophiques. C’est le cas, par exemple, du contrôle du trafic aérien, du contrôle
du système de conduite de missile, etc.
b. Les contraintes temps réel souple (soft real-time) : le respect des échéances de
temps est important, mais un manquement n’engendre pas des conséquences
graves. Par exemple, dans une projection vidéo, un manquement d’échéance peut
entraîner un décalage entre le son et l’image, ce qui est désagréable, mais n’est pas
une catastrophe. Certains subdivisent cette catégorie en deux classes en considérant
les contraintes temps réel ferme (firm real-time), où les contraintes sont
occasionnellement non respectées.
4. En général, les systèmes embarqués n’ont pas de système d’exploitation, sinon alors un
système d’exploitation dédié : Les systèmes d’exploitation généraux tels que Windows 9X,
Windows NT, Windows 2000, Windows XP, Vista, Seven, Unix, Solaris, HPUX, … ne sont pas
souvent utilisés pour piloter un système embarqué. Quand un système embarqué est doté
d’un système d’exploitation, ce dernier est un système d’exploitation temps réel (RTOS : real-
time Operating System).
5. Les implications d’échec logiciel sont sévères dans un système embarqué : par conséquent,
dans les systèmes embarqués, des mécanismes plus poussés seront mis en place pour
contrôler et détecter les dysfonctionnements.
6. Les systèmes embarqués ont souvent des contraintes de consommation d’énergie: les
systèmes embarqués sont souvent alimentés avec de petites batteries et doivent pourtant
fonctionner pendant longtemps avec ces batteries. Cette contrainte de consommation
d’énergie a des implications sur la conception et l’implémentation du système.
7. Les systèmes embarqués opèrent souvent dans un environnement avec des conditions
extrêmes: Les systèmes embarqués sont partout, y compris dans des environnements avec
des conditions de température ou d’humidité extrêmes.
8. Les systèmes embarqués ont peu de ressources : Comparés aux ordinateurs de bureau, les
systèmes embarqués ont très peu de ressources (mémoires, disques, entrées/sorties, …).
9. Les systèmes embarqués stockent tout leur code objet dans une ROM: Cette contrainte de
stockage oblige à optimiser afin de réduire au minimum la taille du système. Le fait que tout
le code réside en ROM a aussi des implications sur la conception du système.
10. La conception des systèmes embarqués nécessite des outils et des méthodes spécialisés.
11. Les systèmes embarqués récents comportent un circuit dédié au débogage.
La figure 1, tirée de [W02] permet de mieux illustrer un système embarqué. Un système embarqué
est constitué de deux parties : le système contrôlé et le système de contrôle.

 Le système contrôlé: environnement (procédé) équipé d'une instrumentation qui réalise

l'interface avec le système de contrôle.

5
  Le système de contrôle : éléments matériels (microprocesseurs…) et logiciels dont la mission
est d'agir sur le procédé via les actionneurs, en fonction de l'état de ce procédé indiqué par
les capteurs, de manière à maintenir ou conduire le procédé dans un état donné.

Figure 1: Système embarqué et son environnement

Les principales caractéristiques d’un système embarqué sont :

 Autonomes. Une fois enfouis dans l'application, les systèmes embarqués ne sont (le plus
souvent) plus accessibles.
 Temps réel. Les temps de réponse de ces systèmes sont aussi importants que l'exactitude
des résultats.
 Réactifs. Il doit réagir à l'arrivée d'informations extérieures non prévues

1.2 Classification des systèmes embarqués

On peut classer les systèmes embarqués selon plusieurs critères : Le type d’activités réalisées, le type
de mission du système, le mode d’interaction avec le système.

1.2.1 Classification par type d’activités réalisées

Par type d’activités réalisées, on distingue les systèmes embarqués orientés contrôle et les systèmes
embarqués orientés calcul/traitement. Les systèmes embarqués orientés contrôle sont le plus
souvent rencontrés en : Automobile, Avionique, Centrales nucléaires. Les systèmes orientés
calcul/traitement sont présents dans les : Télécommunications, MultiMedia, Radio logicielle, TV
numérique.

1.2.2 Classification par type de mission du système

Selon la nature de la mission réalisée par le système, on peut distinguer plusieurs catégories de
systèmes embarqués. Sans être exhaustif, on peut citer dans cette classification : authentification,
calculs numériques, navigation / Internet, automatisme, etc.

1.2.3 Classification par mode d’interaction

Selon le mode d’interaction, on peut distinguer les systèmes transformationnels, les systèmes
interactifs et les systèmes réactifs, ou systèmes temps réel.

6
  Système Transformationnel: activité de calcul qui lit ses données et ses entrées lors de son
démarrage, qui fournit ses sorties, puis meurt.

 Système Interactif: Système en interaction quasi permanente avec son environnement, y

compris après l'initialisation du système; la réaction du système est déterminée par les
événements reçus et par l'état courant (fonction des événements et des réactions passés); le
rythme de l'interaction est déterminé par le système et non par l'environnement.

 Système Réactif ou Temps Réel: Système en interaction permanente avec son

environnement, y compris après l'initialisation du système; la réaction du système est
déterminée par les événements reçus et par l'état courant (fonction des événements et des
réactions passées), mais le rythme de l'interaction est déterminé par l'environnement et non
par le système.

1.3 Domaines d’utilisation des systèmes embarqués

Les domaines d’application des systèmes embarqués sont de plus en plus nombreux :

 Transport : automobile (contrôle de suspension, réseau), Aéronautique (avionique), etc.

 Astronautique : fusée, satellite artificiel, sonde spatiale, etc. Le premier système moderne
embarqué reconnaissable a été le Apollo Guidance Computer (AGC), système de guidage de
la mission lunaire Apollo.
 Militaire : missile
 Télécommunication: téléphonie, routeur, pare-feu, serveur de temps, télécopieur,
téléphone portable, stations de base des cellulaires, etc.
 Electroménager : télévision, four à micro-ondes, machine à laver
 Impression : imprimante multifonctions, photocopieur, etc.
 Informatique : disque dur, lecteur de disquette, imprimante, scanner, etc.
 Multimédia : console de jeux vidéo, assistant personnel = PDA = Personal Digital Assistant est
un ordinateur de poche conçu à l'origine comme un agenda électronique, puis il a intégré les
fonctions de bureautique (dictaphone, reconnaissance vocale) ou d'écriture avec des
Systèmes d’exploitations divers (Microsoft Windows mobile).
 Guichet Automatique Bancaire (GAB) : Différents modèles de GAB permettent de faire des
retraits, acceptent des dépôts en liquide ou par chèque, ordonnent des transferts de fonds,
impriment des mises à jour de carnets, augmentent le montant d'une carte d'appel
téléphonique et, même, vendent des timbres-poste. En Espagne, au Portugal (réseau ≪
Multibanco ≫) et au Canada, il est aussi possible de régler certaines factures via un GAB. Le
GAB est une extension du DAB (distributeur automatique de billets) qui est un GAB simplifié
ne permettant que les retraits.
 Jeux : consoles, appareils photos, chargeurs de batteries.
 Métrologie: appareils photos, caméras
En somme, les systèmes embarqués sont présents dans la quasi-totalité des domaines d’activités des
hommes. Aussi, la production et la vente des microprocesseurs pour systèmes embarqués sont, en
général, des millions de fois supérieures à la production et à la vente des ordinateurs classiques. Pour
ne considérer que le cas de l’automobile, nous avons les chiffres suivants :

 Production de véhicules : 40 millions (1998) → → 60 millions (2010)

7
  Coût des systèmes électroniques embarqués : 37 000 M$ (1995) → →60 000 M$ (2000)
 Coût de l'électronique embarquée : > 20% Coût du véhicule
 Logiciel : 1,1 KBytes (1980) → →2MBytes (2000) → → 10MBytes (2004)
1.4 Evolution des systèmes embarqués (Historique)
Années 70: la conception de systèmes d'électronique numérique se fait essentiellement sous forme
de cartes. On utilisait les circuits imprimés (PCB : Printed Circuit Board). La conception d’un système
complexe se faisait par assemblage de circuits du marché, ce qui conduisait à une mise au point
longue et une évolutivité faible. A cette époque, le développement de circuits VLSI nécessitait une
maîtrise des technologies de conception au niveau silicium. Cette expertise était rare et constituait
un métier spécifique.

Années 80: apparition des composants (re)programmables par l'utilisateur (PLD) ; cela permet une
diminution sensible du nombre de circuits par carte (augmentation du taux d'intégration) et une
souplesse (évolutivité) accrue. Apparition des ASICs, mais leur usage n'est alors justifié que pour de
forts taux d'intégration, de gros volumes de production et/ou des soucis de confidentialité.

Au milieu des années 80: apparition des FPGAs qui combinent les avantages des ASICs (taux
d'intégration) et des PLDs (souplesse), mais la complexité des fonctions implantables rend nécessaire
des méthodes et outils de développement jusque-là réservés aux ASICs (VHDL, ...).

Le microprocesseur est au centre des systèmes embarqués. Comment en est-on arrivé là ? C'est par
dizaines que se comptent actuellement les fabricants de microprocesseurs et chacun des fabricants
possèdent des dizaines, voire des centaines de produits. Cependant, il n'en était pas ainsi au début.
D'ailleurs, le microprocesseur n'est pas né volontairement et n'a reçu ce nom qu'un an plus tard !
C’était au début des années 1970. Cela ne veut pas dire que l'ordinateur date des années 1970. Les
ordinateurs, au contraire, ont toujours été étudiés et déterminés avant que les technologies pouvant
les supporter ne soient disponibles. L'architecture de Harvard qui est la 1ere architecture significative
réalisée dans le calculateur électromécanique Mark 1 par Howard Aiken, physicien de l'Université de
Pennsylvanie a été fonctionnelle en 1944 et a été développée dans les années 30.

La 1ere machine électronique générale fut probablement l'ENIAC (Electronic Numerical Integrator
Analyser and Computer), développée entre 1943 et 1946 à l'Université de Pennsylvanie avec la
même architecture que le Mark 1 : espaces mémoires données et programmes séparés. Cette
architecture ne s'est pas avérée populaire, car compliquée pour les machines à usage général. Un
consultant du projet ENIAC, J. V. Neumann est reconnu créateur d'une architecture alternative
publiée plus tard par Burks, Goldstine et V. Neumann en 1946. Son idée simple est basée sur 2
prémisses : pas de différence intrinsèque entre données et programmes ; une instruction peut être
partitionnée en un champ commandant l'opération et un autre l'opérande (donnée sur laquelle on
veut opérer). On a alors une seule mémoire pour les instructions et les données. L'IAS a été construit
en 1951 à l'Institute of Advanced Studies de Princeton sur ce principe : machine bien simplifiée avec
l'inconvénient de ne pouvoir accéder simultanément aux données et aux programmes. L'histoire du
microprocesseur part d'Intel, Société américaine fondée en 1969 par Gordon Moore 1 et Robert
Noyce. Le premier microprocesseur commercialisé fut le 4 bits 4004 d'Intel en 1971. Avant cela, les
processeurs utilisés dans les ordinateurs n'étaient pas intégrés. Dès 1971, il y a une grande
accélération, avec plusieurs fabricants qui se disputent le marché.

Intel introduit successivement le 8008 en 1972, le 8080 en 1973 et le 8080A en 1974. En 1974
également, Motorola lance son 6800 avec des modes d'adressages plus performants et qui ont
permis de créer des codes plus compacts. En 1976, des transfuges d'Intel, ayant fondé Zilog en 1974,
lancent le Z80 qui a été très utilisé à l'époque. En 1975, Motorola subissait à son tour la désertion des
ingénieurs ayant créé la MOS Technology qui lança le 6500, puis le 6502 (Apple II).

8
A la fin des années 70, Intel introduisit le fameux 8088 et Motorola le 6809. Depuis lors, bien que
certains acteurs aient disparu et que de nouveaux soient apparus, le marché des microprocesseurs
reste dominé par ces 2 sociétés : on retrouve les processeurs d'Intel (80x86 ) dans les compatibles PC
et ceux de Motorola ( 680x0 ) dans les MacIntoshs.

1.5 Problématique de la conception et réalisation des systèmes embarqués

Plusieurs des caractéristiques propres aux systèmes embarqués (contrainte de résidence du code en
ROM, réduction maximale de la consommation d’énergie, la maîtrise du temps de réponse du
système, sûreté de fonctionnement,…) font que la conception et la réalisation des systèmes
embarqués ne peuvent être envisagées avec les outils et méthodes classiques du génie logiciel.

Un autre facteur qui influence de manière très significative la conception et la réalisation des
systèmes embarqués est l’évolution de la technologie. La loi de Moore, bien qu’étant en
ralentissement progressif, demeure encore vraie. Selon cette loi, la capacité en transistors des
circuits intégrés (CI) double tous les 18 mois depuis plusieurs décades passées. Un circuit
d'aujourd'hui (2000) peut contenir environ 15 000 circuits de 1989. Cette évolution est illustrée par la
figure 2.

Figure 2: La loi de Moore (source: http://www.intel.com/research/silicon/mooreslaw.htm)

En plus de la loi de Moore, deux autres lois empiriques sont vérifiées depuis 30 ans dans le monde
des microprocesseurs :

1. La loi de JOY: la puissance CPU en MIPS double tous les 2 ans.

2. La loi de RUGE : on a besoin d’une Bande Passante de 0,3 à 1 Mb/s par MIPS.

Toutes ces lois ont influencé le développement des systèmes embarqués. Hier, les systèmes
embarqués étaient construits avec des circuits intégrés ; aujourd’hui, on construit les SoC (System on
Chip), demain ce seront les MPSoC (Multi-Processors System on Chip) et peut-être que la
nanotechnologie avec l’électronique moléculaire nous apportera une révolution.

9
Conclusion

Ce chapitre a présenté plusieurs définitions d’un système embarqué. Trois choses importantes sont à
retenir de ces définitions: un système embarqué remplit une mission (tâche) bien spécifiée ; un
système embarqué est composé de matériel et logiciel formant un tout ; un système embarqué est
soumis à des contraintes de temps et de consommation d’énergie et fonctionne, en général, dans un
environnement contraint.

Les systèmes embarqués peuvent être classés selon plusieurs critères. Ces critères ainsi que les
classes associées ont été présentés. Les domaines d’application des systèmes ont été énumérés.
Cette énumération nous a révélé que les systèmes embarqués sont quasiment présents dans tous les
domaines d’activités de l’homme.

Les caractéristiques spécifiques aux systèmes embarqués ainsi que l’évolution des technologies font
que leur conception et réalisation sont effectuées avec des outils et langages spécifiques. Les
chapitres 3 et 4 du cours présenteront ces outils, méthodes et langages.

Au terme de ce chapitre, nous avons une idée plus claire de ce que sont les systèmes embarqués,
leurs applications et leurs spécificités. Nous pouvons maintenant commencer leur étude à
proprement parler.

10
Chapitre 2 Architecture d’un système embarqué
Dans le chapitre d’introduction, nous avons vu qu’un système embarqué est constitué de matériel et
de logiciel et que le logiciel réside dans une mémoire ROM. Dans ce chapitre, nous allons plus nous
focaliser sur l’architecture matérielle d’un système embarqué. L’organisation du code (partie
logicielle) sera abordée dans les chapitres 3 et 4 où nous traiterons de la conception et de
l’implémentation des systèmes embarqués.

Le chapitre comporte deux sections. La première section décrit les différents composants de
l’architecture ainsi que les relations entre ces composants. La seconde traite du fonctionnement d’un
système embarqué.

2.1 Structure d’un système embarqué

Figure 3: Architecture matérielle interne d'un Système Embarqué

La figure 3 décrit l’architecture matérielle interne d’un système embarqué. Les principaux éléments
de cette architecture peuvent être décrits comme suit :

 Le microprocesseur: désigné ici par UC ; c’est le cerveau du système.

 RAM: mémoire de travail du système.
 ROM: stocke le logiciel du système.
 Interfaces E/S: ces interfaces permettent de connecter des périphériques au système.
 Bus: les bus sont les nerfs permettant de relier les différents éléments de l’architecture. Dans
cette architecture on a trois types de bus : le bus de données (D), le bus d’adresse (A) et le
bus de contrôle (C).
o Bus de Données (D): bus directionnel permettant le transfert des données entre l’UC,
la RAM et les périphériques d’E/S. Entre la ROM et l’UC, le transfert est
unidirectionnel (ROM vers UC).
o Bus d’adresse (A): est utilisé pour désigner les interlocuteurs. La taille de ce bus
détermine le nombre d’adresses mémoires disponibles. Pour 16 lignes, on aura 216
adresses soit des adresses allant de 0 à 216-1 (65535).

11
 o Bus de contrôle(C): est utilisé pour le transfert des signaux de synchronisation entre
l’UC et les autres éléments interconnectés. Comme exemples de signaux, on peut
citer : Read, Write, Interupt, Acknowledgments, …
D’un point de vue externe et fonctionnel, l’architecture d’un système embarqué est dépeinte par la
figure 4 [W04].

Figure 4: Architecture externe et fonctionnelle d'un système embarqué (source : http://www-igm.univ-

mlv.fr/~dr/XPOSE2002/SE/architecture.html)

Cette architecture peut varier selon les systèmes: on peut, par exemple, ne pas trouver de systèmes
auxiliaires dans de nombreux systèmes embarqués autonomes et indépendants. En revanche,
l'architecture de base est la plupart du temps composée d'une unité centrale de traitement (CPU),
d'un système d'exploitation qui réside parfois uniquement en un logiciel spécifique (ex: routeur), ou
une boucle d'exécution (ex: ABS). De même, l'interface IHM n'est pas souvent existante, mais est
souvent utile pour reconfigurer le système ou vérifier son comportement. Les capteurs et acteurs
(actionneurs) sont des organes permettant au système de communiquer avec son environnement.
Ces actionneurs et capteurs sont, en général, connectés au CPU au moyen d’un convertisseur (A/N et
N/A).

 Capteurs : [W05] définit le capteur comme étant un organe de prélèvement d'information

qui élabore, à partir d'une grandeur physique, une autre grandeur physique de nature
différente (très souvent électrique). Cette grandeur représentative de la grandeur prélevée
est utilisable à des fins de mesure ou de commande. Virtuellement, tous les stimuli physiques
peuvent être captés (température, lumière, couleur, son, vélocité, accélération (linéaire,
angulaire), pression, champ magnétique, tension, courant, capacité...). Les capteurs sont des
organes d’entrées, car ils permettent d’obtenir des informations de l’environnement et de
transmettre ces informations au système.
 Actionneurs : un actionneur est un organe qui, recevant un ordre de la partie commande,
convertit l'énergie qui lui est fournie en un travail utile à l'exécution de tâches -
éventuellement programmées - du système. Les actionneurs permettent au système d’agir
sur l’environnement.

12
  IHM: sont les éléments utilisés pour entrer les données (clavier, boutons poussoirs,
interrupteurs à main, à pied) ainsi que les dispositifs de pointage (souris, touchpad, stylos
optiques) d’une part et les afficheurs (LED, afficheurs LCD, écrans CRT, sortie télévision)
d’autre part.
 Mémoires: On retrouve les deux types de mémoires (volatile et non volatile) dans un
système embarqué.
o Mémoire vive (volatile) : La RAM du système est utilisée pour le fonctionnement du
CPU. Elle est utilisée pour acquérir et restituer des données à haut débit. C’est une
mémoire qui joue un rôle de tampon (buffer). Le choix du type de RAM (Statique ou
dynamique) dépend du type d’interface disponible sur le processeur.
o Mémoire non volatile : est constituée de ROM et/ou de NVRAM (mémoire RAM non
volatile). Cette composante est utilisée pour stocker :
 La partie logicielle (firmware) du système,
 Les données de calibration ou de configuration,
 Les horloges temps réel (RTC) sauvegardées par batteries.
 ASIC / FPGA: Le fonctionnement du processeur peut être amélioré ou rendu plus performant
en utilisant un ASIC ou un FPGA pour réaliser certaines tâches. La figure 5 tirée de [W07]
permet d’illustrer cette approche.

Figure 5: Utilisation ASIC/FPGA dans un système embarqué

2.2 Fonctionnement d’un système embarqué

Le fonctionnement du système embarqué se résume ainsi:
 Le système reçoit des informations de l'environnement extérieur (grâce aux capteurs) et il les
convertit en signal numérique.
 L'unité de traitement composée du CPU, de la mémoire, du logiciel, de l'ASIC et
éventuellement de systèmes externes traite l'information.
 Le traitement génère éventuellement une sortie qui est envoyée vers la sortie, les systèmes
auxiliaires, les ports de monitoring ou l'IHM.
Conclusion
Ce chapitre a présenté l’architecture d’un système embarqué en mettant l’accent sur les éléments
matériels constituant le système. Les organes de calcul, d’entrées/sorties et de stockage ont été
décrits. L’aspect fonctionnement a été décrit du point de vue d’un observateur externe. Le
fonctionnement interne des différents organes ne relève pas des objectifs de ce cours.

13
Chapitre 3 Outils et langages de conception des systèmes embarqués

Contrairement à la conception des applications informatiques sur des plates-formes standard, la

conception des systèmes embarqués implique que le matériel et le logiciel se conçoivent, tous deux,
en parallèle. Bien que cette approche ne soit pas toujours suivie, elle demeure, de nos jours, la
norme. Cette conception simultanée a une profonde influence sur la façon dont la conception est
réalisée.

3.1 L’Evolution de la conception des systèmes embarqués

Aujourd’hui, les systèmes embarqués deviennent de plus en plus complexes au niveau intégration et
fonctionnalités et l'on est en mesure d'intégrer tout dans un même composant : c'est le concept du
single chip. Ceci est en fait lié à la loi empirique de Moore qui stipule que pour une surface de
silicium donnée, on double le nombre de transistors intégrés tous les 18 mois. La figure 6 montre
cette évolution.

Figure 6: Loi de Moore

La loi de Moore a radicalement changé la façon de concevoir les systèmes embarqués. On travaille
maintenant au niveau système (ou fonctionnalité) et non au niveau porte logique (pour le grand bien
des électroniciens).
Les fonctionnalités peuvent être implantées de deux façons :
 dans des composants spécifiques de type ASIC (Application Specific Intregrated Circuit). On
parle alors de Système sur Silicium SoC (System on Chip).
 dans des composants logiques programmables de type FPGA (Field Programmable Gate
Array). On parle alors de système SoPC (System on Programmable Chip).
La figure 7 résume l’évolution dans la conception des systèmes embarqués.

Figure 7: Evolution dans la conception des systèmes embarqués

14
L'approche « schématique » au niveau des portes logiques ou fonctionnalités de base RTL (Register
Transfer Logic) est délaissée pour la conception des systèmes complexes au profit d'une approche «
textuelle », mais elle reste, bien sûr, toujours valable pour la conception des systèmes embarqués
plus modestes. Pour cela, on utilise des langages de description de matériel comme VHDL (Very high
speed integrated circuit Hardware Description Language) ou Verilog pour synthétiser une
fonctionnalité numérique. Ces langages de description de matériel sont en fait de véritables langages
de programmation informatiques orientés objet et peuvent être utilisés comme tels par les
informaticiens. Ils sont utilisés conjointement avec un compilateur ou un simulateur.

Il est d'ailleurs faux de dire compilateur ; il faut plutôt dire synthétiseur, car finalement, on génère
dans la majorité des cas (conception SoPC) un fichier de programmation d'un composant logique
programmable ! On synthétise un circuit numérique, mais on ne le compile pas, bien que l'on ait une
approche logicielle pour concevoir du matériel.

Ces langages ont permis de travailler avec un niveau d'abstraction plus grand, laissant les basses
besognes au synthétiseur. On a pu rapidement développer des bibliothèques de fonctionnalités
comme une interface USB, un contrôleur MAC Ethernet que l'on appelle blocs IP (Intellectual
Property). Ces blocs IP peuvent être un peu comparés à un composant logiciel comme le Java Bean.
On peut les acheter ou bien utiliser des blocs IP libres (comme du logiciel libre) dont le site phare de
référence est http://www.opencores.org.

On peut ainsi voir la conception d'un système embarqué complexe comme un assemblage de blocs
IP, si bien que les langages de description de matériel sont un peu comme un langage assembleur vis-
à-vis d'un langage plus évolué comme le langage C.
Il est à noter que l’exploit serait de pouvoir générer un circuit numérique à partir d'un fichier source
écrit en langage informatique comme le langage C : c'est ce que propose SystemC, mais bien des
progrès restent encore à faire dans ce domaine.
Les langages de description de matériel sont aussi intéressants pour la facilité de modification et de
réutilisation d'un design précédent pour un nouveau design : c'est le design reuse. De plus, cela
permet de réduire aussi le Time To Market (TTM) cher aux gestionnaires.
Il faut noter que lorsque l'on conçoit un système embarqué complexe, on met en œuvre
généralement un processeur embarqué. Ce processeur embarqué est :
 Soit un bloc IP : on parle de processeur softcore.
 Soit déjà implanté dans le circuit électronique en « dur » : on parle de processeur hardcore.
Le processeur de ce type est généralement plus performant que le processeur du type
précédent.
Le processeur embarqué allie la souplesse du logiciel à l'accélération du temps d'exécution du
matériel. Une fonctionnalité particulière peut donc être composée d'une partie matérielle couplée à
une fonctionnalité logicielle dédiée : on a donc une conception conjointe matérielle-logicielle ou
codesign. Le codesign implique donc une conception en même temps du matériel et du logiciel, ce
qui est une nouvelle méthodologie par rapport à la méthodologie de conception classique
(conception matérielle, puis conception logicielle).

Figure 8:Conception traditionnelle et Codesign

15
Il faut noter que les processeurs embarqués, comme leurs cousins du grand public, sont de plus en
plus puissants et que la puissance CPU en MIPS double tous les 2 ans (loi empirique de Joy). En outre,
ils sont de plus en plus communicants et l'on estime que l'on a besoin d'une bande passante réseau
de 0,3 à 1 Mb/s par MIPS (loi empirique de Ruge). La course à la performance gagne aussi le monde
de l'embarqué et des systèmes embarqués complexes.
Enfin, qu'en est-il des systèmes mixtes ou purement analogiques ? Des langages de description du
matériel apparaissent comme VHDL-AMS, par exemple, mais restent confinés à la simulation. Il est à
noter qu'il commence à y avoir des composants analogiques programmables sur le marché. On peut
citer, par exemple, les pSoC de Cypress qui intègrent dans un même circuit un microcontrôleur, une
zone de logique programmable et une zone analogique. La zone analogique comporte des blocs
contenant des composants analogiques élémentaires (capacités, capacités commutées, résistances,
amplificateurs...) pour construire des fonctionnalités analogiques ou mixtes.

3.2 Le codesign
Le codesign est la méthodologie de conception la plus utilisée de nos jours pour concevoir les
systèmes embarqués. Il permet de concevoir à la fois le matériel et le logiciel pour une fonctionnalité
à implémenter. Les circuits logiques programmables offrent encore plus de possibilités d’intégration
et favorisent la mise en œuvre du codesign. Contrairement à l’approche classique où les choix
matériels sont faits en premier lieu, le codesign a l’avantage de repousser, le plus loin possible dans
la conception du système, les choix matériels à faire.

3.2.1 Les étapes dans le codesign

Le cycle de développement dans le codesign peut être découpé en sept étapes qui peuvent être
brièvement décrites comme suit :

1. Spécification : On réalise la liste des fonctionnalités du système de façon abstraite.

2. Modélisation : On conceptualise et on affine les spécifications pour produire un modèle du
matériel et du logiciel.
3. Partitionnement : on décide quelles fonctionnalités seront implémentées en logiciel et
lesquelles doivent l’être en matériel.
4. Synthèse et optimisation : on réalise la synthèse matérielle et la compilation logicielle.
5. Validation : la validation est essentiellement effectuée par co-simulation.
6. Intégration : on réalise un rassemblement des différents modules.
7. Tests d’intégration : on réalise la vérification du fonctionnement.
3.2.2 Les avantages du codesign
Le codesign présente les avantages suivants :

 Amélioration des performances : apport du parallélisme, apport d’algorithmes distribués,

architectures spécialisées, etc.
 Reconfiguration : on peut faire une reconfiguration statique ou dynamique en cours de
fonctionnement.
 Indépendance vis-à-vis des évolutions technologiques : grâce aux circuits logiques
programmables.
 Amélioration des outils de conception : on peut tirer profit des améliorations fournies par les
fabricants de circuits logiques.
 Programmables : permettent une synthèse plus efficace et une performance accrue.

16
 3.2.3 La méthodologie de conception
Comme dans toute approche de conception, une méthodologie est nécessaire. L’utilisation d’une
méthodologie bien définie assure que l’on ne va pas passer « à côté » des paramètres importants.
Une fois qu’une méthode est bien élaborée, on peut utiliser les compilateurs, les outils d’aide à la
conception logicielle ainsi que les outils de conception assistée par ordinateur pour automatiser les
étapes méthodologiques, surveiller et tracer la méthodologie.

Une méthodologie commence par définir les niveaux d’abstraction. Un niveau d’abstraction offre
une perception du système en mettant de côté certains détails pour se concentrer sur un point de
vue donnée. A chaque niveau d’abstraction, on doit analyser le système pour déterminer ses
caractéristiques actuelles et l’améliorer pour prendre en compte les détails manquants. Dans le cas
de la conception des systèmes embarqués, on peut proposer les niveaux d’abstractions indiqués
dans la figure 9.

Une fois les niveaux d’abstraction définis, on peut procéder de deux façons :
« Top-down » (approche descendante) ou « Bottom-up » (approche
ascendante).

 Top-down : on part du niveau d’abstraction le plus élevé et on descend

jusqu’au niveau le plus détaillé.
 Bottom-up : on part des composants de base nécessaires et on
remonte vers le système.
En général, on est souvent amené à utiliser conjointement les deux approches.

Figure 9: Niveaux
d'abstraction

Expression des besoins

L’expression des besoins consiste à décrire de façon précise ce que veut l’utilisateur (le client) et ce
qu’il peut espérer obtenir. Les besoins peuvent être classés en besoins fonctionnels et en besoins
non fonctionnels.

Les besoins fonctionnels expriment les sorties attendues en fonction des entrées et des paramètres.
Ce sont les besoins en termes de réalisations attendues du client.

Les besoins non fonctionnels traitent des problèmes d’efficacité, de performance (temps nécessaire
pour calculer la sortie, la taille, le poids, etc.), de consommation d’énergie, de fiabilité et de sureté du
système. Ce sont des besoins non exprimés directement par le client, mais qui doivent être pris en
compte pour l’acceptation du produit final.

Dans l’expression des besoins, il faut définir un modèle de fonctionnalité. Ce dernier propose un
format pour décrire une fonctionnalité. Un exemple de modèle de fonctionnalité peut inclure les
éléments suivants : Nom, Objectifs, Entrées, Sorties, Fonctions, Performances, Coût de production,
Consommation, Taille et Poids.

17
Spécifications
La spécification consiste à donner une description plus précise du système. Elle n’identifie pas une
architecture particulière, mais donne les éléments nécessaires à la conception de l’architecture. La
spécification prend en compte à la fois les besoins fonctionnels et non fonctionnels.

Conception de l’architecture
La conception de l’architecture consiste à se demander quels sont les composants qui satisfont aux
spécifications majeures. Il s’agit des composants matériels (CPUs, périphériques, etc.) et pour ce qui
est des composants logiciels, il faut déterminer les programmes principaux et leurs opérations. Cette
conception doit prendre en compte les spécifications fonctionnelles et non fonctionnelles.

3.2.4 Exemple : Le système GPS

Pour illustrer la méthodologie présentée, nous allons prendre un exemple
traitant partiellement de la conception du système GPS.

Une carte GPS dispose d’une base de données locale et obtient la position du
GPS lui permettant de se localiser sur la carte.
Figure 10:GPS
Besoins pour le GPS
 Fonctionnalités : Pour l’automobiliste, il faut montrer les axes principaux et les repères.
 Interface utilisateur : il faut :
o un écran 400x600 pixels, au moins,
o 3 boutons, au maximum,
o des menus déroulants.
 Performances : la carte doit être balayée en 1 seconde au maximum, après la mise sous
tension et le calage sur le GPS en moins de 15 secondes.
 Coût : 100 € maximum pour les fournitures et un coût de vente approximatif de 500€.
 Taille/poids : le produit doit tenir dans la main.
 Consommation : le produit doit fonctionner au moins 8 heures avec 4 piles de type AA.
Le modèle de besoins pour le GPS peut être celui présenté par le tableau ci-dessous.

Eléments Descriptions
Nom Carte GPS
Objectifs Carte Routière GPS pour automobile
Entrées 1 bouton on/off, 2 boutons de contrôle
Sorties LCD 400x600 rétro-éclairé
Fonctions Récepteur GPS, 3 résolutions, affichage latitude et longitude
Performances Mise à jour de l’écran 0,25 secondes
Coût de fabrication 100 € (fournitures)
Consommation 100 mW
Taille 5 cm x 12 cm
Poids 100 g

18
Spécifications pour le GPS
Cette spécification doit comprendre : ce qui est reçu du GPS, les données de la carte, l’interface
utilisateur, les opérations nécessaires pour satisfaire à la demande du client, les opérations d’arrière-
plan permettant au système de continuer à fonctionner.

Conception de l’architecture
Les figures 11 (Schéma bloc du système GPS), 12 (Architecture matérielle du système GPS) et 13
(Architecture logicielle du système GPS) décrivent l’architecture de notre système.

Figure 12: Architecture matérielle du GPS

Figure 11: Schéma bloc du GPS

Figure 113: Architecture logicielle du GPS

3.2.5 Les challenges en conception des systèmes embarqués

Les concepteurs des systèmes embarqués font face à de nombreux défis dont les plus importants
peuvent être résumés comme suit :

 De quoi avons-nous besoin en termes de matériel (hardware) ? : caractéristiques du CPU,

taille mémoire.
 Comment respecter les délais ? : faut-il un hardware rapide, ou un software intelligent ?
 Comment minimiser la consommation ? : on peut envisager de mettre en sommeil de la
logique non utilisée et/ou réduire les cycles d’accès mémoire.
 La conception fonctionne-t-elle ? : les spécifications sont-elles correctes ? est-ce que la
réalisation couvre toutes les spécifications ? comment tester les caractéristiques temps réel ?
comment teste-t-on en grandeur nature (avec des données réelles) ?
 Quelle plateforme de développement utiliser ?
3.3 La réutilisation (Reuse): IP
Les systèmes embarqués se sont compliqués et la mise sur le marché se veut plus rapide. La
réutilisation est alors indispensable pour faire face à ce défi ; d’où la notion de « Design Reuse et
d’Intellectual Property (IP) ». Le principe consiste à développer des « composants virtuels »
réutilisables. Le postulat à la base de cette approche est « qu’une compagnie seule ne peut pas
toujours produire tous les composants dont elle a besoin ». Il y a donc nécessité d’organiser un
commerce de composants virtuels. Cette démarche pose deux problèmes qu’il faut résoudre :

19
  Nécessité d’instaurer une protection juridique, d’où le terme « Intellectual Property »
 Nécessité d’utiliser un même formalisme pour la modélisation et l’utilisation pour
l’adaptation rapide au système

L’usage et le format des IPs sont présentés par la figure 14.

Figure 14: Usage et format des IPs

Les fournisseurs d’IPs

 Sociétés d’études et de conception
o Sociétés sans fonderie (« fab ») dont le profit vient des droits sur les licences
 DSP Group (IP pour les télécoms), ARM (processeurs RISCs),
o offre incluant des IPs SOFT, de simulation et synthèse.
 Sociétés de semi-conducteurs
o Peuvent fournir des Ips HARD en plus des Ips SOFT
o TI, Motorola, Lucent, Altera, Xilinx, LSI Logic, STM
 Fournisseurs d’outils de CAO
o Fournissent des Ips SOFT uniquement
 Mentor Graphics, Cadence, Synopsys,…
Types d’IPs généralement disponibles
 Processeurs:
o Picoblaze, microblaze, Leon, Nios, LSI logic CW4001/4010/4100, ARM 7TDMI, ARM
810, NEC 85x, Motorola 680x0, IBM PPC,…
 DSPs:
o TI TMS320C54X, Pine, Oak,…
 Composants de traitement spécialisés
o Cryptographie, traitement d’images, multimédia : JPEGcodec, MPEGdecoder.
 Contrôleurs mémoire et bus : SDRAM, USB, PCI, UART, AMBA
 Réseaux : ATM, Ethernet
20
Sources d’informations sur les IP
 IP commerciales
o www.design-reuse.com
 IP libres
o www.opencore.org

Conclusion

Dans ce chapitre, nous avons présenté d’une manière sommaire la conception des systèmes
embarqués. Nous avons vu que la conception de tels systèmes diffère de la conception des systèmes
informatiques classiques, car ces systèmes impliquent à la fois un aspect matériel (hardware) et un
aspect logiciel (software). L’évolution des méthodologies de conception a été présentée et nous
avons relevé que la méthode actuellement en cours est le codesign. La complexité croissante des
systèmes et le temps de mise sur le marché (TTM : Time To Market) de plus en plus court force à
allier le codesign à la réutilisation au moyen des IPs. Nous avons également décrit les défis auxquels
font face les concepteurs de systèmes embarqués.

La réalisation intégrale d’un système embarqué exige à la fois des compétences informatiques et
électroniques qui dépassent le cadre de ce cours.

Au terme de la première partie de notre cours, nous pouvons, en guise d’évaluation par rapport aux
objectifs fixés au départ, stipuler que l’étudiant qui a suivi le cours est capable de:

 Définir un système embarqué (voir section 1.1),

 Enumérer les différents types de systèmes embarqués et leurs applications (voir section 1.2),
 Décrire et expliquer l’architecture d’un système embarqué (voir chapitre 2),
 Cerner les problématiques de conception des systèmes embarqués (voir chapitre 3).
La seconde partie du cours nous permettra de réaliser la partie logicielle de systèmes embarqués où
le matériel est fixé : un téléphone mobile compatible Android.

21