Manuscrit Thse Nabil LITAYEM

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/277474499
Contributions méthodologiques à la conception et optimisation de systèmes

embarqués
Thesis · July 2014

DOI: 10.13140/RG.2.1.4938.5125
CITATIONS READS
0 5,430
1 author:
Nabil Litayem
Joaan Bin Jassim Academy for Defence Studies
28 PUBLICATIONS 101 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Motion Estimation Implementation for H.264/AVC Baseline Encoder (Master Degree) View project
Complex system modeling and implementation View project
All content following this page was uploaded by Nabil Litayem on 31 May 2015.
The user has requested enhancement of the downloaded file.

Ministère de l’Enseignement Supérieur, de la Recherche Scientifique et des Technologies
de l'Information et de la Communication, Secteur de l'Enseignement Supérieur et de la
Recherche Scientifique
****************************
Université De Carthage
****************************
Institut National des Sciences Appliquées et de Technologie
THÈSE
Présentée
Pour obtenir le grade de
Docteur de L’INSAT
Spécialité : Informatique Industrielle
Contributions méthodologiques à
la conception et optimisation de
systèmes embarqués
Réalisé par : Mr. Nabil LITAYEM
Directeur de thèse: Mr. Slim BEN SAOUD
Préparée au sein du Laboratoire: LSA
Thèse soutenue publiquement le ` 24 Juillet 2014 ´, devant le jury composé de :

Mme. Sonia Hajri Gabouj
Professeur à l’Institut National des Sciences Appliquées et de Technologie, Présidente
Mr. Joseph Haggege
Maitre de conférences à l’Ecole Nationale d’ingénieurs de Tunis, Examinateur
Mr. Mohamed Masmoudi
Professeur à l’Ecole Nationale d’ingénieurs de Sfax, Rapporteur
Mr. Mohamed Khalgui
Maitre de conférences à l’Institut National des Sciences Appliquées et de Technologie, Rapporteur
Mr. Slim Ben Saoud
Professeur à l’Institut National des Sciences Appliquées et de Technologie, Directeur de thèse
Ministère de l’Enseignement Supérieur, de la Recherche Scientifique et des Technologies de l'Information et
de la Communication, Secteur de l'Enseignement Supérieur et de la Recherche Scientifique
***************
Université De Carthage
***************
Institut National des Sciences Appliquées et de Technologie
THÈSE
Présentée
Pour obtenir le grade de
Docteur de L’INSAT
Spécialité : INFORMATIQUE INDUSTRIELLE
Contributions méthodologiques à la
conception et optimisation de systèmes
embarqués
Réalisé par : Mr. Nabil LITAYEM

Directeur de thèse: Mr. Slim BEN SAOUD
Préparée au sein du Laboratoire: LSA
Thèse soutenue publiquement le ` 24 Juillet 2014 ´, devant le jury composé de :

Mme. Sonia Hajri Gabouj
Professeur à l’Institut National des Sciences Appliquées et de Technologie, Présidente
Mr. Joseph Haggege
Maitre de conférences à l’Ecole Nationale d’ingénieurs de Tunis, Examinateur
Mr. Mohamed Masmoudi
Professeur à l’Ecole Nationale d’ingénieurs de Sfax, Rapporteur
Mr. Mohamed Khalgui
Maitre de conférences à l’Institut National des Sciences Appliquées et de Technologie, Rapporteur
Mr. Slim Ben Saoud
Professeur à l’Institut National des Sciences Appliquées et de Technologie, Directeur de thèse
2
Personne ne se souviendra de toi de par tes idées secrètes.
Demande au Seigneur la force et le savoir pour les exprimer.
« Lettre d’adieux de Gabriel García Márquez »

REMERCIEMENTS
Il me sera très difficile de remercier tout le monde, car c’est grâce à l’aide de nombreuses
personnes que j’ai pu mener cette thèse à son terme.
Je tiens tout particulièrement à exprimer ma profonde gratitude à mon directeur de thèse,

Mr Slim Ben Saoud, pour toute son aide. Je suis ravi d’avoir travaillé en sa compagnie, car outre
son appui scientiﬁque, son soutien, ses conseils et ses encouragements permanents tout au long de
ces années de recherche ont joué un rôle déterminant dans ce travail. Qu’il trouve ici l’expression
de ma profonde reconnaissance.
Je souhaite aussi adresser mes plus vifs remerciements aux membres du jury à savoir, Mme.
Sonia Hajri Gabouj, Mr. Joseph Haggege, Mr. Mohamed Masmoudi, Mr. Mohamed Khalgui, et
Mr. Slim Ben Saoud qui ont accepté d’évaluer mon travail.
Durant sept années j’ai fait partie de l’équipe « Systèmes embarqués » au sein de l’Unité de
Recherche Laboratoire d’Étude et de Commande Automatique de Processus (LECAP) de l’École
Polytechnique de Tunisie (EPT). Je remercie tous mes collègues et amis du laboratoire
particulièrement Slim Ben Othman, Ahmed Karim Ben Salem, Ahmad Achballah et Imene
Mhadhbi qui m’ont accompagné durant ces années et qui ont contribué de façon directe ou
indirecte à l’aboutissement de cette thèse. C’est en grande partie grâce aux longues discussions
acharnées concernant les différents choix techniques, les différentes approches de conception et
surtout les solutions qui permettent de contrôler toute cette complexité que j’ai pu découvrir la
richesse de ce domaine de recherche.
Un grand merci à mes collègues de la société Sagem Software and Technologies et mes amis
de la communauté de Logiciels libres en Tunisie qui m’ont donné le premier coup de pouce
permettant de raffiner mes connaissances dans le domaine des systèmes embarqués et dont l’amour
de la technologie m’a imprimé pour toujours. Merci à Ahmad Hajji, Majed Khalfallah et Patrice
Kadionik que je considère toujours comme des leadeurs avant-gardistes et que j’estime chaque
minute passée avec eux comme un don du ciel.
Merci à mes collègues du réseau ISET qui m’ont accompagné dans ce bout de chemin, m’ont
offert des opportunités d’enseigner des matières de spécialité, m’ont accordé leurs confiances et
1
m’ont surtout offert leur amitié. Merci à Mme Khouloud Jebli, Mr Ezzeddine Ben Brayek, Mr
Abdelaziz Sahbani et Mr Mohamed Lassoued.
Merci à mes amis et compagnons de covoiturage Rajoua Anene, Ramzi Ghazouani et Thabet
Slimani qui ont su transformer chaque trajet entre Tunis et Zaghouan en une table ronde concernant
les philosophies de développement économique, technologique et scientifique.
Une dédicace spéciale à mes collègues de la Faculté des Arts et des Sciences de Wadi
Addawassir en Arabie Saoudite qui m’ont accompagné durant ces deux dernières années et dont
les conseils au niveau de la recherche et de l’enseignement m’ont permis de développer divers
aspects de mes performances personnelles. Merci à Said Abdelati, Khozeima Chebr, Feiruz Amer,
Hani Alsalamouni et Ali Lammouchi pour l’ambiance qui ont établi dans le département
informatique et le département de la langue anglaise. Merci à Manzoor Kolhar pour toute
l’expérience qui m’a transférée concernant l’enseignement supérieur dans divers pays dans
lesquels il a travaillé.
Je tiens à remercier mes parents Hassen et Leila pour leurs soutiens, encouragements et
sacrifices. Que ce travail vienne récompenser toutes les années de soutien qu’ils ont pu m’apporter.
J’éprouve un absolu amour à ma femme pour sa patience, sa tendresse et ses précieux conseils,
mais surtout les grands sacrifices qu’elle n’a cessé de faire concernant la réduction des journées
de shopping (Son sport favori) afin de me laisser plus de temps pour finir ma thèse.
Enfin, il m’est impossible d’oublier mes deux anges, Youssef et Yahya pour le courage qu’ils
m’ont donné pour finir ce travail entamé avant leurs naissances et qui sont désormais passionnés
d’inventions, de sciences et de technologie. Je voudrais surtout leur rappeler que mon bureau n’est
pas un monde mystérieux à découvrir à tout prix et que mes cartes de développement ne sont pas
faites pour fabriquer des robots pour enfants.
J’en oublie certainement encore et je m’en excuse.
Encore un grand merci à tous pour m’avoir conduit à ce jour mémorable.
Nabil Litayem
2
Contributions méthodologiques à la conception et optimisation de
Mots-Clés
 Évaluation de performance  Sécurité

 Sureté  Time To market
 Internet des objets  Ingénierie à base de modèles
 SCADA  Hardware in the loop
Résumé
Les travaux présentés dans ce mémoire se situent dans le cadre des recherches en méthodologies de
conceptions de systèmes embarqués dédiés à la supervision/contrôle. Le but de cette thèse est de
proposer une méthodologie appropriée permettant l’amélioration du cycle de conception et
d’optimisation de systèmes embarqués. À travers ce travail, l’auteur essaie de présenter l’évolution des
systèmes embarqués de supervision/contrôle, des solutions méthodologiques pour la conception de ce
type de systèmes, ainsi que l’optimisation de métriques liées aux aspects non fonctionnels qui
deviennent prépondérants, notamment ceux qui sont liés à la sureté et à la sécurité de ces systèmes.
Le travail repose principalement sur quatre volets :
Évolution des technologies embarquées de supervision/contrôle : Ce volet essaie de parcourir

l’évolution de ce domaine permettant de retracer les différentes architectures disponibles pour ce type
de systèmes. Ceci à travers la transmutation de ces technologies du domaine industriel vers le domaine
domotique pour aboutir à l’internet des objets. D’autre part, dans cette section l’auteur essaie de
présenter les différentes solutions technologiques aussi bien matérielles que logicielles permettant de
concevoir ce type de systèmes.
Étude de la conception à base de modèles et son application pour la conception de contrôleur

embarqué : Dans cette partie, l’auteur essaie de faire la comparaison entre plusieurs méthodologies
de conception de systèmes embarqués permettant à la fois d’optimiser les métriques liées au temps de
conception, la traçabilité du produit et la certifiabilité du contrôleur final en vue de son adoption dans
une application critique. Ce travail est validé à travers l’implémentation d’un modèle DCM en utilisant
divers outils d’ingénierie à base de modèles pour une application HIL.
Choix de plateforme matérielle/logicielle, performances, fonctionnalités et outils liés : À

travers cette section l’auteur explore les différentes méthodes d’évaluation de performance afin de
proposer un flot utilisant des solutions open source dans les phases de sélection de la plateforme
d’implémentation. Le flot de conception proposé est particulièrement approprié à la conception de
systèmes embarqués à base de circuit FPGA et fonctionnant sous un environnement Linux temps-réel.
Sécurité des systèmes embarqués de supervision contrôle : Dans cette partie, l’auteur détaille les
problèmes et les solutions de sécurités liés aux systèmes de supervision/contrôle qui sont actuellement
considérés comme un composant essentiel de l’internet des objets. Par la suite, il étudie le cas
particulier des algorithmes de hachage et leurs applications dans ce type d’applications. Cet exemple
est complété par une étude de cas visant à choisir un algorithme de hachage adéquat pour une
plateforme à base du microcontrôleur MSP430 utilisé dans un RTU d’un système SCADA. Enfin cette
étude est complétée par une comparaison des performances obtenues par le passage à des
microcontrôleurs plus performants tels que Tiva_C et Piccolo C2000.
3
Methodological contributions to the design and optimization of
embedded systems
Keywords
 Performance evaluation  Security

 Safety  Time to market
 Internet of Things  Model based design
Summary
The contribution of this thesis is in the context of research in methodologies for embedded system
design. The purpose of this thesis is to propose an appropriate methodology for the design and
optimization of embedded systems used in supervisory control applications. Through this contribution,
the author has taken in an attempt to deliver the progress in the embedded systems field for supervision
and control applications, methodological solutions for the design and optimization of non-functional
metrics mainly related to safety and security standards.
Following are the contributions:
Technological development in the area of supervision/control application: This section

attempts to retrace the development of this unconventional field for tracking different architectures
available for this kind of systems. The evolution of these technologies for industrial automation field
to achieve IoT. On the other hand, in this section, the author tries to survey the different hardware and
software solution suitable for the design of such systems.
Model Based Design and its application in the design of an embedded controller: In this
section, the author tries to make a comparison between several embedded systems design
methodologies allowing both time to market, optimizing, product traceability and certifiability of the
designed controller for potential utilization in critical applications. This work is done using DCM
implementation using various MBD tools for HIL applications.
Choice of hardware/software platform, performance, features and related tools: Through this
section, the author evaluates the different methods of performance evaluation in choosing suitable
hardware/software platform and also provides a performance evaluation methodology using open
source solutions. This work enables developers to make early decisions to choose the adequate
platform. The proposed design flow is particularly suitable for the design of embedded systems based
on an FPGA platform.
Security of embedded systems used in supervisory control application: In this part, the author
describes the security problems and solutions related to the supervisory/control applications, which are
now considered an essential component of the Internet of Things. Subsequently, he presents the special
case of hashing algorithms and their applications in this type of systems. This example is
complemented by a case study to choose a suitable hashing algorithm for an embedded platform based
on MSP430 microcontroller used in a SCADA RTU system. Finally, this study is followed by a
comparison of the achievable performance by switching to more efficient microcontrollers such as
Tiva C C2000 and Piccolo.
4
TABLE DES MATIÈRES
TABLE DES MATIÈRES ________________________________________________________________________ 5
LISTE DES FIGURES ____________________________________________________________________________ 9
LISTE DES TABLEAUX _______________________________________________________________________ 11
LEXIQUE _______________________________________________________________________________________ 12
INTRODUCTION GÉNÉRALE ________________________________________________________________ 17
Objectifs et enjeux de la thèse _________________________________________________________________ 20
Références liées à la thèse ____________________________________________________________________ 22
CHAPITRE 1 : ÉVOLUTION ET ENJEU DES SYSTEMES EMBARQUES

DE SUPERVISION CONTROLE ______________________________________________________ 24
I. Introduction __________________________________________________________________________ 25
II. Évolution des systèmes embarqués ________________________________________________________ 25
III. Systèmes embarque pour des Applications de Supervision Contrôle et Acquisition de Données________ 27
1. Définition des applications SCADA _______________________________________________________ 28
2. Ressources de conception _____________________________________________________________ 31
3. Notions d’écosystème ________________________________________________________________ 32
4. Architecture logicielle du contrôleur embarqué_____________________________________________ 33
5. Sûreté de fonctionnement _____________________________________________________________ 35
6. Sécurité des systèmes de contrôle _______________________________________________________ 35
7. La consommation d’énergie ____________________________________________________________ 36
8. Performance des systèmes embarqués ___________________________________________________ 37
IV. Systèmes embarqués de commande _______________________________________________________ 38
V. Plateforme matérielle pour système embarqué ______________________________________________ 40

1. Influence du contrôleur utilisé sur le processus à commander _________________________________ 40
2. Notions de plateformes matérielles ______________________________________________________ 41
3. Plateformes microcontrôleurs __________________________________________________________ 41
4. Circuit FPGA ________________________________________________________________________ 42
5. Les différents éléments d’un circuit FPGA _________________________________________________ 44
6. System On Chip (SoC) _________________________________________________________________ 46
7. IPs Matérielles ______________________________________________________________________ 48
VI. Plateformes logicielles pour systèmes embarqués de contrôle commande ________________________ 50

1. Introduction ________________________________________________________________________ 50
2. Notion de firmware ou logiciel embarqué _________________________________________________ 51
3. Système d’exploitation et système d’exploitation temps-réel __________________________________ 52
4. Pilote de périphériques________________________________________________________________ 52
5. Couches d’abstraction ________________________________________________________________ 53
VII. Conclusion _________________________________________________________________________ 56
5
Table des matières
CHAPITRE2 : CONCEPTION A BASE DE MODELES POUR
L’ASSURANCE QUALITE DE SYSTEMES EMBARQUES DE
CONTROLE/COMMANDE ______________________________________________________________ 58
I. Introduction __________________________________________________________________________ 59
II. Enjeu et solutions apportées par l’ingénierie à base de modèles _________________________________ 60

1. Maitrise de la complexité ______________________________________________________________ 60
2. Minimisation des coûts ________________________________________________________________ 61
3. Les processus de développement à base de modèle _________________________________________ 62
III. Certification des systèmes critiques de contrôle commande ____________________________________ 63

1. Systèmes critiques et défis industriels ____________________________________________________ 63
2. Systèmes industriels __________________________________________________________________ 65
3. Systèmes médicaux :__________________________________________________________________ 65
4. Transports terrestres et ferroviaires______________________________________________________ 66
5. Certification pour l’aéronautique ________________________________________________________ 67
IV. Exploitation du principe HIL ______________________________________________________________ 69

1. Intérêts de la technique HIL ____________________________________________________________ 69
2. Problématique ______________________________________________________________________ 71
V. Implémentation d’un modèle DCM en utilisant la méthodologie MBD ____________________________ 72

1. Processus de développement et outils associés _____________________________________________ 72
2. Garanties de qualité __________________________________________________________________ 74
3. Architecture du contrôleur _____________________________________________________________ 75
4. Gestion des ressources humaines _______________________________________________________ 76
5. Gestion des propriétés intellectuelles ____________________________________________________ 77
VI. Concept X-IN-THE-LOOP et son application à la conception de contrôleurs embarqués modernes ______ 79
VII. Implémentation matérielle d’un DCM pour une utilisation en HIL _____________________________ 81
1. Introduction aux outils de génération rapide de modules matériels _____________________________ 81
2. Implémentation d’un HIL en utilisant des outils HLS _________________________________________ 81
3. Implémentation d’un HIL en utilisant des outils MBD ________________________________________ 82
4. Comparaison des résultats de synthèse en utilisant l’approche HLS et MBD ______________________ 84
VIII. Implémentation logicielle temps-réel du modèle DCM pour une utilisation HIL __________________ 86
1. Introduction au principe de fonctionnement de Scale-RT _____________________________________ 86
2. Résultats de simulation du DCM utilisant Scale-RT __________________________________________ 87
IX. Conclusion ____________________________________________________________________________ 89
CHAPITRE 3 : CHOIX DE PLATE-FORME MATERIELLE/LOGICIELLE,

PERFORMANCES, FONCTIONNALITES ET OUTILS LIES _________________ 91
I. Introduction __________________________________________________________________________ 92
1. Enjeux liés aux choix d’une plateforme matérielle/logicielle ___________________________________ 92
2. Choix de plateforme __________________________________________________________________ 93
3. Évaluation de performance ____________________________________________________________ 94
II. Plateforme étudiée _____________________________________________________________________ 95

1. Processeur LEON3____________________________________________________________________ 95
2. Le système d’exploitation temps-réel eCos ________________________________________________ 96
3. Combinaison eCos – LEON3 ____________________________________________________________ 97
III. Benchmarks utilisés ____________________________________________________________________ 98

1. Dhrystone __________________________________________________________________________ 98
6
2. Stanford ___________________________________________________________________________ 98
3. Paranoia ___________________________________________________________________________ 99
IV. Mesure et analyse des performances _____________________________________________________ 100

1. Résultats obtenus avec le benchmark Dhrystone___________________________________________ 101
2. Résultats obtenus avec le benchmark Stanford ____________________________________________ 102
3. Résultats obtenus avec le benchmark Paranoia ____________________________________________ 103
4. Analyse des résultats obtenus _________________________________________________________ 104
V. Choix de plateforme logicielle ___________________________________________________________ 105

1. Systèmes d’exploitation temps-réel _____________________________________________________ 105
2. Linux en tant que système d’exploitation temps-réel _______________________________________ 106
3. Choix d’une extension Linux temps-réel pour une application de contrôle _______________________ 110
VI. Technologie Linux temps-réel____________________________________________________________ 113

1. Preemptible Kernel (lowlatency) _______________________________________________________ 114
2. PREEMPT-RT _______________________________________________________________________ 114
3. RTAI ______________________________________________________________________________ 115
4. Xenomai __________________________________________________________________________ 115
VII. Mesure et Benchmarking des performances temps-réel ____________________________________ 117

1. Outils de mesure de performances _____________________________________________________ 117
2. Outils de Benchmarking ______________________________________________________________ 118
3. Outils de stress logiciel _______________________________________________________________ 119
4. Caractérisations temps-réel des différentes extensions temps-réel ____________________________ 120
5. Mesure des performances système _____________________________________________________ 123
6. Interprétations _____________________________________________________________________ 126
VIII. Protocoles de communication _________________________________________________________ 126
IX. Conclusion ___________________________________________________________________________ 128
CHAPITRE 4 : SECURITE DANS LES ENVIRONNEMENTS

EMBARQUES DE SUPERVISION ET DE CONTROLE _______________________ 130
I. Introduction _________________________________________________________________________ 131

1. Évolution __________________________________________________________________________ 132
2. Machine To Machine ________________________________________________________________ 136
3. Défit _____________________________________________________________________________ 137
II. Sécurité des systèmes embarqués de contrôle ______________________________________________ 138

1. Besoin de sécurité___________________________________________________________________ 138
2. Solutions de sécurité_________________________________________________________________ 139
3. Cryptographie ______________________________________________________________________ 140
4. Protocoles de sécurité _______________________________________________________________ 142
5. Filtrage de trafic ____________________________________________________________________ 143
6. Algorithmes de hachage ______________________________________________________________ 144
7. Implémentation embarquée des fonctionnalités de sécurité _________________________________ 146
III. Enjeu de sécurité lié aux applications SCADA _______________________________________________ 146

1. Interconnexion des systèmes SCADA aux réseaux publics ____________________________________ 146
2. Introduction du modèle de « cloud computing » dans les applications SCADA et besoins de sécurité __ 148
IV. Environnement d’implémentation faibles coût s faible consommation___________________________ 149

1. Introduction aux microcontrôleurs MSP430_______________________________________________ 150
2. Carte MSP430 Launchpad _____________________________________________________________ 151
3. RTU étudié ________________________________________________________________________ 153
7
Table des matières
V. Environnements d’implémentation concurrents _____________________________________________ 154
1. Plateforme TIVA_C Launchpad _________________________________________________________ 155
2. Plateforme C2000 Piccolo Launchpad ___________________________________________________ 155
3. BoosterPacks_______________________________________________________________________ 156
VI. Choix et adaptation d’un algorithme de hachage ____________________________________________ 157

1. Etude des algorithmes de hachage légers ________________________________________________ 157
2. Algorithme de hachage QUARK ________________________________________________________ 159
3. Evaluation de performance des différents profils de l’algorithme de hachage QUARK sur notre RTU __ 159
4. Evaluation de performance des différents profils de l’algorithme de hachage QUARK les plateformes
alternatives_____________________________________________________________________________ 161
5. Analyse des résultats ________________________________________________________________ 162
VII. Conclusion ________________________________________________________________________ 163
CHAPITRE 5 : CONCLUSION GENERALE ET PERSPECTIVES _________________________ 165
Conclusion générale ________________________________________________________________________ 166
Perspectives ______________________________________________________________________________ 167
BIBLIOGRAPHIE _____________________________________________________________________________ 169
8
LISTE DES FIGURES
FIGURE 1 . ÉVOLUTION DES TENDANCES ARCHITECTURALES DANS LA CONCEPTION DE
SYSTÈMES EMBARQUES 26
FIGURE 2. ARCHITECTURE GENERALE D’UN SYSTEME DE PRODUCTION MODERNE 28
FIGURE 3. ARCHITECTURE SCADA CLASSIQUE 29
FIGURE 4. ARCHITECTURE SCADA UTILISANT L’INFRASTRUCTURE INTERNET 30
FIGURE 5. GAMME DE PROCESSEURS EMBARQUES A BASE D’ARM CORTEX COMMERCIALISEE
PAR TEXAS INSTRUMENTS 32
FIGURE 6. ARCHITECTURE LOGICIELLE A BASE DE COMPOSANTS 33
FIGURE 7. ARCHITECTURE LOGICIELLE EN COUCHES 33
FIGURE 8. FLOT SIMPLIFIE D’UNE EXPLORATION D’ARCHITECTURE BASEE SUR L’EVALUATION
DE PERFORMANCES 38
FIGURE 9. PHASES DE SIMULATION DANS UN PROCESSUS DE DEVELOPPEMENT SUR CIRCUIT
FPGA 43
FIGURE 10. ARCHITECTURE CLASSIQUE D’UN CIRCUIT FPGA 44
FIGURE 11. STRUCTURE FONCTIONNELLE D’UN SOC 47
FIGURE 12. TOPOLOGIE DES ARCHITECTURES MULTIPROCESSEURS HÉTÉROGÈNES 47
FIGURE 13. ARCHITECTURE DE BASE D’UN FIRMWARE 51
FIGURE 14. DIFFÉRENTES VUES DES PILOTES DE PÉRIPHÉRIQUES DANS LES SYSTEMES
EMBARQUES 53
FIGURE 15. CONCEPT DE HARDWARE ABSTRACTION LAYER 54
FIGURE 16. CONCEPT DE » OPERATING SYSTEM ABSTRACTION LAYER » 54
FIGURE 17. ARCHITECTURE INTERNE DU SYSTEME ANDROID 55
FIGURE 18. PRINCIPE GÉNÉRAL D’UNE SIMULATION UTILISANT LE PRINCIPE HARDWARE IN THE
LOOP 70
FIGURE 19. FONCTIONNEMENT INTERNE D’UN MODULE HARDWARE IN THE LOOP 71
FIGURE 20. CYCLE DE CONCEPTION D’UN CONTRÔLEUR EMBARQUE 72
FIGURE 21. CONCEPT DE PARTITIONNEMENT LOGICIEL 76
FIGURE 22. ARCHITECTURE IMA 76
FIGURE 23. PRINCIPE DE FONCTIONNEMENT D’UN CONTRÔLEUR EMBARQUE GENERIQUE 79
FIGURE 24. PROTOTYPAGE D’UN CONTRÔLEUR EMBARQUE EN UTILISANT LE PRINCIPE X-IN-THE-
LOOP 80
FIGURE 25. SCHEMA DE PRINCIPE DU MODELE D’UNE MACHINE A COURANT CONTINU 82
FIGURE 26.SCHEMA BLOC DU MODELE DE LA MACHINE A COURANT CONTINU IMPLEMENTE
AVEC XSG 83
FIGURE 27. RESSOURCES FPGA UTILISEES PAR LES DIFFÉRENTES IMPLEMENTATIONS
MATERIELLES DE LA MACHINE A COURANT CONTINU 85
FIGURE 28. FREQUENCES MAXIMALES ATTEINTES PAR LES DIFFERENTES 85
FIGURE 29. PRINCIPE DE FONCTIONNEMENT DE SCALE-RT 87
FIGURE 30. MODELE INTERNE DE LA MACHINE A COURANT CONTINU CONÇU AVEC
SCILAB/SCICOS 88
FIGURE 31. VUE HIERARCHIQUE DU MODELE DE LA MACHINE A 88
FIGURE 32. SIMULATION TEMPS-REEL DE LA MACHINE À COURANT CONTINU 89
FIGURE 33. ARCHITECTURE INTERNE DU PROCESSEUR LEON3 96
FIGURE 34. ARCHITECTURE INTERNE DU SYSTEME ECOS 97
FIGURE 35. FLOT D’EVALUATION DE PERFORMANCE ADOPTE 100
FIGURE 36. RESULTATS EN DHRYSTONES MIPS 101
FIGURE 37. TEMPS D’EXÉCUTION EN MILLISECONDES DES DIX ALGORITHMES DU BENCHMARK
STANFORD 102
FIGURE 38. PERFORMANCE COMPOSITE DES DEUX ARCHITECTURES POUR LE CALCUL EN
VIRGULE FIXE ET EN VIRGULE FLOTTANTE 103
FIGURE 39. COMPOSANTS DE BASE D’UN SYSTEME D’EXPLOITATION TEMPS-REEL 106
FIGURE 40. ARCHITECTURE INTERNE D’UN SYSTEME 107
FIGURE 41. ARCHITECTURE INTERNE D’UN SYSTEME LINUX TEMPS 108
FIGURE 42. ARCHITECTURE INTERNE D’UN SYSTEME LINUX TEMPS-REEL UTILISANT 109
FIGURE 43. ARCHITECTURE INTERNE D’UN SYSTEME LINUX TEMPS-REEL BASE SUR LE NOYAU
LINUX 2.6 110
FIGURE 44. PRINCIPE DE FONCTIONNEMENT DU SUPERVISEUR ADEOS 114
9
FIGURE 45. GESTION DES INTERRUPTIONS AVEC XENOMAI 116
FIGURE 46. ARCHITECTURE DES SKINS XENOMAI 117
FIGURE 47. ANALYSE STATISTIQUE DES RÉSULTATS OBTENUS AVEC LE NOYAU LINUX AVEC 120
FIGURE 48. ANALYSE STATISTIQUE DES RÉSULTATS OBTENUS PAR LE NOYAU LINUX AVEC LE
PATCH PREEMPT-RT 121
FIGURE 49. ANALYSE STATISTIQUE DES RÉSULTATS OBTENUS PAR LE NOYAU LINUX
LOWLATENCY 121
FIGURE 50. ANALYSE STATISTIQUE DES RÉSULTATS OBTENUS PAR LE NOYAU LINUX STANDARD
122
FIGURE 51. ANALYSE STATISTIQUE DES RÉSULTATS OBTENUS PAR LE NOYAU LINUX POUR
SERVEURS 122
FIGURE 52. PERFORMANCE GLOBALE POUR LES DIFFÉRENTS
NOYAUX ÉTUDES TOURNANT SUR UNE ARCHITECTURE MONOPROCESSEUR 125
FIGURE 53. PERFORMANCE GLOBALE POUR LES DIFFÉRENTS NOYAUX 125
FIGURE 54. PROTOCOLE IEEE POUR DIVERS DOMAINE GEOGRAPHIQUE 127
FIGURE 55. ÉVOLUTION DES RESEAUX INFORMATIQUES DE PEER TO PEER VERS L’INTERNET DES
OBJETS 133
FIGURE 56. VUE GLOBALE DU DOMAINE DE L’INTERNET DES OBJETS 134
FIGURE 57. ARCHITECTURE MODERNE D’UN SYSTEME A BASE D’OBJETS INTELLIGENTS 135
FIGURE 58. ARCHITECTURE HAUT NIVEAU D’UN SYSTEME M2M 137
FIGURE 59. PRINCIPE DE FONCTIONNEMENT D’UN ALGORITHME DE CRYPTAGE SYMETRIQUE 141
FIGURE 60. PRINCIPE DE FONCTIONNEMENT D’UN ALGORITHME DE CRYPTAGE ASYMETRIQUE 142
FIGURE 61. FILTRAGE DE TRAFIC AU NIVEAU DES COUCHES BASSES DU MODELE TCP/IP 144
FIGURE 62. FILTRAGE DE TRAFIC ENTRE LAN ET WAN PAR UN FIREWALL 144
FIGURE 63. PRINCIPE DE FONCTIONNEMENT D’UN ALGORITHME DE HACHAGE 145
FIGURE 64. ARCHITECTURE D’UN SYSTEME SCADA MODERNE 147
FIGURE 65. SYSTEME SCADA ENTIEREMENT LOGE DANS LE CLOUD 149
FIGURE 66. DIAGRAMME BLOCK DU MICROCONTROLEUR MSP430G2X53 152
FIGURE 67. CARTE MSP430 LAUNCHPAD 152
FIGURE 68. RTU ETUDIEE 153
FIGURE 69. INTERFACE DE SUPERVISION ET DE PARAMETRAGE DU RTU ETUDIE 153
FIGURE 70. TEMPS D’EXÉCUTION DES DIFFÉRENTS PROFILS DE L’ALGORITHME DE HACHAGE
QUARK 160
FIGURE 71. EMPREINTE MEMOIRE DE DIFERENTS PROFILE DE L ALGORITHME QUARK 160
FIGURE 72. TEMPS D’EXÉCUTION SUR LES PLATEFORMES MSP430, C2000 ET TIVA C 161
FIGURE 73. EMPREINTE MEMOIRE DES DIFFÉRENTS PROFILS DE L’ALGORITHME QUARK SUR LES
PLATEFORMES MSP430, C2000 ET TIVA_C 162
10
LISTE DES TABLEAUX
Tableau 1. Modéle en couche de logiciel embarqué ................................................................................34
Tableau 2. Liste des normes de sureté de l’IEC ainsi que leurs domaines d’application ..........................65
Tableau 3. Outils de géneration automatique de codes classifiés selon leurs categories ..........................73
Tableau 4. Configurations materielles des plateformes evaluées ........................................................... 101
Tableau 5. Résultats detaillés des performances obtenus avec le benchmark ........................................ 101
Tableau 6. Resultats obtenus avec les deux simulateurs de plateformes pour le benchmark Stanford .... 102
Tableau 7. Programme de mesure des performances temps-réel ............................................................ 118
Tableau 8. Benchmarks disponibles sous licence libre pour l’évaluation des performances système ...... 119
Tableau 9. Outils de géneration de stress pour un système Linux disponible sous licence libre.............. 119
Tableau 10. Attaques courantes pouvant toucher un système SCADA .................................................. 148
Tableau 11. Principales caractéristiques du microcontroleur MSP430................................................... 150
Tableau 12. Algorithmes de hachage candidats a notre application ....................................................... 158
11
LEXIQUE
ABS: Antilock Braking System

ADEOS: Adaptive Domain Environment for Operating Systems
API: Application Programming Interface
ARINC: Aircraft Radio Incorporated
ASIC: Application-Specific Integrated Circuit
AUTOSAR: Automotive Open System Architecture
CAO: Conception Assistée par Ordinateur

CCS: Code Composer Studio
CDB: Component Based Design
CDRH: Center for Devices and Radiological Health
CENELEC: Comité Européen de Normalisation Électrotechnique
CFS: Completely Fair Scheduler
CISC: Complex Instruction Set Computer
COTS: Component Off the Shelf
CPU: Central Processing Unit
cSoC: Configurable System on Chip
CSP: Communicating Sequential Processes
DCS: Distributed Control System

DECOS: Dependable Embedded Components and Systems
DLL: Delay Lock Loop
DoS: Denial Of Service
DSC: Digital Signal Controller
DSP: Digital Signal Processor
12
DSS: Digital Signature Standard
eCos: Embedded Configurable Operating System

EDF: Earliest-Deadline-First
EDIF: Electronic Design Interoperability Format
EEMBC: EDN Embedded Microprocessor Benchmark Consortium
ESL: Electronic System Level
EUROCAE: European Organisation for Civil Aviation Equipment
FAA: U.S. Federal Aviation Administration

FDA: US Food and Drug Administration
FFT: Fast Fourier Transform
FPGA: Field-Programmable Gate Array
GNU: Gnu's Not Unix

GPL: General Public License
GSM: Global System for Mobile Communications
HAL: Hardware Abstraction Layer

HDL: Hardware Description Language
HIL: Hardware In Loop
HLL: High Level Language
HLS: High Level Synthesis
HMPSoC: Hybrid Multiprocessor System On Chip
13
I
IDE: Integrated Development Environment

IdO: Internet des Objets
IEC: International Electrotechnichal Comission
IHM: Interface Homme Machine
IMA: Integrated Modular Avionics
INNORPI: Institut National de la Normalisation et de la Propriété Industrielle
IPSec: Internet Protocol Security
IRM: Imagerie par résonance magnétique

ITRON: Industrial The Real-time Operation Nucleus
I2C: Inter-Integrated Circuit
IP: Intellectual Property
JTAG: Joint Test Action Group
LAN: Local Area Network

LUT: Look Up Table
MBD: Model Based Design

MCU: Microcontroller Unit
MDA: Model Driven Architecture
MDE: Model Driven Engineering
MHRA: Medecines and Helthcare Product Regulatory Agency
MIPS: Million Instructions Per Second
MISRA: Motor Industry Software Reliability Association
MPSoC: Multiprocessor System On Chip
Mutex: Mutual Exclusion
14
N
NFC: Near Field Communication
OSEK/VDX: Systems and the Corresponding Interfaces for Automotive Electronics

OSAL: Operating System Abstraction Layer
OMG: Object Management Group
PID: Proportional, Integral, Derivative

PIL: Processor In the Loop
PLC: Programmable Logic Control
PLL: Phase-Locked Loop

POSIX: Portable Operating System Interface for Unix
PSoC: Programmable System-On-Chip
RFID: Radio Frequency Identification

RISC: Reduced Instruction Set Computer
RTAI: Real Time Application Interface
RTCA: Radio Technical Commission for Aeronautics
RTOS: Real-Time Operating System
RTU: Remote Terminal Unit
SAT: Satisfiability Modulo Theories

SCADA: Supervisory Control and Data Acquisition
SIL: Software-in-Loop
SMP: Symmetric Multi-Processor
SPEC: Performance Evaluation Corporation standard
15
SRAM: Static Random Access Memory
SPI: Serial Peripheral Interface
TDD: Test Driven Design

TDD: Test Driven Development
TLS: Transport Layer Security
UML: Unified Modeling Language

USCI: Universal Serial Communication Interface
WAN: Wide Area Network

WCET: Worst Case Execution Time
WISP: Wireless Identification and Sensing Platform
XSG: Xilinx System Generator
16
INTRODUCTION GÉNÉRALE
« L’imagination est ce qui tend à devenir réel. »
André Breton
17
Introduction Générale
D
e nos jours, les systèmes embarqués occupent une place de plus en plus
prépondérante dans notre vie quotidienne. Une place qui a fait que le 21éme siècle
soit considéré comme celui de la révolution embarquée, durant lequel les
utilisateurs ont des besoins croissants en termes de fonctionnalités, de performance, de fiabilité et
de qualité. Ces systèmes sont présents dans la majorité des produits technologiques qui nous
entourent, ils intègrent pour la plupart des processeurs, des mémoires et des capacités de
communication évoluées et variables. La conception de tels systèmes est désormais confrontée à
des freins technologiques, notamment liés à la maîtrise de leurs complexités, leurs coûts et leurs
temps de mise sur le marché. Le processus de développement de tels systèmes doit respecter des
flots de conception, de développement et de test normalisés afin de respecter les besoins non
fonctionnels liés à conception de ces systèmes. Par ailleurs le choix de la technologie adéquate
répondant à un besoin fonctionnel devient un point prépondérant dans la conception d’un tel
système vu le nombre colossal d’alternatives technologiques possibles pouvant répondre à un
besoin donné selon des stratégies économiques et techniques variables.
Les constructeurs sont désormais amenés à produire des systèmes de plus en plus complexes
constitués de plusieurs sous-systèmes de natures différentes dans des temps record avec des
niveaux de fiabilité élevés. Les calculateurs au cœur de ces systèmes peuvent être constitués de
plusieurs processeurs de même nature référencés dans la littérature par MPSoC1 ou de nature
différente référencée dans la littérature par HMPSoC2. Par ailleurs, on assiste de nos jours à
l’émergence de plusieurs technologies potentiellement intéressantes telles que les cSoC3 et les
PSoC4 offrant une alternative permettant de contrôler les problèmes liés aux performances, à la
consommation d’énergie et à la complexité des applications modernes.
La plupart des plateformes matérielles haut niveau disponible actuellement sur le marché sont
des HMPSoC ou offrent la possibilité de les étendre vers des HPMSoC. À titre d’exemple, on peut
citer les plateformes Sony CELL, TI OMAP, ST Nomadik, Philips Nexperia, Diopsis D940 et
ACTEL SmartFusion2. Ces plateformes sont constituées de processeurs, interconnexions, caches,
mémoires, réseaux, périphériques matériels. Chaque processeur ou coprocesseur doit disposer de
son programme binaire ce qui introduit un grand nombre de challenges au niveau de la partie
logicielle de ces systèmes notamment lors de leurs exploitations dans des applications critiques.
1
Multiprocessor System On Chip
2
Hybrid Multiprocessor System On Chip
3
Configurable System on Chip
4
Programmable System-On-Chip
18
La partie logicielle pour sa part a connu plusieurs bouleversements conceptuels sur le plan
applicatif ou système [1]. En effet, au niveau applicatif l’évolution des langages de programmation
embarquée [2] est le phénomène le plus remarquable qui a permis d’introduire de plus en plus
d’abstractions au niveau développement d’applications embarquées, mais aussi de maîtriser la
complexité des systèmes conçus. D’autre part, l’adoption de systèmes d’exploitation embarqués
devient un fait irréfutable dans ce domaine. Leur adoption a été accompagnée d’autres challenges
techniques concernant la personnalisation, la certifiabilité pour un domaine spécifique, mais
surtout la cohabitation de plusieurs systèmes d’exploitation sur la même plateforme matérielle afin
de bénéficier des avantages liés à chacun de ces systèmes. On assiste actuellement à l’émergence
d’une nouvelle catégorie de systèmes embarqués multiprocesseurs multisystèmes d’exploitation
[3] à plusieurs niveaux de contraintes temps-réel permettant de bénéficier des diverses possibilités
temporelles et fonctionnelles de ces systèmes sur la même plateforme.
Le domaine du contrôle/commande pour sa part n’a cessé d’évoluer, son évolution est
désormais directement liée à celle des systèmes informatiques qui le contrôle. La transition
mainframe, station de travail, PC continu à évoluer vers des applications de plus en plus
miniaturisées faisant émerger des systèmes embarqués extrêmement sophistiqués à des coûts
abordables. Ces systèmes sont désormais omniprésents dans notre vie courante afin de fournir des
fonctionnalités parfois critiques. Leurs nombres peuvent dépasser les milliards, ce qui a incité
l’émergence de nouvelles technologies réseau indispensables à leur prolifération et
interconnexions.
Ces systèmes sont en grande partie disponibles dans des applications productiques, robotiques,
automobile ou aéronautique. Actuellement, grâce à un système embarqué à faible coût, faible
poids, faible consommation on peut commander un robot mobile, le freinage d’une voiture, le
guidage d’un missile ou une chaîne de production industrielle. Grâce aux nouvelles technologies
de communication, ces systèmes peuvent être supervisés et commandés de n’importe quel point
du globe en utilisant des terminaux standards tels que des ordinateurs personnels, des tablettes ou
des Smartphones. La conception d’un tel système nécessite des outils de CAO1 appropriés et une
méthodologie de conception adaptée afin de profiter des évolutions technologiques sans être
étouffée par la complexité du système ou exposée à des risques sécuritaires.
Avec l’apparition des circuits FPGA2, un autre pas est franchi en avant, offrant de nouvelles
possibilités telles que le développement de fonctions matérielles spécifiques afin d’améliorer les
performances, la possibilité d’ajouter des modules matériels spécifiques à une application
1
Conception Assistée par Ordinateur
2
Field-Programmable Gate Array
19
déterminée, la reconfigurabilité partielle ou totale et le cryptage du code et du design. Ceci a

contribué à améliorer les performances en termes de puissance de calcul, d’économie d’énergie,
de coût de revient et de sécurité.
Par ailleurs, d’autres plateformes matérielles telles que les microcontrôleurs qui sont
massivement présents dans les systèmes embarqués sont l’un des meilleurs rapports qualité-prix
des technologies d’implémentation. Ces microcontrôleurs ont atteint un niveau de maturité
impressionnante favorisant leurs adoptions dans des applications à très large échelle notamment
dans les applications nécessitant un très niveau d’autonomie et d’économie.
Toutefois, ces évolutions génèrent de nouveaux enjeux tels que celui de l’approche
méthodologique à suivre afin de réaliser un tel système dans des délais acceptables, en utilisant les
ressources de façon optimale tout en offrant des possibilités de réutilisation afin de compresser les
coûts des projets futurs.
Objectifs et enjeux de la thèse
On peut classer les systèmes embarqués de façon grossière en deux catégories, ceux qui sont
orientés vers le traitement de signal et le calcul intensif, et ceux qui sont orientés vers les
applications de contrôle/commande. Chacun de ces deux domaines a ses propres classes de
contraintes. Toutefois, ces deux catégories ne sont pas strictement indépendantes. Les systèmes de
production industrielle utilisant des fonctionnalités de traitement d’image et la plateforme de jeu
interactif fournissant des retours de force réagissant aux signaux issus de divers capteurs sont une
forme de la convergence des deux catégories.
Si on avait à dresser l’état actuel des systèmes embarqués de contrôle/commande, on

constaterait que ces systèmes sont omniprésents dans des équipements dont des vies humaines
dépendent directement tels que les applications aéronautiques, spatiales, automobiles ou
robotiques. D’autre part, ils sont de plus en plus intégrés dans des équipements domotiques dont
la défaillance peut affecter des consommateurs ordinaires.
Ces systèmes sont désormais considérés comme critiques vu que leurs défaillances peuvent
amener à des dégâts considérables pouvant mettre en jeu des vies humaines, des biens ou de
l’environnement. Ces aspects incitent les acteurs du domaine à se focaliser sur des techniques, des
méthodologies et des outils permettant de concevoir, implémenter et maintenir ce genre de
systèmes afin d’assurer un niveau de sureté minimum.
20
Actuellement, la majorité des outils et des méthodologies sont focalisés sur des normes de
sécurité établies et approuvés par les équipementiers et les systémiers du domaine. Dans le
domaine aéronautique, l’adoption des normes DO-178 et DO-254 permettent d’assurer une qualité
minimale des systèmes de contrôle aéronautique. Pour le domaine automobile, plusieurs normes
existent telles que AUTOSAR et MISRA permettant de normaliser l’architecture du système de
commande et la règle de codage adoptée.
D’autre part, l’adoption de fonctionnalités de communication pour les systèmes embarqués

modernes a introduit de nouveaux risques pour les individus et les biens. En effet, plusieurs types
d’attaques peuvent être dirigés vers ce type de systèmes. Notamment ceux qui sont utilisés dans
des infrastructures critiques. Ceci a incité plusieurs initiatives essayant de proposer des solutions
permettant d’améliorer le niveau de sécurité de ces infrastructures.
L’objectif général de cette thèse est de proposer une méthodologie permettant d’améliorer les
métriques liées à la conception de systèmes embarqués de supervision contrôle à travers des
pratiques qui peuvent améliorer la durée de conception, le choix de la plateforme
matérielle/logicielle et la sécurité du système conçu. Ceci sera abordé dans les chapitres suivants
à travers des études pratiques concernant les différents points abordés dans cette thèse tels que la
méthodologie de conception et de génération, le choix de la plateforme et la sécurisation du
système réalisé.
Le but de cette thèse est de proposer une méthodologie permettant d’optimiser les métriques
liées au flot de conception des systèmes embarqués destinés aux applications de
contrôle/commande. Les métriques à étudier sont la durée de conception, la portabilité, la
performance, la fiabilité et la sécurité. Ce domaine sera abordé à travers des réalisations pratiques
permettant de mettre l’accent sur les différents aspects liés à la conception de ce type de systèmes.
Durant cette thèse on abordera trois points vitaux dans la réalisation de systèmes embarqués
impliqués dans des applications de supervision/contrôle. Tout d’abord, on abordera les
méthodologies à base de modèle permettant une traçabilité du produit tout au long du cycle de
développement et assurant la possibilité de génération de code certifié. Ces méthodes seront
couplées aux techniques de HIL1 afin de permettre de commencer les tests durant les premières
phases du cycle de vie du produit. Elles peuvent aussi être exploitées pour faire des tests « in situ »
durant le fonctionnement du produit afin d’assurer une meilleure fiabilité. Le concept de HIL peut
aussi être étendu pour minimiser l’utilisation de capteurs ce qui peut contribuer à minimiser le coût
global du système.
1
Hardware In The Loop
21
En second lieu, on abordera les étapes de choix de plateformes matérielles et logicielles. Cette
partie essayera de présenter les critères et le processus de choix afin de garantir le meilleur niveau
de performance du système réalisé. Les étapes de choix seront illustrées par des études de cas
pratiques aussi bien au niveau sélection de plateforme matérielle que logicielles. Les étapes de
sélection de la plateforme matérielle sont guidées par une collection de benchmarks permettant de
refléter les divers aspects de performance de ces plateformes. Pour sa part, le choix de la
plateforme matérielle est entamé à travers l’étude de diverses extensions Linux temps réel afin de
refléter le niveau de déterminisme temporel offert ainsi que son impact sur les performances
globales du système étudié.
Enfin, on étudiera les problèmes de sécurités dans les systèmes embarqués modernes. Ce
problème est devenu un des plus importants aspects à traiter concernant les systèmes modernes
notamment avec l’avènement de l’Internet des Objets. À travers ce volet, on abordera les différents
risques de sécurité ainsi que les solutions disponibles. On complètera cette partie par une étude de
cas pratique concernant les phases de choix d’un algorithme de hachage pouvant fournir plusieurs
fonctionnalités permettant d’améliorer la sécurité de tels systèmes.
Références liées à la thèse
Les travaux effectués durant cette thèse ont donné lieu aux publications suivantes.
Revues internationales avec comité de lecture
1. N Litayem, M Kolhar, I Mhadhbi, S M. Abd El-atty, S Ben Saoud. “Hashing Based

Authentication for Ultra-Low Cost Low Power SCADA Application Using MSP430
Microcontroller”, IJETAE Volume 3, Issue 12, December 2013 500-506.
2. N Litayem, B Jaafar, S Ben Saoud. “Embedded Microprocessor Performance
Evaluation Case Study Of The Leon3 Processor”, JESTEC Vol. 7, No. 5 (2012) 574 –
588.
3. N Litayem, AB Achballah, SB Saoud. « Building XenoBuntu Linux Distribution for
Teaching and Prototyping Real-Time Operating Systems”, IJACSA Vol. 2, No.2,
February 2011.
4. N Litayem, B Jaafar, S Ben Saoud. “Embedded Microprocessor Performance
Evaluation rt Study Of The Leon3 Processor”, TECNIA Journal of Management
Studies, 40, Vol. 2, No.2, September 2011.
5. N Litayem, S Ben Saoud, “Impact of the Linux Real-time Enhancements on the
System Performances for Multi-core Intel Architectures”, IJCA 2011, Number 2 -
Article 3.
6. N Litayem,S Ben Saoud, “Rapid Hardware-In-the-Loop Implementation for FPGA
Based Embedded Controller for More Reliable Electrical Traction Systems”, JCSCS
2010 Volume 3, Issue 2.
22
Conférences internationales et nationales avec comité de lecture
1. I Mhadhbi, N Litayem, S Ben Othmen, and S Ben Saoud, “DSC Performance

Evaluation and Exploration, Case of TMS320F335”, International Conference on
Control, Engineering & Information Technology (CEIT’13) Proceedings Engineering
& Technology - Vol.1, 2013
2. N Litayem, S Ben Saoud, “Impact of real-time enhancements on the computation
performances for multi-core intel architectures”, JTEA’2010, Hammamet, Tunisia,
April 2010.
3. N Litayem, M Ghrissi, AK Ben Salem, S Ben Saoud, “Designing and building
embedded environment for robotic control application”, IECON 2009 Porto,
Portugal, November 3-5, 2009.
4. AK Ben Salem, S Ben Othman, S Ben Saoud, N Litayem, “Servo Drive System Based
on Programmable SoC Architecture”, IEEE IECON 2009 Porto, Portugal, November
3-5, 2009.
5. N Litayem, M Ghrissi, S Ben Saoud, « Étude de l’Influence de la Communication
Processeur Mémoire sur la Performance d’un SoC, à base de circuit FPGA
XILINX », JTEA’08, Hammamet, Tunisia, April 2008.
6. M Ghrissi, S Ben Saoud, N Litayem, « Correction des erreurs systématiques de
l’odomètre et suivi de trajectoires sur un robot mobile industriel type tricycle »,
JTEA’08, Hammamet, Tunisia, April 2008.
7. N Litayem, M Ghrissi, S Ben Saoud, “Embedded Microprocessor Systems Hardware
Performance Evaluation and Benchmarking”, ICESCA’08, Gammarth, Tunisia, May
2008.
8. N Litayem, M Ghrissi, S Ben Saoud, « Étude comparative des moyens de
communication inter processeurs dans les architectures MPSoC », GEI’08, Sousse,
Tunisia, March 2008.
23
CHAPITRE 1 :
ÉVOLUTION ET ENJEU DES SYSTEMES
EMBARQUES DE SUPERVISION CONTROLE
« En vérité, le chemin importe peu, la volonté d’arriver suffit à tout. »
de Albert Camus
Extrait du Le Mythe de Sisyphe
24
Évolution et enjeu des systèmes embarqués de supervision contrôle
I. Introduction
Durant ces deux dernières décennies, les domaines de l’électronique et de la technologie de

l’information ont vécu une évolution remarquable ayant un effet rétroactif qui a été à l’origine de
plusieurs bouleversements conceptuels dans ces deux domaines. Par ailleurs, elle a été à l’origine de
l’apparition d’une toute nouvelle technologie qui est celle des systèmes embarqués. L’utilisation de
ces systèmes a évolué du domaine expérimental vers le loisir pour atteindre les applications critiques.
Ces systèmes occupent une place tellement importante dans la vie des utilisateurs finaux que leurs
dégradations de service même occasionnelles sont devenues intolérables.
Les systèmes embarqués sont désormais enfouis dans la majorité des équipements de
consommation utilisés pour améliorer la qualité de vie des consommateurs. Dans beaucoup de cas, la
défaillance de ces équipements peut mettre en péril des vies humaines ou causer des dégâts matériels
énormes. Ces derniers sont désormais considérés comme critiques, ce qui incite les acteurs du
domaine à se focaliser sur des techniques, des méthodologies et des outils permettant de concevoir,
implémenter, maintenir et optimiser ce genre de systèmes. Ce chapitre a pour objectif de faire le tour
des connaissances de base concernant les systèmes embarqués utilisés dans des applications de
supervision/contrôle afin de fournir un socle de connaissances indispensables pour le reste du
manuscrit.
II. Évolution des systèmes embarqués
Durant les balbutiements liés à l’invention des ordinateurs durant les années 1930-1940, les
ordinateurs ont toujours été conçus pour des tâches spécifiques. Le principal obstacle qui se posait
contre une adoption à large échelle de ce genre de système était toujours lié leurs coûts. La
décroissance des prix imposés par la loi de Moore a permis de réintroduire ces ordinateurs à la place
des contrôleurs électromécaniques classiques. Ce qui a permis au départ d’implanter des algorithmes
de contrôles classiques, mais aussi avec la croissance des performances matérielles de ces calculateurs
d’implanter des algorithmes de contrôle plus sophistiqués basés sur des techniques de traitement
d’image ou de vidéo utilisant des fonctionnalités d’intelligence artificielle. Par ailleurs, les
possibilités offertes par l’interconnexion de plusieurs contrôleurs a permis une évolution considérable
dans l’automatisation de processus industriels et a permis l’apparition de nouvelle génération de
systèmes automatises notamment les systèmes DCS et SCADA.
25
Chapitre 1
Le calculateur de guidage de la fusée Apollo lancée pendant les années 1960 est l’un des premiers
systèmes embarqués reconnus qui ont montré le rôle que ces systèmes peuvent prendre dans les
équipements modernes. Dès le lancement de ce projet, le système de guidage développé par des
chercheurs du laboratoire instrumentation du MIT a été considéré comme le composant le plus risqué
du système [4] vu le nombre d’innovations technologiques introduites par ce composant.
D’ailleurs c’est le succès de ce projet qui a affirmé la place des contrôleurs embarqués dans
l’industrie moderne même si les coûts des premiers systèmes étaient vraiment effrayants. Depuis les
années 1960, les prix des systèmes embarqués n’ont cessé de décroître, les puissances de calcul de
croître et les fonctionnalités de s’enrichir [5]. Ceci a permis une évolution des systèmes à base de
processeur Intel 4004 nécessitant l’utilisation de banc mémoire externe et des circuits d’interface
discrets vers des systèmes à base de microcontrôleurs intégrant tous ces périphériques sur un même
circuit. Cette évolution a permis de s’en passer des circuits analogiques coûteux tels que les
potentiomètres et les capacités variables par des boutons-poussoirs permettant de passer des
informations de paramétrages au calculateur. La réduction de surface silicium a incité les acteurs du
domaine des semi-conducteurs à intégrer de plus en plus de fonctionnalités sur le même circuit
intégré, ce qui a permis de réduire le nombre de composants utilisés lors de la conception d’un
système numérique et par conséquent le coût final du produit. Ceci a conduit à l’apparition de
plusieurs technologies couramment utilisées telles que les SOC, le SOPC et les cSOC. Les
architectures adoptées lors de la conception de tels systèmes ont connu plusieurs phases d’évolution
illustrées par la Figure 1 [6].
Changements dans l’environnement

social
Dernières innovations
Plateforme
Taille du logiciel (Coût)
1000
100 PF
Basés sur des SE
Plateformes
Micro-ordinateur auto adaptatives à
10 l’environnement
relatif)
1990 2000 2010

Équipements Traitement
Interface Adaptation à
Fonction de contrôle
numérique du
utilisateur
Réseaux l’environnement
signal
Micro-ordinateur Systèmes Interface Web

d’exploitation utilisateur
Figure 1. Évolution des tendances architecturales dans la conception de systèmes embarqués
26
III. Systèmes embarqués pour des

Applications de Supervision
Contrôle et Acquisition de Données
L’une des premières applications des systèmes embarqués était dans le domaine de
contrôle/commande et acquisition de données. Depuis quelques années, les systèmes SCADA1 et
DCS2 sont présentés comme deux familles différentes. Une catégorisation controversée par plusieurs
chercheurs. Notamment, avec les progrès technologiques accomplis qui rendent obsolètes les raisons
de distinction basées sur le fait qu’un système DCS est principalement préoccupées par le
comportement du processus et qu’un système SCADA est principalement préoccupé par les
évènements du processus [7]. Dans le reste de notre travail, on parlera essentiellement de systèmes
SCADA sachant que la majorité des points étudiés s’appliquent aux systèmes DCS.
Contrairement aux systèmes de contrôle classiques qui utilisaient des technologies pneumatiques
ou analogiques, les systèmes modernes utilisent des technologies numériques permettant d’introduire
des fonctionnalités de contrôle et de supervision délocalisés faibles coûts avec des niveaux de
performances élevés. Ces systèmes permettent de superviser et de contrôler des équipements
embarqués en donnant des consignes à distance et en collectant des données pouvant être utilisés pour
l’analyse et la prise de décision. Combinés aux nouvelles technologies de communication et d’analyse
de données, ils permettent d’avoir des solutions sophistiquées pouvant être généralisées à divers
domaines de l’électronique classique afin d’introduire un haut niveau d’innovation et de qualité.
De nos jours, il est devenu courant de rencontrer des systèmes SCADA constitués de milliers de
capteurs et actionneurs capables d’enregistrer les données ainsi que de simuler des scénarios
particuliers. Ces systèmes SCADA sont désormais dotés de fonctionnalités réseau très évoluées ainsi
que des architectures matérielles sophistiquées rendant l’implémentation d’algorithme de contrôle
distribué très abordable. Par ailleurs, ces mêmes technologies abordables à des prix extrêmement
compétitifs ont facilité l’implémentation de nouvelles lois de commandes et d’algorithmes
d’intelligence artificielle. Ces systèmes sont omniprésents dans les systèmes de production
industrielle touchant tous les secteurs d’activité comme illustrés par la Figure 2. Cette présence
1
Supervisory Control and Data Acquisition
2
Distributed Control System
27
Chapitre 1
permet d’accroitre le rendement des sociétés et d’améliorer la qualité des produits issus de leurs
chaînes industrielles vu qu’ils bénéficient d’une meilleure traçabilité.
Figure 2. Architecture générale d’un système de production moderne
1. Définition des applications SCADA
SCADA est l’acronyme de « Supervisory control and data acquisition » désignant tout système
permettant la supervision, la gestion et le monitoring de processus ou de production automatisé à
travers la collecte et l’analyse des données issue du monde réel [8]. Ces systèmes sont largement
déployés de façon transparente dans notre vie quotidienne, dans la production d’énergie électrique,
l’extraction et la transformation de produits pétroliers, la production de produits agroalimentaires
ainsi que les domaines liés à l’amélioration des conditions de vie des individus, la préservation de
l’environnement et la surveillance des biens.
Ces systèmes ont évolué du simple pupitre basé sur des boutons-poussoirs et quelques diodes de
supervision vers des systèmes impliquant des technologies de communication radiofréquence et des
terminaux intelligents sophistiqués. Plusieurs acteurs industriels ont investi une grande part de leur
28
budget alloué à la recherche afin de garantir leurs parts de marche dans ce domaine potentiellement
porteur en proposant des solutions innovantes pouvant conquérir les clients potentiels.
Actuellement, SAMSUNG est devenue leadeur dans l’utilisation de terminaux intelligents dans
des tâches de supervision et de contrôle, National Instruments, Siemens et Texas Instruments ont
confirmé leurs places dans le développement de contrôleurs embarqués. Par ailleurs, d’autres sociétés
essaient d’imposer leurs technologies dans des niches de marchés en offrant des innovations
spécifiques à un domaine d’application donné. Le haut niveau d’innovation introduit par ce domaine
ainsi que l’enjeu économique considérable continue à poser des questions d’ordres éthiques. Ceci est
essentiellement dû au fait de connecter des équipements personnels à des réseaux publics facilitant
l’usurpation d’identité, la limitation de la vie privée, ou tout simplement la publicité ciblée posée par
l’utilisation de nouveaux terminaux intelligents pouvant offenser les utilisateurs. En effet, ces
équipements peuvent être exploités pour avoir un nombre impressionnant d’informations
personnelles telles que la localisation, la température ou même le nombre de battements de cœur.
L’architecture globale d’un système SCADA a atteint un haut niveau de maturité. Ce système peut
être vu de façon hiérarchique ou comportementale [9] permettant de le voir en tant que trois ensembles
de composants qui sont le matériel, le logiciel et l’interface graphique. Par ailleurs vu le manque de
visibilité architecturale l’approche hiérarchique est plus adoptée, car elle permet de voir le système
de façon structurée constituée des composants illustrés dans les Figures 3 et 4.
Station principale du système SCADA Lien de communication Station distante
Equipements électroniques
Ondes radiofréquence à intélligents
spéctre étalé
Actionneurs
Instrument de mesure
IHM principale
du système Points de Accumulateurs
SCADA contrôle Remote

externes Terminal
Unit
Paire torsadée
Fibre optique
Ligne téléphonique
Ligne louée
Programmable Logic
Controller (PLC)
Figure 3. Architecture SCADA classique
29
Chapitre 1
Réseau de
communication IS Internet
P
Fournisseur de
services SCADA
Passerelle Internet
Site Web pour

l'accès des
utilisateurs
PLC RTU IED
Processus distants Application client
Figure 4. Architecture SCADA utilisant l’infrastructure internet
L’unité de terminal distant RTU (Remote Terminal Unit)
Un RTU1 est le composant responsable du traitement intelligent des données issues d’entrées
sorties. Ces données peuvent être issues de contacteurs, de capteurs, de transmetteurs ou tout
simplement issues d’un autre RTU. Ils sont par la suite transformés et arrangés dans un format
intelligible par le système SCADA afin d’effectuer des tâches de supervision ou de prise de décision.
D’autre part, le RTU est responsable de la transformation des ordres issus du contrôleur ou de l’IHM2
vers un état approprié au processus contrôlé.
Contrôleur programmable
Le contrôleur programmable est un composant considéré comme le cerveau du système SCADA.

Il peut être construit à base de plusieurs technologies, telles que microcontrôleur, DSC3, FPGA, cSOC
ou PLC4. Le choix d’une plateforme particulière dépend de plusieurs critères tels que le coût de
reviens, la performance escomptée, les fonctionnalités requises, la scalabilité et la connectique. Les
données traitées par ce composant sont essentiellement issues de l’environnement local ou fournies
par les RTU impliquant des contraintes particulières en termes de robustesse et d’autonomie. Ce
composant héberge l’algorithme de contrôle du processus contrôlé, ce qui fait de lui le maillon central
du système SCADA.
1
Remote Terminal Unit
2
Interface Homme Machine
3
Digital Signal Controller
4
Programmable Logic Control
30
Interface homme-machine
L’interface homme-machine est le moyen par lequel l’utilisateur interagit avec le système. Une
interface homme-machine simple permet d’avoir une représentation simple et ergonomique de ce qui
se passe à l’intérieur du système. Ces interfaces utilisent actuellement des technologies d’écran tactile,
de clavier spécialisé, de commandes vocales ou gestuelles. Ceci permet ainsi d’avoir une vision
simplifiée de systèmes extrêmement complexes. Plusieurs métriques sont liées à la qualité
d’utilisation d’une interface homme-machine, ceci a incité plusieurs efforts de standardisations telles
que celui de l’International Engineering Consortium qui a établi le standard ISO 9241 permettant de
qualifier une interface homme machine [10].
2. Ressources de conception
Les ressources de conception associées à une plateforme matérielle ou logicielle donnée sont un
point couramment négligé lors du choix de la plateforme matérielle. Ce choix a un impact non
négligeable sur le coût final du produit, sa sécurité et sa sureté de fonctionnement. En effet, le fait de
choisir une plateforme standard ayant une quantité non négligeable de ressources de développement
aussi bien au niveau matériel que logiciel permet de s’affranchir de plusieurs difficultés concernant
la conception de ce système [11]. Par ailleurs, les outils de conception peuvent être considérés comme
des ressources de conception, car ces derniers sont désormais les socles permettant un accès facile à
diverses ressources de référence. Ainsi le choix d’une plateforme matérielle pour la conception de
systèmes embarqués ne doit pas se faire indépendamment des outils et des ressources associés.
Texas instruments est l’un des meilleurs exemples illustrant l’exploitation de ses ressources de
conception. En effet, son outil de développement Code Composer Studio permet de gérer toutes les
plateformes numériques de la société ainsi qu’une interface Web permettant l’accès aux diverses
ressources de développement concernant toutes les plateformes supportées. Ceci a pour effet direct
de minimiser le temps de conception et d’implémentation vu que plusieurs designs de référence sont
disponibles, mais aussi de faciliter le portage vers d’autres plateformes du même constructeur afin
d’obtenir de meilleures performances, de minimiser les coûts ou la consommation. Pour les domaines
d’application spécialisés, Texas Instruments propose des environnements complémentaires qui
peuvent facilement être intégrés à CCS1 l’exemple le plus connu est Control Suite qui permet de gérer
les plateformes numériques destinées au domaine du contrôle de processus.
1
Code Composer Studio
31
Chapitre 1
3. Notions d’écosystème
Le choix d’une plateforme d’implémentation d’un contrôleur embarqué doit toujours être effectué
en prenant des considérations liées aux possibilités d’évolutions potentielles. En effet, le marché de
siliciums est actuellement submergé par des circuits innovants, mais malheureusement ces derniers
peuvent poser des problèmes potentiels liés à la limitation de la gamme de produits issus de la
compagnie ou à l’absence de support logiciel adéquat. Si on essayait d’analyser une part infime des
produits de la société Texas Instruments illustrée par la Figure 5, on constaterait une richesse
impressionnante, rien qu’en observant la gamme concernant les circuits à base du processeur ARM
Cortex [12]. Ceci donne aux utilisateurs la possibilité de migrer de façon naturelle d’un composant
vers un autre [13]. D’autre part, le fait que la société utilise un cœur standard tel qu’ARM Cortex
offre la possibilité d’utiliser l’écosystème logiciel lié à ce processeur et une migration simple d’un
fabricant silicium vers un autre. Par ailleurs, la majorité des concurrents essaient de proposer des
solutions concurrentes en offrant des choix comparables bénéficiant d’un écosystème le plus complet
que possible. En effet, cette notion d’écosystème regroupant les possibilités matérielles et logicielles
lies a un composant sont un des critères les plus déterminants lors de l’adoption industrielle d’un
circuit, car elle garantit a l’utilisateur un certain niveau d’indépendance du fabricant de silicium.
Figure 5. Gamme de processeurs embarqués à base

d’ARM Cortex commercialisée par Texas Instruments
32
4. Architecture logicielle du contrôleur embarqué
L’implémentation des fonctionnalités de contrôle requiert l’adoption d’une architecture logicielle

adéquate dès les premières phases de la conception. En effet, l’échec de plusieurs projets embarqués
ainsi que plusieurs débordements budgétaires ont été associés à l’absence de standardisations
architecturales. Actuellement, il existe deux architectures couramment utilisées permettant de
modéliser le système en classes illustrées par la Figure 6 ou en couches illustrées par la Figure 7.
Interface utilisateur
supervision contrôle
Contrôleur en
Contrôleur de
Application de
séquence
boucle
I/O Application
Figure 6. Architecture logicielle à base de composants
Niveau Haut
Couche d'interface
utilisateur
Couche de traitement
de processus
Couche de commande de
composants
Couche d'interface / pilote de
périphérique
Couche système
d'exploitation
Couche matérielle
du processeur
Niveau Bas
Figure 7. Architecture logicielle en couches
33
Chapitre 1
Grâce à sa simplicité, l’architecture en couche reste la plus adoptée dans les applications de
contrôle classiques. En effet, elle permet de diviser l’ensemble du logiciel en six couches selon la
séquence d’exécution des commandes envoyées à partir de l’interface utilisateur. La partie de
l’interface qui reçoit d’abord une commande est définie comme le niveau le plus élevé, le processeur
qui répond enfin à cette commande est défini comme le niveau bas. Le rôle de chacune des six couches
utilisées dans les systèmes de contrôle embarqué est récapitulé dans le Tableau 1. Par ailleurs,
contrôleurs modernes ont tendances a adopté l’architecture à base de composants vue qu’elle favorise
l’utilisation d’algorithmes multitâches ainsi que l’introduction d’interface utilisateur.
Tableau 1. Modèle en couche de logiciel embarqué
Couche d’interface Cette couche est responsable de la communication et de l’interaction entre

utilisateur l’utilisateur et le système commandé. Elle reçoit les instructions de l’utilisateur et
les transmet vers une couche inférieure, puis affiche les résultats obtenus du
système à l’utilisateur. Cette couche contient normalement des objets graphiques
tels que des boutons, des bars et des boîtes de dialogue, etc.
Couche de Cette couche est responsable de la création, la gestion et l’élimination de processus
traitement de (appelé aussi tâche). Elle crée un processus chaque fois qu’elle reçoit des
processus instructions de l’utilisateur, puis gère le déroulement de ce processus, y compris les
paramètres obtenus, la gestion de la simultanéité et exclusivité mutuelle, etc. Quand
un processus est terminé, il est supprimé.
Couche de Le composant est défini comme un sous-système ou d’une partie individuelle du
commande de système ou dispositif commandé. Par exemple, le sous-système « scanner » est un
composants composant d’une machine à copier. Un système ou un périphérique peuvent avoir
plusieurs composants pour son contrôle. Les responsabilités de cette couche
comprennent la communication et l’interaction avec les couches supérieures et les
couches inférieures ainsi que la gestion et le traitement des processus en cours.
Couche Dans ce contexte, un dispositif signifie un sous-système ou une partie du composant
d’interface/pilote défini précédemment. Par exemple, le composant de balayage d’une machine de
de périphérique copie peut avoir un tel dispositif que son circuit de papier de transport volant, les
circuits de lecture d’image numériques et les circuits d’interface qui avec d’autres
composants ou dispositifs de la machine. Parce qu’il se compose essentiellement
de firmware codé en dur dans les circuits intégrés programmables ou dans l’ASIC 1,
cette couche peut être comprise dans la couche système d’exploitation.
Cette couche est l’intermédiaire entre le microprocesseur et les composants
Couche système
extérieurs du système commandé. Elle est responsable de l’ordonnancement des
d’exploitation
processus, gère les ressources telles que la mémoire et les disques, et gère la
communication avec les périphériques et les composants.
Couche matérielle Cette couche comprend le firmware du CPU2 et le code de démarrage dans le
du processeur chipset microprocesseur.
1
Application-Specific Integrated Circuit
2
Central Processing Unit
34
5. Sureté de fonctionnement
La sureté de fonctionnement est un des points les plus importants concernant la conception de
systèmes impliqués dans des applications de contrôle. Les domaines d’application de ces systèmes
sont aussi divers que variés. En effet, on peut les trouver dans des applications aéronautiques,
aérospatiales, médicales, transports ferroviaires ou dans les applications de production industrielle.
L’adoption d’une plateforme de contrôle nécessite des choix concernant la plateforme matérielle tels
que l’immunité, la détection et la correction des erreurs. D’autre part, l’adoption de normes
concernant la sureté de fonctionnement telles que les normes DO-178 ou DO-254 permet d’assurer
un minimum de qualité concernant les composants logiciels et matériels [14]. Actuellement, plusieurs
normes sont disponibles afin d’assurer le respect des règles de codage telles que la famille de normes
MISRA largement adoptées dans le domaine automobile [15].
Par ailleurs, le choix d’une méthodologie adéquate telle que la conception à base de modèles ou
la conception à base de composants [16] permet d’assurer une qualité minimale du fait que ces
méthodologies permettent de minimiser l’impact de l’erreur humaine vue que les composants
impliqués sont approuvés et testés. Une connaissance des performances matérielles est nécessaire lors
des premières phases de conception. Les constructeurs de plateformes DSP1, microcontrôleurs
fournissent des valeurs de références pouvant être prise en considération lors du choix d’une
plateforme. Toutefois, lors de l’adoption d’une plateforme FPGA, le large choix en termes de
processeurs embarqués nécessite que ces mesures soient effectuées par le concepteur lui-même. Cette
connaissance permet aux concepteurs d’être à l’abri des défaillances issues d’une non-conformité
temporelle vu que l’exactitude temporelle est un des aspects vitaux de ce type de systèmes.
6. Sécurité des systèmes de contrôle
Les systèmes de contrôle sont désormais remarquablement diffusés et utilisés dans notre vie
quotidienne. Ils sont aussi couramment connectés à divers types de réseaux tels que les réseaux de
contrôle et les réseaux domestiques. Une intrusion dans un réseau de contrôleurs peut causer plus de
dégâts que dans un réseau informatique classique [17]. Ceci a amené plusieurs sociétés, laboratoires
et organismes de normalisation d’essayer de trouver des solutions efficaces aux problématiques de
sécurité des infrastructures de contrôle. D’autre part, l’aspect sécurité concerne aussi les données ou
les programmes disponibles à l’intérieur des systèmes numériques de contrôle qui sont susceptibles
1
Digital Signal Processor
35
Chapitre 1
d’être copiés et dupliqués pour des buts purement commerciaux ou simplement pour corrompre les
données de façon illégale.
Les nouvelles plateformes matérielles intègrent désormais des systèmes de protection

sophistiqués utilisant des algorithmes de cryptographie tels que DPA Hardened, AES2561 et SHA256.
La technologie utilisée a aussi un impact vital sur la sécurité de ces systèmes. Par exemple,
l’utilisation d’une technologie flash au lieu d’une technologie SRAM pour des circuits FPGA permet
d’améliorer la sécurité de ces systèmes vu que ces données ne peuvent pas être copiées durant leurs
transits entre le circuit SRAM et le circuit FPGA.
Les prochaines générations d’équipements électroniques seront dominées par les composants
intelligents et extrêmement communicants. Cette tendance est d’autant amplifiée par le fait que le
coût de revient de ce type d’équipement devient de plus en plus abordable. On voit ainsi un autre
usage de la loi de Moore qui fait que le coût de revient des calculateurs est divisé par deux tous les
18 mois. Cette diminution des prix permet de voir beaucoup plus d’équipements intelligents dans des
domaines autrefois imprévisibles. Ces systèmes seront plus présents dans les applications liées au
suivi médical, sécurité, agriculture ou commerce. Ces applications ont pour points communs des
besoins en communication, supervision et contrôle. En effet, ça devient plus difficile de voir des
limites claires permettant de faire une distinction objective des domaines tels que les WSN2, WSAN3,
SCADA, DCS qui sont désormais considérés comme des objets dans un contexte plus général qui est
l’internet des objets. La criticité des domaines d’application de ces systèmes a introduit de nouveaux
challenges technologiques impliquant des considérations de sécurité au niveau de leur conception.
Actuellement, on assiste à une vague de solutions permettant d’améliorer la sécurité en améliorant
les aspects liés à la sécurisation de la communication, l’authentification ou la protection de la
propriété intellectuelle [18].
7. La consommation d’énergie
L’augmentation impressionnante des factures énergétiques a impliqué plusieurs considérations

dans la plupart des pays industrialisés concernant la minimisation de la consommation d’énergie des
circuits électroniques. En effet, ces pays ont imposé des sanctions économiques aux circuits
gourmands en électricité ce qui a permis de voir naître des systèmes numériques et analogiques plus
1
Advanced Encryption Standard
2
Wireless Sensor Network
3
Wireless Sensors and Actor Networks
36
performants, économes et autonomes. La plupart des fabricants de semi-conducteurs ont optimisé la

consommation de leurs produits de puissance et ont développé une nouvelle génération de
technologies numériques optimisées en consommation d’énergie [19] telle que la nouvelle génération
des processeurs ARM proposée par la majorité des fabricants de silicium, le
MSP430 de Texas Instruments ou le RL78 de Renesas. Ce phénomène s’est aussi étendu aux
fabricants de circuits FPGA qui ont essayé de développer les plateformes FPGA très économiques en
énergie telle que la plateforme ACTEL SmartFusion2. La majorité de ces nouvelles plateformes
travaillent sur la variation de fréquence du composant en fonction de la charge de travail affectée à
ce composant.
Par ailleurs, ces nouvelles plateformes ont introduit plusieurs challenges de programmation vu
que les fonctionnalités de gestion d’énergie sont désormais gérées au niveau applicatif. Les
programmeurs de ces nouvelles générations de plateformes sont désormais confrontés à ce nouveau
problème qui s’ajoute à l’aspect fonctionnel. Vu les coûts des batteries et les exigences des
utilisateurs, cet aspect devient déterminant lors de l’adoption d’une plateforme embarquée ou mobile.
8. Performance des systèmes embarqués
L’évolution actuelle des systèmes embarqués a mis sur le marché des SoC intégrant des
processeurs qui peuvent être considérés comme l’aboutissement des technologies numériques. Ils sont
constitués de plusieurs millions de transistors et sont dotés de plusieurs fonctionnalités d’optimisation
de performance [20].
Ces processeurs sont de plus en plus dotés de fonctionnalités facilitant l’exécution de plusieurs
instructions en parallèle, d’exécuter des programmes dans un ordre différent du programme fourni,
de prévenir les branchements et de gérer la consommation d’énergie de façon intelligente. La
conception, l’optimisation et l’évaluation de performances de tels systèmes peuvent être considérées
comme un vrai défi qui nécessite un long processus itératif de conception, d’optimisation et de
validation. Ce processus est en général effectué selon l’algorithme illustré par la Figure 8.
L’utilisation de méthodes d’évaluation de performances est requise à différents niveaux du flot

de conception. Son utilisation dans les premières phases du cycle de conception permet de minimiser
les retours dus à la non-conformité de performances. Durant ces phases, des modèles de performances
peuvent être adoptés. Toutefois, les performances estimées par ces modèles doivent être validées
après la réalisation du système final. Cette validation est effectuée par mesure de performances en
utilisant des benchmarks appropriés, qui permettent de reporter des résultats permettant de prendre
37
Chapitre 1
des décisions concernant les modifications à apporter pour les réalisations futures. Ainsi, l’évaluation
de performance peut être classifiée en deux catégories, la modélisation de performance et la mesure
de performance [21]. La mesure de performance est uniquement valable si le système en question est
disponible. D’autre part, les travaux de parallélisassions des phases de conception matérielle et
logicielle ont mis sur le devant de la scène les approches d’estimation de performances qui peuvent
être considérées comme les nouveaux challenges qui affrontent à la fois les fabricants de silicium et
les intégrateurs de systèmes.
Analyse fonctionnelle du système
Proposer des architectures candidates pour

répondre aux besoins
Evaluer les performances de ces systèmes
Proposer des points d'amelioration
Figure 8. Flot simplifié d’une exploration d’architecture basée sur l’évaluation de performances
IV. Systèmes embarqués de commande
Les systèmes de contrôle/commande occupent une place de plus en plus grandissante dans
l’économie moderne, la majorité de ces systèmes sont actuellement des systèmes numériques. Ils sont
intégrés dans la majorité des équipements de consommation nécessitant un certain niveau
d’intelligence [2] ou des systèmes de production nécessitant un très haut niveau de qualité. Le
domaine de l’automobile a commencé à utiliser des systèmes électroniques à partir des années
soixante-dix pour substituer des composants mécaniques. Les tâches de contrôle moteur, la conduite
assistée et le système ABS1 sont des exemples flagrants de la place occupée par les systèmes de
commande dans le domaine de l’automobile. Plusieurs normes ont été proposées pour ce domaine
afin d’assurer une qualité des systèmes de contrôle et une interopérabilité entre les différents
1
Antilock Braking System
38
constructeurs. Les normes AUTOSAR et MISRA sont des exemples de succès des efforts de
normalisation dans ce domaine.
Le domaine de l’aéronautique pour sa part implique une quantité énorme de systèmes embarqués
de contrôle destiné à différentes tâches de contrôle ou de supervision [23]. La procédure de
conception, de codage et de test est normalisée pour la majorité de ces systèmes par les normes
reconnues par leurs domaines d’applications.
Depuis 1963, on a assisté à l’apparition des premiers robots industriels aux États-Unis, puis en
Europe et au Japon. Actuellement, la place des robots industriels dans les moyens de production
devient de plus en plus importante, vu la criticité de certaines tâches soit pour des contraintes de
précision soit pour des contraintes de sécurité. Cette évolution récente vers la presque totalité des
industries est la conséquence des progrès réalisés par les robots au niveau de leurs performances et
de leurs moyens de programmation avec des fonctions mieux adaptées aux applications et des
possibilités de calcul offrant de nouvelles perspectives en termes de fonctionnalités.
La place grandissante des systèmes embarqués dans l’automobile, les robots mobiles ou les
applications de contrôle de processus montre les nouvelles orientations du domaine des contrôleurs
embarqués dans l’industrie moderne [24]. Une grande partie de la valeur ajoutée de ces deux types
de systèmes est directement liée aux systèmes embarqués qui les commandent. Les systèmes
avionique, automobile, robotique peuvent être qualifiés de critique vu qu’en cas de défaillance des
vies humaines, des biens ou des ressources naturelles peuvent être mise en danger. La conception des
systèmes embarqués de commande doit à la fois prendre en considération les contraintes liées aux
systèmes embarqués classiques, mais aussi à l’aspect critique lié au domaine de fonctionnement de
ces systèmes.
La définition d’un système embarqué est étroitement liée à celle d’un SoC étant donné que ce
dernier désigne un système complet embarqué sur une puce pouvant comprendre des éléments de
diverses natures (logiciels et matériels) et nécessite donc des environnements de programmation
particuliers pour la spécification, la simulation, la vérification, la compilation et l’exécution [24]. Vu
son domaine d’application, un tel système est soumis à plusieurs contraintes qui sont :
 Les contraintes physiques : il doit présenter un faible encombrement et un faible poids.
 La dissipation de puissance : la dissipation est directement reliée à l’autonomie du système
embarqué.
39
Chapitre 1
 Le temps de développement : en plus des contraintes de temps de développement de

l’architecture système, il faut prendre en compte le temps de développement des fonctions
logicielles associées.
 Le coût : le système ne doit pas être cher tout en tenant compte de la performance.
 La sureté de fonctionnement : lors de la conception d’un tel système, on doit prendre en
compte le domaine d’application de ce système, car ce dernier peut mettre en danger des vies
humaines.
 Flexibilité : Les grands constructeurs de SoC tels que Texas Instruments ou
STMicroelectronics essaient alors de créer des SoC les plus flexibles que possible afin
d’amortir les frais de recherche et de développement et de toucher le maximum de clients
potentiels susceptible d’être intéressé par leurs produits.
Afin de satisfaire toutes les contraintes issues de cette définition, le concepteur est amené à
optimiser un ensemble de métriques afin de garantir la bonne intégration du système dans
l’environnement qu’il contrôle. Cette tâche est toujours considérée comme un défi permettant de
répondre aux besoins fonctionnels tout en respectant les contraintes subites par le système [25].
V. Plateformes matérielles pour

1. Influence du contrôleur utilisé sur le processus à

commander
L’utilisation d’un système embarqué pour le contrôle d’un processus physique peut introduire des
retards dans la boucle de retour. Ce problème est essentiellement lié à la latence du calcul ou à un
problème de partage de ressources entre plusieurs tâches causées par un problème d’ordonnancement.
L’exploitation des possibilités offertes par le domaine des systèmes temps-réel peut apporter des
solutions à ce problème en garantissant un certain degré de déterminisme. En effet, les domaines de
l’automobile, de l’avionique et des équipements industriels ont bénéficié de plusieurs avancées dans
ce sens. Actuellement, on a assisté à l’apparition de normes et standards permettant la standardisation
de l’architecture et du code du logiciel embarqué dans un contrôleur embarqué afin de garantir un
niveau minimum de garantie de bon fonctionnement et de réutilisabilité.
40
Par ailleurs, la partie matérielle a une grande influence sur la qualité du produit final. En effet, les
choix matériels ont un impact direct sur le coût, la consommation et le prix. D’autre part, ce choix
impose un certain niveau de qualité de fonctionnement. Ceci est essentiellement dû à plusieurs
avancées disponibles sur les plateformes modernes telles que la redondance, l’immunité aux erreurs
et la certification logicielle et matérielle liée à ces plateformes.
2. Notions de plateformes matérielles
Le choix adéquat d’une plateforme d’implémentation peut avoir un impact considérable sur les
performances atteintes par le produit final. Actuellement, on assiste à l’émergence de plusieurs
plateformes pouvant être considérées comme candidates à la réalisation d’une application de contrôle
donnée. Classiquement, les plateformes candidates étaient les Microcontrôleurs, les DSPs et les
circuits FPGA. De nos jours, la classification des plateformes matérielle devient de plus en plus
inappropriée vu que les plateformes actuelles offrent une convergence entre ces différentes
technologies. En effet, un grand nombre de circuits FPGA intègrent des microcontrôleurs, mais aussi
un grand nombre de microcontrôleurs intègrent un jeu d’instruction DSP. Par ailleurs, plusieurs
plateformes modernes telles qu’Hercule de TI intègre à la fois un DSP et un microcontrôleur afin de
répondre aux besoins de traitement de signal et aux applications de contrôle.
Les plateformes dsPIC et ARM cortex M4 intègrent un jeu d’instruction DSP sur un
microcontrôleur. Les plateformes DIOPSIS d’ATMEL et Davinci de TI offrent un chip multicœur
intégrant un DSP et un microcontrôleur. Les plateformes VIRTEX 6 de Xilinx et SmartFusion
d’ACTEL offrent des chips intégrant un cœur ARM hardcore utilisable au sein d’un chip FPGA.
D’autre part la firme ARM a récemment intégré dans sa gamme ARM Cortex M4 un jeu d’instruction
DSP. Ce cœur est de plus en plus adopté par les acteurs du marché du semi-conducteur. Les
plateformes à base de circuit FPGA ont le privilège de pouvoir intégrer ces différentes technologies
sur un même circuit avec de grandes possibilités de personnalisation [26].
3. Plateformes microcontrôleurs
Les circuits microcontrôleurs sont le résultat naturel de l’évolution du domaine de la micro-

informatique. En effet, l’architecture générale d’un microcontrôleur est identique à celle d’un
ordinateur classique intégré sur un même circuit. Cette caractéristique est essentiellement liée à la loi
de Moore qui a permis une réduction de la surface silicium des composants numériques. L’évolution
impressionnante des coûts, du nombre de fonctionnalités et de la consommation d’énergie a permis
41
Chapitre 1
aux microcontrôleurs de maintenir leurs places de plateformes de choix pour l’implémentation de

systèmes embarqués.
Par ailleurs, le large choix en termes de microcontrôleurs a rendu cette tâche relativement
fastidieuse. Ces microcontrôleurs sont excessivement utilisés dans les tâches de contrôle ainsi que la
majorité de nos biens électronique. Outre les classifications classiques telles que la largeur des bus,
le type RISC ou CISC, la quantité de mémoire disponible sur le circuit, les fonctionnalités offertes
par le microcontrôleur, il existe de nouveaux critères qui deviennent déterminants lors de l’adoption
d’un microcontrôleur telle que les modes de consommation d’énergie et les connectivités offertes.
D’autre part, l’écosystème logiciel, les possibilités d’évolution et la compatibilité avec des normes de
sureté sont devenus des critères primordiaux lors de l’adoption d’une architecture.
La majorité des acteurs du domaine des microcontrôleurs offrent des solutions d’aide au choix en
fonction des modules requis qui peut être une alternative intéressante aux approches basées sur
l’intégration d’IP matérielle à un processeur embarqué sur circuit FPGA.
4. Circuit FPGA
Un circuit FPGA est un circuit logique reprogrammable [1]. Il est composé de nombreuses
cellules logiques élémentaires librement utilisables. L’un des avantages de ce genre de circuit est son
aptitude à être utilisé dans de nombreux systèmes électroniques. La plupart des circuits FPGA sont
constitués de blocs SRAM1 aussi bien pour le routage du circuit que pour les blocs logiques. Ces blocs
sont connectés entre eux par une matrice de routage configurable qui fait que le même composant
peut être reconfiguré à volonté.
Cependant, le nombre élevé de ces blocs rend le routage manuel une tâche quasi impossible
notamment avec des systèmes logiques complexes intégrés dans les dernières générations de circuits
FPGA. C’est désormais la tâche de l’outil de placement-routage de faire correspondre le schéma
logique voulu par le concepteur aux ressources matérielles disponibles sur la puce.
Grossièrement, on peut classer les FPGA en deux topologies :
 Architecture de type îlots de calcul : Dès le départ, Xilinx a choisi ce type d’architecture. Cette
architecture FPGA est constituée d’une matrice plane d’éléments. Ces éléments constituent
les ressources logiques et de routages programmables du FPGA.
1
Static Random Access Memory
42
 Architecture de type hiérarchique : Dans cette architecture, il existe plusieurs plans dans le
FPGA. Mais, ces plans ne sont pas physiques, ils correspondent au niveau de hiérarchie
logique. C’est-à-dire qu’un élément d’un niveau logique peut contenir des éléments de niveau
logique inférieur, d’où la notion de hiérarchie. Chaque niveau logique reprend la topologie
d’une architecture du type îlots de calcul avec un routage dédié pour chaque niveau. Cette
architecture se trouve dans les FPGA d’Altera.
Les FPGA modernes disposent d’assez de ressources logiques et suffisamment de mémoire pour
héberger un ou plusieurs cœurs de processeur ou DSP afin d’exécuter un logiciel. Ces atouts ont fait
des plateformes FPGA une technologie clé pour les systèmes embarqués. Aujourd’hui, les fabricants
de FPGA intègrent un ou plusieurs cœurs de processeurs hardcore sur un même composant afin de
conserver les ressources logiques configurables du composant. Ceci n’exclut pas la possibilité
d’utilisation de processeurs softcore sur ces mêmes circuits afin de tirer profil des avantages de ces
derniers. Un système construit sur ce type de plateforme est dénommé SOC vu que la totalité du
système est intégrée dans le même composant. L’utilisation d’un circuit FPGA pour construire un
SoC peut être dans le but de commercialiser le produit final en utilisant le circuit FPGA utilisé, ou en
transposant le design sur des circuits spécifiques appelés ASIC en s’adressant à un fondeur qui
réalisera le circuit final [27].
Sorties
Listing
Phases de
développement
Conception Table de
Conception originale Vérité
Graphique
Netliste Synthétisée Simulation

Synthèse
Fichier de sortie
Placement et routage
Implementation Passe/Echoue
Figure 9. Phases de Simulation dans un processus de développement sur circuit FPGA
43
Chapitre 1
La conception d’un module IP1 matérielle pour une plateforme FPGA doit suivre les trois phases
qui sont la conception, la synthèse et l’implémentation illustrées par la Figure 9. Toutefois, il existe
plusieurs moyens d’effectuer ces phases. Les plus courantes sont l’adoption d’un langage HDL tel
que VHDL ou Verilog. Par ailleurs, il existe une nouvelle catégorie de langages permettant une
programmation visuelle du composant permettant la génération d’un fichier HDL ou la production
directe de netliste. Cette nouvelle génération de langages permet de maîtriser la complexité, d’offrir
un certain niveau d’abstraction et de garantir le niveau de qualité des IP conçus.
5. Les différents éléments d’un circuit FPGA
Les éléments constitutifs d’un FPGA sont toujours à peu près les mêmes, quelle que soit
l’architecture choisie [28]. L’architecture générale d’un circuit FPGA illustrée par la Figure 10 permet
de fournir à la fois des blocs logiques et d’interconnexions configurables. Toutefois, la quantité et les
performances de ces ressources imposent les performances finales du système utilisant ce circuit.
Interfaces E/S
E/S E/S E/S E/S E/S E/S
E/S E/S
Logique Logique
Combinatoire Combinatoire
Blocs de
E/S E/S
Construction Interconnection
élémentaires s
E/S E/S
Logique Logique
E/S Combinatoire Combinatoire E/S
E/S E/S E/S E/S E/S E/S
Figure 10. Architecture classique d’un circuit FPGA

Chaque fabricant ayant ses variantes par rapport à un autre. Nous pouvons citer un certain nombre
des éléments communs à la majorité des plateformes FPGA :
 Les éléments logiques : Ce sont les blocs de base de tout circuit FPGA. On peut réaliser dans
ces blocs toutes les opérations de logique combinatoire (dans la limite d’un nombre d’entrées).
1
Intellectual Property
44
Ces blocs ont souvent la même constitution et cela malgré la différence de fabricants et
d’architectures. Ces structures sont généralement constituées d’une ou plusieurs tables LUT1
qui contiennent, après configuration, la table de vérité de la fonction logique qu’elles doivent
réaliser ou alors un ensemble de valeurs qui sont mémorisées comme dans une mémoire ROM.
La taille des tables LUT est généralement de 16x1 (c’est-à-dire qu’elles disposent de 4
entrées). Les tables LUT sont suivies d’un registre de sortie, ce qui permet de synchroniser, si
nécessaire, la sortie sur une horloge. La plupart des blocs logiques de base sont munis d’une
chaîne de propagation rapide de retenue afin de former de petits additionneurs rapides.
 Les éléments de mémorisation : Actuellement, les FPGA sont utilisés pour des applications
plus importantes qui demandent souvent des capacités de stockage (par exemple les
applications du traitement vidéo). La nécessité d’intégrer des blocs de mémoire directement
dans l’architecture des FPGA est vite devenue capitale. De cette façon, les temps d’accès à la
mémoire sont diminués puisqu’il n’est plus nécessaire de communiquer avec des éléments
extérieurs au circuit.
 Les éléments de routage : Les éléments de routage sont les composants les plus importants
dans les FPGA. En fait, ces éléments représentent la plus grosse partie du silicium consommée
sur la puce du circuit. Ces ressources sont composées de segments (de longueurs différentes)
qui permettent de relier entre eux les autres éléments via des matrices de connexions. Le
routage de ces ressources est un point critique du développement d’une application sur un
FPGA. Ces éléments sont très importants puisqu’ils vont déterminer la vitesse et la densité
logique du système. Par exemple, les matrices de routage sont physiquement réalisées grâce
à des transistors de cellules SRAM, qui ont une résistance et une capacité, ce qui entraîne
l’existence de constantes de temps.
 Les éléments d’entrées/sorties : Le but des éléments d’entrées/sorties est de relier un circuit
avec son environnement extérieur. Ceux-ci peuvent bénéficier de protections, de buffer ou
d’autres éléments permettant la gestion des entrées et des sorties. En particulier il est à noter
que les circuits actuels proposent différentes normes pour les niveaux d’entrées et de sorties
qui par configuration peuvent être choisies afin de s’adapter à l’environnement.
 Les éléments de contrôle et d’acheminement des horloges : L’horloge est un élément essentiel
pour le bon fonctionnement d’un système électronique. Les circuits FPGA sont prévus pour
recevoir une ou plusieurs horloges. Des entrées peuvent être spécialement réservées à ce type
de signaux, ainsi que des ressources de routage spécialement adaptées au transport d’horloges
1
Look Up Table
45
Chapitre 1
sur de longues distances. Les circuits FPGA disposent des éléments d’asservissement des
horloges (des PLL1 ou des DLL2) afin d’avoir la même horloge dans tout le circuit
(synchronisation des signaux). Ces éléments permettent de créer à partir d’une horloge
d’autres horloges à des fréquences multiples de la fréquence de l’horloge incidente.
Par ailleurs, il existe une très grande disparité au niveau des technologies de programmation, des
flots de conception et d’environnement de conception. Certaines FPGA comme la VIRTEX 5 offrants
une grande richesse logicielle constitue des alternatives offrant un très haut niveau d’innovations.
6. System On Chip (SoC)
Un SoC est un système qui peut contenir de la mémoire de données et d’instructions, un ou

plusieurs processeurs (MPSoC), des périphériques d’interface et tout autre composant nécessaire à la
réalisation de la fonction attendue. Actuellement, on assiste à l’émergence des SoC à base de circuits
FPGA, ceci est dû essentiellement à l’amélioration du rapport performance coût de reviens des FPGA,
qui deviennent plus abordables par rapport aux ASIC. Le temps de mise sur le marché est devenu un
autre facteur déterminant lié à l’adoption de cette nouvelle génération.
La Figure 11 montre l’architecture générique d’un SoC moderne. Actuellement, de nombreux SoC
sont disponibles sur le marché qu’ils soient à base de circuits FPGA ou ASIC. Ces SoC sont
commercialisés à des prix très compétitifs vu leurs productions en masse, il serait donc très judicieux
pour une firme voulant construire une application quiconque de faire une étude préalable du marché
des SoC afin de voir s’il a une offre qui correspond à son besoin [29]. Afin d’améliorer le temps
d’exécution d’une application, un meilleur moyen est d’utiliser des architectures à plusieurs
processeurs, on parle alors d’un MPSOC [30]. Les programmes ainsi écrits pourront s’exécuter en
parallèle. Il existe plusieurs facteurs pour lesquels le besoin d’implémenter une architecture
multiprocesseur se fait sentir. Dans la plupart de ces cas, c’est tout simplement la performance, dans
d’autres ce choix est essentiellement lié aux contraintes de consommation tandis que pour d’autres
cas ces essentiellement un moyen supplémentaire permettant de faciliter la gestion du projet.
La topologie multiprocesseur massivement parallèle est principalement utilisée dans deux buts :
 Pour les systèmes temps-réel : Certains algorithmes nécessitent une telle puissance de
calcul pour être exécutés en temps-réel que seule une architecture parallèle peut fournir.
Cette utilisation est cependant limitée par la rapide évolution du matériel informatique, et
1
Phase-Locked Loop
2
Delay Lock Loop
46
le temps de conception de la machine parallèle. En effet, la puissance de calcul de la

machine parallèle peut être dépassée par les machines monoprocesseurs de dernière
génération avant la fin de sa conception.
 Pour les algorithmes particulièrement coûteux en temps de calcul, comme certaines
simulations de processus physiques ou pour des opérations de cryptographie.
SRAM
µP
ARM, PowerPC, DSP Contrôleur
LEON …
S
S2
Réseau : Bus, Crossbar, NOC
S
FPGA IP2
IP1
E/S
Figure 11. Structure fonctionnelle d’un SoC
Partie Logicielle T0 T1 T2 ………………………………… Tn

Logiciel Applicatif ………………
Interface Logicielle/matérielle
DSP CPU1 CPU2 ………... CPUn HW MEM

Partie matérielle IP
Architecture cible
Réseau de communication
Figure 12. Topologie des architectures multiprocesseurs hétérogènes
47
Chapitre 1
À l’époque des premières conceptions de ces machines parallèles, le nombre de transistors par
puce était beaucoup trop faible pour mettre plusieurs processeurs sur une même puce. Depuis, ce
nombre a été multiplié par dix tous les cinq ans. Ce qui a permis l’apparition de plusieurs technologies
d’architecture multiprocesseurs qui a induit une complexité respectable des circuits. Cette complexité
a causé des difficultés supplémentaires dans la conception de logiciels embarqués qui limite
l’exploitation des ressources offertes par la puce.
L’utilisation d’une architecture multiprocesseur utilisant une couche d’interfaçage logicielle

permettant la gestion de l’affectation des tâches. En effet une architecture similaire à celle illustrée
par la Figure 12 pourrait permettre de réduire ces problèmes, mais aussi de garantir un certain niveau
d’indépendance des fabricants de silicium.
7. IPs Matérielles
Introduction
À partir d’un certain niveau de complexité de tout système électronique, l’adoption d’une
approche à base d’intégration d’IP matériels est indispensable [31]. Un IP peut être présenté comme
la description matérielle d’un composant électronique pouvant être intégré à un produit final pour
répondre à un besoin spécifique. Un IP matériel peut être un contrôleur USB, une interface série, un
processeur ou tout autre composant numérique. Le choix d’un IP convenable pour une application
bien déterminée peut contribuer à l’amélioration de la qualité ainsi que le coût du produit final. Lors
de l’acquisition ou de la conception d’un IP on doit prendre en considération la portabilité et la
réutilisabilité de ce dernier.
Différentes familles d’IP
Un IP matériel est un composant virtuel qui peut apparaître sous différentes formes.
 IP logiciel softcore : le composant est livré sous la forme d’un code HDL1 synthétisable, c’est-
à-dire flexible. Son principal avantage est sa portabilité. Le code source de l’IP est en soi la
meilleure documentation. On peut ainsi maintenir le produit pendant des années et
éventuellement modifier la source et même changer de technologie cible. L’inconvénient
majeur est qu’il ne peut être prédictif en termes de superficie, puissance et temps. Le travail
d’optimisation du circuit final est à la charge de l’intégrateur du système.
1
Hardware Description Language
48
 IP matériel hardcore : Dans ce cas, le bloc IP est ciblé sur une technologie particulière et le
travail d’optimisation est garanti. Cela englobe la netliste entière, le routage et l’optimisation
pour une librairie technologique spécifique, un layout personnalisé. L’inconvénient est qu’il
est moins flexible, car le processus est dépendant de la technologie. Par contre il a l’avantage
d’être prédictif.
 IP Firm ou firmcore : Un bloc IP firmcore est en général fourni sous forme de netliste
configurable, il offre un compromis entre le softcore et le hardcore. Il est plus flexible que le
hardcore, plus prédictif en termes de performance et de surface que le softcore. En général, le
travail de synthèse HDL est déjà réalisé pour une technologie cible donnant lieu à une
description par netliste (format EDIF1 par exemple). Les firmcore sont en général fournis par
des revendeurs d’IP, car cette solution leur permet de préserver leurs savoir-faire.
Lors de l’acquisition d’IP matériels de sources tierces, les critères suivants doivent être pris en
considération :
 La compatibilité de l’IP avec les outils utilisés et la plateforme cible

 Le degré de maturité de l’IP
 Le coût de l’IP
 Les aspects légaux (essentiellement lié à la licence de l’IP)
 La réputation et l’expérience du vendeur d’IP
La notion de bibliothèque d’IP peut être primordiale notamment dans le cas de besoins de
communication avec le monde extérieur qui est une problématique courante dans le domaine des
applications de contrôle dans lequel le nombre d’interfaces est élevé. Ces interfaces doivent
communiquer avec le calculateur central à travers des IP, dans ce sens la plateforme FPGA s’avère
un choix très intéressant vu la possibilité de choisir les IP adéquats en fonction de l’application visée
[32]. L’adoption d’une architecture multiprocesseur peut être envisageable pour des raisons de
maîtrise de complexité, de performance et d’économie d’énergie. Par ailleurs, le fait que la majorité
des outils de CAO intègrent des bibliothèques préconfigurées d’IPs matérielles rend leurs utilisations
systématiques et naturelles lors de l’adoption d’une conception à base de circuits FPGA.
1
Electronic Design Interoperability Format
49
Chapitre 1
VI. Plateformes logicielles pour

systèmes embarqués de contrôle
commande
1. Introduction
L’utilisation d’un environnement d’exécution ou système d’exploitation dans les systèmes

embarqués devient de plus en plus indispensable [33]. Ceci est essentiellement dû à la diversité des
plateformes matérielles disponibles. L’adoption d’un système d’exploitation permet d’assurer une
certaine portabilité des applications ce qui procure au concepteur du système une indépendance
considérable par rapport aux plateformes matérielles ciblées. Par ailleurs, même si ces
environnements peuvent engendrer une certaine dégradation des performances globales qui était
autrefois intolérables dans des systèmes embarqués à cause de leurs puissances de calculs très
limitées, l’adoption d’un système d’exploitation est devenue indispensable dans les systèmes
embarqués actuels vu le fait que ces derniers offrent des facilités très intéressantes au niveau gestion
de plateformes matérielles, la réutilisation de composants logiciels et la gestion de la programmation
multitâche [34].
L’évolution de la complexité des systèmes informatiques embarqués a nécessité en premier lieu

l’adoption de la notion de driver pour pouvoir offrir un certain niveau d’abstraction suivie par la
notion de système d’exploitation temps-réel pour simplifier aussi bien le modèle de programmation
et offrir des interfaces standardisées. Actuellement, on assiste à l’émergence de plusieurs paradigmes
liés à l’adoption d’architectures multicœurs multisystèmes d’exploitation [35] [36]. Dans un flot de
conception moderne l’adoption d’une architecture multicœurs multisystèmes d’exploitation peut
faciliter l’adoption d’une méthodologie orientée vers le test telle que la méthodologie TDD1 [37] vu
que les différents modules logiciels peuvent être développés de façon indépendante et exécutée par
la suite sur des processeurs séparés. Les phases de tests peuvent désormais commencer dès les
premières phases de développement logiciel vu qu’il n’y a plus d’interdépendance entre les différents
modules logiciels.
1
Test Driven Development
50
2. Notion de firmware ou logiciel embarqué
Seul, le bon choix de la plateforme matérielle ne peut pas garantir les performances escomptées
d’un système embarqué. En effet, la couche logicielle communément appelée firmware est la
deuxième facette de tout système embarqué dont le coût et l’importance surpassent de loin le côté
matériel [38]. Cette couche logicielle naturellement conçue après la réalisation du matériel est d’une
importance capitale pour le bon déroulement des projets et pour la pérennité du produit. Plusieurs
solutions récentes proposent de développer le logiciel embarqué en même temps que le
développement matériel. D’autre part, cette couche permet de fournir les derniers ajustements de la
conception matérielle, vu qu’elle permet de fournir les derniers correctifs aux bogues matériels.
Firmware
Applications Additionnelle du Firmware
Application Application Application

A B … n
Espace Application
Espace Client
Driver A Driver B … Driver n
Block A Block B … Block n
Chip
Figure 13. Architecture de base d’un Firmware

Cette couche logicielle illustrée par la Figure 13, communément appelée firmware ou logiciel
embarqué est systématiquement logée dans une mémoire non volatile. Elle est responsable de toutes
les communications qui s’effectuent avec le matériel du système embarqué à travers les pilotes de
périphérique qui sont le composant indispensable de tout firmware. Cette intime liaison entre cette
couche logicielle et le matériel a amené plusieurs éditeurs à l’appeler « Hardware Dependant
Software » ou « Logiciel dépendant du matériel ». D’autre composant, tel que le système
d’exploitation ou système d’exploitation temps-réel sont couramment présent dans les firmwares,
51
Chapitre 1
mais ne sont pas indispensable vu que les systèmes embarqués d’entrée de gamme peuvent s’en passer
de leurs services pour des raisons de coûts ou de performances.
3. Système d’exploitation et système d’exploitation

temps-réel
Les systèmes d’exploitation ont été introduits afin de faciliter la communication entre les
programmes applicatifs et le matériel sous-jacent. Ils sont directement responsables de la gestion des
processus, la communication et la synchronisation interprocessus, la gestion de la mémoire et des
entrées/sorties. Un système d’exploitation temps-réel couramment appelé RTOS1 est un système
d’exploitation qui met en œuvre des règles et des politiques relatives à l’exactitude temporelle. En
effet, l’exactitude temporelle est une des spécifications fonctionnelles des systèmes de contrôle. Les
systèmes de contrôle temps-réel sont classés comme des systèmes temps-réel dur, ferme ou mou en
fonction de l’influence du non-respect d’une échéance sur l’ensemble du système. Actuellement, une
quantité impressionnante de systèmes d’exploitation embarqués est disponible sous diverses licences.
Ces systèmes représentent l’aboutissement de travaux universitaires ou industriels permettent de
fournir diverses fonctionnalités aux systèmes embarqués tels que des interfaces graphiques, des piles
protocolaires ou des fonctionnalités de gestion de systèmes de fichier. Le large choix en termes de
systèmes d’exploitation embarqués peut être une source de confusion pour un grand nombre de
concepteurs. En effet, plusieurs de ces systèmes ont été conçus comme une simple preuve de concept
et son adoption ne doit pas dépasser le domaine de recherche.
4. Pilote de périphériques
Les pilotes de périphériques sont des programmes spécifiques qui contiennent des codes
dépendants d’un type ou d’une catégorie d’interfaces. Ce genre de logiciel détient une importance
capitale dans le domaine des systèmes embarqués, car il offre des interfaces fiables entre le système
d’exploitation et le matériel spécifique utilisé dans le système [40]. La Figure 14 illustre les
différentes architectures utilisées lors du développement des pilotes de périphériques embarqués. Ce
composant logiciel est considéré comme le type de logiciel le plus coûteux nécessitant une grande
expertise en développement détenu dans la majorité des cas par le fabricant du matérielle. Toutefois,
1
Real-Time Operating System
52
l’intégration de ces pilotes à un système d’exploitation embarqué peut devenir un vrai challenge
notamment lors de l’adoption de plateforme matérielle non supportée par le fabricant lui-même.
Couche logiciel Couche logiciel Couche logiciel

applicatif applicatif applicatif
Couche logiciel Couche logiciel Couche logiciel

système système système
Couche Couche système
Middleware d’exploitation
Couche Pilote de
périphérique Couche Pilote de Couche Pilote de
périphérique périphérique
Couche Matérielle Couche Matérielle Couche Matérielle
Figure 14. Différentes vues des pilotes de périphériques dans les systèmes embarqués
Actuellement, la standardisation des systèmes d’exploitation embarquée a permis une meilleure

gestion des coûts de ce composant vue que la majorité des fabricants essaient d’intégrer leurs pilotes
dans les versions officielles des systèmes d’exploitation standards, ce qui leur permet d’être supportés
par tous les dérivés de ces systèmes. À titre d’exemple si un pilote de périphérique est intégré au
noyau Linux standard il sera systématiquement supporté par tous ces dérivés tels que Android, Ubuntu
ou Ångström.
5. Couches d’abstraction
La complexité croissante des systèmes sur puces intégrant des processeurs homogènes ou
hétérogènes, utilisant une large gamme d’IP matériel a introduit une complexité effrayante lors du
développement de n’importe quel composant logiciel. Plusieurs incitatives de la part de chercheurs
ou d’industriels ont introduit les concepts de couche d’abstraction matérielle communément connue
sous le nom « Hardware Abstraction Layer » ou HAL [41]. Ce composant matériel permet de faire
une séparation claire entre le logiciel dépendant du matériel et le logiciel indépendant du matériel. Ce
concept a permis de révolutionner plusieurs aspects du domaine du software embarqué comme la
facilité du portage de logiciel et le développement parallèle de fonctionnalités dépendantes du
matériel et d’autres indépendants du matériel. L’un des premiers systèmes d’exploitation qui a récolté
53
Chapitre 1
les fruits de cette idée est le système eCos1 qui a envahi un grand nombre de périphériques et qui reste
la référence en termes de portabilité. Comme illustrée par la Figure 15, cette couche permet d’assurer
un niveau d’abstraction entre le matériel et le noyau du système d’exploitation.
Applications
Noyau
Couche d'abstraction matérielle (HAL)
CPU Memory MMU Timer Port/Devices
Figure 15. Concept de Hardware Abstraction Layer

Le succès de ce concept d’abstraction a incité plusieurs acteurs industriels à proposer des couches
d’abstraction du système d’exploitation communément appelée « Operating System Abstraction
Layer » ou OSAL [42] afin d’avoir un haut niveau d’indépendance vis-à-vis du fournisseur de
systèmes d’exploitations de pile protocolaire ou de pilotes matériels. Ce concept a rencontré un succès
immédiat qui a incité plusieurs organismes de normalisation à proposer des standards d’OSAL tels
que le standard POSIX21.b, ITRON3 ou OSEK/VDX4 qui essaient de proposer des interfaces
logicielles unifiées permettant d’interagir avec le matériel. La Figure 16 illustre ce concept qui permet
aux développeurs d’application un très haut niveau d’abstraction du système d’exploitation cible.
Application
Couche d'abstraction du système d'exploitation
Système d'exploitation temps réel
Couche matérielle
Figure 16. Concept de » Operating System Abstraction Layer »
1
Embedded Configurable Operating System
2
Portable Operating System Interface for Unix
3
Industrial The Real-time Operation Nucleus
4
Open Systems and the Corresponding Interfaces for Automotive Electronics
54
Applications
Messagerie
Accueil Numérotation SMS/MMS Navigateur Caméra Alarme Calculateur
Instantanée
Numérotation Lecteur
Contacts Email Calendrier Album Photo Horloge …
Vocale Multimédia
Framework Applicatif
Gestionnaire Gestionnaire de Gestionnaire de Gestionnaire de
Vue du système
d’activités fenêtres contenue notifications
Gestionnaire de Gestionnaire de Gestionnaire de Gestionnaire de
…
Package téléphonie ressources Positionnement
Librairies Runtime Android

Gesionnaire de Framework
SQLite Webkit Libc Librairies de Base
Surfaces Media
Gestionnaire
OpenGLES FreeType SSL … Machine virtuelle Dalvik
Audio
Couche d’abstraction matérielle

Graphique Audio Caméra GPS Radio …
WiFi
Noyau Linux
Pilote de mémoire Pilote de communication
Pilote d’affichage Pilote de Caméra Pilote Bluetooth interprocessus IPC
partagée
Gestionnaire
Pilote USB Pilote de Clavier Pilote WiFi Pilotes Audio
d’énergie
Figure 17. Architecture interne du système Android
D’autre part, l’utilisation d’OSAL permet d’améliorer la qualité du logiciel embarqué. En effet, le
fait d’avoir des interfaces unifiées et une architecture standardisée permettent de faciliter la
conception, mieux documenter le logiciel, commencer les tests dans les premières phases du cycle de
développement ainsi qu’une meilleure gestion du projet. Par ailleurs, ce genre d’architecture permet
d’améliorer la vitesse de production du logiciel embarqué vu que plusieurs phases du projet peuvent
être parallélisées. Par ailleurs, l’utilisation d’OSAL permet de commencer les tests logiciels sur les
plateformes de développements. Ceci permet d’améliorer la qualité et la vitesse de production du
logiciel embarqué. Ces concepts ont facilité les différentes étapes de développement de logiciel
embarqué ce qui a incité les concepteurs du système d’exploitation Android à inclure des
implémentations de couches d’abstraction dans l’architecture interne du système qui a connu un
succès sans précédent [43]. La Figure 17 illustre l’architecture interne du système Android qui a
permis à ce système d’être facilement porté sur un grand nombre de plateformes matérielles et de
devenir le système d’exploitation mobile de référence. Enfin, même si cette montée en abstraction
55
Chapitre 1
génère un autre surcoût en termes de puissance de calcul, les plateformes actuelles sont conçues pour
gérer de façon optimisée ce genre d’architecture logicielle.
VII. Conclusion
Les enjeux impliqués dans le choix et la conception d’un système embarqué utilisé dans une
application de supervision/contrôle sont multidimensionnels. En effet, un vaste choix de solutions
technologiques est disponible pouvant réaliser les fonctions escomptées. Ces technologies peuvent
être équivalentes sur le plan fonctionnel, mais extrêmement différentes sur le plan économique ou
stratégique. Une vision méthodologique prenant en considération les différents aspects économiques
et techniques est nécessaire lors du choix de ces solutions. Le fait que ce domaine connaît une
ébullition sans précédents au niveau innovation et pénétrations de marchés nécessite l’intervention
d’expert en ingénierie système, en markéting et en développement. La concurrence serrée dans ce
marché fait qu’un mauvais choix de plateforme peut mener à l’échec total du produit. Par ailleurs,
une méthodologie basée sur des pratiques claires et approuvées permet de rendre cette tâche
systématique garantissant le succès technologique, économique et la pérennité du produit.
Le large choix de plateformes matérielles est l’un des premiers faits à prendre en considération.
En effet, le choix d’une plateforme spécifique a un impact direct sur le déroulement du projet ainsi
qu’aux aspects commerciaux liés au produit final.
D’autre part, le niveau d’innovation introduit par les composants matériels et logiciels peut avoir
des aspects dangereux liés à leurs adoptions dans des infrastructures critiques. Ceci est
essentiellement dû au fait qu’il est difficile de modifier ces équipements dans une infrastructure en
cours de fonctionnement. Ce qui a incité les acteurs industriels de ce domaine à opter pour des
solutions approuvées permettant de garantir le niveau maximal de maturité. Ceci est assuré à travers
plusieurs pratiques les que le fait d’imposer des architectures logicielles standardiser, des phases de
tests automatises, l’adoption de règles de codage standardisée ou carrément à travers l’adoption
d’outils permettant de gérer tout le cycle de vie en partant par l’étude des besoins et la conception
logicielle pour arriver à la génération de code et l’automatisation des tests. La grande part
d’innovation est laissée aux parties non critiques du système dont une dégradation occasionnelle de
qualité peut être tolérée.
Enfin, un grand nombre de modèles architectural et d’approche de développement peuvent être

adoptés lors du développement du logiciel embarqué. Chacune de ces approches permet d’offrir des
56
avantages donnés tels que le gain de performance, de portabilité ou de temps de développement. La

tendance actuelle essaie de garantir le maximum d’abstraction du matériel. Ceci s’est concrétisé par
l’apparition de plusieurs solutions propriétaires ou commerciales permettant d’offrir cette abstraction
qui permet à chaque niveau du système final d’être indépendant des couches sous-jacentes. Cette
pratique constitue une garantie économique et technologique vu que les différents composants
logiciels d’un système embarqué peuvent être développés et testés auprès de différents acteurs.
57
CHAPITRE2 :
CONCEPTION A BASE DE MODELES POUR
L’ASSURANCE QUALITE DE SYSTEMES
EMBARQUES DE CONTROLE/COMMANDE
« Il est bien des choses qui ne paraissent impossibles que tant qu’on ne les a pas tentés. »
de André Gide
Extrait du Si le grain ne meurt
58
Conception à base de modèles pour l’assurance qualité de systèmes embarqués de Contrôle/Commande
I. Introduction
Le domaine des systèmes embarqués est actuellement plus que jamais confronté à des
problématiques d’ordre méthodologique. Ces systèmes, grâce à l’augmentation des besoins
nécessitent une complexité matérielle et logicielle de plus en plus accrue. Cette complexité rend
l’adoption de méthodologies classiques non adaptées aux problématiques actuelles. D’autre part ces
mêmes systèmes sont confrontés à une concurrence considérable, ce qui peut pousser les industriels
du domaine à chercher plusieurs moyens de minimisation des coûts tout en garantissant un certain
niveau de la qualité de leurs produits. Actuellement, plusieurs méthodologies et outils sont proposés
aussi bien par les industriels que par les chercheurs permettant de maîtriser la complexité, garantir la
qualité et compresser les coûts [44]. D’autre part, des consortiums ou organismes gouvernementaux
sont mis en place pour proposer des standards permettant de réguler ce domaine. Ce genre de système
étant extrêmement complexe, ce qui fait que la règle « diviser pour régner » n’est plus applicable à
ce genre de système. Il faut désormais « grouper pour régner ». En effet, l’approche à base de modèle
permet de voir le système à différents niveaux d’abstraction [45] permettant de contrôler les points
d’une défaillance potentielle [46].
Dans ce chapitre, on va tout d’abord présenter les différents besoins en termes de garantie de
qualité imposée aux systèmes embarqués modernes notamment ceux impliqués dans des applications
critiques. En second lieu on va présenter les différents problèmes liés à la complexité dans divers
domaines de l’industrie, étudier l’avantage de l’approche HIL1 pour ce genre de système et enfin
comparer les différentes approches d’ingénierie à base de modèles ou d’ESL2 pour le développement
d’un module HIL utilisable pour la validation d’algorithmes de commande d’une machine à courant
continu. Cette étude permettra d’aborder ces nouvelles approches de conception aussi bien au niveau
qualitatif que quantitative. Le choix du modèle d’une machine à courant continu a été fait de façon
arbitraire afin d’avoir un socle d’étude commun à appliquer en utilisant les diverses solutions
exploitées. En effet, ce chapitre présente deux contributions directes. La première, est l’étude des
contraintes méthodologiques imposées aux systèmes embarqués critiques imposants divers approches
de conception en vue de garantir leur niveau de qualité. La deuxième contribution est essentiellement
liée à l’exploration qualitative et quantitative des outils de conception haute niveau exploitable dans
le contexte de conception de systèmes embarqués critiques.
1
Hardware In Loop
2
Electronic System Level
59
Chapitre 2
II. Enjeu et solutions apportées par

l’ingénierie à base de modèles
1. Maîtrise de la complexité
L’augmentation de la complexité matérielle et logicielle des systèmes embarqués modernes peut

amener quelques constructeurs à investir de plus en plus de développeurs sur ces produits afin de
répondre à leurs besoins. Plusieurs études [47] ont démontré que l’augmentation du nombre de
développeurs par projet diminuait la productivité de ces derniers et par conséquent augmenter le coût
de ces projets. La solution proposée à ce problème est de diviser le projet en plusieurs sous-projets
indépendants traités par des équipes indépendantes afin de minimiser les flots de communication
inutiles circulant entre divers membres d’une même équipe.
Actuellement, plusieurs solutions peuvent être adoptées afin de maitriser la complexité d’un
système embarqué, certains industriels ont adopté l’ingénierie à base de modèle en tant que solution
à cette problématique. D’autres ont opté pour l’ingénierie à base de composants tandis que certains
ont pensé à répartir leurs systèmes sur plusieurs processeurs afin d’isoler les composants logiciels
fonctionnant sur chaque processeur et d’adopter le processeur le plus adapté à chaque tâche [48] dans
le but de garantir un niveau de performance, mais aussi de faciliter la tâche de gestion des projets
logiciels.
Par ailleurs, dans un contexte de systèmes embarqués, l’adoption d’une architecture

multiprocesseur peut apporter plusieurs avantages aux systèmes conçus. Elle permet de diminuer la
consommation totale du circuit, permet de mieux gérer le projet durant les phases de développement,
faciliter les différentes phases de test et de validation ainsi que le fait de contrôler les coûts du produit
vu que plusieurs composants validés et approuvés peuvent être utilisés [49].
D’autre part, plusieurs domaines industriels utilisant des systèmes embarqués ont opté pour des
standards afin d’assurer un processus de qualité et de remédier aux problématiques liées à la
complexité de leurs systèmes. Actuellement, plusieurs standards sont adoptés tels que AUTOSAR [50]
pour le domaine automobile et la série des standards de la RTCA1 [51] pour le domaine avionique.
D’autres normes de codage existent afin d’assurer une qualité de code dans un domaine spécifique,
la plus répondue est MISRA [52] pour le logiciel embarqué dans les automobiles.
1
Radio Technical Commission for Aeronautics
60
2. Minimisation des coûts
Comme tout domaine de l’industrie moderne, la part de marché d’un industriel dépend
essentiellement du rapport qualité-prix de ces produits. Le coût du contrôleur embarqué peut avoir un
grand impact sur le coût du produit final. D’autre part, la maîtrise des coûts doit passer par la maitrise
du temps de développement et les ressources matérielles et logicielles investies dans le produit final.
En effet, la maitrise du temps de développement est directement liée à la gestion de la complexité.

Plusieurs pratiques de gestion de projet sont basées sur ce fait afin d’assurer le contrôle des différents
aspects du produit. L’adoption de composant matériel physique ou sous forme de propriété
intellectuelle doit se faire en prenant en considération les besoins fonctionnels du système, mais aussi
les possibilités d’évolution de ce dernier. L’existence de plusieurs propriétés intellectuelles sous
licence libre permet de compresser le coût des réalisations matérielles, mais parfois le manque de
fiabilité peut causer des dégâts colossaux pouvant compromettre l’image de la marque et ça part de
marché. Une vue globale sur le marché silicium est devenue indispensable du fait que la concurrence
serrée entre les fabricants incite à l’apparition de large gamme de composants pouvant répondre à nos
besoins à des prix très compétitifs.
Pour sa part, les choix logiciels doivent être guidés par des métriques adoptées afin de pouvoir
faire le bon choix vu la diversité actuelle des briques logicielles qui amène le développeur de nos
jours d’être considéré comme un intégrateur de systèmes [53]. L’adoption de briques logicielles issue
du monde du libre doit être abordée du point de vue qualité, la licence adoptée par ces développeurs
qui peut être contraignante lors de la commercialisation du produit. D’autre part, l’existence de
logiciel libre de très haute qualité est un fait irréfutable qui permet à la fois de compresser les coûts
et de garantir la qualité [54]. Le système d’exploitation Android est la preuve la plus concrète de cette
qualité et supériorité technologique [55].
En revanche, la récupération ou la réutilisation d’infrastructure matérielle disponible peut

contribuer à minimiser le coût d’un produit déterminé. En effet, nous pouvons citer à titre d’exemple
que l’adoption d’interface réseau classique pour le monitoring d’un processus industriel permet de
diminuer de façon considérable les coûts de câblage lié à ce genre de réseau. Dans le cas d’utilisation
d’un réseau local industriel, l’adoption d’une solution basée sur la nouvelle norme Ethernet Powerlink
en substitution à d’autres réseaux tels que CAN1 ou Profibus peut minimiser de façon considérable
les coûts de la réalisation [56] vu que Powerlink peut utiliser une infrastructure Ethernet classique.
1
Control Area Network
61
Chapitre 2
3. Les processus de développement à base de modèle
Dans la majorité des domaines d’ingénierie, les modèles peuvent contribuer à contrôler la
complexité des systèmes étudiés. Cette notion de modèle a été introduite dans le domaine de
l’informatique afin que l’implémentation puisse se faire en liaison avec la spécification [57].
L’ingénierie logicielle utilise de plus en plus l’ingénierie à base de modèles dans divers domaines
d’application. D’autre part, l’ingénierie à base de modèle est relativement nouvelle pour le domaine
des systèmes embarqués [58]. Actuellement aucun standard concernant l’adoption d’ingénierie à base
de modèle pour ce genre de systèmes n’est disponible. Par ailleurs, un grand nombre de solutions
industrielles est disponible et exploités dans diverses applications d’envergure industrielle.
Les avancées actuelles dans le développement de systèmes embarqués ont fait que la
méthodologie Model Based Design devient un fait dans ce domaine de l’industrie. La diminution des
coûts des MIPS1 et des mémoires ont pour leurs parts contribués à l’explosion du nombre de systèmes
embarqués par personne. D’autre part, la demande croissante de fonctionnalités a contribué
l’apparition de systèmes de plus en plus complexes [59]. Ces deux facteurs ont fait que les systèmes
embarqués actuels sont amenés à prendre en considération les critères de fiabilité, de robustesse et de
tolérance aux pannes. Cela est essentiellement dû au fait que la défaillance d’un tel système peut
amener à des catastrophes au niveau financier ou humain. L’ingénierie à base de modèles peut être
considérée comme la solution miracle à tous ces problèmes.
Malgré l’absence de standards, plusieurs outils ont été proposés afin de pouvoir appliquer
l’approche MBD dans la conception de systèmes embarqués. Ces outils sont essentiellement proposés
par des acteurs ayant une expertise dans la simulation et le prototypage de ce genre de systèmes tels
que National Instruments et Mathworks [60], des acteurs du domaine de la CAO tel que Mentor
Graphics ou des acteurs du semi-conducteur tel que Xilinx [61] et Altera. La notion de modèle permet
de donner une représentation abstraite du système indépendamment des aspects liés à
l’implémentation. Actuellement, les modèles basés sur UML sont les plus adoptés dans les systèmes
purement logiciels. Ils sont pour la plupart destinés à une utilisation générique. Par ailleurs, plusieurs
extensions permettent d’utiliser UML ou un de ses dérivés dans la conception des systèmes embarqués
[62]. Cependant, la non-standardisation du domaine a permis l’apparition d’outils telle que VisSiM et
de normes de codage telles que ceux basés sur le langage Processing ont tendance à être considérés
comme des standards industriels.
1
Million Instructions Per Second
62
III. Certification des systèmes critiques

de contrôle commande
1. Systèmes critiques et défis industriels
Les systèmes embarqués de contrôle peuvent être considérés comme la catégorie la plus complexe
des systèmes embarqués. Leur complexité est essentiellement due à l’implication de différentes
disciplines dans leur processus de conception. Ce fait est dû à l’utilisation du contrôleur intégré dans
les dispositifs mécatroniques qui comprennent des éléments mécaniques, électriques ou
informatiques [63]. La conception de ce type systèmes peut révéler plusieurs défis liés au
développement et aux tests. La moindre défaillance au niveau du flot de conception peut avoir des
effets néfastes sur les utilisateurs et peut compromettre la part de marché et même l’existence de la
compagnie qui développe ces produits.
La complexité croissante et spectaculaire du matériel et du logiciel impliqués dans des systèmes

embarqués de contrôle moderne peut inciter les sociétés développant ce genre de produit à investir
un nombre élevé de développeurs afin d’implémenter les différentes fonctionnalités du système.
Plusieurs études [47] ont montré que l’augmentation du nombre de développeurs peut diminuer leur
productivité, ce qui peut avoir un impact négatif sur le coût de l’ensemble du projet. La complexité
de ces systèmes doit être maîtrisée en utilisant une méthodologie appropriée au domaine d’application
du système conçu. De nombreux travaux de recherche et de normes industrielles [64] ont proposé
plusieurs méthodologies, bonnes pratiques et outils qui peuvent être adoptés pour améliorer le
processus de développement et la qualité du produit.
Ces systèmes embarqués de contrôle peuvent être considérés comme critique en raison de leur
utilisation dans des environnements hostiles avec des contraintes thermiques des rayonnements et des
processus chimiques. En effet, la défaillance d’un tel système présent dans la majorité de ces
équipements peut gravement affecter les utilisateurs finaux. Ce défaut peut présenter des risques
éventuels pour la sécurité des utilisateurs et de l’environnement. Les premières intégrations d’un
contrôleur utilisé dans des systèmes critiques ont été associées à de nombreuses catastrophes
reconnues comme l’explosion du missile Ariane, le bug latent du missile Patriot et Mars Pathfinder
[65]. En fait, ces erreurs ne peuvent pas être acceptables et une assurance qualité doit être garantie.
De nombreuses initiatives dirigées par des acteurs industriels ou des gouvernements tentent de
réglementer ce domaine en proposant des normes et des lignes directrices, qui peuvent être adoptées
63
Chapitre 2
au cours du cycle de vie du produit. Ces travaux sont présentés comme des normes, des méthodologies
ou des outils qui peuvent être adoptés dans différentes étapes du cycle de vie d’un produit ou utilisés
dans un domaine d’application spécifique d’un système embarqué de contrôle [66]. En effet, elles
permettent d’améliorer le processus de développement, la qualité du code ou l’architecture du
contrôleur.
La certification est devenue un critère vital pour les systèmes embarqués qui contrôlent des
équipements dont la défaillance peut causer des problèmes de sécurité. Le terme certification peut
avoir trois faces : la certification du produit, du processus ou des personnes. La certification du produit
et du processus sont ceux qui posent le plus de défi pour le développement de logiciel temps-réel
critique. De nos jours, ces systèmes se trouvent dans les systèmes de contrôle de vol, de sécurité et
d’assistance au conducteur de véhicules ou de contrôle de centrale nucléaire. La défaillance de ce
genre de systèmes au niveau fonctionnel ou temporel peut causer de sérieux dégâts sur le matériel et
les personnes. Pour assurer un niveau de qualité minimum pour ce genre de systèmes, plusieurs
gouvernements et consortiums industriels ont mis en place des standards permettant d’assurer une
qualité minimale dans un domaine spécifique tels que le domaine aéronautique, automobile,
ferroviaire, nucléaire, médical, etc. [67].
L’exemple le plus frappant d’une défaillance d’un système critique est celui de Toyota avec des
cas de voitures qui accélèrent sans contrôle ou qui échouent à faire arrêter le véhicule correctement
ce qui a causé un nombre considérable de morts ou de blessés et une perte difficilement réparable de
l’image de marque de cette compagnie. La majorité des voitures modernes utilisent des systèmes
embarqués afin de pouvoir contrôler divers systèmes tels que le système Anti-lock braking (ABS) et
le système de contrôle des injecteurs. Ces systèmes sont essentiellement caractérisés par leurs aspects
critiques, car ils doivent garantir la sécurité des passages ainsi que celle des autres véhicules. Ceci a
poussé plusieurs gouvernements à définir des standards rigoureux auxquels les systèmes critiques
doivent se conformer. Ceci est autant applicable pour le domaine automobile que pour les autres
domaines de l’électronique. Dans les domaines tels l’électronique médicale, l’avionique ou du
contrôle industriel ; les organismes de standardisation et les développeurs doivent prouver la
conformité aux standards avant de pouvoir commercialiser leurs produits. Les logiciels utilisés dans
des systèmes critiques sont en effet un élément clé du bon fonctionnement des systèmes en question
nécessitant aussi une certification préalable pour pouvoir être utilisée dans le flot de développement
de ces systèmes.
Dans la majorité des cas, le logiciel embarqué est une application tournant au-dessus d’un système
d’exploitation qui peut être fait maison, issue du monde du libre ou propriétaire. À cause de la criticité
64
de tels systèmes, plusieurs gouvernements sponsorisent des agences indépendantes afin de mettre en
place des standards d’assurance qualité.
2. Systèmes industriels
Le domaine de la production industrielle a connu une évolution foudroyante due à l’adoption de

technologies numériques pour la conduction de divers processus de production industrielle.
L’adoption de ces technologies a nécessité diverses garanties de sureté de fonctionnement. En effet,
divers travaux ont été effectués dans ce sens dont ceux de la commission internationale
d’électrotechniques IEC1. L’IEC est une commission internationale de standardisation dans le
domaine électrique et électronique. Elle a produit divers standards, dont l’IEC 61508 qui couvre
différents aspects d’électricité, de l’électronique et des techniques connexes dans le domaine
industriel [68]. D’ailleurs, l’IEC est considéré comme un organisme complémentaire de l’ISO2
auxquels la Tunisie contribue activement aux efforts de normalisation à travers l’organisme
INNORPI3. Les travaux de cet organisme ont permis la finalisation de plusieurs standards applicable
au domaine industriel, parmi lesquels le standard IEC 61508 qui propose un ensemble de directives
permettant d’assurer qu’un système est spécifié, implémenté, fonctionnant et maintenu à un niveau
de sureté requit SIL4. D’autres standards de l’IEC sont récapitulés par le Tableau 2. Ces standards
sont considérés comme des standards dérivés de l’IEC 61508 qui a aussi servi de socle pour
l’élaboration de plusieurs autres standards de sureté dans d’autres domaines d’application.
Tableau 2. Liste des normes de sureté de l’IEC
ainsi que leurs domaines d’application
Norme Domaine d’utilisation
IEC 61511 Processus industriel
IEC 61513 Processus nucléaire
IEC 6206 Domaine de contrôle de machines
IEC 61800 Systèmes d’entraînement de puissance
IEC 60730 Équipements à usage domestique
D’autres standards, tels que ceux issue de l’organisme UL5 notamment la série de standards
UL-508 essaient de normaliser les pratiques ayant un impact direct sur la sureté des systèmes
industriels. Récemment, des efforts d’harmonisation des architectures utilisés dans les contrôleurs
1
International Electrotechnichal Comission
2
International Standards Organization
3
Institut National de la Normalisation et de la Propriété Industrielle
4
Safety Integrity Level
5
Underwriters Laboratories
65
Chapitre 2
industriels ont permis de mettre à jour les standards UL-508 vers le standard UL-61010 qui est
compatible avec les standards de l’IEC.
3. Systèmes médicaux
De nos jours, les systèmes embarqués jouent un rôle vital dans des systèmes médicaux dont la
moindre défaillance peut causer des préjudices irréparables. En effet, la majorité des systèmes
impliques dans les phases de diagnostic ou de thérapie sont désormais basés sur des systèmes
embarqués. Des systèmes tels que les pompes à infusion, les appareils de mesure ou carrément des
implants sont carrément équipés de processeur exécutant une forme de code embarqué. Par ailleurs,
d’autres équipements plus sophistiques tels que les ordinateurs de contrôle d’IRM ou les équipements
d’aide au diagnostic utilisent des systèmes embarqués ayant un haut niveau de complexité. La criticité
de ce domaine nécessite la prise en considération des problèmes liés à la sureté et au cyber sécurité.
En effet, ces systèmes constituent un marché en pleine expansion essentiellement lié au vieillissement
des populations, la maturité des technologies embarquées et l’ubiquité des terminaux intelligents.
Actuellement, ce domaine est confronté à des demandes conflictuelles parmi lesquels le time to
market, le contrôle de coûts, la minimisation des risques, la compatibilité avec les standards actuels
et futurs, l’amélioration de la qualité de support à long terme et le développement d’outils assurant
une valeur ajoutée à long terme.
Afin d’assurer une certaine harmonie dans ce domaine, la FDA1 et le CDRH 2 sont responsables
des nouvelles accessoires médicales mises sur le marché et celles déjà présentes et susceptibles de
mal fonctionner aux États-Unis [69]. Aux royaumes unis, la MHRA3 régule le domaine des
accessoires médicaux [70]. L’IEC essaie de proposer des standards permettant de réguler ce domaine,
dont le standard IEC-62304 qui adresse la gestion de qualité pour les équipements médicaux [71].
4. Transports terrestres et ferroviaires
De nos jours, l’intégration de fonctionnalités assurant une meilleure mobilité, une meilleure sureté
et de meilleurs moyens de distraction est devenue un fait dans les moyens de transport terrestre et
ferroviaire. En effet, ces fonctionnalités imposes par la concurrence accrue du domaine constitue
d’innovation, mais posent aussi de vrais challenges technologie en vue du respect des standards
1
US Food and Drug Administration
2
Center for Devices and Radiological Health
3
Medecines and Helthcare Product Regulatory Agency
66
assurant un niveau respectable de sureté. Bien que l’objectif d’atteindre des systèmes de transport
sans faute logicielle reste non réalisable avec les moyens actuels, plusieurs organismes ont anticipé
les problèmes pouvant subvenir dans ces systèmes et ont commencé par proposer des standards
permettant de garantir un niveau minimal de sureté. La commission européenne de normalisation
électrotechnique des moyens de transport commence à prendre son chemin dans les pays nord-
Américains dans le domaine des transports publics.
Les standards du CENELEC1 tels que l’EN50129, EN50128 et EN50129 sont qualifiés de critères
d’acceptation pour des éléments de sécurité [72]. L’EN50126 est parfois appelé RAMS2 puisqu’il
touche la fiabilité (Reliability), la disponibilité (Availability), la maintenabilité (Maintainability) et la
sureté (Safety) [73]. D’autre part, les surcouts imposes par les phases de test constitue un handicap
économique pour les acteurs du transport terrestre et ferroviaire, notamment avec les demandes
accrues en termes de certification. Ces acteurs sont désormais en train d’adopter des solutions
permettant de modifier le cycle de développement de leurs systèmes afin d’améliorer une meilleure
rentabilité tout en garantissant un haut niveau de qualité. En effet, des standards tels qu’ISO 26262
basé sur une approche d’évaluation des risques à travers l’injection de fautes constitue une solution
radicale permettant de garantir les aspirations de ce domaine.
5. Certification pour l’aéronautique
Le domaine de l’aéronautique peut être considéré comme le plus représentatif des applications
critiques nécessitant un très haut de fiabilité. Ce domaine est particulièrement contrôlé par le
gouvernement des états unis. Ce dernier à travers des agences de régulation a proposé plusieurs
standards, directives et rapport concernant la certification et les critères d’assurance qualité pour les
systèmes embarqués. Ces standards abordent la gestion des licences, la qualification et la validation.
Dans le domaine de l’aviation civile, deux normes principales ont été développées et proposées par
la RTCA qui sont la norme DO-178B et la norme DO-254. Ces normes décrivent les approches à
suivre pour concevoir la partie logicielle et électronique d’un système de contrôle de vol et sont
imposés par la loi à tous les intervenants dans le flot de conception logiciel et matériel. Ces normes
ont été adoptées par la FAA3 et par l’agence Européenne EUROCAE comme base pour la conception
et l’implémentation de systèmes de contrôle de vol. Grâce à ces standards l’ingénierie du logiciel
avionique est en train de devenir une des épines dorsales de l’ingénierie aérospatiale.
1
Comité Européen de Normalisation Électrotechnique
2
Reliability Availability Maintainability and Safety
3
U.S. Federal Aviation Administration
67
Chapitre 2
Intérêts des standards dans la certification
La divergence des intérêts économiques a incité le gouvernement des états unis à imposer un socle
commun de standard à travers la société RTCA1. Cette dernière est une société à but non lucratif créée
pour superviser le domaine de l’électronique avionique. Le principal but de la RTCA est de travailler
comme un comité fédéral pour développer des recommandations au domaine de l’aviation. Ces
recommandations sont utilisées comme bases par le « Federal Aviation Administration Technical
Standard Orders » pour contrôler la certification des systèmes avioniques. En 1980, la RTCA a mis
en place un comité (SC-145) pour établir des directives destinées à réguler le domaine de la
construction des équipements avioniques. Ce comité a produit un rapport intitulé « Software
Considérations in Airbone Systems and Equipement certification », qui a été validé et approuvé par
le comité exécutif de la RTCA et publié en janvier 1982 sous le nom RTCA DO-178. Après avoir
gagné de l’expérience dans la certification des systèmes de contrôle de vol, la RTCA a décidé de
réviser le standard DO-178 par un autre comité (SC-152) pour proposer le « draft » DO-178A qui a
été publié en 1985. L’avancée technologique a poussé la RTCA à établir une révision du standard DO-
178A par le comité (SC-167) qui a été republié en 1989 sous le nom DO-178. Cette révision a abordé
cinq aspects du logiciel avionique qui sont :
 L’intégration et la production de documents
 Gestion des défaillances système
 Le développement de logiciel
 La vérification de logiciel
 La gestion de configuration du logiciel et l’assurance qualité
D’autre part la RTCA et EUROCAE2 ont proposé en 2000 le standard DO-254/ED-80. Ce standard
adresse essentiellement le processus d’assurance qualité pour la conception d’équipements
électroniques complexe. Les directives adressent un large éventail d’équipements électroniques tels
que :
 La technologie intégrée hybride

 Les composants multichip
 Composants programmables sur mesure
 Assemblage des composants sur carte imprimée
 Les COTS3
1
Radio-Telecommunication Commitee for Aviation
2
European Organisation for Civil Aviation Equipment
3
Component Off the Shelf
68
Certification logicielle selon la norme DO-178B
La certification logicielle cible trois catégories de composants classés selon leurs fonctionnalités,
ces composants sont :
 Le système d’exploitation temps-réel

 Le langage de programmation
 L’outil de développement
Certification du système d’exploitation temps-réel
L’adoption de systèmes d’exploitation temps-réel est devenue une évidence dans les systèmes de
contrôle modernes afin d’augmenter la qualité et la vérifiabilité de ces systèmes. Vu l’intérêt
économique de la certification, différents fournisseurs de RTOS1 tels que VxWorks, LynxOS, Integrity
Linux, RTLinux, RTEMS2 et microC ont suivi le boum et se sont lancés dans la certification de leurs
produits. La certification de VxWorks a commencé depuis 1999. Dès le départ, les spécifications, la
documentation et le code source sont analysées pour déterminer quelles sont les fonctionnalités à
modifier ou à éliminer pour assurer la certification [75] du système en question.
IV. Exploitation du principe HIL
1. Intérêts de la technique HIL
La notion de HIL3 a été introduite pour le développement et le test de systèmes embarqués temps-
réel complexe. Le fait que la validation de ces systèmes étant extrêmement difficile et que les
composants ne sont pas encore disponibles a incité les concepteurs à utiliser une approche basée sur
l’émulation. En effet, un système HIL doit permettre l’émulation du processus, des capteurs et des
actionneurs [76] utilisés dans le système contrôlé. Ce système peut être exploité dans les premières
phases de développement d’un contrôleur embarqué en favorisant l’introduction de test dès les
premières phases de développement. L’émulateur conçu peut être associé à une méthodologie de
développement logiciel dénommé TDD4 ou toute autre méthodologie favorisant une intégration
1
Real-Time Operating System
2
Real-Time Executive for Multiprocessor Systems
3
Hardware In The Loop
4
Test driven development
69
Chapitre 2
avancée des tests dans le flot de conception afin de garantir un niveau acceptable de qualité du
contrôleur notamment que ces contrôleurs sont exploités dans des applications critiques.
Par ailleurs, le concept de HIL pour le test de systèmes de commande est largement adopté durant
les phases de développement de ces systèmes. Ce paradigme suppose l’élaboration des tests avant
même le développement de l’application. Pour le cas d’un système embarqué temps-réel de contrôle
commande, les procédures de test fonctionnel peuvent être associées aux modèles qui seront utilisés
dans les HIL. Le principe de fonctionnement des modules HIL est illustré par les Figures 18 et 19.
Cependant, l’élaboration d’un émulateur exploitable dans une application HIL peut être effectuée
par une implémentation purement matérielle, purement logicielle temps-réel ou par une
implémentation mixte. Le critère le plus important permettant de vérifier le succès de
l’implémentation d’un module HIL est son déterminisme temporel respectant le modèle physique du
processus émulé et son déterminisme fonctionnel garantit par la qualité de l’implémentation.
Actuellement, plusieurs approches sont disponibles permettant de minimiser le temps de

développement d’un module HIL tout en garantissant le succès de l’implémentation. La majorité de
ces méthodes tendent à monter en abstraction afin de pouvoir suivre toutes les phases du
développement. Les méthodes les plus adoptées sont la génération de l’émulateur à partir d’un code
haut niveau telle que les approches basées sur les outils CatapultC et ImpulseC ou les approches
dérivées des méthodologies basées sur l’ingénierie à base de modèles. Cette dernière consiste à
générer le logiciel ou le matériel qui sera exploité en tant qu’émulateur à partir d’un modèle haut
niveau (Matlab, LabView, UML…).
Entrées du système Sorties du

embarqué
Système Système embarqué
Embarqué
Simulateur HIL
Sorties du Simulateur Entrées du Simulateur
Figure 18. Principe général d’une simulation utilisant le principe Hardware In the Loop
70
Sorties Entrées
Matérielles Matérielles
Simulateur Hardware in The Loop
Table de vérité,
implémentation
Sorties matérielle ou Entrées
logicielle
Sorties Logicielles Entrées Logicielles
Figure 19. Fonctionnement interne d’un module Hardware In the Loop
2. Problématique
L’augmentation de la pression industrielle en termes de minimisation des coûts de production a

fait émerger plusieurs problématiques telles que :
1. Contrôle de la complexité et des phases de développement du logiciel embarqué.

2. Maitrise de la consommation des systèmes électroniques embarqués.
3. Minimisation des coûts des systèmes embarqués
4. Exploitions de technologies classiques
À travers ce chapitre, nous allons entamer une étude de cas concernant la réalisation haut-niveau
d’un module HIL pour une machine à courant continu. Le but de ce travail étant purement
méthodologique permettant de valider les différentes approches sélectionnées en utilisant le cycle de
conception illustré par la Figure 20.
Le modèle étudié peut ultérieurement être substitué par un modèle plus complexe, ce dernier
permet de générer du code utilisable dans les phases de développement ou de production. Cette
approche basée sur des phases de transformation de modèles permet d’éliminer les erreurs de
fonctionnement tout en gardant la compatibilité avec le modèle de référence. D’autre part, cette
approche montre l’utilité de l’approche HIL ou XIL dans les phases de vérification et de validation.
71
Chapitre 2
Spécification Applications
Logiciel/Systéme
Besoins des
utilisateurs
Réinitialisation
Donnée
Scénario
Génération de
Tests Cas de Tests
Besoins en Modèle de Tests du Système
sureté défaut (Unitaire, système,
(standards) SIL, HIL)
Figure 20. Cycle de conception d’un contrôleur embarqué
V. Implémentation d’un modèle DCM

en utilisant la méthodologie MBD
1. Processus de développement et outils associés
L’utilisation du processus de conception adéquat a un impact direct sur la qualité finale du

contrôleur embarqué. Plusieurs projets de recherche ont proposé différentes approches à ce problème.
La recherche dans ce domaine est particulièrement active. En fait, nous assistons à l’émergence de
deux écoles de systèmes critiques :
 L’école nord-américaine qui travaille essentiellement sur le modele checking, vérification

formelle, les techniques de solveurs SAT1 et bounded model checking [77].
 L’école européenne qui travaille sur les langages basés sur des approches dirigées par des
modèles comme Esterel, Signal et Lustre [78].
1
Satisfiability Modulo Theories
72
Tableau 3. Outils de génération automatique de codes classifiés

selon leurs catégories
Synthèse haut niveau en utilisant les outils HLS

Outil Langage de développement Sortie
CoDeveloper ImpulseC VHDL/Verilog
CatapultC C, C++, SystemC VHDL/Verilog
PicoC C, C++ VHDL/Verilog
AutoESL C, C++, SystemC VHDL
C-to-Verilog C Verilog
Cynthesizer SystemC VHDL
Ingénierie à base de modèles pour des applications de contrôle

Matlab/Simulink Matlab C, C++, VHDL, Verilog, PLC
Labview Labview C, C++, VHDL, Verilog
Simulationx SimulationX C
Scilab/Scicos Scilab C, VHDL
XSG Matlab VHDL, Verilog
Synphony HLS Matlab VHDL, Verilog, C
Beremiz IL, ST, LD, FBD C++
Scade ESTEREL, Scade block C, C++, VHDL
20-sim 20-sim block diagram C

C (Xenomai), C (Erika Enterprise RTOS),
Scale-RT Scicos, Matlab, Simulationx
VHDL
Ingénierie à base de modèles pour des applications de traitement de signal

GASPARD UML VHDL
Cofluent Studio UML (SysML and MARTE profiles) SystemC
Ingénierie à base de modèles pour des applications temps-réel critiques

Topcased/Acceleo UML C, Java, PHP, CSharp
Papyrus MARTE UML C, C++
Ingénierie à base de modèles universelle

UML (SysML, MARTE, CCM and LwCCM profiles),
OpenEmbeDD C, C++, Java
AADL
73
Chapitre 2
L’industrie est également active dans ce domaine et de nombreux paradigmes sont effectivement
adoptés en réponse à la co-conception et l’exigence d’exactitude. Ces paradigmes sont appliqués par
différents outils et normes. En fait, de nombreux outils existants peuvent être utilisés comme
plateformes pour les normes disponibles, les plus adoptés sont :
 Matlab, Labview, Ptolemy, Scilab, ASCET and SCADE pour une approche MBD.
 ImpulseC et CatapulteC pour une approche HLS basée sur le langage C.
Ces outils peuvent être utilisés pour mettre en œuvre des techniques X-in-the-loop (MIL, SIL, PIL
et HIL) qui peuvent augmenter la traçabilité et la testabilité antérieures du produit conçu [79]. Les
outils de CAO modernes peuvent être utilisés dans le cadre de MBD1 pour générer un contrôleur
certifiable selon la norme présentée précédemment ou dans un langage de programmation standard.
Les environnements Matlab, Scilab et LabVIEW sont les outils les plus polyvalents, car ils peuvent
être utilisés dans une étape différente du processus de développement et peuvent générer du code
compatible avec la plupart des normes introduites précédemment. SCADE pour sa part est le plus
adapté pour la génération de code critique, en particulier pour les normes DO-178 et DO-254. En
revanche, certains outils HLS comme CoDeveloper se concentrent sur la production de code HDL
certifié. D’autres méthodes basées sur UML ou un de leurs dérivés tels que SysML et MARTE [80]
peuvent offrir des logiciels temps-réel de haute qualité ou simplement être limités à la modélisation
de systèmes. Le Tableau 3 présente une revue de certains outils de génération de code étudié pour
des applications HLS, de contrôle ou de traitement du signal orienté MBD.
2. Garanties de qualité
L’intégration de systèmes embarqués dans des applications critiques a introduit de nouveaux défis
en termes de validation et de vérification (V & V) [81]. En effet, les organismes de normalisation et
les autorités d’octroi de licences ont fait beaucoup d’efforts pour construire des documents
d’orientation et des normes de codage comme une solution viable aux problèmes de qualité de ces
systèmes. Certains de ces efforts se concentrent sur le processus de conception des systèmes
embarqués, d’autres se concentrent sur le respect des règles de codage. Le logiciel embarqué doit être
soigneusement testé en utilisant diverses techniques de tests tels que :
 L’analyse de code statique en utilisant des outils tels que Polyspace, Logiscope CAQ [82]
ou FramaC [83] qui peut certifier la qualité du code.
1
Model Based Design
74
 Les tests dynamiques RTRT1 qui peuvent certifier la conformité temporelle des
algorithmes utilisés [84].
Le côté matériel pour sa part doit également passer par des processus V & V en particulier pour
les parties innovantes telles que le matériel basé sur des plateformes FPGA. Des outils de CAO
modernes proposent différentes approches pour offrir des solutions autotests puisque le nombre de
solutions possibles pour le matériel séquentiel tend à être infini.
Aujourd’hui, les outils de CAO permettent de générer des logiciels et du matériel selon la norme
largement adoptée comme AUTOSAR, DO-178 et DO-254. En revanche, de nouvelles méthodes
formelles et langage de modélisation mathématique comme le langage SPARK dont la prochaine
version du standard apparaitra en 2014 commence à gagner du terrain [85].
3. Architecture du contrôleur
Afin d’assurer la réutilisabilité des logiciels et de ces composants matériels, plusieurs normes ont
été proposées afin de standardiser l’architecture des contrôleurs embarqués. La majorité de ces
normes sont basées sur le concept d’architecture cloisonnée illustré par la Figure 21. L’idée directrice
de ce concept est l’isolement des différents éléments logiciels au sein de diverses partitions permettant
de les faire apparaître indépendant. Ce concept rend chaque composant logiciel indépendant, comme
s’il fonctionne sur un processeur distinct. Ceci permet une meilleure gestion du produit lors des
phases de développement, mais facilite aussi les phases de maintenance.
Dans le domaine de l’automobile, ce concept est proposé dans les normes AUTOSAR et DECOS2
[86] qui visent à standardiser l’interaction entre les différents composants logiciels en utilisant une
interface normalisée dans l’architecture du logiciel afin de faciliter l’adoption de composants logiciels
issue de diverses sources sans se soucier des interfaces logicielles requises. Ceci a poussé les acteurs
de l’industrie automobile de passer de l’architecture traditionnelle basée sur le principe d’une fonction
par contrôleur embarqué pour des systèmes intégrant plusieurs fonctions dans le même contrôleur
embarqué. Par ailleurs, l’industrie aéronautique utilise essentiellement les standards IMA3 illustrés
par la Figure 22 et ARINC6534 qui sont des architectures logicielles basées sur ce même concept de
partitionnement [87]. D’autre part ce concept est utilisé avec succès dans divers domaines des
systèmes embarqués dans des buts de contrôle de la complexité et de sous-traitance des
1
Rational Test Real Time
2
Dependable Embedded Components and Systems
3
Integrated Modular Avionics
4
Aircraft Radio Incorporated
75
Chapitre 2
fonctionnalités. Par ailleurs, plusieurs implémentations du concept de cloisonnement ont été

appliquées à d’autres domaines de l’informatique telle que celui de la virtualisation à travers le projet
XEN.
Barrière de
Partitionnement
Composant
Logiciel
Composant ....
Logiciel
Composant
Composant Composant Logiciel
Logiciel Logiciel
Deuxième SE
Système d'exploitation pour le partitionnement
Figure 21. Concept de Partitionnement logiciel
Application
Application
Application
de
de
deContrôle
Contrôle Radar
Mode génération
de
devol
vol(FC)
(FC) Niveau B
utilisateur graphique
Niveau
NiveauAA
Niveau C
ARINC 653 Executif applicatif

(Ordonnancement Spatiotemporel)
Mode
Plateforme matérielle Noyau
Figure 22. Architecture IMA
4. Gestion des ressources humaines
L’évolution spectaculaire des systèmes embarqués en termes de complexité peut conduire à

classer ces projets parmi les plus grands projets jamais entrepris par l’humanité. Les systèmes
embarqués modernes peuvent être plus complexes qu’une grande application d’un système
76
informatique classique. Plusieurs études comparatives ont montré que le système de commande de
vol a une complexité supérieure à celle du noyau Linux [88] qui est considéré comme le projet open
source le plus complexe. Contrôler le temps de développement de ces projets est étroitement lié à la
complexité des systèmes. De nombreuses études attestent que le temps de développement n’est pas
linéairement proportionnel à la complexité [89]. Par ailleurs, la gestion appropriée des ressources
humaines peut contribuer à réduire le coût de ces projets. C’est ainsi que les considérations de
conceptions telles que la spécification de séparation fonctionnelle peut contribuer à améliorer la
gestion des ressources humaines puisque l’ensemble du projet peut être traité par différentes équipes
de développement sans un réel besoin de communication excessive.
Les approches modernes telles que MBD, CDB1 [90] ou HLL2 peut être très bénéfique pour limiter
la complexité d’un système embarqué réel. Les impacts directs de ces approches sont l’amélioration
de la productivité des ressources humaines, car elles permettent au développeur de faire abstraction
sur les détails inutiles. Mais aussi elles contribuent à améliorer la qualité du produit final vu qu’elles
permettent de minimiser le nombre de défauts causé par une erreur humaine.
Ces approches permettent au concepteur d’utiliser une méthodologie unifiée pour concevoir
l’ensemble du système. Ils peuvent être basés sur différents langages tels qu’UML, Simulink ou
simplement C dans le cas de C’Based Design [91]. Les nouvelles méthodologies de gestion de projets
tels que AGILE [92] peuvent être adoptées afin de minimiser les retours clients et de corriger la
spécification dans les premiers stades du développement du produit. La variante la plus utilisée de
ces approches est la méthodologie TDD3 qui permet d’améliorer de façon considérable le taux de
réussite des projets vu que la phase de test et de validation commence dès l’élaboration des premiers
modèles du système.
5. Gestion des propriétés intellectuelles
Aujourd’hui, les contrôleurs embarqués sur circuits FPGA ne font pas de distinction réelle entre
les composants matériels et logiciels. En effet, ils peuvent être considérés comme des propriétés
intellectuelles (IP). Ceci est essentiellement dû à la présence de plusieurs outils permettant de gérer
la transition en implémentation matérielle et logicielle. La maitrise des ressources matérielles doit
passer par le choix approprié de ces ressources dans leurs différentes formes (softcore, firmcore et
1
Component Based Design
2
High Level Language
3
Test Driven Design
77
Chapitre 2
hardcore). En fait, il existe un vaste choix d’IP matériels qui sont disponibles sous différents types
de licences, leurs choix doivent être faits de façon judicieusement afin de garantir les critères de coût
et de qualité. Le domaine de l’open source est riche en IP haute qualité comme la librairie GRLIB de
la société Gaisler Research ou OpenRISC du projet OpenCores.
Par ailleurs, ces IP reposent essentiellement sur des standards ouverts non soumis à des frais de
brevets ce qui permet de s’affranchir de plusieurs dépenses superflues. Cependant, nous pouvons
parfois trouver des IP de très mauvaise qualité qui n’ont jamais été testés, mais qui peuvent parfois
servir de preuve de concepts. En effet, l’adoption d’un composant open source doit être faite à la suite
d’une phase d’investigation qui peut avoir des coûts non négligeables pour la société. Dans plusieurs
cas il peut être plus judicieux d’opter pour une IP entièrement validée bénéficiant d’un support associé
à un vendeur, en particulier si le produit sera commercialisé à grande échelle ou dans des applications
critiques.
Pour sa part, le choix logiciel devrait être guidé par les métriques de qualité permettant de guider
le choix adéquat compte tenu de la diversité actuelle des composants logiciels. De nos jours, le travail
d’un ingénieur en logiciel peut être considéré comme un travail d’intégration plutôt qu’un travail de
développement. En effet, la majorité des composants logiciels usuels sont disponibles en plusieurs
implémentions avec des niveaux de qualités et de coûts variables nécessitant un niveau d’expertise
adéquat de la part du développeur afin d’adopter le composant adéquat.
Ces choix doivent être guidés par deux aspects importants, qui sont le coût d’acquisition et le
niveau de maturité des composants logiciels. La vaste gamme de logiciels libres doit être étudiée en
prenant en considération le coût, le support, la qualité et les formations requises pour la prise en main.
En fait, l’adoption de blocs de construction libres peut être utilisée pour réduire les coûts du projet,
mais ce choix doit être fait de manière appropriée pour garantir un niveau minimum de qualité du
système conçu.
Enfin, la réutilisation de l’infrastructure matérielle disponible peut aider à réduire le coût global
du produit. À titre d’exemple, nous pouvons constater que l’adoption d’une interface réseau standard
pour le contrôle de processus industriel permet de réduire considérablement les coûts de câblage
associés à ces réseaux. D’ailleurs le fait que plusieurs standards tels que Profinet et Ethernet
Powerlink soient basés sur ce concept a favorisé leur prolifération au niveau industriel. Par ailleurs,
on assiste à l’émergence d’une nouvelle génération de transducteurs utilisable dans le domaine des
réseaux sans fils telle que le transducteur WiLink de Texas Instruments pouvant être exploité avec
différentes technologies réseau sans fils.
78
VI. Concept X-IN-THE-LOOP et son

application à la conception de
contrôleurs embarqués modernes
L’ouverture des marchés due à la mondialisation a introduit de nouvelles règles de concurrence

et a élevé les exigences des consommateurs en termes de coût et de qualités. Ces exigences non
fonctionnelles doivent être prises en considération lors des premières phases de conception. Ceci a
incité l’émergence de nouveaux paradigmes capables d’assurer une meilleure qualité du système final
tout en gardant un coût raisonnable.
La méthodologie TDD qui nécessite le développement de tests avant l’application peut être très
bénéfique pour de tels systèmes. Dans cette approche, les tests doivent inclure des émulations de
capteurs et d’actionneurs. Dans les premières applications de ce paradigme, les émulateurs ont été
mis en œuvre manuellement à l’aide de HDL ou de logiciels temps-réel. La complexité de ce type
d’approche peut avoir un impact négatif sur le TTM1 de l’ensemble du projet.
Dans de nombreux cas, le développement de tests peut devenir plus coûteux que le produit final.
La notion X-in-the-loop illustrée dans la Figure 24 a été largement adoptée pour le développement et
le test de systèmes embarqués complexes comme une substitution à l’approche classique illustrée
dans la Figure 23. Ce concept permet de minimiser les coûts associés aux phases de test et de
validation tout en assurant que ces derniers sont effectués de façon satisfaisante.
Interface
Homme/Machine
Variables
Contrôleur manipulés CNA Actionneurs Convertisseur d'énergie
embarqué
Variables
Mesurées
CAN Capteur
Figure 23. Principe de fonctionnement d’un contrôleur embarqué générique
1
Time-To-Market
79
Chapitre 2
Interface
Homme/Machine
Variables manipulés MIL

Contrôleur (Actionneurs, capteurs et
embarqué Variables mesurés modèle du processus)
SIL
(Actionneurs, capteurs et
modèle du processus)
Comparer les
résultats
PIL
HIL
Figure 24. Prototypage d’un contrôleur embarqué en utilisant le principe X-in-the-loop
Ceci à travers le test de la conformité d’un produit donné à des exigences initiales dans les
différentes phases du cycle de vie du produit. En effet, plusieurs approches et outils peuvent être
utilisés pour minimiser le développement de l’émulateur. Les outils HLS1 comme CatapultC et
CoDeveloper peuvent être utilisés dans les différentes phases d’élaboration de SIL2, PIL3, ou HIL.
Une telle approche permet une mise en œuvre rapide de l’émulateur matériel qui peut être utilisé dans
le test ou dans des systèmes en phase de production. D’autres approches permettent une utilisation
ultérieure du modèle du processus dans les phases d’autodiagnostic ou de vérification des
caractéristiques de l’environnement. Cette dernière approche permet d’intégrer des fonctionnalités
BIST4 permettant d’améliorer la fiabilité des systèmes conçus et une détection automatique des
défauts permettant d’assurer un haut niveau de disponibilité des infrastructures utilisant cette
technologie. Les approches MBD peuvent être classées en deux catégories. La première est basée sur
le contrôle, et les outils d’instrumentation comme Matlab, Labview, Scilab ou Beremiz [93]. La
seconde est basée sur des solutions orientées vers UML comme CoFluent Studio [94] ou GASPARD
[95], qui est plus adapté à des applications de traitement de signal intensif. Ces outils sont réellement
en mesure de générer du matériel, du logiciel temps-réel, ou un code PLC5.
1
High Level Synthesis
2
Software-in-Loop
3
Processor In the Loop
4
Built-In Self Test
5
Programmable Logic Control
80
VII. Implémentation matérielle d’un

DCM pour une utilisation en HIL
1. Introduction aux outils de génération rapide de

modules matériels
Pour répondre aux exigences actuelles du marché des systèmes embarqués, l’implémentation
matérielle peut être un choix astucieux, mais qui peut causer des surcouts non négligeables. En effet,
cette tâche requiert un investissement supplémentaire en termes de silicium, mais surtout une
complexité supplémentaire à gérer, notamment si les méthodes classiques restent utilisées. Les
ressources humaines impliquées dans ce genre de projet sont généralement des ingénieurs en logiciel
ou en automatique. Chacune de ces disciplines a ses outils approuvés et adoptés. Le basculement vers
la conception matérielle pour ces ingénieurs peut-être coûteux. En fait, deux grandes approches sont
disponibles et peuvent permettre la mise en œuvre rapide du matériel :
 La première est l’approche HLS (synthèse de haut niveau) qui permet de générer du code
HDL à partir de la mise en œuvre de langage de haut niveau.
 La seconde est l’approche MBD appliquée à la conception de matériel. MBD est un terme
très générique décrivant le langage de modélisation qui peut varier selon les langages de
programmation. Les langages les plus adoptés sont le langage G de National Instruments
et Simulink de MathWorks. Les langages basés sur des extensions UML tels que SysML ou
MARTE sont encore en phase de recherche.
2. Implémentation d’un HIL en utilisant des outils

HLS
Pour mettre en œuvre le modèle de la machine à courant continu à l’aide d’outil HLS, nous avons
adopté l’environnement CoDeveloper. Cet environnement est largement adopté à la fois dans les
domaines industriels et académiques. CoDeveloper permet la conception de module matériel en
utilisant un langage de type C (ImpulseC). Le modèle de programmation en langage ImpulseC est
basé sur la communication entre des processus séquentiels CSP1. Il s’agit d’un ensemble de processus
1
Communicating Sequential Processes
81
Chapitre 2
qui sont reliés entre eux par des canaux de données, tels que les cours d’eau, des signaux, des registres
et des mémoires partagées.
Wm
Producteur Alpha Consommateur
Emulateur Im
Logiciel Logiciel
Matériel
Flot de données
Figure 25. Schéma de principe du modèle d’une machine à courant continu

Chaque processus est considéré comme un processus matériel ou logiciel. Les modules déclarés
en tant que modules matériels seront traduits en une description matérielle tandis que la description
complète sert de moniteur de simulation ou la génération de pilote si le module matériel est associé à
un processeur embarqué. Le code HDL généré peut être synthétisé pour une large gamme de circuits
FPGA des sociétés Altera ou Xilinx. La mise en œuvre de la propriété intellectuelle du module HIL
utilisant cet outil peut être intéressante puisque le code écrit en langage ImpulseC permettra de valider
l’implémentation matérielle. La Figure 25 montre le modèle DCM1. Les résultats obtenus seront
discutés dans la section suivante.
3. Implémentation d’un HIL en utilisant des outils

MBD
Aujourd’hui, divers outils MBD sont disponibles dans le domaine du contrôle. Labview, Matlab
et Scade sont les outils les plus connus et utilisés. Ils ont les avantages de :
 Améliorer la qualité globale du système puisque la couverture des tests est améliorée.
 Améliorer la traçabilité et la reproductibilité du test.
 Améliorer la productivité puisque les lots de tests peuvent être exécutés par nuit.
 Garantir une meilleure adaptation aux besoins des clients depuis les premières phases
du développement, ce qui peut contribuer à garantir une meilleure conformité aux
besoins du client final.
1
Direct Current Machines
82
L’environnement XSG1 est un IDE2 conçu par la société Xilinx comme un outil d’ingénierie à base
de modèles destinés à ces plateformes FPGA. Cet environnement peut être exploité pour la
modélisation, la vérification et la mise en œuvre de composants matériels embarqués. Il permet
d’augmenter le niveau d’abstraction afin de maitriser la complexité, minimiser le Time-To-Market et
d’améliorer la flexibilité du design en ajoutant, supprimant et modifiant des IP de façon visuelle des
composants matériels gérable sous forme de propriétés intellectuelles. XSG permet la conception
modulaire de modèle en exploitant l’infrastructure Matlab/Simulink et la bibliothèque de Xilinx, y
compris la communication, la logique de contrôle, le traitement du signal, les blocs de mémoire et les
accélérateurs mathématiques.
D’autre part, XSG permet de générer du code HDL (Hardware Description Language) de façon
automatique comme il permet de produire un fichier binaire prêt à être mis en œuvre sur un circuit
FPGA Xilinx. Il permet d’améliorer l’efficacité à travers la vérification de la conception avant la mise
en œuvre sur FPGA par la génération automatique d’un banc d’essai compatible avec de nombreux
outils tels que Mentor Graphics ModelSim et Candence Incisive, qui permettent la vérification et la
validation de la conception.
Le prototypage rapide du système de contrôle de la machine à courant continu, en utilisant XSG,

nécessite le développement et l’intégration de fonctions Matlab (Mcode) à partir des spécifications
de l’algorithme décrivant la machine à courant continu avec une précision du type de données à
virgule fixe. La Figure 26 illustre la mise en œuvre du modèle de la DCM. Les outils utilisés sont
Matlab/Smimulink 2008a, XSG 11.1 pour DSP et ISE 11.1 de Xilinx.
Figure 26. Schéma bloc du modèle de la machine

à courant continu implémenté avec XSG
1
Xilinx System Generator
2
Integrated Development Environment
83
Chapitre 2
4. Comparaison des résultats de synthèse en utilisant

l’approche HLS et MBD
En utilisant les deux outils XSG et CoDeveloper présentés précédemment, nous avons mis en
place un modèle d’une machine à courant continu pouvant être utilisé comme HIL pour les
applications de contrôle de cette machine. Après la génération du code VHDL avec les deux outils
présentés précédemment et sa synthèse pour le circuit FPGA Virtex2Pro de Xilinx, nous avons
comparé les résultats de synthèse obtenus pour mesurer l’efficacité des deux outils étudiés. En effet,
les deux outils étant bases sur deux concepts différents les résultats peuvent varier de façon
considérable en fonction des technologies FPGA utilises et des algorithmes implémentés. Toutefois,
cette étude a été entamée afin de comparer à la fois les aptitudes des deux solutions du point de vue
qualitatif, mais aussi d’avoir un point de référence quantitatif qui est celui de la machine à courant
continu qui peut être considéré comme un exemple classique des systèmes commandables.
Dans la Figure 27, nous montrons la quantité de ressources FPGA utilisées par les trois modèles.
Le premier modèle est une mise en œuvre de la DCM en utilisant XSG. Le second modèle est une
mise en œuvre du modèle en utilisant l’environnement CoDeveloper avec la technique de
communication de flux. Le dernier modèle est une implémentation du même système avec
l’environnement CoDeveloper en utilisant la technique de communication registre. Cette dernière
méthode est plus simple a implémenté et ne nécessite aucune considération spécifique lors des phases
de codage peut être très intéressante pour une mise en œuvre rapide d’un concept donnée. Toutefois,
les résultats obtenus par cette méthode montrent une occupation exagérée de ressources par rapport
aux autres méthodes.
Les résultats illustrés montrent que XSG est de loin plus efficace en termes d’utilisation de
ressources que CoDeveloper. En effet, même si CoDeveloper présente la technique de
communication registre comme une technique permettant d’optimiser l’utilisation de ressources
matérielle les ressources utilises en adoptant cette technique dépassent le double de ceux utilisés lors
de l’implémentation en utilisant XSG.
Pour sa part, la Figure 28 montre les fréquences des IPs synthétisé conçu en utilisant XSG et
CoDevelopper. La fréquence maximale obtenue en utilisant XSG est de loin meilleure que celles
obtenues avec CoDeveloper. Les résultats obtenus peuvent être justifiés par le fait que CoDeveloper
se concentre sur la portabilité du code HDL généré. D’autre part, XSG est spécialement conçu et
optimisé pour les FPGA de Xilinx. Par ailleurs, cette spécificité de XSG aux FPGA de Xilinx facilite
84
de façon considérable les phases de conception, mais aussi laisse une marge de manœuvre aux
développeurs afin de raffiner les algorithmes développés en choisissant d’implémenter certains blocs
de l’algorithme directement en HDL.
450
400
350
300
250
200
150
100
50
0
Registre LUTs Unité logique Mémoire RAM
XSG virgule Fixe

CoDeveloper Virgule Fixe avec technique de Streams
CoDeveloper Virgule Fixe avec technique de registres
Figure 27. Ressources FPGA utilisées par les différentes implémentations

matérielles de la machine à courant continu
140
120
100
80
MHz
60
40
20
XSG avec virgule fixe

CoDeveloper en utilisant la technique fixed point Streams
CoDeveloper en utilisant la technique fixed point Register
Figure 28. Fréquences maximales atteintes par les différentes

Implémentations du modèle de la machine à courant continu
85
Chapitre 2
VIII. Implémentation logicielle temps-

réel du modèle DCM pour une
utilisation HIL
1. Introduction au principe de fonctionnement de

Scale-RT
L’émulation de processus ou de systèmes physiques réels exige le respect de leurs caractéristiques

temporelles. L’adoption de système temps-réel dur est devenue un fait dans la simulation HIL. Le
respect de l’échéance peut être assuré en utilisant le logiciel temps-réel adéquat fonctionnant sur le
matériel approprié ou en utilisant une implémentation purement matérielle du système. En fait,
plusieurs outils de CAO peuvent générer du code logiciel à partir d’un système simulé. Les outils les
plus puissants comme Matlab, Scilab ou LabView sont capables de produire une implémentation
logicielle sous un RTOS déterminé fonctionnant sur une plateforme matérielle connue. Par ailleurs il
existe plusieurs alternatives issues du monde de logiciel libre telle que Beremiz ou Scale-RT
permettant d’effectuer des tâches comparables sur un nombre plus limites de plateformes.
Dans notre étude, nous avons mis en place un modèle de moteur à courant continu utilisant cette
approche sur l’environnement Scale-RT. Le but de cet environnement est d’intégrer plusieurs outils
de prototypage de contrôle pour réaliser un modèle de simulation Hardware-in-the-loop. L’idée
originale de Scale-RT est l’utilisation d’un ordinateur standard comme une cible en temps-réel [96].
Comme le montre la Figure 29, cet ordinateur peut être partagé par plusieurs utilisateurs afin
d’exécuter leur modèle temps-réel respectif. Scale-RT ajoute un plug-in pour les environnements pris
en charge afin d’assurer la capacité de ces environnements de générer l’application temps-réel sous
le système Linux temps-réel Xenomai.
La plateforme matérielle pour l’implémentation Hardware-in-the-loop est un ordinateur typique

fonctionnant sous une distribution Linux Debian patchée avec Xenomai. Toutefois, elle offre le
support de certaines cartes d’interface pour la version commerciale. Ce type d’approche permet au
concepteur d’utiliser des environnements de CAO standard pour prototyper et tester leur contrôleur
en utilisant le concept X-in-the-loop. En revanche Scale-RT peut permettre d’utiliser plusieurs
interfaces de contrôle en utilisant LabVIEW ou une technologie Web.
86
Génération de modèles avec

Simulation X/Matlab ou Scilab
Visualisation et contrôle des
modèles (Windows)
Cible Temps réel

(Linux)
Génération de modèles avec
Simulation X/Matlab ou Scilab
Visualisation et contrôle des
modèles (Windows)
Figure 29. Principe de fonctionnement de Scale-RT
2. Résultats de simulation du DCM utilisant

Scale-RT
Puisque Scale-RT peut prendre en charge divers outils d’ingénierie à base de modèles, nous avons
décidé d’utiliser Scilab/Scicos afin de modéliser et générer du code temps-réel de la machine à courant
continu. Le choix de Scilab/Scicos est dû au fait que cet environnement est devenu l’alternative open
source majeur qui peut substituer Matlab/Simulink. En revanche plusieurs extensions de Scilab/Scicos
permettent de générer du logiciel temps-réel pour Xenomai, Erika entreprise RTOS ou du code HDL.
Dans notre cas, le système modélisé est utilisé pour simuler le comportement d’une machine à
courant continu et de générer son modèle logiciel temps-réel exécutable sous Linux Xenomai. Ce
modèle peut être manipulé de façon hiérarchique comme indiqué sur les Figures 30 et 31 afin d’offrir
différents niveaux d’abstraction. Le code généré est compilé, chargé, exécuté et supervisé en utilisant
l’interface de supervision de Scale-RT.
Dans nos premières simulations temps-réel, nous avons eu quelques délais qui faisaient que le
modèle ne soit pas utilisable. Ceci était dû au taux d’échantillonnage élevé qu’on a fixé et qui
nécessitait des puissances de calcul nettement supérieur à celle que notre ordinateur pouvait fournir.
Ce problème pouvait être corrigé par l’adoption d’une configuration matérielle supérieure ou par la
modification des pas d’échantillonnage. En effet, on a opté pour cette dernière solution qui nous a
permis d’obtenir les résultats illustrés par la Figure 32. Par ailleurs, si l’on avait à modéliser un
87
Chapitre 2
système plus complexe le changement de configuration matérielle pourrait devenir indispensable.

Cette configuration pourrait être obtenue en adoptant un PC du commerce ou mieux encore auprès de
la société Scale-RT qui commercialise des configurations matérielles très performantes munies de
cartes d’interfaces permettant d’émuler les interfaces physiques d’un système réel.
Figure 30. Modèle interne de la machine à courant continu conçu avec Scilab/Scicos
Figure 31. Vue hiérarchique du modèle de la machine à

courant continu implémenté avec Scilab/Scicos
88
Ia
Cem
Figure 32. Simulation temps-réel de la machine à courant continu

en utilisant la plateforme Scale-RT
IX. Conclusion
Dans cette partie, nous avons présenté les méthodes et outils permettant la transformation de
modèle en vue de la génération haut-niveau de composants logiciels ou matériels embarqués pour
une utilisation potentielle dans une application de supervision/contrôle. Cette approche a été
appliquée à la génération module HIL dans toutes les phases de développement d’un contrôleur
embarqué. Nous avons aussi présenté les avantages de ce genre de méthode permettant d’obtenir des
systèmes de haute fiabilité pouvant immédiatement passer un processus de certification matérielle ou
logicielle en vue de leurs adoptions dans des applications industrielles à large échelle. Ces approches
ont aussi l’avantage de ne pas avoir d’impact néfaste sur le temps de mise sur le marché. Notre
approche étant ciblée pour des plateformes FPGA, les implémentations matérielle ou logicielle
peuvent être équivalentes du point de vue applicatif. Finalement, on a validé ces affirmations
qualitatives par une étude de cas permettant de comparer différents outils de conception utilisant les
approches hautes niveau pour la génération de composant matériel ou logiciel.
Dans notre étude, on a choisi d’utiliser les outils les plus représentatifs pouvant être appliqués à
la génération de HIL en utilisant des techniques d’ingénierie à base de modèles. Ces outils ont
l’avantage de générer du code de haute qualité permettant de minimiser les erreurs humaines. Les
résultats obtenus ont montré la supériorité de l’environnement XSG par rapport à CoDeveloper en
termes d’optimisation de ressources matérielles.
89
Chapitre 2
Ce résultat peut essentiellement être expliqué par le fait que XSG est essentiellement optimisé
pour des plateformes Xilinx. Scale-RT pour sa part a l’avantage d’utiliser des plateformes PC standard
en se basant sur des logiciels open source. L’utilisation de ce genre de technologie permet le
prototypage et le déploiement d’application de contrôle haute qualité avec des surcouts négligeables.
D’autre part, cette approche peut devenir une solution compétitive pour les implémentations à large
échelle, notamment avec la vulgarisation des nouvelles architectures Intel pour des applications
embarquées ainsi que l’apparition de PC industriels de différentes configurations pouvant être
substituées aux architectures embarquées classiques.
Par ailleurs, la comparaison qualitative nous a permis de constater la supériorité technique des
outils MBD utilisant Matlab, vu qu’à partir du même environnement on peut valider l’algorithme de
contrôle et générer du code HDL ou logiciel certifiable. L’environnement CoDeveloper pour sa part
bénéficie de sa grande facilité d’utilisation avec des FPGA Xilinx permettant à la fois d’exploiter les
ressources de calcul et les interfaces matérielles allant jusqu’à la génération automatique de pilotes
logiciels pour les modules matériels générés.
Enfin, durant ce travail on a constaté une disposition générale vers l’adoption d’outils d’ingénierie
à base de modèle qui a tendance à être préférée dans les différents niveaux du flot de conception de
systèmes embarqués et mobiles. Ces solutions sont fournies par plusieurs acteurs du marché. Chacune
de ces solutions est basée sur une approche qui le rend approprié à un domaine d’application
spécifique. Les possibilités offertes par ces produits sont très variables et doivent être un choix
déterminant lors de l’adoption d’une solution parmi d’autres. En effet, des solutions telles que
Labview permettent de générer directement le fichier binaire permettant de programmer un circuit
FPGA ou l’exécutable pouvant être chargé sur un processeur. D’autres sont basés sur des langages
innovants permettant de modéliser la totalité du système et de générer les modules nécessaires.
D’autre part, l’adoption de ces approches pour la génération de module HIL permet de contrôler
les surcouts introduits par ces composants tout en bénéficiant des avantages liés à l’amélioration de
la qualité globale du système introduite par leur adoption.
Afin de compléter cette contribution, diverses autres solutions doivent être investiguées afin de
comparer de façon plus exhaustive les possibilités offertes par ces diverses solutions, notamment
celles permettant de générer des systèmes mixtes afin de gérer les ressources de façon optimale.
90
CHAPITRE 3 :
CHOIX DE PLATEFORME
MATERIELLE/LOGICIELLE,
PERFORMANCES ,
FONCTIONNALITES ET OUTILS LIES
« Il n’y a qu’une morale : vaincre tous les obstacles qui nous empêchent de nous surpasser. »
de Louis Pauwels
Extrais du Blumroch l’admirable
91
Choix de plateforme matérielle/logicielle, performances, fonctionnalités et outils liés
I. Introduction
De nos jours, le nombre de solutions technologiques pour la réalisation d’un système donné est
devenu énorme. Le choix d’une plateforme d’implémentation doit passer par des étapes normalisées,
car il a un impact direct sur les différentes caractéristiques du produit technologique réalisé [97]. En
effet, les différents composants matériels, logiciels et protocolaires du système à réaliser doivent
passer par des étapes d’investigation et de mesure qualitative et quantitative afin de garantir les
différentes caractéristiques requises sur le plan fonctionnel et non fonctionnel. Actuellement, il n’y a
pas de méthode approuvée dans le milieu industriel permettant d’effectuer ce choix. Par ailleurs,
plusieurs outils issus du domaine de la recherche sont orientés vers l’exploration d’architectures, mais
restent toujours orientés vers les acteurs du domaine de silicium [98]. Plusieurs organismes et agences
d’expertise travaillent sur des rapports d’évaluation de tendances stratégiques du marché en évaluant
les points forts et faibles des produits déjà présents et en estimant les tendances dans les années à
venir. Ces rapports vendus à des prix très élevés restent la meilleure alternative lors des phases de
choix technologique et leur surcoût pour une production à large échelle devient négligeable [99]. Par
ailleurs, les sociétés de petite taille ou de taille moyenne doivent avoir leurs propres stratégies de
choix. Dans ce chapitre, nous présenterons des approches méthodologiques permettant de faire le
choix de plateforme matérielle et logicielle en utilisant des outils disponibles sous licence libre.
1. Enjeux liés aux choix d’une plateforme

matérielle/logicielle
L’enjeu économique lié au marché des systèmes embarqués a incité l’émergence de plusieurs
technologies matérielles et logicielles pouvant être adoptées pour la réalisation d’un même système.
Les acteurs respectifs des solutions matérielles et logicielles essaient de conquérir une part de marche
selon des stratégies diverses, partant du simple markéting à des innovations foudroyantes en passant
par des coopérations stratégiques. Les critères les plus évidents lors de l’adoption d’une solution
technologique sont évidemment liés aux métriques de performance, de coût et de consommation. De
nos jours, ces métriques sont devenues assez floues vu la complexité effrayante des plateformes
matérielles et logicielles modernes ainsi que les applications qui leur sont associées. Afin de
contourner cette complexité, plusieurs solutions technologiques ont vu le jour tel que les benchmarks,
les outils d’exploration d’architecture et les outils d’estimation de performances.
92
Chapitre 3
2. Choix de plateforme
Le choix de la technologie d’implémentation est une des premières décisions à prendre lors de la
conception de n’importe quel système. En effet, le choix par défaut lors de l’implémentation d’un
algorithme de commande était les Automates programmables. L’émergence de solutions telles que
les microcontrôleurs, les DSP1, les DSC2 et les FPGA a permis de compresser les coûts, améliorer les
performances et garantir la fiabilité. Ces nouvelles alternatives permettent une implémentation
logicielle ou matérielle des algorithmes de contrôle et de supervision. Les nouvelles technologies de
circuits FPGA, appelées parfois cSOC intégrant des processeurs Softcore ou Hardcores permettent
de fournir une solution offrant les performances du matériel et la souplesse du logiciel [100].
Toutefois, le choix du processeur embarqué reste un choix vital vu le grand nombre de choix et les
diverses possibilités et niveau de performance de ces systèmes. Ce processeur embarqué peut être un
Hardcore (gravé sur silicium) ou Softcore (netlist ou source HDL). Le processeur Hardcore a
l’avantage de la puissance de calcul, mais peut limiter le système en termes de portabilité et
l’évolutivité. Le processeur embarqué Softcore offre moins de possibilités de calcul si la plateforme
finale est un FPGA, mais est extrêmement avantageux en termes de configurabilité, portabilité, et
d’évolutivité [101].
Le système d’exploitation embarqué pour sa part peut-être à temps partagé ou temps-réel,

propriétaires ou open source. L’adoption d’un système d’exploitation embarqué dépend de la
mémoire disponible, de la stratégie, des exigences temporelles, des champs d’applications et des
besoins en certification. D’autre part, la limitation des ressources matérielles pour le logiciel
embarqué nécessite que les développeurs doivent avoir une idée claire sur la performance du matériel
de calcul. En fait, de nombreuses études se concentrent sur l’évaluation ou l’estimation de la
performance matérielle de l’architecture personnalisée [102]. D’autre part, l’adoption d’un système
d’exploitation offrant des fonctionnalités validées et approuvées permet de compresser le coût et la
qualité globale du système final.
Cette partie est subdivisée en deux sous partis. Dans la première, nous présentons une approche
pour mesurer la performance du matériel des systèmes embarqués à base de circuits FPGA en utilisant
des solutions de référence disponibles gratuitement. Dans la deuxième partie nous étudions les phases
de choix d’une extension Linux temps-réel en utilisant des solutions disponibles sous une licence
libre.
1
Digital Signal Processor
2
Digital Signal Controller
93
3. Évaluation de performance
L’évaluation des performances matérielles dans un système informatique [103] sera toujours un
véritable défi pour le concepteur de ce type de systèmes en raison de l’évolution constante de ces
systèmes, en particulier pour le domaine des systèmes embarqués où l’architecture a tendance à être
de plus en plus complexe [104]. Ce genre d’activité est en fait lié au domaine de l’ingénierie de la
performance, qui essaie de proposer des outils et des méthodes pour quantifier les exigences non
fonctionnelles des systèmes informatiques. L’analyse des performances d’un système embarqué peut
avoir différents aspects en fonction de l’application pour laquelle le système embarqué est conçu.
Plusieurs décisions de conception sont une conséquence directe de l’évaluation des performances.
La première méthode d’évaluation était basée sur le nombre d’opérations par seconde. Cette approche
est rapidement devenue obsolète en faveur des benchmarks qui ont été élaborés et adoptée pour
mesurer des aspects particuliers de la performance. Ces aspects peuvent être l’un des différents
critères de performance d’un système informatique. En effet, il existe plusieurs solutions permettant
de mesurer la performance matérielle. La plupart des solutions sont basées sur des algorithmes
standards qui sont exécutés et utilisés pour produire un score, qui reflète la performance ou la vitesse
du matériel dans un domaine particulier.
En général, l’unité MIPS1 est utilisée pour mesurer la performance matérielle du processeur. Cette
unité est devenue insignifiante avec l’apparition des architectures RISC2 puisque l’instruction
effectuée par un cycle CISC3 nécessite plusieurs instructions RISC. Ce qui a conduit à la redéfinition
du MIPS4 comme VAX MIPS qui est le rapport de performance d’une machine donnée par rapport à
la performance d’un VAX 11/780. D’autres redéfinitions ont été ensuite proposées telles que Peak
MIPS, MIPS et EDN.
En raison de l’imprécision de la définition de l’unité d’exécution, plusieurs benchmarks ont été

proposés qui peuvent être exécutés sous différentes architectures afin de refléter leurs vitesses
d’exécution. Les solutions les plus reconnues sont Dhrystone qui permet de prendre compte de la
performance de l’architecture en Dhrystone MIPS, Stanford qui exécute des algorithmes différents
afin de refléter les performances de l’architecture dans des domaines de calcul variés et Paranoïa qui
est en mesure de refléter les caractéristiques de l’unité de calcul en virgule flottante.
1
2
Reduced Instruction Set Computer
3
Complex Instruction Set Computer
4
94
Chapitre 3
Aujourd’hui, il existe plusieurs nouveaux benchmarks qui incluent ceux présentés précédemment
combinés avec d’autres fonctionnalités telles que Whetstone et Linpac. Chacun de ces benchmarks
essaie de tenir compte de la plupart des aspects de la performance du matériel. Mibench [105] est
l’application la plus populaire de cette combinaison, car elle permet de mesurer les performances
d’une architecture étudiée dans plusieurs domaines d’application.
Nous pouvons également trouver d’autres solutions de benchmarking commerciales plus efficaces
et plus spécialisées comme SPEC1 [106] qui couvrent différents domaines de l’informatique ou
EEMBC2 [107] spécialement conçus pour les systèmes embarqués. Dans la prochaine section, nous
allons présenter une analyse de performance du matériel monoprocesseur et biprocesseurs utilisée
dans des applications embarquées à l’aide de trois benchmarks. Chaque benchmark sera utilisé pour
refléter un aspect de performance du système final. Notre plateforme est basée sur les deux
composants open source le processeur LEON3 et le système d’exploitation temps-réel eCos qui nous
permettent d’être indépendants de tout fournisseur FPGA ou RTOS.
II. Plateforme étudiée
1. Processeur LEON3
LEON3 présenté dans la Figure 33 est un modèle VHDL synthétisable d’un processeur 32 bits
basé sur la spécification SPARC V8 [108]. Le modèle est hautement configurable, et particulièrement
adapté pour la conception de système sur puce (SOC). Le code source est disponible sous la licence
GNU3 GPL4, permettant l’utilisation gratuite et illimitée pour la recherche et l’éducation [109].
LEON3 est également disponible sous une licence commerciale à faible coût, ce qui lui permet d’être
utilisé dans n’importe quelle application commerciale pour une fraction du coût des cœurs IP
comparables.
D’autre part, Gaisler Research propose une version de LEON3 intégrant des fonctionnalités de
tolérance aux pannes pour un coût très compétitif. Le processeur LEON3 est distribué comme une
partie de la bibliothèque IP GRLIB, permettant une intégration simple dans la conception de systèmes
sur puce complexes. GRLIB comprend également une version configurable de LEON3 pour une
1
Performance Evaluation Corporation standard
2
EDN Embedded Microprocessor Benchmark Consortium
3
Gnu's Not Unix
4
General Public License
95
utilisation multiprocesseur. Cette version peut atteindre 16 CPU attachés au bus AHB. La bibliothèque
GRLIB est constituée d’une large gamme de blocs de périphériques pouvant être adoptés pour
diverses plateformes FPGA des firmes Actel, Altera, Xilinx et Latice.
IRQ Interrupt
Control 3-Port Regfile
15
MUL32 IEEE 754 Floating-

7-Stage Point Unit
MAC 16
Integer
Pipeline Co-Processor
Debug
I/F
DIV 32 Instruction Data
Cache
Debug Interface
Cache
MMU Trace Buffer
AMBA AHB Interface
32 Minimum Configuration
Optional Blocks
Co-Processors
Figure 33. Architecture interne du processeur LEON3
2. Le système d’exploitation temps-réel eCos
eCos est un système d’exploitation temps-réel destiné aux applications profondément enfouies
disponibles sous Licence libre et sans droits d’utilisation. La nature hautement configurable d’eCos
lui permet d’être personnalisé selon les besoins de l’application ciblée. Cet aspect lui offre le meilleur
rendement possible ainsi qu’une empreinte mémoire optimisée. La communauté internet active
travaille sur l’amélioration régulière du système d’exploitation, ce qui lui assure de suivre le cours de
l’innovation technologique ainsi qu’un large support de plateformes matérielles. La Figure 34 montre
l’architecture en couches du système eCos. Les principales composantes de l’architecture eCos sont
la HAL1 et le noyau eCos. Le but de la couche HAL d’eCos est de permettre à l’application d’être
indépendant de la cible matérielle. La couche matérielle peut être manipulée via l’API2 HAL. Cette
HAL est également utilisée par les couches supérieures du système ce qui simplifie le portage d’eCos
vers de nouvelles cibles matérielles. Désormais, le portage revient à une adaptation de la HAL vers la
nouvelle cible. Actuellement, le système eCos est essentiellement maintenu et géré par la société
eCosCentric qui propose diverses solutions de développement ainsi qu’un nombre respectable
d’extensions du système.
1
Hardware Abstraction Layer
2
Application Programming Interface
96
Chapitre 3
Application
Librairies Compatibilité
Math C POSIX µITRON Serveur

Web
Noyau Pile réseau Système de

fichier
Hardware Abstraction Layer Device Driver

RedBoot
ROM
Monitor Interruptions Vecteurs Exceptions Ethernet Série Flash
Virtuel
Hardware
Figure 34. Architecture interne du système eCos
Le noyau est le cœur du système eCos, il comprend la plupart des éléments modernes du système
d’exploitation : ordonnancement, synchronisation, interruption, gestion d’exceptions, temporisateur,
horloges, alarmes, etc. Il est écrit en langage C + + permettant à une application écrite en ce langage
de s’interfacer directement aux ressources du noyau. Le noyau eCos prend également en charge les
interfaces de la norme ITRON1 et les couches de compatibilité POSIX.
3. Combinaison eCos – LEON3
Le choix de ces composants nous permet d’être indépendants de tout constructeur de circuits
FPGA ou de RTOS puisque eCos est disponible pour une large gamme de processeurs embarqués et
LEON est porté pour les FPGA de XILINX, ALTERA, ACTEL et LATICE. D’autre part, eCos permet
une migration facile vers un système Linux embarqué. Ce choix est pris à titre d’exemple de
combinaison de technologies libres, d’autres combinaisons peuvent présenter des avantages
technologiques appropriés. Le processeur OpenRISC [111] est le concurrent le plus sérieux de
LEON3. RTEMS [112] ou Linux embarqué [113] peuvent remplacer eCos dans le cas de besoins de
programmation en langage ADA ou de l’utilisation d’une interface graphique. La mesure de la
performance sera présentée en utilisant les trois benchmarks Dhrystone, Stanford et Paranoia. La
plateforme matérielle sera simulée à l’aide tsim-leon3 pour une architecture monoprocesseur et grsim-
leon3 pour la plateforme biprocesseur SMP configuration. Ces deux outils de simulation sont en
1
Industrial The Real-time Operation Nucleus
97
mesure de représenter de très près l’architecture LEON3 avec de nombreuses autres fonctionnalités
avancées très importantes pour le prototypage de systèmes.
III. Benchmarks utilisés

Dans notre travail, nous avons choisi d’adopter trois benchmarks complémentaires qui peuvent
refléter trois aspects de performance des systèmes embarqués étudiés. Chacun des résultats obtenus
par ces benchmarks peut être utilisé pour évaluer un aspect particulier de la performance de la
plateforme matérielle.
1. Dhrystone
Dhrystone [114] est un benchmark synthétique développé en 1984 par Reinhold P.Weicker en
langages ADA, Pascal et C. Il est destiné à être représentatif des performances du système entier.
Dhrystone est constitué de 12 procédures incluses dans une boucle de mesure avec 94 déclarations.
L’idée de Dhrystone est de grouper les instructions couramment utilisées dans divers programmes
afin d’avoir un seul outil donnant une valeur représentative des performances globales. Le benchmark
Dhrystone a évolué pour devenir le représentant des performances de processeur générique jusqu’à
ce qu’il soit dépassé par la suite CPU89 de référence du « Standard Performance Evaluation
Corporation », connue aujourd’hui comme la suite « SPECint » [115]. D’autre part, Dhrystone a été
conçu sans prise en considération des calculs en virgule flottante ce qui a incité d’autres chercheurs
à développer le benchmark Whestone qui est considéré comme une extension de Dhrystone pour les
opérations en virgule flottante.
2. Stanford
Le Stanford Benchmark Suite [116] est une petite suite de tests qui a été assemblée par John
Hennessy et Peter Nye. La suite est constituée d’un ensemble de dix applications, huit entre elles sont
destinées pour les calculs en entier et deux sont destinées pour évaluer les calculs en virgule flottante.
La suite mesure le temps d’exécution en millisecondes pour chaque algorithme de référence. Le
benchmark est constitué des algorithmes suivants :
 Perm : Un programme compacte de permutation récursive.
 Towers : Algorithme permettant la résolution du problème des tours de Hanoi.
 Queens : Le problème d’échecs des huit reines résolut 50 fois.
98
Chapitre 3
 Integer MM : Multiplication de deux matrices entières 2-D.

 FP MM : Multiplication de deux matrices flottantes 2-D.
 Puzzle : Programme de calcul limité.
 Quicksort : Algorithme de trie d’un tableau en utilisant l’algorithme quicksort.
 Bubblesort : Algorithme de trie d’un tableau en utilisant l’algorithme bubblesort.
 Treesort : Algorithme de trie d’un tableau en utilisant l’algorithme Treesort.
 FFT1: Un programme de calcul de la transformée de fourrier rapide.
Ce type de benchmark est très intéressant du fait qu’il permet de caractériser les performances d’une
architecture dans divers domaines spécifiques et non de façon globale ce qui peut être décisif lors de
l’adoption d’une architecture pour une application donnée.
3. Paranoia
Le benchmark de référence Paranoia [117] conçu par William Kahan comme un programme écrit
en langage C destiné à caractériser le comportement de l’unité de calcul en virgule flottante d’un
système donné fonctionnant selon la norme IEEE 754. Par ailleurs, les applications de ce type de
benchmarks se sont étendues pour valider le fonctionnement des compilateurs ou tout simplement
pour des buts pédagogiques. En effet, l’intérêt pour ce type de benchmarks est dû au fait du constat
de la divergence de quelques opérations effectué sur divers unités de calculs en virgule flottante
utilisés dans les premières générations des processeurs. Paranoia est basé sur les tests suivants :
 Ensemble d’opérations entières.

 Recherche de racine et de la précision.
 Vérifier si les arrondissements sont faits correctement.
 Vérifier l’état du « sticky bit ».
 Tester si 2√𝑋² = 𝑋 pour un nombre d’entiers.
 Si le calcul est arrondi ou haché.
i
 Tester le calcul Z pour des entiers de Z et i de petites valeurs.
 Chercher les seuils d’underflow et le nombre positif le plus faible.
Q
 Tester le calcul Z pour quatre valeurs extrêmement proches.
 Chercher les seuils d’overflow et les saturations.
 Essayer de calculer 1/0 et 0/0.
1
Fast Fourier Transform
99
IV. Mesure et analyse des performances

Le système d’exploitation eCos étant un système profondément enfoui il doit tout d’abord être
configuré avant d’être compilé et lié à l’application cible. Après avoir effectué la configuration pour
n’utiliser que les composants logiciels indispensables au fonctionnement de notre application, nous
avons mesuré les performances pour les deux architectures sélectionnées et récapitulées par le
Tableau 4. Cette mesure de performance a été effectuée de façon séquentielle selon l’organigramme
représenté par la Figure 35.
Figure 35. Flot d’évaluation de performance adopté

100
Chapitre 3
Tableau 4. Configurations matérielles des plateformes évaluées

Configuration Configuration
Monoprocesseur Biprocesseur
SDRAM 16 Mo 16 Mo
ROM 2048 Ko 2048 Ko
Cache d’Instruction Cache 1*4 Ko, 16 octets/ligne 1*4 Ko, 16 octets/ligne
Cache de donnée 1*4 Ko, 16 octets/ligne 1*4 Ko, 16 octets/ligne
1. Résultats obtenus avec le benchmark Dhrystone
Après l’exécution du benchmark Dhrystone sur nos simulateurs de plateformes, nous avons
collecté les résultats présentés par la Figure 36 et résumées dans le Tableau 5 reflétant les
performances globales des deux architectures étudiées. En effet, ces résultats montrent que les
performances de l’architecture biprocesseur en termes de Dhrystone MIPS sont supérieures d’environ
33 % par rapport à l’architecture monoprocesseur.
70
60
Dhrystones MIPS
50
40
30
20
10
0
Architecture Monoprocesseur Architecture Biprocesseur
Figure 36. Résultats en Dhrystone MIPS

obtenus pour les deux architectures étudiées
Tableau 5. Résultats détaillés des performances obtenus avec le benchmark

Dhrystone pour les deux plateformes étudiées
Configuration Configuration
Monoprocesseur Biprocesseur
Cycles 247650694 189292275
Instructions 156822447 156860966
CPI Globale 1.58 1.21
CPU performance 31.66 MOPS 41.43 MOPS
(50.0 MHz) (31.66 MIPS, (41.43 MIPS,
0.00 MFLOPS) 0.00 MFLOPS)
101
2. Résultats obtenus avec le benchmark Stanford
Après l’exécution de Stanford dans notre simulateur de plateforme, nous avons recueilli le rapport
de performance tracé dans les Figure 37, la Figure 38 et résumés dans le Tableau 6. Ces résultats
montrent une légère amélioration apportée par l’architecture multiprocesseur, en particulier pour les
algorithmes complexes tels que Puzzle et Intmm. Ces résultats peuvent être expliqués par le fait que
le benchmark Stanford n’a pas été écrit pour exploiter des architectures parallèles. Le rapport sur le
rendement composite montre que l’amélioration du calcul en virgule fixe par la configuration
multiprocesseur est d’environ 14 %. D’autre part, l’amélioration apportée par l’adoption d’une
architecture multiprocesseur pour les calculs en virgule flottante est d’environ 55 %. Ces résultats
peuvent être justifiés par la complexité des algorithmes en virgule flottante qui peuvent exploiter
l’architecture multiprocesseur. Ce gain de performance n’est pas également réparti entre les dix
algorithmes inclus dans le benchmark Stanford. L’adoption de l’une de ces deux architectures
dépendra de l’application finale.
250
200
150
mS
100
Architecture
Monoprocesseur
50
Architecture
Biprocesseur
0
Perm Towers Queens Intmm Mm Puzzle Quick Bubble Tree FFT
Figure 37. Temps d’exécution en millisecondes des dix algorithmes du benchmark Stanford
Tableau 6. Résultats obtenus avec les deux simulateurs de

plateformes pour le benchmark Stanford
Architecture Monoprocesseur Architecture Biprocesseur
Cycles 36873110 26063953

Instructions 22181699 22218991
CPI Globale 1.66 1.17
CPU performance 30.08 MOPS (29.49 MIPS, 42.62 MOPS (41.79 MIPS,
(50.0 MHz) 0.59 MFLOPS) 0.83 MFLOPS)
Taux de « Cache hit » 96.5 % (99.8 / 75.1) 93.5 % (99.8 / 60.2)
Temps de Simulation 737.46 ms 521.28 ms
102
Chapitre 3
Virgule Flottante Composite
Virgule Fixe Composite
0 20 40 60 80 100 120 140 160
Architecture Biprocesseur Architecture Monoprocesseur
Figure 38. Performance composite des deux architectures pour le calcul en

virgule fixe et en virgule flottante
3. Résultats obtenus avec le benchmark Paranoia
Après l’exécution du benchmark Paranoïa sur les deux simulateurs de plateforme, nous
concluons que les opérations exécutées sur la FPU1 se sont correctement déroulées pour les deux
architectures. Mais les rapports de référence que nous avons :
Addition/Subtraction neither rounds nor chops.

Sticky bit used incorrectly or not at all.
FLAW : lack (s) of guard digits or failure (s) to correctly round or chop (noted above) count as
one flaw in the final tally below.
Ce type de défaillance reflétant une défaillance dans les opérations d’arrondissement est
essentiellement lié à l’utilisation d’un simulateur. En effet, on a pu confirmer ce soupçon après
réexécutions du même algorithme sur la plateforme réelle. D’autre part, il n’est pas extrêmement
dangereux pour le fonctionnement du système s’il s’agissait d’un système réel, mais peut entrainer
une certaine perte de précision qui doit être prise en considération lors de l’adoption d’algorithme
faisant des calculs en virgule flottante sur des systèmes critiques. En effet, quelques règles de codages
adoptés dans des normes liées à des systèmes critiques tels que MISRA-C interdisent l’utilisation de
calculs en virgule flottants afin de contourner ce type de problèmes. La source de cette défaillance
peut être liée à l’architecture, au compilateur ou juste une erreur de simulation si l’on faisait cette
évaluation sur un simulateur.
1
Floating Point Unit
103
4. Analyse des résultats obtenus
Les résultats de performance reportés par les benchmarks montrent une amélioration des
performances 0-55 % en utilisant des architectures multicœurs. C’est surtout en raison de la non-
optimisation des deux benchmarks et des compilateurs pour des architectures multicœurs. Les
meilleures améliorations sont obtenues en utilisant des algorithmes complexes comme puzzle ou Mm.
Ce fait doit être pris en compte lors du développement d’algorithmes pour exploiter de manière
adéquate les aspects multicœurs.
Les résultats des benchmarks présentés reflètent trois domaines de performance des systèmes
informatiques. Dhrystone est utilisé afin d’évaluer les performances de l’unité entière. Stanford est
utilisée pour mesurer les temps d’exécution de divers algorithmes ainsi que les performances
composites en virgule fixe ou en virgule flottante. Paranoia pour sa part est capable de caractériser
les opérations en virgule flottante.
Nous avons observé que le gain de performance pour une architecture multicœur n’est pas si
considérable puisque les benchmarks de référence utilisés n’ont pas été conçus pour exploiter les
architectures multicœurs. La même approche peut être utilisée pour comparer les performances des
autres architectures, mais ce genre de travail peut être fait avec soin puisque quelques études
rapportent une certaine fragilité de CPU95 de SPEC et CPU2000 [19] qui sont des surensembles des
benchmarks utilisés.
Dans cette partie, nous nous sommes concentrés sur l’évaluation des performances matérielles
dans un flot de conception de systèmes embarqués. Ce travail est essentiellement destiné à la prise de
décision concernant l’adoption de processeur embarqué notamment pour des architectures à base de
circuits FPGA. Les systèmes embarqués modernes ont d’autres aspects de performance et des facteurs
qui doivent être considérés comme effet de l’adoption d’une architecture multiprocesseur sur le temps
de développement des applications ainsi que le coût en termes de performance introduits par
l’adoption de systèmes d’exploitation temps-réel [118]. Ce dernier point sera discuté dans la partie
suivante.
Enfin, le travail de mesure de performances matérielles peut être amélioré par l’adoption de
benchmarks industriels. Pour les architectures multicœurs, la mise en place de benchmark tel que
Splash2 ou PARSEC1 reste une tâche fastidieuse nécessitant la mise en place d’environnements ou
1
Princeton Application Repository for Shared-Memory Computers
104
Chapitre 3
systèmes temps-réel spécifiques. Les nouvelles approches d’estimation de performances peuvent être
une solution très intéressante pour ce problème.
V. Choix de plateforme logicielle
1. Systèmes d’exploitation temps-réel
Les premières évolutions des systèmes embarqués ont montré des besoins de programmation
multitâches imposés par les demandes en termes de fonctionnalités et de réutilisabilité. Les systèmes
d’exploitation temps-réel ou RTOS sont la solution naturelle permettant d’assurer ce besoin tout en
respectant les contraintes temporelles liées à ces systèmes. En effet, ces fonctionnalités sont fournies
grâce à un composant logiciel appelé noyau, responsable de la gestion des tâches, leurs
communications, la gestion des ressources ainsi que plusieurs autres fonctionnalités telles que les
interfaces graphiques, le système de fichier et les protocoles de communication.
Les principales fonctionnalités offertes par ce type de systèmes sont illustrées par la figure 39.
Toutefois, la majorité des systèmes modernes offrent beaucoup plus de fonctionnalités ainsi que
diverses facilités de développement et d’instrumentation qui peuvent être des paramètres déterminant
pour son adoption parmi le nombre impressionnant de systèmes disponibles. Par ailleurs, certains
systèmes tels que RTEMS vont jusqu’à proposer diverses implémentations avec des langages de
programmation différents. D’autres systèmes, telle que HartOS vont jusqu’à proposer des
implémentations matérielles de la majorité des composants du système afin d’assurer le maximum de
déterminisme lors de la gestion de système à forte contrainte temporelle.
L’adoption d’un système d’exploitation temps-réel est généralement indispensable lorsque le

système à concevoir est constitué de plusieurs tâches indépendantes et que ces taches ont besoin de
communiquer. Dans le cas contraire, il est possible de s’en passer du système d’exploitation en
utilisant des solutions élémentaires telles que les boucles infinies ou les boucles infinies avec
interruption.
105
Gestionnaire de
Tâches
Gestionnaire de Synchronisation
périphériques et &
d'E/S Communication
Noyau
Gestion Gestion de la
d'interruptions mémoire
et d'événements
Gestion du
temps
Figure 39. Composants de base d’un système d’exploitation temps-réel
2. Linux en tant que système d’exploitation temps-

réel
Les systèmes temps-réel à base de Linux sont de plus en plus adoptés au niveau industriel, ceci
n’est pas dû à une rapidité exceptionnelle du système Linux, mais est essentiellement dû à une qualité
reconnue de ce système, qui après quelques modifications peut bien répondre à des contraintes temps-
réel moyen ou dur. Dans ce chapitre nous allons étudier différentes solutions Linux temps-réel adopté
dans l’industrie. Cette étude se basera essentiellement sur celle de différentes modifications apportées
au système Linux afin de lui ajouter des fonctionnalités temps-réel. Dans ce qui suit, nous détaillerons
les architectures micronoyaux, nanonoyau et ressource noyau, à travers des cas appliqués au noyau
Linux 2.6.
Approche micronoyau
L’approche micronoyau est basée sur l’ajout d’un deuxième noyau au noyau Linux qui peut être
utilisé comme couche d’abstraction entre le matériel et le noyau Linux. Le noyau Linux tourne en
tâche de fond comme une tache de faible priorité et est utilisé pour exécuter toutes les tâches non
temps-réel. Les tâches temps-réel sont directement exécutées sur le micronoyau [119]. La Figure 40
illustre l’architecture d’un système construit en utilisant ce principe.
106
Chapitre 3
Domaine utilisateur
(Tâches non temps-réel)
Tâches temps-réel Noyau Linux

(Non temps-réel)
Micronoyau
Hardware
Figure 40. Architecture interne d’un système

Linux temps-réel utilisant l’architecture micronoyau
Le micronoyau est principalement utilisé pour gérer les interruptions, il intercepte les
interruptions pour les diriger vers le noyau considéré afin de s’assurer que le noyau non temps-réel
ne peut pas préempter le noyau temps-réel. Ceci permet au micronoyau de garantir des fonctionnalités
temps-réel dures. L’approche micronoyau a l’avantage de garantir la coexistence d’applications
temps-réel avec des applications Linux standards. D’autre part, cette approche a quelques
inconvénients tels que l’indépendance des domaines non temps-réel et temps-réel, ce qui rend le
débogage de telles applications assez difficile notamment pour les applications ayant des taches
reparties sur divers domaines. Nous pouvons aussi noter que cette architecture a quelques limitations
au niveau des fonctionnalités offertes notamment pour la gestion de quelques pilotes de périphériques.
Plusieurs architectures modernes largement adoptées par l’industrie se basent sur ce principe. Les
plus adoptés sont RTLinux (actuellement propriété de Wind River Systems), Real-Time Application
Interface (RTAI), et Xenomai qui a le privilège de pouvoir émuler la majorité des API des RTOS
classiques.
Approche nanonoyau
L’approche nanonoyau est beaucoup plus radicale que l’approche micronoyau qui cherche à
minimiser la partie du noyau responsable de la gestion des tâches. Dans cette approche, le noyau est
réduit au strict minimum. Le noyau est considéré dans ce cas comme une couche d’abstraction
matérielle. Le nanonoyau offre la possibilité de partager les ressources matérielles entre plusieurs
systèmes d’exploitation. Ce principe permet d’affecter des priorités à divers systèmes d’exploitation,
ce qui permet de faire cohabiter des systèmes temps-réel avec des systèmes non-temps-réel avec le
minimum d’effort de personnalisation.
107
Espace noyau Espace noyau Tâches non temps-réel

(Tâches non temps-réel) (Tâches non temps-réel)
Noyau Noyau Noyau temps-réel
Nano-noyau / Aiguilleur d’interruptions
Hardware
Figure 41. Architecture interne d’un système Linux temps

réel utilisant l’architecture nanonoyau
Cette approche est très similaire avec les approches de virtualisation permettant d’exécuter
plusieurs systèmes d’exploitation sur une même plateforme materielle. Dans ce cas, le nanonoyau
offre une abstraction matérielle pour le noyau temps-réel et le noyau non-temps-réel. Ceci est très
similaire au fait qu’un système d’exploitation hôte offre une abstraction matérielle pour le système
d’exploitation invité dans le cas d’utilisation de machine virtuelle (VmWare ou VirualBox).
L’exemple le plus adopté dans les solutions actuelles est ADEOS1 [120]. ADEOS peut gérer le
fonctionnement simultané de plusieurs systèmes d’exploitation. Quand une interruption matérielle est
enclenchée, ADEOS se charge de diriger cette interruption vers le système d’exploitation concerné
afin de gérer les niveaux de priorité des systèmes supervisés.
Approche ressource noyau
L’approche ressources noyau est la plus simple à utiliser, cette approche ajoute des modules au
noyau Linux afin de permettre une réservation de divers types de ressources. La réservation permet
de garantir l’accès à un système dont les ressources matérielles (CPU, réseaux, bande passante des
disques) sont multiplexées temporellement. Ces ressources ont plusieurs paramètres de réservation
comme la période d’occurrence, le temps de traitement requis et les échéances associées à chaque
traitement. Le gestionnaire des ressources noyau offre un ensemble d’API permettant aux tâches de
faire des réservations de ressources.
1
Adaptive Domain Environment for Operating Systems
108
Chapitre 3
Le gestionnaire de ressources noyau permet ainsi une convergence entre les intérêts des tâches en
offrant un ordonnancement afin de garantir un accès respectant les contraintes fixées par la tâche (il
permet aussi de renvoyer une erreur si la contrainte ne peut pas être garantie). En utilisant un
algorithme d’ordonnancement tel qu’EDF1, le noyau peut alors être utilisé pour gérer la charge
dynamique de travail. La Figure 42 illustre l’architecture interne d’un système Linux temps-réel basé
sur une architecture de ressources noyau. Le concept de ressources noyau a été implémenté par
l’université CMU2 dans la solution Linux/RK qui a évolué pour être implémentée dans la solution
industrielle Linux/RT commercialisée par la société TimeSys [121].
Tâches temps-réel Espace Utilisateur Tâches non temps-réel
Ressources Noyau Noyau Linux
Hardware
Figure 42. Architecture interne d’un système Linux temps-réel utilisant

l’architecture ressource noyau
Solutions temps-réel à base de noyau standard 2.6
Même si toutes les solutions présentées précédemment sont intéressantes du point de vue
architecture, elles essaient toutes d’implémenter des fonctionnalités temps-réel en parallèle au noyau
Linux standard. Le plus intéressant serait que le noyau Linux puisse intégrer les fonctionnalités temps-
réel de façon native. Actuellement, on peut avoir des caractéristiques temps-réel mou de façon native
au sein du noyau Linux par une simple reconfiguration du noyau Linux. Dans le noyau Linux
standard 2.6, quand un processus de l’espace utilisateur fait un appel système, ce processus ne peut
pas être préempté. Ceci veut dire que si un processus de faible priorité fait un appel système, un
processus de haute priorité doit attendre jusqu’à ce que cet appel soit terminé.
La nouvelle option de configuration CONFIG_PREEMPT permet de changer ce comportement

du noyau en permettant au processus d’être préempté si un traitement de haute priorité doit être
1
Earliest-Deadline-First
2
Carnegie Mellon University
109
effectué même si un appel système est en cours. Cette fonctionnalité a de répercussions négatives sur
les performances globales du système.
Le noyau 2.6 peut aussi être configuré pour utiliser un temporisateur de haute résolution si celui-
ci est présent au niveau matériel. Cette nouvelle configuration permet au temporisateur de fournir des
résolutions inférieures à 1 microseconde. Enfin, tout récemment le patch PREEMPT_RT vient d’être
intégré au noyau Linux standard, ce noyau offre de meilleures performances temporelles que
CONFIG_PREEMPT.
Ces performances sont atteintes grâce à des modifications plus radicales au niveau du noyau en
modifiant les primitives de verrouillage du noyau pour être entièrement préemptible,
l’implémentation du mécanisme d’héritage de priorité pour les mutex1 internes du noyau et en
changeant les gestionnaires d’interruption en tâche noyau qui sont entièrement préemptibles.
Tâches temps-réel Espace Utilisateur Tâches non temps-réel
Tâches temps-réel Noyau

Tâches non Linux
temps-réel
(préemptible)
Hardware
Figure 43. Architecture interne d’un système

Linux temps-réel basé sur le noyau Linux 2.6
3. Choix d’une extension Linux temps-réel pour une

application de contrôle
Un système informatique peut être considéré comme un système temps-réel si le temps est une
dimension de l’exactitude. L’aspect le plus important d’un tel système est le respect de l’échéance.
Linux est un système d’exploitation polyvalent conçu pour une utilisation de bureau et de serveur.
Son noyau a été préalablement conçu pour garantir la meilleure allocation des ressources pour tous
les processus exécutés. Les noyaux adoptés pour les distributions de bureaux ou de serveurs utilisent
l’algorithme d’ordonnancement CFS2. Cet algorithme d’ordonnancement n’est pas adapté aux
systèmes temps-réel, car ils sont caractérisés par la différence de priorité des taches. Le succès du
1
Mutually Exclusive
2
Completely Fair Scheduler
110
Chapitre 3
système Linux dans le domaine des bureaux et des serveurs a poussé les différents acteurs de systèmes
embarqués d’essayer de l’adopter dans leurs domaines. Une telle adoption a un effet reconnu dans le
domaine embarqué, mais le noyau n’a pas les performances temporelles requises pour les applications
temps-réel. De nombreux projets universitaires et industriels ont été faits afin de proposer des
améliorations au noyau Linux avec des fonctionnalités temps-réel. En fait, il existe plusieurs
implémentations existantes d’extensions temps-réel pour le noyau Linux [122].
Linux embarqué est devenu un choix dominant dans les systèmes divertissement embarqués, les
terminaux mobiles et les applications serveurs. Leur adoption dans les applications de contrôle
largement utilisées est la deuxième phase de leur domination du marché des systèmes embarqué. L’un
des critères les plus importants à prendre en considération lors de l’adoption d’un système
d’exploitation temps-réel pour une application de contrôle est le déterminisme et le surcoût au niveau
performance introduit par l’adoption de ce système. En effet, de nombreuses extensions existent pour
apporter des fonctionnalités temps-réel au noyau Linux. En revanche, l’architecture standard de
l’ordinateur devient largement adoptée dans le marché de l’embarqué, avec une grande variété de
performances et de puissances.
Dans cette partie, nous étudierons l’impact de l’amélioration de synchronisation offerte par
diverses extensions temps-réel du noyau Linux et leur impact sur les performances globales du
système. Les résultats obtenus sont comparés avec les performances des noyaux standards et serveurs.
Nous avons utilisé pour notre étude une architecture Intel multiprocesseur. En effet, cette
architecture est en train de conquérir le marché à travers les PC industriels. Dans notre travail, nous
avons étudié deux métriques pour refléter la performance du noyau étudié qui sont la latence et la
puissance de calcul. Un tel travail peut être utilisé pour orienter l’adoption de l’extension Linux en
temps-réel adéquat pour une architecture matérielle donnée afin d’atteindre les exigences des
applications de contrôle.
Les applications modernes de contrôle exigent beaucoup plus de fonctionnalités récentes comme
l’interface graphique, les possibilités de communication ainsi qu’une grande réutilisabilité des
logiciels. Les systèmes d’exploitation temps-réel peuvent assurer les performances temporelles
requises, mais ont beaucoup de faiblesses concernant les aspects nécessaires aux applications
actuelles. Divers RTOS traditionnels essaient d’améliorer leurs fonctionnalités en proposant des
composants logiciels supplémentaires par le biais des licences coûteuses supplémentaires. En
revanche, le système Linux peut assurer ces exigences, mais ne peut pas être utilisé comme système
d’exploitation en temps-réel dur.
111
Ces raisons ont incité plusieurs initiatives visant à intégrer des fonctionnalités temps-réel dans le
noyau Linux, ce qui a fait que Linux devient un candidat très sérieux dans le domaine des systèmes
embarqués. En fait, de nombreuses approches sont disponibles pour offrir ces fonctionnalités en
utilisant différentes architectures [123]. Les solutions les plus adoptées sont RTLinux/RTCore, RTAI1,
Xenomai et PREEMPT-RT [124]. Chacune de ces extensions permet d’intégrer des fonctionnalités
temps-réel à l’architecture interne du noyau Linux. Toutefois, chaque extension présente des
avantages et des inconvénients particuliers. Le large choix disponible en termes de performances et
de fonctionnalités de synchronisation offerte par les différentes variantes du noyau Linux a fait de
Linux un des systèmes d’exploitation embarqués les plus appropriés, largement adoptés pour
différentes applications embarquées avec différentes gammes de contraintes.
Récemment, l’extension PREEMPT-RT a été finalement intégrée dans la version actuelle du

noyau. Cette solution a été récupérée, améliorée et commercialisée par plusieurs acteurs reconnus du
domaine des systèmes temps-réel tel que WindRiver qui commercialise une version basée sur cette
extension dans sa solution Linux5. Xenomai, est une autre extension temps-réel largement adoptée
dans l’application en temps-réel dur. Cette extension est effectivement adoptée par la société Sysgo
dans leur solution Linux en temps-réel appelé ELinOS. En outre, quelques travaux récents tentent de
fusionner avec Xenomai PREEMPT-RT, dans la solution originale baptisée Xenomai/Solo, qui intègre
les fonctionnalités populaires de Xenomai avec l’extension PREEMPT-RT.
En revanche, les exigences en termes de traitements embarqués augmentent à un rythme

exponentiel. L’offre en matière de processeurs embarqués est de plus en plus large. Différentes
plateformes peuvent être adoptées et utilisées dans le domaine embarqué, classiquement les FPGA et
les DSP sont les architectures les plus adoptées dans le domaine de haute performance embarqué. En
fait, nous assistons à la convergence des architectures PC classiques et des architectures embarquées.
Différents fabricants de microprocesseurs conventionnels tentent d’élargir leurs activités avec un
processeur qui peut être utilisé sur des ordinateurs classiques et sur des architectures embarquées.
Intel et AMD avec leurs processeurs respectifs ATOM et GEODE sont considérés comme des
candidats intéressants dans le domaine embarqué. D’autres processeurs haut de gamme conçus pour
les systèmes de bureau et serveur sont adoptés dans des contrôleurs industriels conçu par des acteurs
de renommés dans le domaine de contrôle embarqué tel que Siemens et National Instruments. Ces
processeurs sont utilisés par différents fabricants dans le contrôle industriel ou pour des applications
hardware-in-the-loop. Ces types d’architecture sont souvent adaptés pour offrir des périphériques
1
Real Time Application Interface
112
Chapitre 3
robustes spécialement adaptés pour travailler dans des environnements industriels. Dans ce travail,
nous essayons d’investiguer la facilité d’utilisation industrielle pour des applications de contrôle en
utilisant diverses extensions Linux temps-réel. Pour cet objectif, nous allons évaluer les performances
temps-réel et leurs impacts sur la puissance globale de calcul pour les extensions Xenomai,
PREEMPT-RT, lowlatency, le noyau standard et le noyau serveur. Les performances temporelles sont
mesurées en utilisant Cyclictest et Unixbench qui permettent d’évaluer le rendement des architectures
étudiées. Nos tests de performance temporelle sont effectués sous une charge de travail générée à
l’aide du benchmark hackbench. Ces outils d’évaluation des performances ont été adoptés après une
comparaison qualitative des différents outils. Cette approche est adoptée pour étudier les
performances temporelles de Linux et son impact sur les performances globales du système pour les
architectures monocoeur et multicœurs. La plateforme étudiée est un ordinateur standard avec
microprocesseur Intel Core2 Duo, 3 Go de RAM DDR2 et basés sur Ubuntu Linux 10.10. Une telle
plateforme est similaire aux ordinateurs industriels haut de gamme conçus à des fins de contrôle
commercialisés par plusieurs sociétés proposant des solutions de contrôle tels que Siemens en
National Instruments.
VI. Technologie Linux temps-réel

Les efforts de recherches universitaires et industrielles ont permis l’apparition de plusieurs
implémentations Linux temps-réel [125]. Ces extensions peuvent être classées en deux catégories en
fonction de l’approche utilisée pour améliorer les performances de synchronisation.
La première approche consiste à modifier le comportement du noyau pour améliorer ses

caractéristiques temporelles, en réduisant les durées de tâche à haute priorité. La deuxième approche
consiste à utiliser un petit noyau temps-réel pour gérer les tâches temps-réel et qui peut exécuter le
noyau Linux comme une tâche de faible priorité. L’idée derrière cette approche est illustrée par la
Figure 44. Les projets les plus connus utilisant cette technologie sont RTAI et Xenomai. Ces deux
projets sont construits en utilisant ADEOS qui permet la création de plusieurs domaines. ADEOS est
également responsable de la gestion des interruptions, comme chaque interruption déclenchée est
orientée vers son domaine enregistré. Cependant, si une interruption est non enregistrée auprès d’un
domaine ADEOS, elle est systématiquement transmise vers le domaine suivant d’ADEOS. La
Figure 44 montre la gestion des interruptions d’ADEOS basé sur Linux temps-réel.
113
Tâches Temps-réel Espace utilisateur
Noyau Temps-réel Noyau Linux
1 2 3 4
1
Tube d'interruptions
ADEOS
Interruption Matérielle
Plateforme matérielle
Figure 44. Principe de fonctionnement du superviseur ADEOS

Les travaux remarquables visant à transformer Linux en système d’exploitation temps-réel dur ou
mou sont essentiellement basés dans l’une des technologies présentées précédemment. Dans ce qui
suit, on présentera les implémentations les plus populaires de ces technologies.
1. Noyau préemptible (lowlatency)
L’extension « lowlatency » a été initialement développée par Robert Love [126] comme un patch
externe appelé preempt-kernel. Depuis la version 2.5 du noyau, les nouveaux patchs de preempt-
kernel sont incorporés dans le noyau principal afin d’offrir de meilleures qualités et pérennité à cette
extension. Grâce à cette extension, tous les processus peuvent être ordonnancés n’importe où dans
l’espace noyau. Ce projet a été initié par les transformations apportées au noyau Linux pour le support
des SMP1. Ce support nécessite la protection des sections critiques et l’accès simultané de processus
en cours d’exécution sur des processeurs distincts. Cette protection a été réalisée en utilisant le
nouveau concept de spinlocks utilisés pour protéger les zones du noyau de l’accès simultané. Ces
zones sont à peu près les mêmes qui doivent être protégées afin d’offrir un noyau rentrant utilisable
sur des plateformes multiprocesseurs.
2. PREEMPT-RT
Le patch PREEMPT-RT est la modification Linux la plus réussie qui permet de rendre le noyau
Linux entièrement préemptible sans l’aide d’un micronoyau [127]. Il permet à presque tout le noyau
d’être préempté, sauf pour de sections limitées de code. Ceci est fait en remplaçant la plupart des
1
Symmetric Multi-Processor
114
Chapitre 3
spinlocks du noyau avec des mutexs qui supportent l’héritage de priorité et sont préemptibles, ainsi
que le déplacement de toutes les interruptions comme thread du noyau.
Ce patch présente de nouveaux enrichissements du système d’exploitation afin de réduire le temps

de réponse maximum et moyen du noyau Linux. Ces améliorations sont progressivement ajoutées au
noyau Linux pour offrir des fonctionnalités temps-réel. Les améliorations les plus importantes sont :
 Temporisateur haut résolution
 Noyau totalement préemptible
 Gestion de file d’interruptions.
 Interruptions matérielles et logicielles comme des files.
 Mécanisme d’héritage de priorité
Certaines de ces nouvelles fonctionnalités comme les files d’interruptions sont actuellement
intégrées au noyau principal par les responsables du patch.
3. RTAI
RTAI est une extension en temps-réel [128] utilisable pour des architectures monoprocesseurs et
multiprocesseurs symétriques (SMP). Cette extension permet l’utilisation de Linux dans de
nombreuses applications temps-réel dur. RTAI permet le contrôle des tâches temps-réel, en utilisant
des appels système temps-réel RTAI à partir de l’espace utilisateur. Ceci permet de faire des appels
systèmes protégés utilisables pour des applications temps-réel souple. D’autre part, RTAI bénéficie
aussi d’un ordonnanceur à faible latence. RTAI est l’extension Linux temps-réel qui a la meilleure
intégration avec d’autres outils open source Scilab/Scicos [129]. Cette extension lui permet une très
bonne intégration aux applications de contrôle. Toutefois, le fait que RTAI soit basée sur une
architecture double noyau limite la portabilité des applications temps réel tournant sur ce système.
4. Xenomai
Xenomai [130] est un framework temps-réel qui peut être intégré au noyau Linux pour fournir un
support temps-réel dur. La version actuelle est basée sur l’approche à double noyau. Il utilise pour
cela le micronoyau ADEOS (I-Pipe) qui offre une interface entre le matériel et le noyau Linux. I-Pipe
est responsable de l’exécution des tâches en temps-réel. Il est aussi responsable de l’interception et le
blocage des interruptions pour qu’elles ne puissent pas atteindre le noyau Linux, ce qui peut causer la
préemption des tâches temps-réel par le noyau Linux. La Figure 45 illustre le comportement
fonctionnel d’ADEOS/I-PIPE dans le cas de son utilisation avec Xenomai. Le système ainsi obtenu
115
est composé du noyau Linux ainsi qu’un co-noyau fonctionnant sur le même processeur. Linux a la
plus faible priorité d’exécution. Le co-noyau Xenomai est exclusivement responsable du contrôle des
tâches temps-réel. Ces tâches peuvent être exécutées aussi bien en espace utilisateur qu’en espace
noyau. En cas de besoin de communication entre tâches noyau et utilisateur c’est Xenomai qui s’en
charge d’acheminer les messages échangés afin d’assurer un certain cloisonnement entre les
différentes tâches.
utilisateur
Espace
Processus rt_task
skins
rt_task
rt_task
Espace Noyau
Domaine B Domain A
Linux Xenomai Nucleus
Adeos/ I-Pipe
Plateforme Matérielle
Figure 45. Gestion des Interruptions avec Xenomai

Xenomai offre aussi un concept innovant qui est la notion de skins qui permet de fournir des
interfaces de programmation identiques à celles fournies par les systèmes d’exploitation temps-réel
classiques tels que pSOS +, VRTX, VxWorks, POSIX, ITRON et RTAI. Grâce à cette caractéristique,
Xenomai a été considéré comme le caméléon des RTOS. Il a été conçu pour permettre une migration
en douceur de RTOS traditionnel vers Linux sans avoir à réécrire toute l’application. La Figure 46
illustre l’architecture des skins Xenomai et montre que tous les skins peuvent être équivalents à
l’interface native. D’autre part, Xenomai prend en charge un large éventail d’architecture
(PowerPC32, PowerPC64, Blackfin, ARM, x86, x86_64, et ia64).
116
Chapitre 3
Interface d'appels système

Native POSIX VxWorks pSOS uITRON VRTX
Noyau Temps réel
SAL/HAL
Adeos
Applications exécutés dans l'espace utilisateurs

Applications exécutés dans l'espace noyau
Figure 46. Architecture des skins Xenomai
VII. Mesure et Benchmarking des

performances temps-réel
Les systèmes informatiques temps-réel possèdent trois aspects de performance qui doivent être
analysés pour révéler les performances globales du système [103] [131]. Ces trois aspects sont les
performances temps-réel, la puissance de calcul et la stabilité. Un tel travail peut être fait en utilisant
des programmes de mesure de performances temps-réel, des benchmarks et des outils de stress. Les
résultats obtenus sont généralement utilisés pour mesurer, analyser et améliorer à la fois l’architecture
matérielle et logicielle en manipulant divers facteurs impliqués dans le système afin d’atteindre une
consigne de performance et de stabilité.
1. Outils de mesure de performances
Afin d’évaluer les performances d’un système temps-réel, diverses solutions logicielles existent.
Chacune de ces solutions a sa propre approche et se focalise sur un aspect spécifique de la
performance. Le Tableau 7, récapitule les programmes de mesure de performances temps-réel les
plus importantes. La caractéristique la plus importante de ces systèmes est de garantir le déterminisme
temporel avec une dégradation de performance globale acceptable.
D’autres caractéristiques telles que le temps de réponse, la performance de l’ordonnancer, la

protection contre l’inversion de priorité, les mécanismes de préemption offerte, etc., peuvent être
117
considérées comme des critères de qualité. Chacun de ces programmes est en mesure d’évaluer un ou
plusieurs critères de performance. Cependant, les critères WCET1 et le jitter peuvent résumer toutes
les performances temporelles. Cyclictest peut être utilisé pour mesurer ces deux paramètres en
mesurant le temps entre l’expiration d’une minuterie configurée, et l’actuel temps d’expiration. Pour
ces raisons, nous avons décidé d’adopter pour Cyclictest afin de refléter la performance en temps-réel
de notre système pour le reste de ce travail.
Tableau 7. Programme de mesure des performances temps-réel
Programme de Description
mesure de
performances
temps-réel
lpptest Benchmark inclus dans le patch PREEMPT-RT, il permet de mesurer la latence des
interruptions reçue sur le port parallèle.
RTMB Microsuite de benchmark conçue pour comparer plusieurs des métriques de
performances temps-réel standard. Elle permet aussi de comparer ces performances
sur diverses plateformes et plusieurs langages (C, C++ and Java).
RealFeel Programme ANSI/C qui teste le bon déroulement d’une interruption périodique.
Cyclictest Programme ANSI/C qui mesure le temps de latence d’ordonnancement du noyau
Linux.
LRTBF Un framework de benchmarking composé d’un ensemble de pilotes de
périphériques et de scripts permettant d’évaluer la performance des différentes
extensions temps-réel du noyau Linux.
Houglass Une application temps-réel synthétique qui peut être utilisée pour refléter
l’ordonnancement d’un système d’exploitation à usage général à des résolutions
temporelles en microseconde et en millisecondes.
Senoner test Un benchmark de latence conçu pour analyser le comportement de Linux sous une
charge système élevée.
Bytemark Suite de benchmark processeur permettant d’obtenir les performances du
processeur, la mémoire cache, la mémoire ainsi que les performances entières et à
virgule flottante.
2. Outils de Benchmarking
Les systèmes informatiques temps-réel peuvent être comparés par leurs performances relatives.
Cela peut être fait en exécutant un certain nombre de tests standards. Les résultats du benchmark
dépendent essentiellement du matériel, mais l’environnement d’exécution logiciel qui a un impact
non négligeable sur les résultats obtenus. Le but principal des benchmarks est d’offrir un moyen de
comparer les performances de plusieurs systèmes à travers des critères reflétant les différents aspects
de performance matérielle et logicielle. Chaque benchmark est en mesure de couvrir divers aspects
de performances du système. Dans le contexte d’un système informatique basé sur Linux, divers choix
de benchmarks sont possibles. Ces benchmarks sont développés par des organismes communautaires
ou des acteurs industriels. Le Tableau 8, reprend les benchmarks open source le plus utilisé.
1
Worst Case Execution Time
118
Chapitre 3
Tableau 8. Benchmarks disponibles sous licence

libre pour l’évaluation des performances système
Benchmarking Description
program
Hackbench Benchmark ANSI/C conçu pour mesurer la performance, les surcouts et
la scalabilité de l’ordonnanceur Linux.
Lmbench Benchmark ANSI/C conçu pour mesurer la latence et la bande passante.
UnixBench Benchmark ANSI/C conçu pour fournir un indicateur de base de la
performance d’un système compatible Unix. UnixBench peut mesurer
différents aspects de performance du système monoprocesseur et
multiprocesseur.
IOZone Benchmark de système de fichiers ANSI/C qui permet de générer et
mesurer une grande variété d’opérations sur des fichiers.
3. Outils de stress logiciel
Les programmes de stress sont en général utilisés pour tester la stabilité d’un système
informatique ou une application en la poussant dans des conditions extrêmes afin de déterminer ces
points faibles afin de les éliminer. Ces applications sont couramment utilisées dans les phases de
construction et d’optimisation notamment pour les systèmes impliqués dans des applications
critiques. Actuellement, l’application de test de stress c’est généralisée à tous les systèmes nécessitant
un certain niveau de qualité. D’autre part, le fonctionnement d’une application soumise à un test de
stress permet de voir ces limites de fonctionnement et de s’affranchir de plusieurs tests inutiles. Pour
le noyau Linux, plusieurs programmes de génération de stress sont utilisés pour la validation de
chaque nouvelle version du noyau. Chacun de ces programmes, récapitulés dans le Tableau 9 peut
stimuler plusieurs aspects des fonctionnalités du noyau.
Tableau 9. Outils de génération de stress pour un

système Linux disponible sous licence libre
Stress program Description
dohell Script basé sur le benchmark hackbench présenté

précédemment et la commande dd. Il permet d’imposer une
lourde charge à l’ensemble du système.
Stress Programme ANSI/C simple qui peut imposer une quantité
configurable de charges CPU, mémoire, I/O, et le stress de
disque sur des systèmes d’exploitation compatibles POSIX.
Calibrator Petit programme ANSI/C destiné à extraire la mémoire cache,
la mémoire principale et des paramètres TLB
Cpu Burn Programme du stress, conçu pour charger lourdement le
microprocesseur.
119
4. Caractérisations temps-réel des différentes

extensions temps-réel
Performances temporelles
La mesure de la performance temps-réel d’un système d’exploitation basé sur Linux peut
nécessiter l’investigation des divers aspects de performance de ce système. Les mesures les plus
importantes sont le WCET, la puissance de calcul et la stabilité. En effet, l’aspect WCET permet de
voir le temps de réponse du système à une tâche prioritaire dans le pire cas des scénarios de
fonctionnement. Pour sa part la puissance de calcul reflète la puissance du système dans des
conditions précises de fonctionnement. Enfin, la stabilité qui est l’un des aspects les plus importants
de tous systèmes informatiques est un besoin vital pour les systèmes temps-réel critique, ce qui
nécessite plusieurs garantis de la part des développeurs afin de prouver le niveau de stabilité du
système livré.
Le benchmark Cyclictest peut être utilisé avec différents paramètres afin de déterminer le temps
de latence de divers échantillons ou seulement la latence moyenne et maximale. Dans notre cas, nous
avons utilisé le mode verbose pour étudier statistiquement la latence et le mode silencieux pour
déterminer la moyenne et le temps de latence maximum. Les résultats obtenus pour les noyaux étudiés
sont présentés par les Figures 47, 48, 49, 50 et 51.
Figure 47. Analyse statistique des résultats obtenus avec le noyau Linux avec
l’extension temps-réel Xenomai
120
Chapitre 3
Figure 48. Analyse statistique des résultats obtenus par le noyau Linux avec le patch PREEMPT-RT
Figure 49. Analyse statistique des résultats obtenus par le noyau Linux lowlatency
121
Figure 50. Analyse statistique des résultats obtenus par le noyau Linux standard
Figure 51. Analyse statistique des résultats obtenus par le noyau Linux pour serveurs
122
Chapitre 3
Interprétation
Les résultats précédemment présentés concernant le temps de réponse montrent que pour les cinq
noyaux étudiés la majorité des échantillons répondent dans des délais de l’ordre de 10usec. Toutefois,
la caractéristique temporelle la plus importante étant la latence maximale. Les meilleurs résultats sont
obtenus avec Xenomai qui a une latence maximale de 15uS. Ce résultat peut être justifié par
l’architecture de Xenomai constitué de domaines temps-réel et Linux séparé.
En revanche, le résultat obtenu avec PREEMPT-RT peut encourager l’utilisation de ce noyau pour
les applications en temps-réel puisque la latence maximale est d’environs 62uS. Le principal avantage
d’une telle solution est sa compatibilité avec les applications Linux classiques.
Le noyau low-latency montre de meilleurs résultats que le noyau standard, mais sa latence
maximale peut être une limitation sérieuse pour son adoption dans les applications temps-réel. Les
noyaux Linux standard et serveur sont donnés à titre de référence pour d’autres noyaux et montrent
des temps de latence maximale pouvant atteindre 17168uS.
5. Mesure des performances système
Les nouvelles améliorations de la technologie informatique ont introduit diverses exigences et

contraintes pour l’évaluation des performances de ces nouveaux systèmes, en particulier avec
l’émergence des architectures multicœurs.
L’évaluation de la performance de ces systèmes peut être très utile dans le flot de conception, car
elle reflète les performances globales du système à travers un indice groupant les différents aspects.
Plusieurs suites de benchmarks système existent. Ces benchmarks peuvent être classés comme suit :
 Benchmark générique
 Benchmark Processeur
 Benchmark multimédia
 Benchmark spécifique à un langage de programmation
 Benchmark de transactions
 Benchmark orienté serveur Web
 Benchmark à domaine spécifique (Automobile, télécoms, domotique, etc.)
Chaque catégorie de benchmarks est représentative des applications qui peuvent s’exécuter sur
les systèmes réels. Ces différentes catégories et leurs indices de performance sont détaillés dans le
livre de référence [131]. En effet, la convergence des systèmes embarqués et bureautiques permet
123
l’utilisation de benchmarks génériques tels que lmbench, UnixBench et Nbench pour l’évaluation des
performances globales d’un système.
Nous avons adopté UnixBench pour le reste de notre travail puisque ce benchmark est
régulièrement mis à jour pour supporter les toutes dernières architectures multiprocesseurs, d’autre
part ce benchmark bénéficie d’une grande portabilité sur divers systèmes Unix.
UnixBench
Le benchmark UnixBench [132] est conçu pour évaluer les performances globales d’un système
UNIX. Divers aspects de performance du système sont pris en compte afin de comparer le système
étudié à un système de référence. L’ensemble des valeurs d’index sont ensuite combiné afin de donner
un indice global pour le système. UnixBench peut également supporter les systèmes multiprocesseurs.
L’avantage de ce benchmark dans notre étude est sa capacité à refléter la performance du système
dans son ensemble (y compris le système d’exploitation et le compilateur utilisé). Ceci permet
d’évaluer les performances obtenues de façon globale afin d’approcher le domaine des systèmes réels.
Le benchmark permet aussi d’avoir des rapports individuels concernant la performance du système
en virgule flottante ou entière.
Résultats de performance
UnixBench est capable de reconnaître les différents CPU disponibles sur le système étudié et de
paralléliser son exécution sur ces différents processeurs. Les valeurs reportées et illustrées par les
Figures 52 et 53 sont données pour une configuration uni-processeur et biprocesseur. Les résultats
obtenus sont un score global attribué au système, calculé selon les résultats obtenus de divers
benchmarks internes tels Dhrystone et Whetstone.
Les valeurs de performances mesurées pour l’architecture uniprocesseur montrent la dégradation

des performances globales causées par les extensions temps-réel tel que PREEMPT-RT de l’ordre de
16 % par rapport au noyau Linux standard. Le noyau lowlatency présente des performances
légèrement meilleures que celles obtenues avec le noyau standard. D’autre part, les meilleures
performances sont celles obtenues par l’extension Xenomai. Ce résultat peut être expliqué par la
désactivation de la gestion d’énergie et la variation de fréquence du processeur. En revanche, les
résultats sont obtenus avec Xenomai sans charge d’exécution dans le domaine temps-réel.
Les résultats obtenus par l’architecture biprocesseurs montrent que les extensions PREEMPT_RT
et Xenomai ne tirent pas un grand profil de cette architecture. En effet, l’amélioration de la
124
Chapitre 3
performance ne dépasse pas les 10 % dans le cas de ces deux extensions. Par ailleurs, nous avons
constaté que les performances obtenues par la version serveur et lowlatency sont presque le double
de celles obtenues avec la configuration monoprocesseur. Ceci peut essentiellement être expliqué par
la maturité de ces noyaux pour les architectures multicœurs permettant de repartir les taches de façon
équilibrée entre les différents cours disponibles. D’ailleurs, c’est cet aspect qui explique le succès du
système Linux sur des plateformes fortement parallèles.
580
560
540
520
500
480
460
lowlatency Kernel PREEMPT-RT Kernel Xenomai patched Kernel Server Kernel Generic Kernel
Figure 52. Performance globale pour les différents

noyaux étudiés tournant sur une architecture monoprocesseur
1400
1200
1000
800
600
400
200
0
lowlatency Kernel PREEMPT-RT Kernel Xenomai patched Kernel Server Kernel Generic Kernel
Figure 53. Performance globale pour les différents noyaux

Étudiés tournant sur une architecture biprocesseur
125
6. Interprétations
À travers cette étude, nous avons constaté que les extensions PREEMPT_RT et Xenomai offrent
des performances temporelles satisfaisantes ainsi qu’une dégradation négligeable des performances
globales due à l’adoption de ces patchs. Le noyau générique et le noyau serveurs ont été utilisés à
titre de référence, et les résultats obtenus avec ces deux noyaux ont montré leurs inadéquations aux
applications temps-réel. Le noyau Lowlatency pour sa part a montré des performances temporelles
acceptables pouvant favoriser son adoption sur des systèmes temps-réel mou tout en montrant un gain
de performance respectable lors de l’adoption d’une architecture multi-cœur.
Par ailleurs, lors des tests des extensions PREEMPT_RT et Xenomai sur des architectures
multicœurs nous avons constaté que le gain de performance introduit par l’utilisation d’un deuxième
cœur était négligeable. Ceci est essentiellement dû au fait que ces deux noyaux n’ont pas encore
atteint un niveau de maturité satisfaisant au niveau de la gestion des architectures multicœurs.
Désormais, le choix le plus adéquat lors de l’adoption de l’une de ces deux solutions serait d’opter
pour une architecture monoprocesseur en jouant sur le facteur fréquence afin d’obtenir les
performances requises.
VIII. Protocoles de communication

La connectique réseau est une des exigences imposées par le besoin grandissant des utilisateurs
en termes de mobilité, de contrôle des coûts et de consommation. Le support filaire étant encombrant
et coûteux est actuellement substitué par des solutions sans fil. En effet, ces technologies largement
adoptées dans les systèmes embarqués sont disponibles sous la forme de protocole ouvert ou
propriétaire. L’adoption d’une solution réseau doit prendre en considération divers aspects tels que la
consommation, la sécurité et le coût. Ces choix dépendent essentiellement du domaine d’application
du système à concevoir.
Des technologies telles que Bluetooth et NFC sont désormais présentes dans la majorité des
terminaux mobiles ce qui offre des possibilités de communication avec des équipements ou des objets
auxiliaires pour les contrôler ou la collecte de données. Par ailleurs, l’adoption de ces technologies
reste très limitée dans le domaine industriel. D’autres technologies telles que Wimedia et Zigbee sont
destinées à des domaines spécifiques tels que le multimédia ou le contrôle industriel sont en pleine
extension pour conquérir leurs domaines de prédilection. En revanche, ces standards restent pour la
126
Chapitre 3
majorité contrôlés par des acteurs industriels malgré qu’une grande partie des spécifications soient
ouvertes. En effet, la majorité des implémentations fiables sont propriétaires touchant à la fois le
composant matériel, le protocole utilisé et la pile protocolaire.
L’évolution des émetteurs-récepteurs a permis l’apparition de nouveaux circuits offrant la

possibilité de communiquer via diverses technologies réseau en même temps. D’autre part, chaque
protocole a une bande de fréquences qui lui est allouée. Certaines bandes de fréquences nécessitent
une autorisation préalable d’exploitation alors que d’autres sont libres d’utilisation. La Figure 54
récapitule les principaux protocoles IEEE sans fil applicable pour des réseaux WAN1, RAN2, MAN3,
LAN4 et PAN5. L’adoption d’une technologie réseau dépend essentiellement de la portée escomptée,
du débit nécessaire et de la disponibilité des émetteurs-récepteurs.
Personnel
802.15 GSM, WCDMA, LTE
Bluetooth WAN
Large (Basé 3GPP)
ZigBee
60 Ghz MAN
UWB LAN TVWS
802.22
Régional
PAN
RAN
802.11
Wi-Fi
Métropolitain
Local
802.16
WiMax
Figure 54. Protocole IEEE pour divers domaines géographiques
Actuellement, plusieurs émetteurs-récepteurs sans fils sont intégrés dans des plateformes
matérielles telles que le CC430 de Texas Instruments ou Si10xx de Sillicon Labs. On assiste carrément
à l’apparition d’une nouvelle génération de microcontrôleurs appelés Wireless MCUs qui sont dotés
de cette facilité. La disponibilité d’une telle facilité peut être un choix déterminant dans le choix d’une
1
Wide Area Network
2
Regional Area Network
3
Metropolitan Area Network
4
Local Area Network
5
Personal Area Network
127
plateforme matérielle. En effet, la connectivité sans fil est en train de devenir un besoin vital pour les
systèmes embarqués de toutes dimensions, ce besoin est essentiellement lié à l’ubiquité de ces
systèmes et à la vulgarisation des terminaux intelligents susceptible d’interagir avec ces derniers. La
communication entre ces terminaux intelligents et les systèmes embarqués diffus dans leurs
environnements peut être dans un but de collecte ou d’analyse de données. D’ailleurs, ses interactions
qui nous positionnent dans un nouveau contexte qui est celui de l’internet des objets.
En réalité, ce domaine constitue l’aboutissement de diverse technologie présente plusieurs défis

liés à l’interconnexion de systèmes embarqués de contrôle issu de divers acteurs impliqués dans
divers types de taches avec de niveau de criticité variable. En effet, les applications de ces systèmes
peuvent toucher divers équipements qui touchent divers aspects de la vie privée des individus
notamment avec l’émergence des concepts de maisons intelligentes, de réseaux intelligents ou de
réseau corporel (Body Area Network). Le problème lié à la sécurité de ces systèmes sera détaillé dans
le chapitre suivant à travers l’étude des problématiques lies à ce domaine et la proposition de solution
permettant d’améliorer les problèmes d’authentification liés à ces systèmes.
IX. Conclusion
Les problèmes liés au choix de plateformes matérielles et logicielles sont multidimensionnels
impliquant plusieurs aspects tels que le coût, la pérennité, la performance et la qualité. Cet axe est
considéré comme un axe de recherche indépendant pour plusieurs unités de recherche et sociétés de
consulting. Dans ce chapitre nous avons essayé de classer les différents choix en deux catégories,
ceux qui sont liés à un aspect quantitatif et ceux qui sont liés à un aspect qualitatif. Nous avons appuyé
notre approche par des études de cas impliquant des systèmes réels permettant de prendre des
décisions adéquates concernant des choix de plateformes matérielles ou concernant le choix d’une
extension temps-réel du noyau Linux.
Dans la première partie ce chapitre, nous avons étudié les problèmes liés au choix de processeur
embarqué sur une plateforme FPGA. Cette approche basée sur trois benchmarks ouverts et
complémentaires permet de voir divers aspects de performance de l’architecture choisie ce qui peut
permettre aux développeurs de prendre des décisions architecturales dès les premières phases du
processus de développement.
Dans la deuxième partie de ce chapitre, nous avons fourni une étude comparative des différents
noyaux Linux avec des extensions temps-réel. Nos résultats montrent que Xenomai et PREEMPT-RT
128
Chapitre 3
ont une performance comparable pour le système monoprocesseur avec un peu de supériorité de
Xenomai pour la latence et la puissance de calcul. Nous avons conclu que l’adoption de PREEMPT-
RT peut être un choix judicieux pour le système monoprocesseur temps-réel en raison de la facilité
de migration des applications d’un système Linux standards vers Linux PREEMPT-RT. En revanche,
le résultat multiprocesseur montre une nette dégradation des résultats obtenus par le patch PREEMPT-
RT peuvent être un obstacle à son adoption pour de tels systèmes. L’extension Lowlatency du noyau
Linux peut être un candidat sérieux pour une application temps-réel souple dans un environnement
multiprocesseur puisque cette extension montre un bon comportement sous un tel environnement.
D’autre part, la solution Lowlatency a le même modèle de programmation que le noyau Linux
standard.
Le travail entamé dans ce chapitre peut être complété par diverses études complémentaires. Tout
d’abord la partie concernant le choix de plateforme matérielle peut être complétée par des études
utilisant les nouvelles générations de benchmarks spécifiques à des domaines d’application
particuliers, mais aussi par des approches abordant les nouvelles solutions d’exploration
d’architectures basée sur des solutions d’estimation de performance. Des solutions telles que SoCLib
ou OVP peuvent être très intéressantes vu qu’ils permettent d’assurer les points précédemment sites,
mais aussi de débuter le développement sur des plateformes virtuelles avant la mise en œuvre de la
plateforme physique.
D’autre part, nous envisageons d’étudier la capacité de Xenomai/Solo qui tente de fusionner
PREEMPT-RT et Xenomai. Par ailleurs, nous essayons d’étendre notre étude par la mesure de la
performance d’eCos et en la comparant avec celle obtenue par d’autres RTOS comme RTEMS, uC/OS
et VxWorks en utilisant la même plateforme matérielle.
Enfin, les travaux effectués concernant l’évaluation de performance temporelle sur des
plateformes similaires à des PCs industrielle peuvent être étendue pour couvrir des architectures
embarqués largement adoptés basés sur des architectures ARM et utilisant à la base des systèmes
Linux tels que la plateforme BeagleBone ou Raspberry Pi.
129
CHAPITRE 4 :
SECURITE DANS LES ENVIRONNEMENTS
EMBARQUES DE SUPERVISION ET DE
CONTROLE
« La difficulté ou l’obscurité d’un sujet n’est pas une raison suffisante pour le négliger. »
de Alexis Carrel
Extrait de L’homme, cet inconnu
130
Chapitre 4
I. Introduction
La majorité des équipements modernes impliqués dans des tâches de supervision/contrôle sont
désormais connectés au réseau internet. Cette connexion, introduite afin de faciliter les tâches usuelles
et de minimiser les coûts de ces infrastructures a introduit de nouveaux challenges concernant la
sécurité et la sureté de ces derniers.
Durant ces cinq dernières années, plusieurs attaques ont ciblé des infrastructures telles que les
réseaux de distribution électriques ou des centrales nucléaires. Récemment, des chercheurs ont
découvert que des pirates ont inséré des virus dans le réseau de distribution électrique des états unis
pour l’amorcer plus tard [133]. Un nombre important de pirates avertis a constaté que ces
infrastructures ont été construites sans grandes considérations de sécurité vu que l’architecture à la
base était déconnectée des infrastructures du réseau internet. Actuellement, avec l’émergence de
nouveaux concepts tels que l’internet des objets, les réseaux électriques intelligents et les réseaux de
capteurs, les problématiques de sécurité sont devenues une affaire gérée au niveau des états [134].
D’autre part, plusieurs études reportent que les équipements embarqués sont 15 fois plus
vulnérables à des attaques que les équipements informatiques classiques [135]. En effet, après les
attaques successives touchant un grand nombre de pays, nous avons assisté à plusieurs déclarations
de chef d’État abordant les problématiques de sécurité vu qu’une intrusion étrangère sur les
infrastructures critiques d’un pays donné peut avoir un impact plus néfaste qu’une attaque militaire
[136]. La majorité des pays développés ont établi des lois permettant de réguler ce domaine [137]
dont la négligence peut compromettre la sécurité des individus et des états. Quelques experts
considèrent que les prochaines guerres seront des guerres électroniques. Ceci a poussé plusieurs pays
à signer des accords concernant la sécurité numérique afin de minimiser les risques d’attaques issues
d’organismes gouvernementaux. Toutefois, le plus grand danger reste les individus avertis agissants
seuls ou en groupe limité. Les motivations de ces attaques sont multiples pouvant être la simple
recherche d’aventure numérique, l’activisme, le terrorisme ou l’escroquerie [138] [139]. En effet,
l’idée d’atteindre des infrastructures de grande envergure telle que les réseaux électriques ou les
réseaux de distribution d’eau potable peut effleurer l’esprit de beaucoup de malfaiteurs pour atteindre
des buts pas toujours coutumiers. Les nouveaux concepts liés à l’internet des objets ou les réseaux
électriques intelligents rendent cette possibilité un cauchemar effrayant, car pouvant avoir des
répercussions dangereuses sur les personnes, l’environnement et les gouvernements.
131
Sécurité dans les environnements embarqu és de supervision et de contrôle
Au travers de ce chapitre, nous présenterons les différents problèmes liés à la sécurité des
infrastructures de supervision/contrôle ainsi que les solutions technologiques permettant
l’amélioration des différents piliers de la sécurité. Par la suite, nous détaillerons les différentes
solutions possibles en termes d’algorithmes de hachage permettant d’améliorer à la fois l’aspect
authentification, vérification d’intégrité et signature des données. Ce volé sera complété par une étude
qualitative et quantitative concernant le choix d’un algorithme de hachage pour une application de
supervision/contrôle limitée en ressources. En effet, l’ajout de fonctionnalité d’authentification fiable
au niveau des nœuds d’un système constitué d’un ensemble d’objets intelligents, peut améliorer de
façon considérable la sécurité de ce dernier. Ceci est essentiellement dû au fait que la première étape
d’une attaque réussite est l’intrusion. Notre démarche réalisée sur trois plateformes matérielles
complémentaires qui sont le microcontrôleur MSP430, le DSC Piccolo et le Microcontrôleur haut de
gamme Tiva_C, permet d’avoir une solution très compétitive et complémentaire utilisable dans les
applications modernes de l’internet des objets. En effet, la société Texas Instruments a produit trois
cartes de développement permettant d’assurer un haut niveau de compatibilité matérielle et logicielle.
Les phases de choix seront donc dirigées par les facteurs de performance, d’empreinte mémoire, mais
aussi de scalabilité et de temps de prise en main.
1. Évolution
Les réseaux informatiques ont connu plusieurs vagues d’évolutions illustrées par la Figure 55 qui
ont permis un rapprochement considérable de l’utilisateur ordinaire. La dernière évolution représente
une révolution dans le mode de vie des utilisateurs. Elle est essentiellement due aux changements
enregistrés dans le domaine des systèmes embarqués qui ont permis une réduction, voire une
banalisation des prix des plateformes matérielles. Ceci a permis l’introduction d’une nouvelle
génération d’équipements et de biens extrêmement communicants pouvant utiliser une multitude de
technologies réseau. Cette nouvelle catégorie de systèmes a passé par plusieurs phases d’évolution
pour atteindre la dénomination d’internet des objets (IdO1) qui n’est pas encore reconnue comme une
désignation commune par tous les acteurs du domaine. En effet, le domaine de l’IdO est en pleine
effervescence vu la différente vision technologique et éthique de chaque acteur. L’idée directrice la
plus appropriée à l’internet des objets est l’omniprésence d’une variété d’objets comme les étiquètes
d’identification radiofréquence (RFID2), les capteurs, les actionneurs, téléphones portables, etc. Qui
1
Internet des Objets
2
Radio Frequency Identification
132
Chapitre 4
à travers des schémas d’adressage uniques, est capable d’interagir les uns avec les autres et de
coopérer avec leurs voisins pour réaliser des objectifs communs.
Plusieurs études ont estimé que le nombre d’objets connectés à internet a dépassé le nombre
d’habitants sur la planète depuis l’année 2008 [140]. En effet, à travers la Figure 55 illustrant
l’évolution des réseaux à travers ces trois dernières décennies pour atteindre le domaine de l’internet
des objets, nous voyons bien que ces équipements sont désormais intégrés dans la majorité de nos
biens.
Internet mobile Appareils mobiles +

Réseau Le réseau Internet Internet des objets
utilisateurs + PCs
Terminal Terminal
Mobile Mobile
Hôte Utilisateurs
Hôte
Hôte Terminal
Hôte
Mobile
Web
Hôte Hôte Hôte Hôte Hôte

Hôte
Hôte Terminal Terminal

Hôte Terminal Utilisateurs
Hôte Mobile Mobile Mobile Hôte
Objets interconnectés
Figure 55. Évolution des réseaux informatiques de Peer to Peer vers l’Internet des objets
L’utilisation de l’internet des objets a désormais dépassé le but d’étiquetage pour lequel elle a été
initialement prévue, ces objets sont actuellement présents dans les applications médicales,
automobiles, agricoles ou militaires. Ils sont parfois utilisés dans des accessoires de modes comme
ils peuvent être utilisés dans les systèmes de contrôle d’une centrale nucléaire. Dans pas mal d’études,
ils sont considérés comme la technologie qui va étendre la possibilité du corps humain ou du moins
lui garantir de meilleures conditions d’existence [141].
Outre leurs possibilités de transférer des données pour des tâches de supervision ou de contrôle à
l’image des systèmes SCADA classiques, ces objets sont capables de coopérer pour la réalisation
d’une tâche spécifique à l’image des DCS.
En effet, l’internet des objets présente l’aboutissement d’une quantité énorme de technologies
faisant intervenir le domaine des réseaux, des systèmes embarqués, des algorithmes distribués, de
l’automatique, etc. la Figure 56 montre que le domaine de l’internet des objets est le croisement de
plusieurs technologies reflétant plusieurs vues [142].
133
Vue orientée « Objets »
RFID
UID Objets de tous

NFC
les jours
spimes Capteurs et
Actionneurs
Objets
Sans Fil WISP
intelligents
Connectivité
de n’importe
quoi
Objets
communicants
Technologie
sémantique
IPSO (IP for Internet
smart Objects) des Objets Raisonnement
sur des données
Objets internet Middleware Environnement

sémantique d’exécution
intelligent sémantique
Web des objets Semantic
Vue orientée « Internet » Vue orientée « Sémantique »
Figure 56. Vue globale du domaine de l’internet des objets
La vue orientée « objets » est essentiellement liée aux applications de suivi de production liée aux
utilisations des technologies RFID ou NFC1, permettant de construire des plateformes WISP2
sophistiquées d’acquisition et d’analyse de données à partir d’objets physiques. Ces plateformes
permettent d’améliorer les chaînes de production et de commercialisation de divers produits
industriels notamment après leurs interconnexions à des systèmes de collecte et d’analyse de données.
En effet, ces systèmes sont généralement exploités dans des contextes plus globaux faisant intervenir
des technologies de Cloud Computing pour la gestion distribuée des objets impliqués dans le système
ainsi que diverses technologies de Data Warehouse pour guider les phases de collecte de données et
de prises de décisions.
La vue orientée « sémantique » complémente la vue précédente du fait qu’elle insiste sur l’aspect
analyse des données issues de ces objets. Cette vue permet de se focaliser sur le sens des données
1
Near Field Communication
2
Wireless Identification and Sensing Platform
134
Chapitre 4
plus que les données eux-mêmes. Ces données sont collectées et analysées dans les entrepôts de
données couramment appelés « data warehouse ».
La vue orientée « internet » permet de voir ces systèmes comme étant des objets intelligents
connectés à internet et se focalise par conséquent sur les moyens de construction et d’optimisation de
réseau IP assurant la communication entre ces objets.
En effet, une des plus grandes innovations qu’a connue le réseau IP qui est la norme IPv61 est
essentiellement due aux besoins d’introduire ces objets dans le réseau IP. Plusieurs travaux de
recherche parlent carrément du Web des objets, vu que ces objets gèrent les protocoles du Web et
qu’ils peuvent être contrôlés ou supervisés à partir d’une interface Web. Par ailleurs, cette norme a
connu diverses extensions afin de mieux couvrir des domaines d’applications spécifiques à travers
des nomes tels que MIPv6 pour les applications mobiles et 6LoWPAN pour les applications sans fils
économes en énergie.
Applications
Supervision infrastructures Supervision de Supervision Transport

Surveillance critiques l’environnement de la santé intelligent
Computing
Virtualisation Analytics
Cloud
Saas
Paas
Iaas
Calcul Stockage
Réseau de capteurs sans
fils « Réseau d’objets »
Figure 57. Architecture moderne d’un système à base d’objets intelligents

utilisant des infrastructures de Cloud Computing
1
Internet Protocol Version 6
135
Le concept de l’internet des objets est en train de bouleverser le mode de vie des utilisateurs au
niveau domotiques, mais aussi dans les domaines industriels, agricole ou de recherche scientifique.
Les applications liées à ce domaine peuvent simplement être exploitées pour l’étiquetage et le suivi
de produits, comme elles peuvent être utilisées dans les maisons intelligentes offrant tout le confort
nécessaire grâce à une auto adaptabilité de tous les équipements disponibles à l’intérieur du bâtiment.
Ces technologies sont pour la plupart liées à un autre concept relativement nouveau qui est celui
du cloud computing permettant la collecte et l’analyse de données dans des infrastructures réseau
distantes. La Figure 57 illustre les architectures de l’internet des objets attendus dans les années à
venir qui sont basés sur le concept de cloud computing [143].
2. Machine To Machine
Le concept de M2M1 est intimement lié au concept de l’internet des objets. En effet, il peut être
considéré comme la vision de l’internet des objets directement liée au contrôle industriel. Ce concept
est par ailleurs considéré comme une étape de la consumérisation menant à la vulgarisation de
l’Internet des Objets.
L’idée directrice du concept M2M est le fait que les équipements se contrôlent eux-mêmes ou
coopèrent pour la réalisation d’une tâche spécifique sans l’intervention d’un opérateur humain. La
majorité des technologies M2M allouent une grande importance aux supports de communication
basés sur les nouvelles technologies de communication radiofréquence offerte par les opérateurs
GSM2 classiques tels que les technologies 2G, 3G et 4G ou les technologies industrielles tels que
Zigbee. De nos jours, les domaines privilégiés des applications M2M sont essentiellement le domaine
automobile et le domaine de suivi médical [159].
La Figure 58 illustre l’architecture haut-niveau d’un système M2M faisant intervenir des nœuds
de rassemblement permettant de contrôler des périphériques M2M, les données sont par la suite
collectes et acheminés aux clients du service pour fournir divers services permettant d’interagir avec
l’infrastructure sous-jacente. De nos jours, on assiste à la démocratisation des technologies M2M
notamment grâce à la vulgarisation des technologies réseaux IP. Ceci a permis de voir de nouvelles
tendances qui permettent de voir des applications M2M au-delà du domaine industriel pour atteindre
la distribution afin d’assurer une interaction entre le consommateur et le producteur.
1
Machine to Machine
2
Global System for Mobile Communications
136
Chapitre 4
Par ailleurs, le domaine des M2M reste confronte a plusieurs défis technologiques qui sont pour
la plupart communs aux composants impliques dans les systèmes embarqués modernes tels que le
coût, l’autonomie et les capacités de communication. Ces différents points sont pour la majorité gérés
par les fabricants de silicium eux-mêmes. Toutefois, les challenges liés à la sécurité peuvent être les
plus durs à relever, car ils touchent les trois aspects matériels, logiciels et réseau ce qui nécessite une
prise en considération de la part des systémiers et des donneurs d’ordres.
Clients de
services M2M
Cloud Serveur M2M

Réseau social
Peer-to-peer
Interface système de
l’opérateur mobile Utilisateur local
visualisation/contrôle
Réseau Wan
(Cellulaire ou fixe)
Passerelle
Communication Passerelle
Peer To Peer
Réseau local entre Passerelles
Réseau
Filaire ou Wi-Fi personnel
(Zigbee, Wifi
ou Bluetooth)
Point de Point de
rassemblement rassemblement
Périphériques
Périphériques M2M direct
M2M indirect
Figure 58. Architecture haut niveau d’un système M2M
3. Défit
L’avènement de l’internet des objets a introduit les fonctionnalités de supervision/contrôle dans

notre vie courante. En effet, ces nouveaux équipements sont en train de charger nos habitudes sur
tous les aspects, en partant de notre façon de faire nos courses pour aboutir aux dernières tendances
de surveillance médicale en passant par nos nouveaux moyens de loisirs.
En effet, tous ces nouveaux aspects n’ont fait que faciliter notre vie actuelle. D’ici 2015, on
s’attend avoir 15 millions de périphériques connectés à internet. Ces objets génèrent une quantité
énorme de données qui nécessitent dans la majorité des cas un traitement en temps-réel. Ces données
contiennent des informations confidentielles concernant des personnes, des sociétés ou des
137
gouvernements. L’aspect distribué des objets rend cette approche difficile au niveau global. En effet,
les approches de sécurités les plus intéressantes sont celles essayant d’affecter les principales tâches
de sécurités aux objets eux-mêmes. D’autre part, la quantité énorme de données générées nécessite
une prise en compte du surcoût introduit par les fonctionnalités de sécurité ainsi que les opérations
d’analyse des données générées. Dans le reste de ce travail, nous aborderons divers aspects
concernant la sécurité. Par ailleurs, l’analyse des données est hors de propos de ce manuscrit.
II. Sécurité des systèmes embarqués

de contrôle
1. Besoin de sécurité
Beaucoup d’organismes ont sonné la sonnette d’alarme concernant la sécurité des systèmes
embarqués. En effet, des attaques répercutées par le ver conficker ont causé l’arrêt d’un grand nombre
de vols à cause du fait que les ordinateurs responsables de fournir les plans de vol sont infectés et mis
en quarantaine. Mais pire encore ce même virus a infecté un grand nombre d’ordinateurs utilisés dans
des hôpitaux, ce qui a perturbé un grand nombre d’équipements qui dépendent de ces ordinateurs tels
que les IRM1, et les équipements de suivi cardiovasculaire.
Le virus Psyb0t détecté en 2009 a infecté plus de 100 000 routeurs et modem haut débit. Même
si ce virus ne cause pas un préjudice direct au système infecté, il est capable de diriger des attaques
DoS2 vers des cibles extérieures. Les buts essentiels de ce genre d’attaques sont le vol d’informations,
le contrôle du fonctionnement du système et le reverse engineering. Les dégâts pour la société
attaquée peuvent varier de la simple perte financière à des pertes totales de marché dues à des
scandales liés à la prise de contrôle de leurs équipements. En effet, le contrôle d’un équipement
industriel, médical ou militaire par un hacker peut mener à des résultats effrayants vus que ces
attaques peuvent compromettre des vies humaines sans avoir à interagir physiquement avec le
système.
Dans quelques cas, il est très difficile de prouver une attaque ou une défaillance sécuritaire. Un
nombre non négligeable d’applications destinées à des terminaux intelligents sont suspectées
d’espionnage et de vol d’informations.
1
Imagerie par résonance magnétique
2
Denial Of Service
138
Chapitre 4
Récemment, on vient de reporter une défaillance majeure dans la sécurité du système

d’exploitation Android, une telle défaillance peut toucher tous les équipements tournant sur ce
système à partir de la version 1.6 [144]. En effet, même si Google fournit des patchs de sécurité il est
difficile de les appliquer à des équipements tels que les Smart TV ou les lecteurs multimédias des
véhicules.
Par ailleurs, le nombre de fonctionnalités et de possibilités intégrées dans ces terminaux

complique la tâche des acteurs essayant d’améliorer leurs sécurités. Ceci est essentiellement dû au
nombre colossal de technologies utilisées augmentant le nombre de points de défaillances possibles.
Enfin, il est impossible de prétendre à une sécurité parfaite vu que chaque étape dans le processus
d’amélioration de la sécurité présente un surcoût qui peut être un handicap commercial pour le produit
final. Toutefois, quelques études du domaine reportent des points qui doivent être respectés afin
d’assurer la sécurité d’un tel système [145].
Les points suivants sont les plus importants à mettre en œuvre :
 Résistance aux attaques : Le système doit éviter les points uniques de défaillance et doit
pouvoir s’adapter à des défaillances de nœuds.
 Authentification des données : En principe, les adresses et les informations récupérées

concernant un objet doivent être authentifiées.
 Contrôle d’accès : Les fournisseurs d’information doivent être capables de mettre en œuvre
un contrôle d’accès sur les données fournies.
 Vie privée du client : Des mesures doivent être prises pour que seul le fournisseur
d’information soit le seul en mesure de consulter et utiliser les informations liées à un client
donné.
2. Solutions de sécurité
Le fait que les premières générations de systèmes embarqués impliqués dans des applications de
supervision et de contrôle ne posaient pas des problématiques liées à leurs sécurités est
essentiellement dû à l’obscurité et l’isolement physique. L’obscurité est liée au fait que ces systèmes
utilisaient des technologies propriétaires et des composants non conventionnels. Pour sa part,
l’isolement physique est garanti grâce à la déconnexion de ces équipements de toutes les
infrastructures réseau.
139
Avec l’enjeu économique grandissant des systèmes embarqués, la première forme d’attaque était
le vol de propriétés intellectuelles en utilisant des fonctionnalités auparavant disponibles dans les
circuits intégrés tels que les interfaces JTAG1 ou les bus offrant un accès à la mémoire.
D’ailleurs, la majorité des acteurs ont proposé des solutions rapides et efficaces à ces problèmes,
tels que le brouillage de code, la désactivation de l’interface JTAG ou la désactivation définitive de
l’accès externe à la mémoire. D’autre part, plusieurs fabricants essaient d’effacer ou de remplacer les
identifiants des circuits numériques afin d’augmenter la sécurité de ces derniers.
La deuxième forme d’attaque de systèmes embarqués est liée aux attaques issues des réseaux. En
effet, le but de ces attaques peut être le vol ou la corruption de données, la mise hors-service des
infrastructures utilisant ces systèmes ou tout simplement le contrôle total de ces infrastructures. La
sensibilité de ces infrastructures a incité les acteurs du domaine à proposer des solutions permettant
d’améliorer la sécurité de façon considérable.
Ces solutions ont été pour la première génération des adaptations de ce qui existait déjà en
informatique classique pour passer à une deuxième génération de solutions de sécurité entièrement
conçues pour le domaine des systèmes embarqués. Actuellement, il existe une large gamme de pare-
feu, d’algorithmes de hachage, d’algorithmes de cryptage et d’autres solutions de sécurités
spécialement conçues pour le domaine des systèmes embarqués.
3. Cryptographie
Le transfert d’information entre différents objets composant un réseau nécessite des mécanismes
de cryptage de données consistant à encoder les données dans une forme non intelligible. Le principe
du cryptage consiste à chiffrer un ensemble de données à l’aide d’une clé. Le message crypté sera
désormais inintelligible pour quiconque ne possédant pas la clé de décryptage. Ceci permet d’envoyer
le message à travers les canaux standards sans risque d’interception de données. Lors du décryptage
le destinataire devra utiliser la même clé utilisée lors du cryptage en cas d’utilisation d’algorithme
symétrique. En cas d’adoption d’algorithmes de cryptographie asymétrique, le destinataire devra
utiliser sa propre clé.
De nos jours, avec l’ubiquité de systèmes embarqués communiquant les intérêts d’intégrer des
fonctionnalités de cryptographie sur ces systèmes devient un besoin vital. Désormais, plusieurs
sociétés, universités et gouvernements essaient de proposer des solutions pouvant répondre aux
1
Joint Test Action Group
140
Chapitre 4
besoins de ce domaine en termes de cryptographie. Ces solutions se présentent sous forme

d’algorithmes, d’implémentation logicielle ou matérielle.
D’autre part, malgré les efforts fournis par ces différents acteurs sur le plan technique d’autres
travaux doivent être développés afin de vulgariser les connaissances de base en cryptographie au
niveau des utilisateurs normaux, car ces utilisateurs peuvent être une source de défaillance sécuritaire
notamment avec les techniques de social engineering.
Cryptographie symétrique
Le cryptage symétrique illustré par la Figure 59 permet d’envoyer un message nécessitant la

même clé utilisée lors du cryptage, ceci nécessite l’envoi de cette clé. Le transfert de cette clé sur le
même réseau que les données présente un risque majeur lié à son interception. Toutefois, cette
technique a l’avantage de la rapidité favorisant son adoption sur des systèmes embarqués limités en
ressources de calcul.
Clé symétrique
Message Message Message

non crypté Crypté non crypté
Encrypter Décrypter
Figure 59. Principe de fonctionnement d’un algorithme de cryptage symétrique
Cryptographie asymétrique
Cette technique parfois appelée cryptage à clé publique est couramment utilisée dans les systèmes
informatiques bancaires offrant un niveau de sécurité très appréciable. Ce genre de communications
implique l’utilisation de deux paires de clés, qui sont les clés privées et les clés publiques. Seule la
clé privée du récepteur est capable de décoder le message, ce qui minimise les risques liés à l’échange
de clés. La clé publique est uniquement utilisée lors de la phase de chiffrement du message.
141
Clé publique Clé privée
Message Message Message

non crypté Crypté non crypté
Algorithme Algorithme
de cryptage de cryptage
Côté émetteur Côté récepteur
Figure 60. Principe de fonctionnement d’un algorithme de cryptage asymétrique
Vulnérabilité des algorithmes de cryptage
La majorité des algorithmes de cryptage offrent un certain niveau de fiabilité qui peut s’effondrer
lors de la découverte de défaillance au niveau de l’algorithme. En effet, chaque algorithme de
cryptage est susceptible d’être cible d’une cryptanalyse afin de trouver ces défaillances potentielles.
Ces défaillances peuvent être exploitées pour améliorer sa sécurité ou pour diriger des attaques vers
des systèmes utilisant cet algorithme. La fiabilité d’un algorithme de cryptage doit au moins respecter
les trois premiers principes de Kerchhoff [146] qui sont :
 Le système doit être matériellement et mathématiquement indéchiffrable.

 Il faut qu’il n’exige pas le secret pouvant tomber entre les mains de l’ennemi.
 La clé doit pouvoir être communiquée et retenue sans l’utilisation de notes écrites, et être
changée ou modifiée au gré des correspondants.
4. Protocoles de sécurité
Les protocoles de sécurités permettent d’introduire des mécanismes capables d’améliorer les
caractéristiques de sécurité des nœuds tels que les aspects concernant la disponibilité, l’intégrité et la
confidentialité. Ces protocoles appliqués à travers les différentes couches de protocoles de
communication posent des contraintes liées au fait que les nœuds correspondants doivent utiliser le
même protocole. D’autre part, vu le surcoût imposé par l’introduction de ces nouveaux protocoles,
ces derniers doivent être choisis avec vigilance afin de respecter les contraintes en termes de
ressources et de consommation d’énergie liée à ces systèmes. En effet, les protocoles adoptés pour ce
genre de systèmes doivent passer un long processus d’optimisation au niveau performance et
142
Chapitre 4
empreinte mémoire afin de pouvoir être adoptés. Par ailleurs, le niveau de qualités est devenu un
point vital pour ce genre de systèmes qui nécessitent un long procédé de test et d’inspection afin de
vérifier la compatibilité avec les standards liés au domaine d’application du système en question.
Âpres avoir vécu une ère de personnalisation et d’adaptation de protocole et d’algorithmes

autrefois utilisés dans des systèmes informatiques classiques, on assiste aujourd’hui à l’émergence de
plusieurs protocoles et d’algorithmes conçus afin de répondre aux besoins liés aux systèmes
embarqués. Actuellement, il devient très difficile de recenser toutes les solutions existantes, mais il
est vital de constater la disponibilité de plusieurs implémentations matérielle ou logicielle valides et
approuvées par les fabricants de circuits intègres. Ces solutions sont disponibles sur divers niveaux
tels que le cryptage de design offert par la société Xilinx dans ces FPGA Virtex 5 ou le coprocesseur
cryptographique offert par Texas Instruments dans ces circuits CC430.
5. Filtrage de trafic
L’intrusion dans un système de contrôle est l’un des problèmes les plus effrayants qui se posent
devant les responsables d’infrastructures gérés par des systèmes embarqués. Plusieurs solutions
technologiques sont actuellement disponibles afin de minimiser ce genre de risque. Le firewall ou
mure de feux pouvant être un composant matériel ou logiciel est la solution la plus fiable permettant
de limiter le trafic entre LAN1 et WAN2 comme illustré par la Figure 61. Les technologies de firewall
actuellement disponibles nécessitent des puissances de calcul et des ressources mémoires variables.
Toutefois, ces firewalls sont parfois inappropriés au domaine des systèmes embarqués vu qu’ils
essaient essentiellement de filtrer des attaques ciblées vers de systèmes Windows, Linux ou Mac OS
sans prendre en considération la spécificité des systèmes embarqués.
Cependant, le fait que les systèmes embarqués modernes utilisent couramment des serveurs
embarqués a incité la croissance des attaques DoS qui ont enregistré une croissance de 1000 %
entre 2005 et 2010 [147]. Plusieurs travaux de recherche sur ce domaine ont permis l’apparition d’une
nouvelle génération de firewall embarqué travaillant sur les couches basses du modèle TCP/IP
comme illustré par la Figure 62. Ces firewalls sont désormais disponibles sur plusieurs formes telles
que des piles protocolaires disponibles sous forme de librairie logicielle, d’IP matériels ou de
composants autonomes pouvant être directement connectés sur tout réseau comportant des
infrastructures IdO.
1
Local Area Network
2
Wide Area Network
143
HTTP, etc... HTTP, etc..
SH/SSL SH/SSL
TDP/UDP TDP/UDP
IP IP w/Firewall
Ethernet Ethernet
Figure 62. Filtrage de trafic entre Figure 61. Filtrage de trafic au

LAN et WAN par un Firewall niveau des couches basses du modèle
TCP/IP
6. Algorithmes de hachage
Principe de fonctionnement des algorithmes de hachage
Tous les systèmes informatiques modernes utilisent un nombre énorme d’algorithmes de hachage
de façon transparente. En effet, la principale caractéristique de ces algorithmes est le fait d’associer
à un message de taille variable une valeur de longueur fixe [148]. Ces applications partent du simple
bit de parité utilisé dans la majorité des transferts de données sur divers supports de transmission
jusqu’aux fonctionnalités d’authentifications de comptes bancaires.
Le principe de fonctionnement de tout algorithme de hachage « H » est de fournir un résultat
« H (X) » d’un message X. En revanche, il doit être impossible de trouver un message « Y » qui
permet d’avoir H (Y) = H (X). Ce comportement est largement exploité pour assurer des fonctions
d’authentification, identification et de signatures telles que les applications suivantes :
 Algorithmes d’authentification
 Mécanismes de stockage de mot de passe
 Norme DSS1
 Algorithme TLS2
 Protocole de sécurité internet IPSec3
 Algorithme de génération de nombre
1
Digital Signature Standard
2
Transport Layer Security
3
Internet Protocol Security
144
Chapitre 4
Les fonctionnalités offertes par ces algorithmes présentent une solution très efficace aux
problèmes de sécurités qui touchent les systèmes embarqués modernes. Toutefois, les premières
générations de ces algorithmes souffrent d’une complexité algorithmique élevée qui présentait un
obstacle devant leurs larges adoptions dans les systèmes embarqués ayant une quantité de ressources
limitées. Actuellement, on assiste à l’apparition d’une nouvelle génération d’algorithmes de hachage
optimisée pour ce genre de plateformes. Ces algorithmes sont le résultat d’un long effort
d’optimisation et de créativité aussi bien au niveau algorithmique qu’au niveau technique
d’implémentation. Les phases de choix qualitatives et quantitatives seront discutées dans la prochaine
section de ce chapitre.
D’autre part, la principale source de défaillance de ces algorithmes est la présence de collision
qui permet d’avoir la même empreinte pour deux messages différents.
Intégrité de données
L’intégrité des données est l’un des piliers de la sécurité de tout système numérique, en effet elle
permet de confirmer que les données n’ont pas été corrompues pour n’importe quelle raison. Ces
données peuvent être endommagées lors du processus de transfert, de stockage ou par des acteurs
extérieurs essayant de détruire ou d’introduire de nouvelles données. Il devient alors indispensable
de fournir des mécanismes assurant l’intégrité des données. Les algorithmes de hachage sont la
solution la plus fiable aux problèmes d’intégrité, car ils permettent d’associer une seule signature à
un contenu donné, le moindre changement causera un changement radical de la signature. Ce
comportement est illustré par la Figure 63.
Message texte
Empreinte
Salut c’est Nabil Fonction de
20A27B40D3195T490C570
Litayem Hachage 8
Effet d’avalanche
Le moindre changement du message change l’empreinte de façon radicale
Message texte Empreinte

Salut c’est Nabil Fonction de
53B97Y35D434T922C27
Litaiem Hachage 0
Figure 63. Principe de fonctionnement d’un algorithme de hachage
145
7. Implémentation embarquée des fonctionnalités de

sécurité
Les algorithmes de cryptage, de filtrage ou de hachage couramment utilisés dans les applications
embarquées nécessitent des considérations particulières lors de leurs implémentations. Ces
implémentations sont intimement liées aux critères de choix de la plateforme matérielle ou logicielle
discutée dans le chapitre précèdent de ce manuscrit.
Le choix de l’algorithme adéquat a un impact respectable sur les performances globales du
système conçu. À titre indicatif les algorithmes de cryptage asymétriques requièrent mille fois plus
de puissance de calcul que les algorithmes symétriques. Par ailleurs, plusieurs plateformes matérielles
intègrent des fonctionnalités d’accélération de fonctionnalités cryptographiques ou carrément
intègrent une IP matérielle implémentant un algorithme de cryptographies donné.
D’autre part, les efforts entamés par les sociétés, les gouvernements et les universités commencent
à donner lieu à des solutions pouvant remédier aux divers problèmes liés à l’implémentation des
fonctionnalités de sécurité. En effet, ces travaux ont permis de produire des coprocesseurs
cryptographiques, des implémentations plus fiables, des fonctions physiquement non copiables ainsi
que diverses innovations pouvant bouleverser les concepts liés à la sécurité de ces systèmes [149].
Par ailleurs, la spécificité des systèmes embarqués permet dans plusieurs cas d’opter pour des
algorithmes élémentaires pouvant répondre à ces besoins notamment des systèmes qui bénéficient
encore d’une isolation physique.
III. Enjeu de sécurité lié aux

applications SCADA
1. Interconnexion des systèmes SCADA aux réseaux

publics
Dans le contexte actuel de l’internet des objets, les applications SCADA modernes illustrées par
la Figure 64 peuvent être considérées comme un sous-ensemble de la famille IdO. Par ailleurs, les
systèmes SCADA classiques n’ont pas été conçus avec des considérations d’accès public vue que la
seule menace possible pour la sécurité de ces systèmes était la destruction physique.
146
Chapitre 4
Divers systèmes SCADA ont été récemment interconnectés à internet afin de profiter des
possibilités offertes par ce réseau. Cette intégration nécessite la prise de plusieurs précautions de
sécurité afin de garantir l’intégrité de ces infrastructures et la sécurité des utilisateurs tout en
bénéficiant des avantages offerts par les réseaux modernes.
D’autre part, les autres objets internet modernes connectés aux mêmes réseaux ont été conçus
pour être connectés. Ce qui fait que plusieurs précautions de sécurités ont déjà été prises et qu’il existe
diverses possibilités de renforcer cette sécurité.
Ces systèmes sont considérés comme le composant fondamental de plusieurs infrastructures
critiques. Ils sont désormais constitués en utilisant une grande quantité de technologies modernes
telles que les réseaux sans fil qui représentent une nouvelle source de défaillance. En effet, de
nombreux travaux ont abordé ce problème en prouvant la possibilité d’attaque, à travers des
simulations ou des attaques réelles sur des infrastructures SCADA existantes.
Compte tenu du fait que de nombreuses failles de sécurité critiques sont bien connues pour les
attaquants potentiels, beaucoup de gouvernements investissent dans divers organismes [149]
travaillant sur la normalisation de la sécurité des réseaux industriels. Sandia National Laboratories
(USA), National Infrastructure Security Coordination Centre (UK) et British Columbia Institute of
Technology (Canada) sont les organismes les plus influents travaillant dans ce domaine. Le
Tableau 10 récapitule les attaques les plus reportées par ces organismes et leurs impacts sur le
système.
Nœud de visualisation Station de travail Station de travail

Firewall
Réseau LAN
de la Société
LAN Redondant Réseau
Ingénierie SCADA
Serveurs
SCADA
Serveur de Serveur Application
communication Historien
Server
Liens de
Serveurs communication Périphériques
Centre de contrôle indépendant
PLC
de terrain
Seria RTU RTU
l
I/O I/O
Terminal
Local
Figure 64. Architecture d’un système SCADA moderne
147
Tableau 10. Attaques courantes pouvant toucher un système SCADA

Attaque Impacte sur le système
Déni de service Retarder ou bloquer le flux de données à travers des réseaux de
contrôle
Modifications non Modification des instructions programmées dans un RTU sur des
autorisées sites distants, causant des dommages au matériel, des arrêts précipités
de processus, ou même désactivation de l’équipement.
Envoi d’informations Utilisé pour contrôler les utilisateurs du système pour dissimuler
erronées des modifications non autorisées ou d’initier des actions
inappropriées.
Modification du Obtention de résultats imprévus.
logiciel du contrôleur
Interférence Interférence avec le fonctionnement d’un système de sureté.
2. Introduction du modèle de « cloud computing »

dans les applications SCADA et besoins de sécurité
Après avoir vécu la première phase d’interconnexion avec le réseau internet à l’image des objets
internet, les systèmes SCADA sont en train de vivre une deuxième phase d’évolution consistante à
l’adoption des fonctionnalités de « cloud computing » (le terme francophone calcul dans les nuages
étant très peu adopté). Ce concept illustré par la Figure 65 permet de virtualiser un grand nombre de
ressources nécessaires au bon fonctionnement du système telles que les systèmes d’exploitation, les
logiciels de visualisation, le périphérique de stockage, les logiciels d’analyse de donnée, etc. Cette
virtualisation permet de mieux contrôler les couts des infrastructures SCADA tout en améliorant la
qualité globale du système grâce à l’adoption de composant valide et approuvé à large échelle. Le
changement majeur lié à l’adoption de cette technologie est le fait que ces données sont traitées dans
le « cloud » et non plus dans des endroits connus à priori, ce qui nécessite une attention
supplémentaire concernant les aspects de sécurité. Par ailleurs, ces nouveaux concepts sont en train
de bouleverser le modèle économique des sociétés vu qu’ils ne sont plus obligés d’acquérir des
licences onéreuses pour effectuer des tâches de supervision. Désormais, il devient possible de louer
des plateformes de supervision selon les besoins en termes de consommation. Dans le même contexte
d’évolution, on s’attend à voir le logiciel embarqué loué à partir d’un « cloud » dans un contexte de
système SCADA entièrement dans le « cloud » [150]. Enfin, les visions futures des systèmes SCADA
rendent l’assurance de sécurité une tâche fastidieuse qui doit être considérée avec soin. Cette tâche
nécessite des interventions à diverse couche afin d’assurer l’intégrité, la confidentialité et la
disponibilité des ressources. Dans le reste du manuscrit, nous nous intéresserons essentiellement au
choix d’un algorithme de hachage pouvant être adopté dans des fonctionnalités d’authentification, de
vérification d’intégrité ou la signature de données.
148
Chapitre 4
Application SCADA
basée sur le Cloud
Commandes système pour le

contrôle de trafic
Donnée transférée dans le Cloud pour le

traitement temps rées /historisation ou les
commandes
Réseau de supervision
Système de contrôle Système de contrôle
Figure 65. Système SCADA entièrement logé dans le cloud
IV. Environnement d’implémentation

faible coût faible consommation
Les systèmes impliqués dans le contexte de l’IdO utilisent divers types de plateformes matérielles
et divers types de connectivité réseau. Afin d’approcher le domaine d’application, on a réalisé un
prototype de système de supervision SCADA qui sera présenté dans ce qui suit. Ce prototype
développé comme preuve de concept permettant d’implémenter les fonctionnalités de base de tels
systèmes. Par ailleurs, les systèmes impliqués dans des applications industrielles implémentent
beaucoup plus de fonctionnalités. Heureusement, l’approche de TI était de fournir des plateformes
modulaires permettant d’intégrer des fonctionnalités en fonction du besoin ou de passer d’une
plateforme matérielle à une autre en gardant un haut niveau de compatibilité matérielle et logicielle.
149
La famille de plateformes Launchpad est l’exemple le plus impressionnant de cette approche. En

effet, cette famille est actuellement constituée de trois cartes de développement garantissant un très
haut niveau de compatibilité et de salacité. D’autre part, le marché de carte d’extensions appelées
dans le jargon de TI sous le nom de BoosterPack permet d’étendre les fonctionnalités d’une carte en
offrant un nouvel ensemble de fonctionnalités.
En effet, on peut trouver un très large ensemble de cartes BoosterPack permettant de fournir des
connectivités radiofréquence telle que Zigbee, Wi-Fi, Bluetooth, mais aussi des cartes offrant tous
type de fonctionnalités telles que des capteurs, des écrans LCD ou des interfaces de commande. Ceci
permet au concepteur d’avoir un très haut niveau de souplesse au niveau choix des calculateurs et des
interfaces utilisés. L’existence d’un nombre énorme de design de référence permet de compresser de
façon impressionnante le temps de développement.
1. Introduction aux microcontrôleurs MSP430
Connu pour sa faible consommation d’énergie, le microcontrôleur MSP430 de Texas Instruments

est largement adopté dans les applications de réseaux de capteurs/actionneurs [151]. Ce
microcontrôleur 16 bits voit ses domaines d’application s’élargir, notamment après l’introduction de
la nouvelle famille combinant des fonctionnalités innovantes, à faible coût et de faible puissance. En
effet, cette nouvelle gamme a permis de nouveaux domaines tels que le suivi médical, la sécurité et
la domotique. D’autre part, la promotion de ce composant comme un membre d’une famille complète
de microcontrôleurs produit par Texas Instruments a consolidé sa place comme un choix industriel
fiable. Les principales caractéristiques du microcontrôleur MSP430 sont résumées dans le tableau 11.
Tableau 11. Principales caractéristiques du microcontrôleur MSP430

Caractéristique Description
Architecture 16 Bit, Von Neumann
Jeu d’Instruction set 27 instructions RISC
Registres 12 registres à usage général
Mémoire Adressage de Mots16 Bit Word ou adressage par octets
Modes d’adressage Registre direct, registre indexé et registre indirect
USART, SPI, I²C, 10/12/14/16-bit ADCs, Oscillateur interne,
temporisateur, PWM, watchdog, circuiterie de reset, comparateur,
Périphériques
amplificateur opérationnel, CNA 12-bit, driver LCD, multiplicateur
matériel, USB, et DMA.
Fréquence 1Mhz- 25Mhz
Consommation
< 1 µA in IDLE mode
électrique
Mémoire sur puce 256KB Flash, 16 KB RAM
150
Chapitre 4
Texas instruments dispose d’un large éventail de versions du microcontrôleur MSP430 destiné à
divers domaines d’application, tels que les compteurs intelligents, la communication sans fil, le
contrôle moteur, la santé personnelle, etc. Pour chaque domaine d’application et chaque famille de
MSP430 Texas Instruments propose au moins une carte d’évaluation ou de développement.
Actuellement, les cartes de développement les plus appréciées sont la carte MSP-EXP430F5529,
le kit eZ430 Chronos [152] et la carte MSP430 Launchpad [153]. Les microcontrôleurs MSP430 ont
aussi l’avantage de bénéficier de l’écosystème logiciel très complet allant de l’environnement de
développement puissant comme IAR, Code Composer Studio et Energia à des bibliothèques
logicielles extrêmement optimisées comme SimpliciTI [11] ou capacitive sense library. En revanche,
les solutions MCU1 de TI sont également très rentables et évolutives. La grande variété des
microcontrôleurs Texas Instruments disponible offre la possibilité de passer facilement d’un
microcontrôleur TI à un autre.
D’autre part, Texas Instruments ne cesse d’enrichir sa gamme de contrôleurs embarqués pour
conquérir des marches très spécifiques. Une grande partie des contrôleurs récemment présentés sont
basés sur des cœurs MSP430 ce qui fait qu’ils bénéficient de tous les avantages lies a cette
architecture.
2. Carte MSP430 Launchpad
Depuis 2010, Texas Instruments a élargi sa gamme de microcontrôleurs MSP430 en introduisant

la nouvelle famille MSP430 Value Line. Cette nouvelle famille à faible coût et faible consommation
est essentiellement destinée à remplacer les anciens microcontrôleurs 8 bits. Figure 66, montre
l’architecture interne du MSP430G2553.Afin de promouvoir cette nouvelle famille, Texas
Instruments a mis en place la carte d’évaluation MSP-EXP430G2 Launchpad illustrée par la
Figure 67. Cette carte d’évaluation est une plateforme très intéressante à faible coût avec un prix de
10 $ pouvant être utilisée pour développer des applications tournant sur l’ensemble des
microcontrôleurs MSP430 Value Line.
L’architecture de la carte est basée sur trois composants qui sont le microcontrôleur MSP430, les
capteurs et les afficheurs. Le microcontrôleur, est considéré comme le cerveau de la carte vu qu’il est
responsable de la prise de décision suite à la réception de données issues de capteurs. D’autre part, le
microcontrôleur peut interagir avec des données issues de capteurs internes ou externes. En effet, les
microcontrôleurs MSP430G2X disposent de capteurs internes pouvant mesurer la température ou le
1
Microcontroller Unit
151
voltage internes. Par ailleurs, le MSP430G2X peut facilement être intégré à n’importe quel capteur
numérique pouvant fournir des données sur le bus SPI1 ou I2C2 qui sont implémentées au niveau
matériel. Les afficheurs sont présents sur la carte Launchpad sous forme de diodes LED afin de
montrer l’état des sorties. Ces sorties peuvent être récupérées afin de commander n’importe quel
dispositif.
Figure 66. Diagramme Block du microcontrôleur MSP430G2x53
Figure 67. Carte MSP430 Launchpad
Enfin, une large collection de cartes d’extension peut être ajoutée à la carte Launchpad afin
d’étendre les fonctionnalités du module Launchpad, d’ajouter des fonctionnalités de communication
radiofréquence, d’acquisition de données ou de contrôle d’un dispositif. Vu le nombre de
fonctionnalités, le faible coût et l’aspect modulaire de cette plateforme, elle peut être une candidate
très intéressante à l’étude de composants intelligents dans le contexte de l’internet des objets ou des
applications SCADA.
1
Serial Peripheral Interface
2
Inter-Integrated Circuit
152
Chapitre 4
3. RTU étudié
Fonctionnement
Afin de valider diverses fonctionnalités de système SCADA dans un environnement réel, nous
avons conçu un système physique illustré par la Figure 68 pouvant émuler une serre agricole ainsi
que le RTU qui la contrôle. Ce système est capable de fonctionner en mode autonome sans avoir à
être connecté à une interface de supervision afin de faire des tâches de régulation PID1 de la
température, d’afficher l’état du processus, mais aussi de déclencher des alarmes sonores et visuelles
si les niveaux de température sortent à l’extérieur d’une plage donnée.
Figure 68. RTU étudiée
Figure 69. Interface de supervision et de paramétrage du RTU étudié
1
Proportional, Integral, Derivative
153
D’autre part, le système est capable d’effectuer diverses tâches de supervision et de contrôle à
travers une interface graphique conçue en langage Visual Basic. Grâce à cette interface, l’utilisateur
peut ajuster les paramètres du régulateur PID, fixer la température de consigne et surveiller son
évolution au cours du temps. La Figure 69 montre quelques vues de cette interface.
Architecture
Le microcontrôleur MSP430 présenté dans la partie précédente est un des meilleurs choix pouvant
répondre à nos besoins. En effet, le MSP430G2553 qui est le cœur du système précédemment présenté
intègre un capteur de température, une interface USCI1 permettant de réaliser n’importe quelle
communication série ainsi qu’une capacité de calcul largement suffisante pour répondre aux besoins
du système conçu. D’autre part, la carte MSP430 Launchpad peut être utilisée dans les phases de
prototypage, mais aussi comme programmateur de microcontrôleur en cas de besoins de modification
du firmware.
V. Environnements d’implémentation
concurrents
Le succès foudroyant rencontré par la plateforme Launchpad MS430 a incité la société Texas
Instruments à essayer d’étendre sa gamme de produits Launchpad pour couvrir d’autres types de
microcontrôleurs. Ces derniers appartiennent à diverses familles technologiques et sont généralement
exploités dans des domaines d’application différents. Actuellement, cette famille est constituée de
quatre cartes de développement basé sur des quatre microcontrôleurs différents. Chacun de ces
microcontrôleurs a des caractéristiques uniques telles que l’économie d’énergie ou son optimisation
pour un domaine particulier telle que les applications critiques, mais toutes les cartes Launchpad
gardent les mêmes interfaces électriques.
Ceci a permis à plusieurs acteurs de proposer diverses cartes d’extension BoosterPacks pouvant
être exploitées pour étendre les fonctionnalités des cartes Launchpad. Ces cartes qui sont
essentiellement commercialisées sur le site de TI permettent d’ajouter divers types de fonctionnalités
telles que la communication sans fil, l’affichage ou le contrôle d’équipements de puissance. Cette
facilité d’ajout de fonctionnalités est l’un des plus grands moteurs de succès des plateformes
1
Universal Serial Communication Interface
154
Chapitre 4
Launchpad, car elles permettent de mettre en place des systèmes embarqués mixtes en garantissant
différentes métriques liées à ces systèmes tels que le Time To Market et à la qualité.
1. Plateforme TIVA C Launchpad
La série de microcontrôleurs Tiva_C est la toute dernière plateforme introduite par Texas
Instruments afin d’offrir un compromis entre performances, consommation d’énergie et coût. Cette
famille est basée sur l’architecture ARM Cortex M4 et bénéficie par conséquent de tous les avantages
de cette famille de microcontrôleurs, notamment son écosystème logiciel. Par ailleurs, Texas
Instruments offre l’environnement TivaWare qui est une nouvelle extension de Code Composer
Studio permettant de tirer le maximum de profil de cette nouvelle plateforme.
Comparé au microcontrôleur MSP430, Tiva_C permet de cibler des équipements plus haut de
gamme utilisés dans le contexte de l’internet des objets, notamment les nouvelles générations
d’équipements électroménagers nécessitant à la fois des performances de calcul élevées, des
interfaces graphiques attractives et un niveau de sureté élevé avec des couts compétitifs.
Pour sa part, la plateforme Tiva Launchpad tire profil de l’architecture matérielle offerte par son
processeur ARM et son écosystème, mais aussi de l’écosystème Launchpad offert par Texas
Instruments. En effet, cette plateforme de développement peut à la fois exploite les plateformes
BoosterPacks conçus pour les autres membres de la famille pour étendre ces fonctionnalités, mais
aussi de facilement récupérer les code conçus pour d’autres Launchpad vue l’unicité de
l’environnement et la similarité des architectures.
2. Plateforme C2000 Piccolo Launchpad
La famille des microcontrôleurs temps-réel de la famille C2000 est une des premières gammes de
microcontrôleurs 32 bits commercialisés par Texas Instruments. Dès ces premières générations, cette
famille a rencontré un grand succès dû au fait de sa large gamme de périphériques intégrés, ces
fonctionnalités temps-réel, son jeu d’instruction DSP et son environnement de développement.
Plusieurs cartes de développement ont été mises sur le marché par la société afin de booster l’adoption
de la plateforme dans divers domaines d’applications. Le succès de la plateforme sur le niveau
industriel a incité la société à élargir la famille au niveau fonctionnalités, mais aussi en introduisant
de nouvelles familles dérivées telle que la famille Delfino qui a permis d’intégrer un module de calcul
en virgule flottante ou la famille Hercule destinée aux applications temps réel critique. Récemment,
Texas Instruments a essayé d’améliorer cette gamme de plateformes afin d’atteindre le marché grand
155
public en introduisant la plateforme à faible coût C2000 Piccolo qui est destiné aux applications
embarquées de contrôle ne nécessitant pas de fonctions de calculs flottants. Afin d’élargir la gamme
de carte Launchpad Texas Instruents a introduit la carte C2000 Piccolo LaunchPad Experimenter
Kit, cette carte de développement construite autour du microcontrôleur temps-réel TMS320F28027
permet à la fois de répondre à des besoins de contrôle, mais aussi de traitement de signal. Sa
compatibilité avec les autres membres de la famille Launchpad permet une prise en main plus facile
ainsi qu’une grande compatibilité avec les composants matériels et logiciels conçus pour les autres
membres de la famille.
D’autre part, la spécificité du microcontrôleur au Piccolo F28027 utilise au cœur de la plateforme

et destines aux applications de contrôle offre une meilleure intégration à la suite ControlSUITE
offrant une panoplie de composant valides et approuves. Par ailleurs, ces mêmes spécificités font que
cette carte peine encore à être intégrée aux environnements de codage haut niveau telle que Energia.
3. BoosterPacks
Le fait que les interfaces des plateformes Launchpad soient standardisées a permis l’émergence
d’un grand nombre de cartes d’extension dénommées BoosterPacks. Ces plateformes développées
par la société Texas Instruments et ces collaborateurs fournissent un large éventail de cartes
d’extensions qui peuvent varier du simple module d’afficheur LED, une interface tactile pour arriver
aux modules radiofréquences. Ces derniers permettent une intégration aisée des composants TI dans
le contexte de l’Internet des Objets. D’autre part, ces modules sont livrés avec des designs de
références permettant d’avoir des applications prêtes à être personnalisées et utilisées. Ce genre
d’approche permet d’améliorer de façons considérables les aspects liés aux besoins non fonctionnels
tels que le temps de mise sur marché et la qualité. En effet, à travers ce système Texas Instruments a
favorisé la conception à base de modules ce qui permet d’accélérer de façon considérable la preuve
de concepts vu la possibilité d’intégrer des composants tout prêts avec la possibilité de les raffiner
par la suite. Par ailleurs, le fait que la spécification des premiers BoosterPacks développés par Texas
Instruments soit ouverte a incité des volontaires et des sociétés tierces à proposer les schématiques
des BoosterPacks sur divers outils tels qu’Eagle, Altium et Kicad. Pour notre domaine d’étude on a
repéré les BoosterPacks CC3000 et CC110L qui peuvent être des candidats très intéressants
permettant d’offrir des fonctionnalités de communication réseau aux différentes plateformes
Launchpad permettant leurs exploitations dans des applications IdO.
156
Chapitre 4
VI. Choix et adaptation d’un algorithme

de hachage
Le but de cette section est d’étudier les algorithmes de hachage disponibles en vue d’adopter une
implémentation appropriée comme une solution de vérification d’intégrité et d’authentification pour
notre système SCADA. Notre système est considéré comme un exemple pratique de plateforme
physique servant juste à faire des preuves de concepts. En effet, les opérations de vérification
d’intégrité et d’authentification mutuelles sont un besoin commun de tous les objets intelligents
modernes qu’ils soient impliqués dans une application M2M, SCADA ou objet IdO générique. Le but
de cette partie est de faire une revue des algorithmes de hachage pouvant être utilisés dans un système
limité en ressource afin de choisir l’algorithme adéquat à notre application. Cette étude se déroulera
en deux phases, en premier lieu nous aborderons l’aspect qualitatif reporté par les ressources
académiques disponibles puis on raffinera notre choix par une approche quantitative.
1. Étude des algorithmes de hachage légers
Notre plateforme cible étant le microcontrôleur MSP430G2553, disposant de 16 Ko de mémoire

flash, de 512 Octets de mémoire RAM et 16 MHz de fréquence maximale est une plateforme assez
contraignante pour les algorithmes de hachage classique. D’autre part, le niveau de sécurité requis est
largement inférieur à celui des applications informatiques classiques vu l’existence de barrières
physiques et l’obscurité comportementale des équipements impliqués.
Plusieurs travaux académiques ont permis de produire un nombre respectable d’algorithmes de

hachage issu de diverses écoles de recherche différentes et ayant diverses qualités et spécificités. En
effet, chaque algorithme de hachage peut être approprié à une application spécifique et une plateforme
d’implémentation particulière. D’autre part, la qualité de l’implémentation de référence, les profils
disponibles, les ressources associées et les publications scientifiques étudiant un algorithme de
hachage particulier sont des critères déterminants dans le choix de cet algorithme.
Lors de la première phase d’investigation, nous avons constaté le grand nombre d’algorithmes de
hachage disponibles. Toutefois, une grande partie souffre d’une faiblesse intolérable au niveau des
ressources associées et est parfois limité à des implémentations en langage C ou en langage Pascal.
Dans le Tableau 12 nous avons regroupé les algorithmes de hachage les plus intéressants disponibles
avec une implémentation libre.
157
Tableau 12. Algorithmes de hachage candidat à notre application

Algorithme Présentation
SHA family Représente une famille d’algorithmes de hachage publiés par le
NIST depuis 1993. SHA a beaucoup de normes dérivées telles que
SHA-0, SHA-1, SHA-3
MD4, MD5, MD6 MD est l’acronyme de Message-Digest Algorithm représente une
famille d’algorithmes de hachage largement utilisé dans les fonctions
de hachage. Cette famille développée par Ronald Rivest permet de
produire des clés de 128-bit pour MD4 et MD5, 256 bits pour MD6.
Quark Famille de fonctions cryptographiques destinées aux environnements
matériels ressources limités.
CubeHash Une fonction de hachage cryptographique très simple, conçue à
l’Université de l’Illinois à Chicago, Department of Computer
Science
Grøstl Algorithme de hachage conçu par une équipe de cryptographes de
l’Université Technique du Danemark (DTU) et TU Graz
Lane Fonction de hachage proposé dans le SHA-3 du concours NIST par
le groupe de recherche COSIC.
Shabal Fonction de hachage cryptographique présenté par le projet français
Saphir dans le concours NIST.
Spectral Hash Famille d’algorithmes de hachage basée sur la transformée de
fourrier discrète.
Keccak-f Famille d’algorithmes de hachage participant au concours NIST
SHA-3.
Whirlpool Whirlpool est une fonction de hachage recommandée par le projet
NESSIE, adoptée par l’ISO dans le cadre de la norme ISO / IEC
10118-3
UHASH UHASH est une fonction de hachage à clé, spécifiée dans la
RFC4418. La principale application de cet algorithme est dans le
code d’authentification de message UMAC.
SPONGENT Une famille de fonctions de hachage légères, connues pour leurs
faibles besoins en ressources lors d’une implémentation matérielle.
Photon Fonction de hachage légère conçue pour les appareils très limités en
ressources.
dm-present Algorithme de chiffrement/hachage par bloc ultraléger, conçu pour
les applications RFID
SQUASH Algorithme de hachage non résistant à collisions, adaptées pour les
applications RFID
Parmi les algorithmes présentés dans le tableau précédent, trois algorithmes s’avèrent très
intéressants pour notre application. En effet, les algorithmes Photon, Spongent et QUARK peuvent
répondre aux besoins de notre application tout en respectant les contraintes de la plateforme. Les
algorithmes Photon (présenté à CRYPTO2011 [154]) et Spongen (présenté à CHES2011 [155]) sont
largement inspirés de l’algorithme QUARK qui a été publié pour la première fois CHES2010 [156].
Selon les résultats obtenus par [154] et [157], QUARK est le plus approprié pour une implémentation
logicielle.
D’autre part, l’algorithme QUARK bénéficie d’une très bonne documentation, d’une
implémentation logicielle et matérielle ainsi qu’un nombre respectable de publications académiques.
Par ailleurs, QUARK possède quatre profils pouvant être appropriés à divers niveaux de performance
158
Chapitre 4
et de sécurité. Ceci nous a incités à investiguer les différents niveaux de performances et d’empreintes
mémoires des différents profils de l’algorithme QUARK.
2. Algorithme de hachage QUARK
Comme indiqué dans [158], les concepteurs d’algorithmes et protocoles cryptographiques légers
doivent choisir entre deux philosophies de conception opposées. La première consiste à créer de
nouveaux programmes à partir de zéro, tandis que la seconde consiste à réutiliser les algorithmes
disponibles en les adaptant aux contraintes du système. Cette deuxième approche a l’avantage de
garantir un certain niveau de compatibilité avec les algorithmes existants en offrant des
implémentations adaptées au domaine des systèmes embarqués.
D’autre part, l’approche visant à produire des algorithmes spécialement conçus pour les
applications embarquées a l’avantage de prendre en considération les contraintes spécifiques liées à
ces systèmes dès les phases d’élaboration de l’algorithme. Ce qui peut permettre de garantir une
meilleure adéquation algorithme/architecture. L’algorithme QUARK a été conçu dans cet esprit pour
répondre aux besoins des applications RFID.
Ces applications sont connues pour leurs très hauts niveaux de contraintes au niveau énergétique
et ressources de calculs. Les applications SCADA disposent de beaucoup plus de ressources
matérielles que les applications RFID, ce qui rend l’adoption de ce type d’algorithme une tâche
relativement aisée. La principale caractéristique de QUARK est la séparation du message en longueurs
fixe permettant de travailler avec des registres à décalage. Ceci minimise la complexité de cet
algorithme de façon très considérable, ce qui facilite son adoption à large échelle pour des
applications très limitées en puissance de calcul.
3. Évaluation de performance des différents profils de

l’algorithme de hachage QUARK sur notre RTU
Après avoir adapté les différents profils de l’algorithme QUARK pour MSP430G2553, nous avons
procédé à la mesure du temps d’exécution ainsi que l’empreinte mémoire de chaque profil de
l’algorithme. Toutes les phases d’adaptation et de compilation ont été effectuées sur l’environnement
Code Composer Studio 5.
D’autre part, les mesures des données temporelles étaient effectuées à travers la mesure d’un
signal externe récupéré sur un oscilloscope (mis à un au début de l’exécution de l’algorithme et à zéro
159
à la fin de l’exécution). Pour sa part, l’empreinte mémoire est récupérée à travers le compilateur après
exécution des phases de compilation et d’édition des liens. On doit noter que les paramètres
d’optimisation de code étaient désactivés pour tous les profils de l’algorithme.
Les résultats obtenus sont récapitulés par la figure 70 et la figure 71 récapitule le temps
d’exécution ainsi que les empreintes mémoires des différentes variantes de l’algorithme QUARK.
TEMPS D EXECUTION (MS)

2 1.902949572
1.8 1.652073352
1.6 1.486546752
1.414027149
1.4
1.2
1
0.8
0.6
0.4
0.2
0
UQUARK DQUARK SQUARK CQUARK
Figure 70. Temps d’exécution des différents profils de l’algorithme de hachage QUARK
EMPREINTE MEMOIRE (OCTET)

4400 4376
4300
4230
4188
4200
4100 4057
4000
3900
3800
Figure 71. Empreinte mémoire de différents profils de l’algorithme QUARK
160
Chapitre 4
4. Évaluation de performance des différents profils de

l’algorithme de hachage QUARK les plateformes
alternatives
Afin d’étudier les possibilités d’amélioration de performance de l’algorithme de hachage soit par
l’augmentation de fréquence du processeur étudié ou par la substitution de la plateforme MSP430 par
des plateformes plus performantes telles que le microcontrôleur Tiva_C ou le microcontrôleur
Piccolo C2000, on a procédé à l’implémentation des différents profils de l’algorithme Quark sur les
deux plateformes précédentes ainsi qu’une modification de la fréquence du microcontrôleur MSP430.
Les microcontrôleurs Tiva_C et C2000 et MSP430 sont configurés à des fréquences respectives de
80 MHz, 60 MHz et 16 MHz qui sont la fréquence maximale de ces plateformes. En effet, ces
plateformes permettent de gérer la variation de la vitesse de fonctionnement au niveau logiciel afin
d’atteindre le niveau de performance requis sans gaspiller de l’énergie, ce qui fait que les
performances obtenues reflètent les possibilités maximales de chaque plateforme.
Vu que l’augmentation de la vitesse d’exécution, les mesures ont été effectuées à travers le calcul
du temps d’exécution moyen de 1000 itérations de chaque profil de l’algorithme. Les résultats obtenus
concernant le temps d’exécution ainsi que l’empreinte mémoire sont récapitulés dans la Figure 72 et
la Figure 73.
160
141
140 134
117
120
105
100
80
60
40
21 17 21 17 23 25
18 20
20
0
Temps d’exécution sur MSP430 (uS) Temps d’exécution sur C2000 (uS)
Temps d’exécution sur Tiva_C (uS)
Figure 72. Temps d’exécution sur les plateformes MSP430, C2000 et Tiva_C
161
7000
6214 6376
6007 6022
6000
5095 5190 5212
5022
5000
4230 4376
4057 4188
4000
3000
2000
1000
0
Empreinte mémoire en octets MSP430 Empreinte mémoire en octets C2000
Empreinte mémoire en octets Tiva_C (uS)
Figure 73. Empreinte mémoire des différents profils de l’algorithme

Quark sur les plateformes MSP430, C2000 et Tiva_C
5. Analyse des résultats
Les résultats obtenus reflètent les bonnes performances obtenues par l’algorithme QUARK
indépendamment de la plateforme cible. La version allégée UQUQRK peut être très appropriée pour
les applications de réseaux de capteurs sans fil utilisant des plateformes matérielles faible coût faible
et faible consommation telle que le MSP430. En revanche, l’implémentation CQUARK permet de
garantir le meilleur niveau de sécurité. Lors de son implémentation sur des architectures embarquées
performantes telles que Tiva_C et C2000 la dégradation de performance due au passage à CQUARK
est tolérable et l’empreinte mémoire est acceptable vu les ressources mémoires disponibles sur ces
plateformes. En effet, c’est cette implémentation qui peut être la plus adoptée au domaine des
applications SCADA modernes, car elle offre un plus haut niveau de sécurité. D’autre part les
possibilités offertes par ces microcontrôleurs sont plus appropriées aux applications SCADA utilisées
dans des applications industrielles. Par ailleurs, la combinaison MSP430/UQUARK est plus
appropriée aux applications IoT utilisés dans le domaine domotique vu que les risques en termes de
sécurité sont moindres, la consommation d’énergie est vitale et que le coût est déterminant. Enfin,
les résultats obtenus pour un microcontrôleur cadencé à 1 MHz sont satisfaisants pour une application
profondément enfouie vu que pour ce type d’applications la consommation est l’un des facteurs les
plus déterminants.
162
Chapitre 4
À travers cette section on a constaté le niveau de maturité des solutions Texas Instruments qui
permet de couvrir une large gamme de solution tout en offrant des solutions facilitant la réutilisabilité
et la scalabilité. Ceci est garanti à travers un écosystème complet de composant matériel et logiciel
accessible aux développeurs a des prix extrêmement compétitifs.
VII. Conclusion
Dans cette partie, nous avons adressé les problèmes de sécurité dans les systèmes embarqués de
supervision/contrôle en tant qu’exemple de systèmes impliqués dans la nouvelle génération d’objets
interconnectés dans le contexte de l’internet des objets. On a constaté que ces systèmes deviennent
omniprésents dans notre vie courante et que la moindre intrusion peut compromettre notre vie privée,
notre sécurité ou nos biens. Après avoir abordé l’évolution de ces systèmes pour atteindre le concept
de l’internet des objets nous avons abordé les problématiques liées à leurs sécurités pour aboutir au
problème particulier lié aux algorithmes de hachage cryptographique. En effet, ces algorithmes
peuvent fournir un nombre impressionnant de fonctionnalités tels que l’authentification, la signature
numérique des données et l’identification des données et des utilisateurs. Ces fonctionnalités sont
désormais vitales dans ces systèmes couramment victimes de problèmes liés à l’usurpation d’identité.
L’ajout des fonctionnalités offertes par les algorithmes de hachage dans un RTU peut améliorer
de façon considérable son niveau de sécurité. Le large choix en termes d’algorithme de hachage, nous
a amenés à faire une étude qualitative sur les algorithmes de hachage disponibles. Cette étude nous a
permis de constater l’existence de plusieurs algorithmes pouvant répondre à nos besoins qui sont
essentiellement liés à l’économie de ressource.
L’algorithme QUARK s’est avéré un candidat sérieux bénéficiant d’une implémentation

matérielle et logicielle disponible sous licence libre avec un nombre respectable d’études
académiques utilisant cet algorithme. Afin de raffiner notre choix, nous avons procédé à une étude
pratique permettant d’évaluer la performance temporelle et les besoins en ressources des différents
profils de cet algorithme sur une architecture fortement limitée en ressources. L’utilisation de la
plateforme MSP430 comme architecture cible est liée au fait que cette architecture bénéficie d’une
réputation industrielle dans des domaines liés aux réseaux de capteurs et actionneurs ainsi que le
domaine de l’électronique médicale. L’évolution de ces domaines vers l’internet des objets a fait de
cette plateforme une des plateformes les plus intéressantes pour ce domaine.
163
Afin d’explorer les possibilités de cet algorithme ainsi que les solutions technologiques offertes
par la société Texas Instruments on a procédé à l’implémentation de l’algorithme sur les plateformes
C2000 et Tiva_C ainsi que le MSP430 tous cadences à leurs fréquences maximales. Ceci nous a
permis de fixer les limites de performances pouvant être atteintes par ces architectures, mais aussi de
voir les différentes facilités de développement offertes par Texas Instruments.
Enfin, notre travail peut être complété par une phase d’optimisation de cet algorithme afin
d’exploiter les ressources disponibles sur les différentes architectures étudiées. En effet, le fait que
l’algorithme QUARK soit basé sur l’utilisation de registres à décalage ouvre beaucoup de perspectives
permettant son optimisation sur des architectures disposant de jeu d’instruction facilitant cette
fonctionnalité. D’autre part, ce travail peut être étendu pour explorer les possibilités offertes par une
implémentation matérielle notamment qu’une implémentation matérielle de référence est déjà
disponible.
164
CHAPITRE 5 :
CONCLUSION GENERALE ET PERSPECTIVES
« Le projet est le brouillon de l’avenir. Parfois, il faut à l’avenir des centaines de brouillons. »
de Jules Renard
Extrait de son Journal
165
Conclusion Générale et Perspectives
Conclusion générale
Dans ce mémoire, la thématique conception et optimisation de systèmes embarqués dans des

applications de supervision contrôle a été abordée. Ce domaine multidisciplinaire requiert un soin
très particulier durant les différentes étapes de conception. Par ailleurs, la connaissance approfondie
des différentes tendances technologiques liées à ce domaine est nécessaire vu que chaque innovation
peut bouleverser les tendances du marché et les habitudes des consommateurs.
Ce domaine particulièrement vaste et en pleine ébullition est l’une des plus grandes sources
d’innovation durant cette décennie. Ces innovations sont en grande partie dues à la convergence de
connaissances établie et approuvée telles que le domaine des réseaux sans fil, l’électronique médicale,
les réseaux de distribution intelligents, etc. Désormais, c’est assez courant de rencontrer des
applications destinées au grand public utilisant ce combiné de technologie pour effectuer des tâches
parfois ordinaires telles que la supervision du niveau de tension artérielle.
Vu qu’il est hors propos de présenter un travail exhaustif abordant tous les aspects de ce domaine,
nous avons abordé trois aspects vitaux à prendre en considération lors de la conception de tels
systèmes. Ces aspects sont la conception à base de modèles qui est l’une des solutions les plus
appropriées liées à la gestion de la complexité de ces systèmes, l’accélération du flot de conception
et la garantie de qualité. Le choix de la plateforme matérielle et logicielle qui est l’un des piliers du
flot de conception, car il a un impact considérable sur tous les aspects ultérieurs du système
notamment la performance et le coût. Enfin, nous avons abordé les problématiques de sécurité liées
au déploiement de systèmes embarqués utilisés dans le contexte de l’Internet des objets dont le risque
d’intrusion ou de corruption de données peut avoir des répercussions considérables sur les utilisateurs
ou les infrastructures.
Les trois aspects étudiés permettent l’optimisation de façon globale du coût en ingénierie, le coût
des composants logiciels et matériels ainsi que la qualité du système.
Le travail entamé dans le contexte des systèmes embarqués de contrôle/commande nous a permis de
constater l’évolution spectaculaire de ce domaine notamment avec l’émergence des technologies liées
à l’internet des objets.
En effet, cette technologie peut être considérée comme le dernier levier technologique permettant
l’intégration des systèmes de contrôle/commande dans divers nouveaux domaines d’application.
Toutefois, cette technologie est accompagnée de plusieurs nouveaux challenges concernant la sécurité
de ces infrastructures.
166
Chapitre 5
Perspectives
Cette thèse a permis d’explorer différents aspects concernant la conception et optimisation de

systèmes embarqués. Aucune des approches présentées concernant les trois points étudiés ne
constitue une réponse définitive, plusieurs points peuvent être optimisés et améliorés dans une
approche de veille technologique. Il est par ailleurs possible d’esquisser quelques perspectives
immédiates permettant de finaliser ce travail.
 Tout d’abord, les technologies à base d’UML pour la génération de code dans une approche à
base de modèles sont devenues des candidats très intéressants. Ces technologies bénéficient
du support de l’OMG1 notamment le profil UML MARTE, qu’un grand nombre d’outils issus
du monde industriel ou du domaine de recherche commencent à supporter de façon très
efficace aussi bien pour la conception que pour la génération automatique de code. Le standard
OMG SysML, vient pour combler le manque de moyens de spécifications haut niveau de
système mixte qui est un cas assez courant des systèmes étudiés dans cette thèse. L’outil
OpenEmbeddeDD basé sur l’environnement Eclipse propose UML MARTE et SysML comme
standards pour la conception de systèmes intégrant des composants critiques.
L’investigation de ces deux standards devient indispensable pour la complétion de ce travail
afin de combler l’aspect spécification temporelle, hybride et la génération automatique de
code.
 Le fait que de nos jours les barrières entre le logiciel et le matériel sont devenues virtuelles.
La mesure de performances des plateformes cibles est devenue une tâche assez fastidieuse et
parfois introduisant des surcouts inutiles. Il est possible de compléter le travail de choix de
plateforme matérielle par une étude concernant l’estimation de performance et la génération
hauts niveaux de système. Cette dernière approche commence à avoir du succès industriel,
notamment avec les nouvelles générations de circuits FPGA et leurs outils associés.
 La sécurité et la sureté sont deux domaines technologiques relativement indépendants.
Cependant, les attaques qui ont touché des infrastructures critiques des états unis et dans
plusieurs pays européens ont montré le contraire. Le domaine de sécurité des infrastructures
de contrôle est devenu un des domaines les plus vitaux durant ces dernières années,
notamment avec l’émergence des concepts d’internet des objets et la démocratisation des
terminaux intelligents. Notre choix de travailler sur des architectures faibles coûts et faible
1
Open Management Group
167
Conclusion Générale et Perspectives
consommation est dû au fait que pour ce domaine d’activité ces deux critères sont parmi les
plus importants lors du choix d’une plateforme. Évidemment, plusieurs autres critères existent
qui sont liés au domaine d’application. Notre travail peut être complété par une étude
approfondie concernant l’authentification et le cryptage de données dans un domaine critique,
notamment les applications médicales. Ces domaines imposent d’autres contraintes qui sont
la certifiabilité du code de hachage ou de cryptage introduit.
Notre travail dans ce sens serait de proposer une application haute niveau permettant d’intégrer
des solutions de sécurité notamment de hachage et de cryptage en utilisant un outil d’ingénierie à
base de modèles. La plateforme OpenEmbedded peut être un candidat intéressant vu qu’elle supporte
déjà des outils approuvés d’ingénierie à base de modèles. Notre approche n’est pas de générer du
code de cryptage et de hachage, mais de mapper du code à des modèles en intégrant leurs modèles de
performances. Ainsi l’utilisateur n’aura plus à mesurer les performances du code, mais peut avoir une
idée sur les performances à partir du modèle.
168
Bibliographie
1. Noergaard, Tammy. "Embedded Systems Architecture: A Comprehensive Guide for Engineers and
Programmers. » Access Online via Elsevier, 2005.
2. Hudak, Paul. « Building domain-specific embedded languages. » ACM Comput. Surv. 28.4es (1996):
196.
3. Kanda, Wataru, Yu Murata, and Tatsuo Nakajima. « SIGMA System: A Multi-OS Environment for
Embedded Systems. » Journal of Signal Processing Systems 59.1 (2010): 33-43.
4. Hall, Eldon C. "Journey to the Moon: The History of the Apollo Guidance Computer. » Aiaa, 1996.
5. Flamm, Kenneth. « Moore's law and the economics of semiconductor price trends. » International
Journal of Technology, Policy and Management 3.2 (2003): 127-141.
6. Kushiki, Yoshiaki. "The Future of Embedded Software: Adapting to Drastic Change. » Computer 43.5
(2010): 0084-86.
7. Parker, Peter, and Simon Chadwick. « SCADA approaches to remote condition monitoring. » Railway
Condition Monitoring and Non-Destructive Testing (RCM 2011), 5th IET Conference on. IET, 2011.
8. Boyer, Stuart A. SCADA: supervisory control and data acquisition. International Society of Automation,
2009.
9. Robles, Rosslin John, Maricel Balitanas, and Tai-hoon Kim. "Security Encryption Schemes for Internet
SCADA: Comparison of the Solutions. »Security-Enriched Urban Computing and Smart Grid. Springer
Berlin Heidelberg, 2011. 19-27.
10. Jokela, Timo, et al. "The standard of user-centered design and the standard definition of usability:
analyzing ISO 13407 against ISO 9241-11. » Proceedings of the Latin American conference on Human-
computer interaction. ACM, 2003.
11. Sangiovanni-Vincentelli, Alberto, and Grant Martin. « Platform-based design and software design
methodology for embedded systems. » Design & Test of Computers, IEEE 18.6 (2001): 23-33.
12. TI Embedded Processing Overview,
http://www.sps.ele.tue.nl/members/B.B.A.J.Bloemendal/TI/TUE_EP_story.pdf
13. Paliwal, Prashant. An ecosystem strategy for Intel Corporation to drive adoption of its embedded
solutions. Diss. Massachusetts Institute of Technology, 2010.
14. Schoitsch, Erwin. "Design for safety and security of complex embedded systems: A unified
approach. » Cyberspace Security and Defense: Research Issues. Springer Netherlands, 2005. 161-174.
15. Touloupis, Emmanuel, James A. Flint, and D. Ward. « Safety-critical architectures for automotive
applications. » Electronic Systems and Control Division Research 2003 (2003).
16. Keutzer, K., Newton, A. R., Rabaey, J. M., & Sangiovanni-Vincentelli, A. (2000). System-level design:
Orthogonalization of concerns and platform-based design. Computer-Aided Design of Integrated
Circuits and Systems, IEEE Transactions on, 19(12), 1523-1543.
17. Motta Pires, P. S., and Luiz Affonso HG Oliveira. "Security aspects of SCADA and corporate network
interconnection: An Overview. » Dependability of Computer Systems, 2006. DepCos-RELCOMEX'06.
International Conference on. IEEE, 2006.
18. Valenzano, A., Luca Durante, and M. Cheminod. « Review of security issues in industrial networks. »
(2013): 1-1.
169
19. Tewolde, Girma S. "Current trends in low-power embedded computing."Electro/Information
Technology (EIT), 2010 IEEE International Conference on. IEEE, 2010.
20. Rana, Vincenzo, et al. « A reconfigurable network-on-chip architecture for optimal multi-processor SoC
communication. » VLSI-SoC: Design Methodologies for SoC and SiP. Springer Berlin Heidelberg,
2010. 232-250.
21. Mohanty, Sumit, and Viktor K. Prasanna. « Rapid system-level performance evaluation and
optimization for application mapping onto SoC architectures. »ASIC/SOC Conference, 2002. 15th
Annual IEEE International. IEEE, 2002.
22. Isermann, Rolf. « Mechatronic systems—innovative products with embedded control. » Control
Engineering Practice 16.1 (2008): 14-29.
23. Vaccare Braga, Rosana T., et al. « The prolices approach to develop product lines for safety-critical
embedded systems and its application to the unmanned aerial vehicles domain. » CLEI Electronic
Journal 15.2 (2012): 2-2.
24. Ben Salem, A. K., et al. « RTOS for SoC embedded control applications. »Design and Technology of
Integrated Systems in Nanoscale Era, 2008. DTIS 2008. 3rd International Conference on. IEEE, 2008.
25. Oh, Hyunok, and Soonhoi Ha. « Hardware-software cosynthesis of multi-mode multi-task embedded
systems with real-time constraints. » Proceedings of the tenth international symposium on
Hardware/software codesign. ACM, 2002.
26. Ben Othman, S., Ahmed K. Ben Salem, and Slim Ben Saoud. « MPSoC design of RT control
applications based on FPGA Softcore processors. » Electronics, Circuits and Systems, 2008. ICECS
2008. 15th IEEE International Conference on. IEEE, 2008.
27. Rodriguez-Andina, Juan J., María José Moure, and María Dolores Valdes. « Features, design tools, and
application domains of FPGAs. » Industrial Electronics, IEEE Transactions on 54.4 (2007): 1810-1823.
28. Kuon, Ian, Russell Tessier, and Jonathan Rose. FPGA architecture. Now Publishers Inc., 2008.
29. Hébert, Nicolas, et al. « A cost-effective solution to increase system reliability and maintain global
performance under unreliable silicon in MPSoC. »Reconfigurable Computing and FPGAs (ReConFig),
2010 International Conference on. IEEE, 2010.
30. Moyer, Bryon, ed. « Real World Multicore Embedded Systems. » Newnes, 2013.
31. Paiz, Carlos, and Mario Porrmann. "The utilization of reconfigurable hardware to implement digital
controllers: a review. » Industrial Electronics, 2007. ISIE 2007. IEEE International Symposium on.
IEEE, 2007.
32. Garcia, Philip, et al. « An overview of reconfigurable hardware in embedded systems. » EURASIP
Journal on Embedded Systems 2006 (2006).
33. Reddy, S. Ramanarayana. « Selection of RTOS for an efficient design of embedded
systems. » International Journal of Computer Science and Network Security 6.6 (2006): 29-37.
34. Rhodes, David L., and Wayne Wolf. « Overhead effects in real-time preemptive
schedules. » Proceedings of the seventh international workshop on Hardware/software codesign. ACM,
1999.
35. Reeves, Brian, et al. « Multi-Operating System. » U.S. Patent Application 13/217,108.
36. Kinebuchi, Yuki, et al. « Constructing a multi-os platform with minimal engineering cost. » Analysis,
Architectures and Modelling of Embedded Systems. Springer Berlin Heidelberg, 2009. 195-206.
37. Liggesmeyer, Peter, and Mario Trapp. « Trends in embedded software engineering. » Software,
IEEE 26.3 (2009): 19-25.
170
38. Stringham, Gary. « Hardware/Firmware Interface Design: Best Practices for Improving Embedded
Systems Development. » Access Online via Elsevier, 2009.
39. Penumuchu, Chowdary Venkateswara. "Simple Real-time Operating System: A Kernel Inside View for
a Beginner. » Trafford Publishing, 2007.
40. Heiser, Gernot. « The role of virtualization in embedded systems. » Proceedings of the 1st workshop on
Isolation and integration in embedded systems. ACM, 2008.
41. Handziski, Vlado, et al. « Hardware abstraction architecture. » 2007-02-22). http://www.tinyos.
net/tinyos-2. x/doc/tep2 (2012).
42. Schaefer, Stuart. « Operating system abstraction and protection layer. » U.S. Patent No. 7,028,305. 11
Apr. 2006.
43. Shanker, Abhyudai, and Somya Lal. « Android porting concepts. » Electronics Computer Technology
(ICECT), 2011 3rd International Conference on. Vol. 5. IEEE, 2011.
44. Wolf, Marilyn. « Computers as components: principles of embedded computing system design. » Access
Online via Elsevier, 2012.
45. Hamberg, Roelof, Frans Reckers, and Jacques Verriet. « Model-based design of adaptive embedded
systems. » Springer, 2013.
46. Dubois, Hubert, M. Peraldi-Frati, and Fadoi Lakhal. "A model for requirements traceability in a
heterogeneous model-based design process: Application to automotive embedded
systems. » Engineering of Complex Computer Systems (ICECCS), 2010 15th IEEE International
Conference on. IEEE, 2010.
47. Ganssle, Jack. The art of designing embedded systems. Access Online via Elsevier, 1999.
48. Sangiovanni-Vincentelli, Alberto, and Grant Martin. « Platform-based design and software design
methodology for embedded systems. » Design & Test of Computers, IEEE 18.6 (2001): 23-33.
49. Kumar, Rakesh, et al. « Heterogeneous chip multiprocessors. » Computer 38.11 (2005): 32-38.
50. Fürst, Simon, et al. "AUTOSAR–A Worldwide Standard is on the Road." 14th International VDI
Congress Electronic Systems for Vehicles, Baden-Baden. 2009.
51. DO, RTCA. « 178B (and EUROCAE ED-12), “. » Software considerations in airborne systems and
equipment certification (1993).
52. Ward, David D. « MISRA standards for automotive software. » Automotive Electronics, 2006. The 2nd
IEE Conference on. IET, 2006.
53. Voas, Jeffrey. « COTS software: the economical choice?.» Software, IEEE 15.2 (1998): 16-19.
54. Feller, Joseph, and Brian Fitzgerald. Understanding open source software development. London:
Addison-Wesley, 2002.
55. Butler, Margaret. « Android: Changing the mobile landscape. » Pervasive Computing, IEEE 10.1
(2011): 4-7
56. Felser, Max. « Real-time ethernet-industry prospective. » Proceedings of the IEEE 93.6 (2005): 1118-
1129.
57. Thomas (Tom) Stahl, and Markus Voelter. Model-driven software development. Chichester: John Wiley
& Sons, 2006.
58. Schattkowsky, Tim, and Wolfgang Muller. « Model-based design of embedded systems. » Object-
Oriented Real-Time Distributed Computing, 2004. Proceedings. Seventh IEEE International
Symposium on. IEEE, 2004.
171
59. Ingham, Michel D., et al. « Engineering complex embedded systems with state analysis and the mission
data system. » Journal of Aerospace Computing, Information, and Communication 2.12 (2005): 507-
536.
60. Jensen, Jeff C., Danica H. Chang, and Edward A. Lee. « A model-based design methodology for cyber-
physical systems. » Wireless Communications and Mobile Computing Conference (IWCMC), 2011 7th
International. IEEE, 2011.
61. Coussy, Philippe, et al. « An introduction to high-level synthesis. » Design & Test of Computers,
IEEE 26.4 (2009): 8-17.
62. Vidal, Jorgiano, et al. « A co-design approach for embedded system modeling and code generation with
UML and MARTE. » Design, Automation & Test in Europe Conference & Exhibition, 2009. DATE'09..
IEEE, 2009.
63. Isermann, Rolf. « Mechatronic systems—innovative products with embedded control. » Control
Engineering Practice 16.1 (2008): 14-29.
64. Babau, Jean-Philippe, et al. eds. "Model Driven Engineering for Distributed Real-Time Embedded
Systems 2009: Advances, Standards, Applications and Perspectives. » Wiley. com, 2013.
65. Singhoff, Frank, and C. Bureau. « Développement de systèmes embarqués temps-réel avec Ada. »
66. Lee, Insup, et al. « High-confidence medical device software and systems. »Computer 39.4 (2006): 33-
38.
67. Kornecki, Andrew, and Janusz Zalewski. "Certification of software for real-time safety-critical systems:
state of the art. » Innovations in Systems and Software Engineering 5.2 (2009): 149-161.
68. Bell, Ron. « Introduction to IEC 61508. » Proceedings of the 10th Australian workshop on Safety critical
systems and software-Volume 55. Australian Computer Society, Inc., 2006.
69. Kaplan, Aaron V., et al. « Medical Device Development From Prototype to Regulatory
Approval. » Circulation 109.25 (2004): 3068-3072.
70. Karunanithi, Mohanraj. « Monitoring technology for the elderly patient. » Expert review of medical
devices 4.2 (2007): 267-277.
71. Huhn, Michaela, and Axel Zechner. « Arguing for software quality in an IEC 62304 compliant
development process. » Leveraging Applications of Formal Methods, Verification, and Validation.
Springer Berlin Heidelberg, 2010. 296-311.
72. Bitsch, Friedemann. "Requirements on methods and techniques in perspective to approval process for
railway systems." 2nd International Workshop on Integration of Specification Techniques for
Applications in Engineering (INT’02), Grenoble, France. Vol. 193. 2002.
73. Filip, Aleš. « Safety Aspects of GNSS Based Train Position Determination for Railway
Signalling. » UIC GALILEO for Rail Symposium, Paris, France. 2007.
74. Plan, AIRE-Oceanic Demonstration. « Federal Aviation Administration. » US Department of
Transportation, Washington, DC, (May, 1983) (2010).
75. Parkinson, Paul, and Larry Kinnan. « Safety-critical software development for integrated modular
avionics. » Embedded System Engineering 11.7 (2003): 40-41.
76. Isermann, R., J. Schaffnit, and S. Sinsel. « Hardware-in-the-loop simulation for the design and testing
of engine-control systems. » Control Engineering Practice7.5 (1999): 643-653.
77. Bérard, Béatrice, et al. Systems and software verification: model-checking techniques and tools.
Springer Publishing Company, Incorporated, 2010.
172
78. Halbwachs, Nicholas, et al. « The synchronous data flow programming language
LUSTRE. » Proceedings of the IEEE 79.9 (1991): 1305-1320.
79. Bringmann, Eckard, and A. Kramer. « Model-based testing of automotive systems. » Software Testing,
Verification, and Validation, 2008 1st International Conference on. IEEE, 2008.
80. Mura, Marcello, Amrit Panda, and Mauro Prevostini. "Executable models and verification from
MARTE and SysML: a comparative study of code generation capabilities. » Proceedings of MARTE
Workshop (DATE08), Munich, Germany. 2008.
81. Engel, Avner. Verification, validation, and testing of engineered systems. Vol. 84. Wiley. com, 2010.
82. Borchert, Thomas. Code Profiling: Static Code Analysis. Diss. Karlstad University, 2008.
83. Khoroshilov, Alexey. « Open Source Certification and Educational Process. »Electronic
Communications of the EASST 20 (2009).
84. Campos, H. F., et al. "A Practical Approach for Software Engineering Teaching: A Case Study for Real
Time System Development. » Anais do XXIX Congresso da Sociedade Brasileira de Computação
(CSBC 2009)-XVII Workshop sobre Educação em Computação (WEI). 2009.
85. Amey, Peter. « A language for systems not just software. » ACM SIGAda Ada Letters. Vol. 21. No. 4.
ACM, 2001.
86. Schlager, Martin, et al. « Encapsulating application subsystems using the DECOS core OS. » Computer
Safety, Reliability, and Security. Springer Berlin Heidelberg, 2006. 386-397.
87. Prisaznuk, Paul J. « Arinc 653 role in integrated modular avionics (IMA). » Digital Avionics Systems
Conference, 2008. DASC 2008. IEEE/AIAA 27th. IEEE, 2008.
88. Ebert, Christof, and Capers Jones. « Embedded software: Facts, figures, and future. » Computer 42.4
(2009): 42-52.
89. Hazzan, Orit, and Irit Hadar. « Why and how can human-related measures support software development
processes?." Journal of Systems and Software81.7 (2008): 1248-1252.
90. Ibrahim, Abdelgadir E., Liping Zhao, and John Kinghorn. "Embedded systems development: quest for
productivity and reliability. » Commercial-off-the-Shelf (COTS)-Based Software Systems, 2006. Fifth
91. Wakabayashi, Kazutoshi, and Benjamin Carrion Schafer. « “All-in-C” Behavioral Synthesis and
Verification with CyberWorkBench. » High-Level Synthesis. Springer Netherlands, 2008. 113-127.
92. Wilking, Dirk. « Agile methods for embedded systems. » Extreme Programming and Agile Processes
in Software Engineering. Springer Berlin Heidelberg, 2005. 319-320.
93. Kwon, Soon-Bum, Hee-Yeon Cho, and Dong-Ryeol Shin. « Software development environment design
in robot device operation based on IEC61131-3. » Advanced Communication Technology (ICACT),
2010 The 12th International Conference on. Vol. 2. IEEE, 2010.
94. Davare, Abhijit, et al. « A next-generation design framework for platform-based design. » Conference
on using hardware design and verification languages (DVCon). Vol. 152. 2007.
95. Yu, Huafeng, et al. « Model transformations from a data parallel formalism towards synchronous
languages. » Embedded Systems Specification and Design Languages. Springer Netherlands, 2008. 183-
198.
96. Schulze, Christian, et al. « Real-Time Simulation of Vapour Compression Cycles. » Proceedings of the
8th International Modelica Conference. 2011.
97. [97] Wolf, Marilyn. Computers as components: principles of embedded computing system design.
Access Online via Elsevier, 2012.
173
98. [98] Westerlund, Bo. Design space exploration. Diss. thesis, Stockholm, KTH, 2009.
99. [99] Global Business Intelligence. Microprocessor Market to 2015 - Enterprise Shift to Cloud
Computing and Popularity of Mobile Computing Increasing Demand for Multi-Core Processor Chips.
2011.
100. Patel, Pourash, and Mehrdad Moallem. « Using FPGA-based platforms for embedded control
applications in Mechatronics. » Advanced Intelligent Mechatronics (AIM), 2010 IEEE/ASME
101. Monmasson, Eric, et al. « FPGAs in industrial control applications. » Industrial Informatics, IEEE
Transactions on 7.2 (2011): 224-243.
102. Grossschadl, J., Stefan Tillich, and Alexander Szekely. « Performance evaluation of instruction set
extensions for long integer modular arithmetic on a SPARC V8 processor. » Digital System Design
Architectures, Methods and Tools, 2007. DSD 2007. 10th Euromicro Conference on. IEEE, 2007.
103. John, Lizy Kurian, and Lieven Eeckhout, eds. Performance evaluation and benchmarking. CRC Press,
2005.
104. Wolf, Wayne. High-performance embedded computing: architectures, applications, and methodologies.
Morgan Kaufmann, 2010.
105. Guthaus, Matthew R., et al. « MiBench: A free, commercially representative embedded benchmark
suite. » Workload Characterization, 2001. WWC-4. 2001 IEEE International Workshop on. IEEE, 2001.
106. Henning, John L. "SPEC CPU2000: Measuring CPU performance in the new
millennium. » Computer 33.7 (2000): 28-35.
107. Embedded Microprocessor Benchmark Consortium. « EEMBC benchmark suite. » (2009).
108. Gaisler, Jiri. « A portable and fault-tolerant microprocessor based on the SPARC v8
architecture. » Dependable Systems and Networks, 2002. DSN 2002. Proceedings. International
Conference on. IEEE, 2002.
109. Rosen, Lawrence. Open source licensing. Prentice Hall PTR, 2004.
110. Massa, Anthony J. Embedded software development with eCos. Prentice Hall Professional, 2003.
111. Pelgrims, P., T. Tierens, and D. Driessens. "Overview of embedded processors: Excalibur, LEON,
MicroBlaze, NIOS, OpenRISC, Virtex II Pro. » De Nayer Instituut, Tech. Rep (2003).
112. Colin, Antoine, and Isabelle Puaut. « Worst-case execution time analysis of the RTEMS real-time
operating system. » Real-Time Systems, 13th Euromicro Conference on, 2001.. IEEE, 2001.
113. Henkel, Joachim. "Selective revealing in open innovation processes: The case of embedded
Linux. » Research policy 35.7 (2006): 953-969.
114. Weiss, Alan R. « Dhrystone benchmark. » History, Analysis,„Scores “and Recommendations, White
Paper, ECL/LLC (2002).
115. Dujmovic, Jozo J., and Ivo Dujmovic. “Evolution and evaluation of SPEC benchmarks.” ACM
SIGMETRICS Performance Evaluation Review 26.3 (1998): 2-9.
116. Assmann, Uwe. “How to uniformly specify program analysis and transformation with graph rewrite
systems.” Compiler Construction. Springer Berlin Heidelberg, 1996.
117. Hillesland, Karl, and Anselmo Lastra. “GPU floating-point paranoia.”Proceedings of GP2 (2004).
118. Proctor, Frederick M., and William P. Shackleford. “Real-time operating system timing jitter and its
impact on motor control.” Proceedings of SPIE. Vol. 4563. No. 10. 2001.
119. Hart, Darren, John Stultz, and Ted Ts'o. “Real-time Linux in real time.” IBM Systems Journal 47.2
(2008): 207-220.
174
120. Marieska, M. D., et al. "On performance of kernel based and embedded real-time operating system:
Benchmarking and analysis.” Advanced Computer Science and Information System (ICACSIS), 2011
121. Mosnier, Alain. “Embedded/real-time linux survey.” (2005).
122. Jones, M. Tim. “Anatomy of real-time Linux architectures From soft to hard real-time.” IBM developer
work 15 (2008).
123. Karim, Yaghmour, et al. “Building embedded linux systems.” (2008).
124. Ghosh, Sanjay, and Pradyumna Sampath. “Evaluation of embedded virtualization on real-time Linux
for industrial control system.”
125. Chen, Zujue, Xing Luo, and Zhixiong Zhang. “Research Reform on Embedded Linux's Hard Real-Time
Capability in Application.” Embedded Software and Systems Symposia, 2008. ICESS Symposia'08.
126. Heursch, Arnd C., et al. "Time-critical tasks in Linux 2.6: Concepts to increase the preemptability of the
Linux kernel.” Linux Automation Konferenz, Germany. 2004.
127. Kang, Dongwook, Woojoong Lee, and Chanik Park. “Kernel thread scheduling in real-time Linux for
wearable computers.” ETRI journal 29.3 (2007): 270-280.
128. Mantegazza, Paolo, E. L. Dozio, and S. Papacharalambous. “RTAI: Real time application
interface.” Linux Journal 2000.72es (2000): 10.
129. Bucher, Roberto, and Silvano Balemi. “Scilab/Scicos and Linux RTAI-a unified approach.” Control
Applications, 2005. CCA 2005. Proceedings of 2005 IEEE Conference on. IEEE, 2005.
130. Gerum, Philippe. “Xenomai-Implementing a RTOS emulation framework on GNU/Linux.” White
Paper: http://www. xenomai. org (2004).
131. Fortier, Paul J., and Howard Edgar Michel. Computer systems performance evaluation and prediction.
Access Online via Elsevier, 2003.
132. Niemi, D. C. “Unixbench 4.1. 0.”
133. Gorman, Siobhan. “Electricity grid in US penetrated by spies.” The Wall Street Journal 8 (2009).
134. Stone, Richard. “A Call to Cyber Arms.” Science 339.6123 (2013): 1026-1027.
135. Jha, Engin Kirda Somesh, and Davide Balzarotti. “Recent Advances in Intrusion Detection.” (2009).
136. Hahn, Adam, et al. "Cyber-Physical Security Testbeds: Architecture, Application, and Evaluation for
Smart Grid.” (2013): 1-1.
137. Hardy, Keiran. “WWWMDs: Cyber-attacks against infrastructure in domestic anti-terror
laws.” Computer Law & Security Review 27.2 (2011): 152-161.
138. Mo, Yilin, et al. “Cyber–physical security of a smart grid infrastructure.” Proceedings of the IEEE 100.1
(2012): 195-209.
139. Lewis, James Andrew. Assessing the risks of cyber terrorism, cyber war and other cyber threats. Center
for Strategic & International Studies, 2002.
140. Aggarwal, Charu C., Naveen Ashish, and Amit Sheth. "The Internet of Things: A Survey from the Data-
Centric Perspective.” Managing and Mining Sensor Data. Springer US, 2013. 383-428.
141. Starner, Thad. “Project Glass: An Extension of the Self.” Pervasive Computing, IEEE 12.2 (2013): 14-
16.
142. Atzori, Luigi, Antonio Iera, and Giacomo Morabito. "The internet of things: A survey.” Computer
Networks 54.15 (2010): 2787-2805.
175
143. Gubbi, Jayavardhana, et al. "Internet of Things (IoT): A vision, architectural elements, and future
directions.” Future Generation Computer Systems (2013).
144. Fahmida Y. Rashid. “Android Master Key Bug Not a Risk if You Stick With Google Play.” PCMAG
Securitywatch, Jul 2013.
145. Weber, Rolf H. “Internet of Things–New security and privacy challenges.” Computer Law & Security
Review 26.1 (2010): 23-30.
146. Nichols, Randall K., and Panos C. Lekkas. Wireless security. New York: McGraw-Hill, 2002.
147. Alan Grau. "Basics of embedded firewalls" Icon Labs, EETIMES 2012.
148. Standard, Secure Hash. "The Cryptographic Hash Algorithm Family: Revision of the Secure Hash
Standard and Ongoing Competition for New Hash Algorithms.” (2009).
149. Figure, Vinay M., Sean A. Laughter, and Ronald D. Williams. “Security issues in SCADA
networks.” Computers & Security 25.7 (2006): 498-506.
150. Kyle Wilhoit. “SCADA in the Cloud, A Security Conundrum?” Trend Micro Incorporated Research
Paper 2013.
151. Lynch, Ciaran, and Fergus O’Reilly. “Processor choice for wireless sensor networks.” Proc. ACM
Workshop on Real-World Wireless Sensor Networks (REALWSN). 2005.
152. Instrumetns, Texas. "Chronos watch information [Online] Available: http://processors. wiki. ti.
com/index. php.”
153. Unsalan, Cem, and H. Deniz Gurhan. Programmable Microcontrollers with Applications: MSP430
Launchpad with CCS and Grace. Mcgraw-hill, 2013.
154. Guo, Jian, Thomas Peyrin, and Axel Poschmann. “The PHOTON family of lightweight hash
functions.” Advances in Cryptology–CRYPTO 2011. Springer Berlin Heidelberg, 2011. 222-239.
155. Bogdanov, Andrey, et al. “SPONGENT: A lightweight hash function. »Cryptographic Hardware and
Embedded Systems–CHES 2011. Springer Berlin Heidelberg, 2011. 312-325.
156. Aumasson, Jean-Philippe, et al. ‘Quark: A lightweight hash.’ Journal of cryptology 26.2 (2013): 313-
339.
157. Balasch, Josep, et al. ‘Compact implementation and performance evaluation of hash functions in a tiny
devices.’ Smart Card Research and Advanced Applications. Springer Berlin Heidelberg, 2013. 158-172.
158. Eisenbarth, Thomas, and Sandeep Kumar. ‘A survey of lightweight-cryptography
implementations.’ Design & Test of Computers, IEEE 24.6 (2007): 522-533.
Wu, Geng, et al. ‘M2M: From mobile to embedded internet.’ Communications Magazine, IEEE 49.4
(2011): 36-43.
176
177
Contributions méthodologiques à la conception
et optimisation de systèmes embarqués
Nabil LITAYEM INSAT 2014

Mots-Clés
 Évaluation de performance  Sécurité
 Sureté  Time To market
 Internet des objets  Ingénierie à base de modèles
Résumé
Les travaux présentés dans ce mémoire se situent dans le cadre des recherches en méthodologies de conceptions de systèmes
embarqués dédiés à la supervision/contrôle. Le but de cette thèse est de proposer une méthodologie appropriée permettant
l’amélioration du cycle de conception et d’optimisation de systèmes embarqués. À travers ce travail, l’auteur essaie de présenter
l’évolution des systèmes embarqués de supervision/contrôle, des solutions méthodologiques pour la conception de ce type de
systèmes, ainsi que l’optimisation de métriques liées aux aspects non fonctionnels qui deviennent prépondérants, notamment
ceux qui sont liés à la sureté et à la sécurité de ces systèmes.
Le travail repose principalement sur quatre volets:
Évolution des technologies embarquées de supervision/contrôle : Ce volet essaie de parcourir l’évolution de ce domaine
permettant de retracer les différentes architectures disponibles pour ce type de systèmes. Ceci à travers la transmutation de
ces technologies du domaine industriel vers le domaine domotique pour aboutir à l’internet des objets. D’autre part, dans cette
section l’auteur essaie de présenter les différentes solutions technologiques aussi bien matérielles que logicielles permettant de
concevoir ce type de systèmes.
Étude de la conception à base de modèles et son application pour la conception de contrôleur embarqué : Dans cette
partie, l’auteur essaie de faire la comparaison entre plusieurs méthodologies de conception de systèmes embarqués permettant
à la fois d’optimiser les métriques liées au temps de conception, la traçabilité du produit et la certifiabilité du contrôleur final en
vue de son adoption dans une application critique. Ce travail est validé à travers l’implémentation d’un modèle DCM en utilisant
divers outils d’ingénierie à base de modèles pour une application HIL.
Choix de plateforme matérielle/logicielle, performances, fonctionnalités et outils liés : À travers cette section l’auteur
explore les différentes méthodes d’évaluation de performance afin de proposer un flot utilisant des solutions open source dans
les phases de sélection de la plateforme d’implémentation. Le flot de conception proposé est particulièrement approprié à la
conception de systèmes embarqués à base de circuit FPGA et fonctionnant sous un environnement Linux temps-réel.
Sécurité des systèmes embarqués de supervision contrôle : Dans cette partie, l’auteur détaille les problèmes et les solutions
de sécurités liés aux systèmes de supervision/contrôle qui sont actuellement considérés comme un composant essentiel de
l’internet des objets. Par la suite, il étudie le cas particulier des algorithmes de hachage et leurs applications dans ce type
d’applications. Cet exemple est complété par une étude de cas visant à choisir un algorithme de hachage adéquat pour une
plateforme à base du microcontrôleur MSP430 utilisé dans un RTU d’un système SCADA. Enfin cette étude est complétée par
une comparaison des performances obtenues par le passage à des microcontrôleurs plus performants tels que Tiva_C et Piccolo
C2000.
View publication stats

Manuscrit Thse Nabil LITAYEM

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Manuscrit Thse Nabil LITAYEM

Transféré par

Droits d'auteur :

Formats disponibles

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Contributions méthodologiques à la conception et optimisation de systèmes

Thesis · July 2014

Complex system modeling and implementation View project

The user has requested enhancement of the downloaded file.

Thèse soutenue publiquement le ` 24 Juillet 2014 ´, devant le jury composé de :

Réalisé par : Mr. Nabil LITAYEM

Thèse soutenue publiquement le ` 24 Juillet 2014 ´, devant le jury composé de :

Demande au Seigneur la force et le savoir pour les exprimer.

« Lettre d’adieux de Gabriel García Márquez »

Je tiens tout particulièrement à exprimer ma profonde gratitude à mon directeur de thèse,

J’en oublie certainement encore et je m’en excuse.

Encore un grand merci à tous pour m’avoir conduit à ce jour mémorable.

 Évaluation de performance  Sécurité

Évolution des technologies embarquées de supervision/contrôle : Ce volet essaie de parcourir

Étude de la conception à base de modèles et son application pour la conception de contrôleur

Choix de plateforme matérielle/logicielle, performances, fonctionnalités et outils liés : À

 Performance evaluation  Security

Following are the contributions:

Technological development in the area of supervision/control application: This section

TABLE DES MATIÈRES ________________________________________________________________________ 5

LISTE DES FIGURES ____________________________________________________________________________ 9

LISTE DES TABLEAUX _______________________________________________________________________ 11

INTRODUCTION GÉNÉRALE ________________________________________________________________ 17

Objectifs et enjeux de la thèse _________________________________________________________________ 20

Références liées à la thèse ____________________________________________________________________ 22

CHAPITRE 1 : ÉVOLUTION ET ENJEU DES SYSTEMES EMBARQUES

II. Évolution des systèmes embarqués ________________________________________________________ 25

IV. Systèmes embarqués de commande _______________________________________________________ 38

V. Plateforme matérielle pour système embarqué ______________________________________________ 40

VI. Plateformes logicielles pour systèmes embarqués de contrôle commande ________________________ 50

VII. Conclusion _________________________________________________________________________ 56

II. Enjeu et solutions apportées par l’ingénierie à base de modèles _________________________________ 60

III. Certification des systèmes critiques de contrôle commande ____________________________________ 63

IV. Exploitation du principe HIL ______________________________________________________________ 69

V. Implémentation d’un modèle DCM en utilisant la méthodologie MBD ____________________________ 72

IX. Conclusion ____________________________________________________________________________ 89

CHAPITRE 3 : CHOIX DE PLATE-FORME MATERIELLE/LOGICIELLE,

II. Plateforme étudiée _____________________________________________________________________ 95

III. Benchmarks utilisés ____________________________________________________________________ 98

IV. Mesure et analyse des performances _____________________________________________________ 100

V. Choix de plateforme logicielle ___________________________________________________________ 105

VI. Technologie Linux temps-réel____________________________________________________________ 113

VII. Mesure et Benchmarking des performances temps-réel ____________________________________ 117

VIII. Protocoles de communication _________________________________________________________ 126

IX. Conclusion ___________________________________________________________________________ 128

CHAPITRE 4 : SECURITE DANS LES ENVIRONNEMENTS

I. Introduction _________________________________________________________________________ 131

II. Sécurité des systèmes embarqués de contrôle ______________________________________________ 138

III. Enjeu de sécurité lié aux applications SCADA _______________________________________________ 146

IV. Environnement d’implémentation faibles coût s faible consommation___________________________ 149

VI. Choix et adaptation d’un algorithme de hachage ____________________________________________ 157

VII. Conclusion ________________________________________________________________________ 163

CHAPITRE 5 : CONCLUSION GENERALE ET PERSPECTIVES _________________________ 165

Conclusion générale ________________________________________________________________________ 166

Perspectives ______________________________________________________________________________ 167

BIBLIOGRAPHIE _____________________________________________________________________________ 169

ABS: Antilock Braking System

CAO: Conception Assistée par Ordinateur

DCS: Distributed Control System

eCos: Embedded Configurable Operating System

FAA: U.S. Federal Aviation Administration

GNU: Gnu's Not Unix

HAL: Hardware Abstraction Layer