CEG4566/CSI4541 – Conception de systèmes temps réel

CEG4566/CSI4541 – Conception de systèmes temps réel
Chapitre 6 – Vivacité, sécurité (Safety), fiabilité et tolérance aux fautes dans les systèmes
en temps réel
6.1 Introduction générale aux notions de sécurité et de vivacité
• Une propriété de sécurité indique que rien de mauvais ne peut arriver.
• Une propriété de vivacité indique qu’une bonne chose peut éventuellement arriver.
• En pratique ses notions sont implémentées par l’utilisation des threads et des moniteurs.
Notre objectif : Est de s’assurer que les deux propriétés ci-dessus sont satisfaites dans notre
système en temps réel.
6.2 Vivacité
6.2.1 Définition
Il est possible que deux processus n'arrivent jamais à se synchroniser pour une raison ou pour une
autre. Ceci peut conduire à l'absence de réalisation d'un objectif fixé sans pour autant qu'il y ait
interblocage.
Exemple: Pour réparer un chauffe-eau électrique, le plombier peut demander que l’alimentation
électrique soit correctement installée: il faut donc l'intervention préalable de l'électricien;
l'électricien peut lui exiger de ne faire les travaux que lorsque il n’y ai plus de risques et que les
problèmes de fuites d'eau seront résolus : il faut au préalable l'intervention du plombier
Les deux processus sont actifs (ils viennent régulièrement) mais ils ne font pas progresser les
choses : on est face à une activité non constructive et donc un problème de vivacité
6.2.2 Propriétés de la vivacité
Soit l’exemple suivant (d’après Jeff Magee). Un passage sur un pont à sens unique ne peut laisser
passer les voitures que sur une seule voie.
Les voitures ne peuvent avancer concurremment que ci elles vont dans la même direction.
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
1

On a un problème si deux voitures avançant dans deux directions différentes entrent sur le pont en
même temps.
Model :
- Événements ou actions intéressantes ? Entrer et Sortir
- Processus? Voitures et Pont
- Propriétés? Sens unique
- Définir chaque processus et les interactions entre processus (structure)
- const N = 3 //nombre de chaque type de voiture
- Range T = 0..N //comptage de voiture
- Range ID= 1..N //Identité de la voiture
La question est : Est-ce chaque voiture a éventuellement une chance de traverser le pont? On dit
qu’elle progresse.
La propriété de progression indique qu’il est toujours possible qu’une action va éventuellement
s’exécuter.
La progression est le contraire de la famine (nom donné à une situation où une action n’a aucune
de s’exécuter).
Choix équitable : Si un ensemble de transitions est exécuté indéfiniment souvent, alors chaque
transition de cet ensemble doit être exécutée indéfiniment souvent. Exemple : Jeter indéfiniment
une pièce en l’air, les deux faces de la pièce (pile, face) vont sortir indéfiniment souvent.
Si on applique le principe du choix équitable à notre exemple de pont, il y aura toujours
progression.
progress BLUECROSS = {blue[ID].enter}
progress REDCROSS = {red[ID].enter}
Aucune violation de la progression détectée.
Pour détecter des violations de la règle de progression, il faut soumettre le système à des
situations où le choix équitable n’est plus possible. Par exemple, une congestion du pont. Dans ce
cas on impose une règle d’ordonnancement adaptée pour éviter la famine et assurer la
progression.
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
2

Exemple d’algorithme (d’après Jeff Magee) :
Le problème est qu’il se peut que des voitures attendent aux deux extrémités du pont et que le
pont n’autorisent ni les voitures bleues ni rouges à le traverser. Si on suppose qu’on a 3 voitures
rouges et 3 bleues qui attendent, on aura le cas suivant :
red.1.request
red.2.request
red.3.request
blue.1.request
blue.2.request
blue.3.request
Solution?
Introduire une certaine asymétrie dans le problème sous la forme d’une variable booléenne (bt)
qui casse le blocage en indiquant si c’est le tour des bleues ou des rouges de traverser.
Arbitrairement on initialise bt à ‘1’ ce qui donne la priorité au bleues.
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
3

6.3 Sécurité (safety)
6.3.1 Définitions
Aptitude d’une entité à maintenir un niveau d’acceptabilité d’événement à priori redoutés pouvant
mettre en cause immédiatement ou à terme la vie de l’homme, l’intégrité de ses biens, son
environnement (c’est la probabilité que le système puisse faire apparaitre des événements définis
comme redoutés avec un niveau de risque inacceptable).
Par contre, la sureté de fonctionnement :
Caractérise l’aptitude pour un système, un produit ou une activité de satisfaire l’ensemble des
performances opérationnelles requise pour une mission donnée.
Quand on dit que la sécurité indique que rien de mauvais ne peut arriver, on sous-entend que :
- Pas d’ARRET ou de BLOCAGE (aucune transition possible)
- Pas d’ERREUR dans la détection d’un comportement erroné du système.
- Aucun état ERREUR/ARRET qui soit un état puits du système (voir RdP, chapitre II).
6.3.2 Exemple
Dans l’exemple précédent du pont à sens unique, une erreur dans la détection du comportement
erroné du système peut provoquer des conséquences catastrophiques.
Des solutions s’imposent :
- Synchronisation
- Priorité
- Exclusion mutuelle
Les conditions d’erreur indiquent ce qui n’est par requis par le système (ex : les exceptions)
Dans les systèmes complexes et critiques, on préfère spécifier clairement toutes les exigences de
sécurité on indiquant ce qui est requis par le système.
Souvent on fait ce qu’on appelle une analyse de sécurité.
Remarque :
En plus d’assurer la sécurité on doit assurer aussi la vivacité du système et une certaine sureté de
fonctionnement.
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
4

6.4 Fiabilité et tolérance aux fautes
6.4.1 Mise en situation
Dans les systèmes à grande présence de logiciel (des millions de ligne de code):
- Pour chaque million de lignes de code → 20000 erreurs (bugs)
- 90% des erreurs sont détectées lors des tests logiciels
- 200 erreurs vont apparaitre lors de la première année d’utilisation.
- 1800 erreurs vont rester non détectées.
- Et le pire c’est les erreurs dormantes !
6.4.2 Définitions
Fiabilité du logiciel :
- On ne peut pas vraiment parler de fiabilité quand in s’agit de logiciel, la fiabilité est
plutôt réserver au matériel.
- Certain la définissent comme une mesure du succès qu’a un système à se conformer à
certaines exigences de son comportement.
Défaillance du logiciel :
- C’est une déviation du système par rapport aux exigences pour lesquelles il a été
développé.
- Les défaillances résultent de problèmes internes au système qui se manifestent dans le
comportement externe du système.
- Ces problèmes sont appelés erreurs et les algorithmes qui les causent sont appelés fautes.
- 4 Sources de fautes qui peuvent conduire à la défaillance du système :
o Spécification (exigences) incorrectes.
o Erreurs de conception du logiciel.
o Erreurs matériel (processeur)
o Erreurs de communication entre sous-systèmes.
Classification des fautes :
- Transitoire : Elle apparait une fois puis disparait.
- Intermittente : Elle est transitoire et apparait périodiquement.
- Permanente : Continue d’exister jusqu’au moment où on répare la composante fautive.
Types de défaillance :
- Crash : Un serveur s’arrête de fonctionner mais jusque là il fonctionne correctement.
- Omission : Un serveur omet de répondre à une demande.
- Timing : La réponse est en dehors des limites temporelles imposées par le système en
temps réel.
- Réponse incorrect.
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
5

- Défaillance arbitraire (Byzantine) : Des réponses arbitraires sont produites à des temps
arbitraires.
Erreur de
contrainte
6.4.3 Risques et sécurité
Classification des modes de défaillance
- dans le cadre des systèmes informatiques, la sécurité doit couvrir aussi bien les nuisances
de nature aléatoire (les dangers) que les nuisances de nature volontaire (les menaces).
- Pour bien marquer cette distinction, les spécialistes de gestion des risques informatiques
utilisent les termes de :
La sécurité-innocuité :
o Sécurité-innocuité dans le premier cas (Safety)
o Sécurité-confidentialité dans le second cas (Security)
- Elle concerne l’aptitude du système à ne pas connaitre d’événements catastrophiques.
- Les dangers sont des défaillances du matériel, les défaillances du logiciel et les erreurs
humaines non intentionnelles (non malicieuses).
- Ces aspects sont traités dans le cadre de la sureté de fonctionnement.
La sécurité-confidentialité :
Erreur
de
valeur
Mode défaillance
Domaine valeur Domaine temps
En avance Omission En retard
- Elle concerne l’aptitude du système à se prémunir de la manipulation non-autorisée de
l’information à des fins malveillantes.
- Ces aspects sont traités dans le cadre de la sécurité des systèmes informatiques.
Note : Dans notre cours de système en temps réel, on ne regarde que les aspects de sureté de
fonctionnement (safety)
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
Aléatoire
(Incontrollable)
Défaillance sourde Arrêt Défaillance contrôlée
6

Exercice :
Cocher la bonne case : Sécurité-innocuité? ou –confidentialité?
6.4.4 Tolérance aux fautes
• Les systèmes embarqués, critiques et en temps réel sont toujours conçus comme étant des
systèmes ‘tolérants aux fautes’.
• La tolérance aux fautes est fortement liée aux notions suivantes : Disponibilité, fiabilité,
sécurité, sureté, maintenabilité. C’est ce qu’on appelle la ‘dépendabilité’.
Prêt à
l’usage
Disponible
Continuité
de
délivrance
du service
Fiable
Sécuritaire
Dépendabilité
Pas de
conséquences
catastrophiques
Pas d’accès
non autorisé
à
l’information
Confidentiel
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
Pas
d’altération de
l’information
Intègre
Aptitude à
être
réparé
Maintenable
7

Exemple : Une attaque cybernétique :
6.4.5 Comment construire un système en temps réel tolérant aux fautes?
Réponse 1 : Il faut construire un système sûr de sa conception à sa validation.
Évitement
des fautes
Tolérance
aux fautes
Un Un Un Un système système système système sûr sûr sûr sûr de de de de sa sa sa sa conception conception conception conception
à à à à sa sa sa sa validation validation
validation validation
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
Élimination
des fautes
Prévision
des fautes
8

Réponse 2 : Il faut prévoir des dispositions à la sécurité
Réponse 3 : Il faut intervenir à différentes étapes de la conception pour démontrer une assurance
de la conception et une assurance qualité.
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
9

6.5 Étude de cas, Pompe à insuline pour personnes diabétiques
(D’après Ian Sommerville, Software Engineering 8th edition)
6.5.1 Introduction
• Les systèmes médicaux intègrent de plus en plus des systèmes informatiques qui sont souvent
critiques. La défaillance de ces systèmes peut causer un danger pour la santé ou la vie des
patients.
• La sécurité des patients dépend du bon fonctionnement de ces équipements ainsi que de leur
exacte réponse dans le temps.
• Contrairement aux systèmes industriels, ces instrumentations biomédicales sont souvent
fortement intégrées et nécessitent une très grande précision.
6.5.2 Mise en situation
Les personnes soufrant de diabète ne sécrètent plus d’hormones naturelles pour le métabolisme
du glucose. La fonction du pancréas est remplacée par une insuline artificielle. D’où dans certains
cas la nécessité d’utiliser des pompes à insuline.
La pompe utilise un capteur qui mesure la quantité de glucose dans le sang à des intervalles de
temps réguliers. L’insuline sera injectée à des quantités qui ramènent le taux de glucose au taux
‘normal’. On observe donc, qu’on a des contraintes de temps et de précision.
Les attributs de ce type de système sont nécessairement :
- La disponibilité.
- La fiabilité
- La sécurité
- La vivacité
Question : Justifier ces trois attributs.
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
10

6.5.3 Architecture du système
Le flux de données pour un tel système peut se représenté comme suit :
Blood
Insulin
6.5.4 Algorithme
- Mesurer le taux de glucose dans le sang
- Comparer des mesures successives.
- Si le niveau de glucose augmente, alors injecter de l’insuline
- Maintenir un niveau stable de glucose
- Répéter.
Needle
assembly
Sensor
Blood sugar
sensor
Insulin
pump
Blood
parameters
Insulin reservoir
Pump Clock
Controller
Display1 Display2
Power supply
Blood sugar
analysis
Insulin
requirement
computation
Pump control
commands
Insulin
Insulin
delivery
controller
requirement
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
Alarm
Blood sugar
level
11

Note : L’injection de l’insuline ne dépend pas seulement de la quantité de glucose dans le sang
mais aussi des injections précédentes car l’action de l’insuline n’est pas instantanée. L’algorithme
de décision d’injecter de l’insuline et sa quantité est assez complexe.
6.5.5 Scénarios d’injection d’insuline
Niveau
De glucose
6.5.6 Travail personnel
Injecter
t1 t2 t3
Injecter
Ne pas injecter
Ne pas injecter
Ne pas injecter
Étudier et analyser en détail cette pompe à insuline. Décrire des architectures logicielles et
matérielles qui respectent les attributs de ce système en temps réel, embarqué et critique.
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
Région indésirable
Région sécuritaire
Région non sécuritaire
Temps
12