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.
Classification des modes de défaillance
Mode défaillance
Domaine valeur
Domaine temps
En avance Omission
Erreur de
contrainte
Aléatoire
(Incontrollable)
En retard
Erreur
de
valeur
Défaillance sourde
Arrêt
Défaillance contrôlée
6.4.3 Risques et sécurité
-
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 :
o
Sécurité-innocuité dans le premier cas (Safety)
o
Sécurité-confidentialité dans le second cas (Security)
La sécurité-innocuité :
-
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é :
-
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
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é’.
Dépendabilité
Prêt à
l’usage
Disponible
Continuité
de
délivrance
du service
Fiable
Pas de
Pas
Aptitude à
conséquences Pas d’accès
être
catastrophiques non autorisé d’altération de
à
l’information
réparé
l’information
Sécuritaire
Confidentiel
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
Intègre
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.
Un système sûr de sa conception
à sa validation
Évitement
des fautes
Tolérance
aux fautes
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
Insulin reservoir
Needle
assembly
Pump
Clock
Sensor
Controller
Alarm
Display1
Display2
Power supply
Le flux de données pour un tel système peut se représenté comme suit :
Blood
Blood
parameters
Blood sugar
sensor
Blood sugar
analysis
Blood sugar
level
Insulin
requirement
computation
Insulin
Pump control
commands
Insulin
pump
Insulin
delivery
controller
Insulin
requirement
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.
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
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
Injecter
Région indésirable
Injecter
Ne pas injecter
Ne pas injecter
Région sécuritaire
Ne pas injecter
Région non sécuritaire
t1
t2
t3
Temps
6.5.6 Travail personnel
É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
12