Chapitre 4 : Problématiques
d'un système embarqué
Notions des systèmes embarqués critiques,
systèmes embarqués temps réel.
Sources de contraintes de temps dans un système embarqué.
Conséquences de dégradation du fonctionnement,
Notion de chien de garde,
Sureté
Notions des systèmes embarqués critiques,
• Un système critique est un système dont une panne peut avoir des
conséquences dramatiques, tels des morts ou des blessés graves, des
dommages matériels importants, ou des conséquences graves pour
l’environnement. Par opposé, un système non critique va correspondre
aux applications dédiées aux loisirs (les jeux vidéos par exemple). Ainsi,
sont par exemple critiques les logiciels intervenant dans :
les systèmes de transport : pilotage des avions, des trains, logiciels
embarqués automobiles ;
la production d’énergie : contrôle des centrales nucléaires ;
la santé : chaînes de production de médicaments, appareil médicaux (à
rayonnement ou contrôle de dosages) ;
le système financier : paiement électronique ;
les applications militaires.
Evaluer le niveau de criticité
Prenons l’exemple de l’aviation. En aviation, la norme DO-178B
sépare les logiciels avioniques en 5 catégories :
• niveau A : un dysfonctionnement du logiciel provoquerait ou
contribuerait à une condition de perte catastrophique de l’appareil ;
• niveau B : un dysfonctionnement du logiciel provoquerait ou
contribuerait à une condition dangereuse ou un dysfonctionnement
sévère et majeur de l’appareil ;
• niveau C : un dysfonctionnement du logiciel provoquerait ou
contribuerait à un dysfonctionnement majeur de l’appareil ;
• niveau D : un dysfonctionnement du logiciel provoquerait ou
contribuerait à un dysfonctionnement mineur de l’appareil ;
• niveau E : aucun impact sur le fonctionnement de l’appareil ou la
charge de travail du pilote.
Des contraintes particulières de
développement
Les précautions à prendre dans le développement d’un logiciel critique sont
généralement fixées par une norme, et dépendent du domaine d’application et surtout
de la criticité du logiciel. Généralement, on trouve des impératifs :
• de documentation : tous les composants doivent être documentés, notamment dans
l’interface qu’ils présentent aux autres composants ;
• de traçabilité : le système doit répondre à chaque spécification, soit dans sa mise en
œuvre, soit dans des spécifications intermédiaires (auquel il faudra aussi répondre) ; on
doit donc avoir une chaîne complète de traçabilité entre les spécifications fonctionnelles
et la mise en œuvre du système ;
• de limitation des pratiques dangereuses : certaines techniques de programmations,
sources possibles de problèmes, sont interdites, ou du moins leur usage doit être justifié
par des raisons impératives (ex: allocation dynamique de mémoire, procédures
récursives) ;
• de test : on devra essayer le logiciel dans un grand nombre de configurations, qui
couvrent tous les points et un maximum des chemins de fonctionnement du programme
;
• d’utilisation d’outils de développement et de vérification eux-mêmes sûrs.
systèmes embarqués temps réel
Un système temps réel se compose d'un ou
plusieurs sous-systèmes devant répondre en un
temps fini et spécifié à des stimuli générés par le
monde extérieur
Une réponse hors échéance est invalide
Même si son contenu semble correct
Un contrôleur de vitesse pour voiture, une
machine à laver, un pilotage automatique de TGV,
une centrale nucléaire, un système international de
routage aérien, etc.
Sources de contraintes de temps dans un
système embarqué
Les contraintes temporelles qui sont classiquement
présentées sont des contraintes de bout en bout, appelées aussi
contraintes de latence. Ces contraintes représentent le délai
maximal entre lecture de l’état du système (lecture des capteurs)
et commande de celui-ci (commande des actionneurs).
Le respect du protocole de communication avec les
capteurs, actionneurs, ou bus de communication est une autre
source, très importante, de contraintes temporelles. Ainsi, à
chaque fois qu’une trame est disponible sur un réseau, le système
doit la lire et soit la traiter, soit la stocker pour traitement
ultérieur, sous peine de la voir être remplacée (ou « écrasée »)
par la trame suivante.
Conséquences de dégradation du
fonctionnement
De nombreuses méthodes et outils ont été développés pour faire face à la complexité
croissante des systèmes embarqués. Malgré cela, une méthodologie avec une démarche
systémique est nécessaire pour passer du simple cahier des charges, qui exprime les
besoins et exigences, à la réalisation du produit final.
Les études montrent que les principaux défauts de conception sont dus à:
• des besoins mal spécifiés ou exigences mal formulées,
• une évolution des besoins/exigences dans le temps,
• une modification spontanée, parfois faite avec de bonnes intentions,
• la non accumulation de savoir-faire et manque de retour d’expérience,
• au pari technologique,
• une définition erronée d’interfaces,
• la pression de la concurrence,
• une extension d’exigences fonctionnelles.
Traditionnellement, dans la conception des systèmes, chaque fonction pouvait être étudiée
et développée indépendamment des autres et l’implication de la sûreté de fonctionnement
se résumait à la réutilisation de modèles génériques issus du retour d’expérience.
Sécurité vs. sûreté de fonctionnement
• Sûreté de fonctionnement (Dependability) : propriété qui
permet aux utilisateurs du système de placer une confiance
justifiée dans le service qu’il leur délivre Plusieurs facettes •
Disponibilité (Availability) : aptitude du système à être prêt à
délivrer un service correct
• • Fiabilité (Reliability) : aptitude du système à assurer la
continuité du service correct durant un certain laps de temps
• • Sécurité-innocuité (Safety) : aptitude du système à éviter des
conséquences catastrophiques sur son environnement •
Sécurité (Security) : aptitude du système à préserver la
confidentialité et l’intégrité des informations
• • Maintenabilité (Maintainability) : aptitude du système à être
maintenu ou remis en état de fonctionnement
