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

Transcription

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é 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é 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

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

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

4 6.3 Sécurité (safety) 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) 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

5 6.4 Fiabilité et tolérance aux fautes 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 erreurs (bugs) - 90% des erreurs sont détectées lors des tests logiciels erreurs vont apparaitre lors de la première année d utilisation erreurs vont rester non détectées. - Et le pire c est les erreurs dormantes! 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

6 - 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 Aléatoire (Incontrollable) Erreur de contrainte Erreur de valeur En avance Omission En retard Défaillance sourde Arrêt Défaillance contrôlée 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

7 Exercice : Cocher la bonne case : Sécurité-innocuité? ou confidentialité? 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 Continuité de délivrance du service Pas de conséquences catastrophiques Pas d accès non autorisé à l information Pas d altération de l information Aptitude à être réparé Disponible Fiable Sécuritaire Confidentiel Intègre Maintenable Chapitre VI - CEG4566/CSI4541 RNM SIGE UOttawa Hiver

8 Exemple : Une attaque cybernétique : 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 Élimination des fautes Tolérance aux fautes Prévision des fautes Chapitre VI - CEG4566/CSI4541 RNM SIGE UOttawa Hiver

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

10 6.5 Étude de cas, Pompe à insuline pour personnes diabétiques (D après Ian Sommerville, Software Engineering 8th edition) 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 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

11 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 sugar sensor Blood parameters Blood sugar analysis Blood sugar level Insulin Insulin pump Pump control commands Insulin delivery controller Insulin requirement Insulin requirement computation 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

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 Scénarios d injection d insuline Niveau De glucose Injecter Région indésirable Injecter Ne pas injecter Ne pas injecter Ne pas injecter Région sécuritaire Région non sécuritaire t1 t2 t3 Temps 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