Post on 17-Mar-2021
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
1
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
2
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
3
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
4
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
5
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
6
- Défaillance arbitraire (Byzantine) : Des réponses arbitraires sont produites à des temps arbitraires.
Classification des modes de défaillance
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)
Aléatoire (Incontrollable)
Erreur de contrainte
Erreur de
valeur
Mode défaillance
Domaine valeur Domaine temps
En avance Omission En retard
Défaillance sourde Arrêt Défaillance contrôlée
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
7
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é
Fiable
Continuité de
délivrance du service
Sécuritaire
Pas de conséquences
catastrophiques
Confidentiel
Pas d’accès non autorisé
à l’information
Intègre
Pas d’altération de l’information
Maintenable
Aptitude à être
réparé
Disponible
Prêt à l’usage
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
8
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
Élimination des fautes
Tolérance aux fautes
Prévision des fautes
Un système sûr de sa conceptionUn système sûr de sa conceptionUn système sûr de sa conceptionUn système sûr de sa conception à sa validationà sa validationà sa validationà sa validation
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
9
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
10
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
11
6.5.3 Architecture du système
Le flux de données pour un tel système peut se représenté comme suit :
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.
Insulinrequirementcomputation
Blood sugaranalysis
Blood sugarsensor
Insulindelivery
controller
Insulinpump
Blood
Bloodparameters
Blood sugarlevel
Insulin
Pump controlcommands Insulin
requirement
Needleassembly
Sensor
Display1 Display2
Alarm
Pump Clock
Controller
Power supply
Insulin reservoir
Chapitre VI - CEG4566/CSI4541 – RNM – SIGE – UOttawa – Hiver 2013
12
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
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.
Temps
Niveau De glucose
Région non sécuritaire
Région sécuritaire
Région indésirable
t1 t2 t3
Injecter Injecter
Ne pas injecter
Ne pas injecter
Ne pas injecter