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