ANALYSE DE RISQUE SUR UN SYSTEME DE GESTION DE CRISE RISK ANALYSIS ON A CRISIS MANAGEMENT SYSTEM

Transcription

1 ANALYSE DE RISQUE SUR UN SYSTEME DE GESTION DE CRISE RISK ANALYSIS ON A CRISIS MANAGEMENT SYSTEM Raymond MARIE IRISA Université de Rennes 1 Campus de Beaulieu Rennes Cedex France Zina BRIK et Emmanuel ARBARETIER APSYS 22 Quai Gallieni Suresnes Cedex Résumé L objectif est de simuler la performance d un système de gestion de crise : ce système de gestion de crise consiste essentiellement en un système de télécommunication intégrant des centraux d appel répartis sur un territoire géographique, permettant de recueillir et de traiter des appels d urgence dans le cas d apparition d une crise, et de diffuser des commandes d intervention afin de parer aux conséquences les plus graves. Chaque central téléphonique reçoit plus couramment des appels administratifs. De plus, les centraux téléphoniques sont répartis dans plusieurs régions et certaines peuvent être en secours les unes vis-à-vis des autres. L enjeu de cette publication est de présenter différentes approches d analyse de risque concernant la tenue en performance de ce système de gestion de crise. Summary For crisis management systems, performance is difficult do define, because these systems mainly operate in emergency cases where it is difficult to control and anticipate all values of operational parameters. This article deals with performance definition, measurement, and simulation of such systems, as well as computation of the number of objects required to produce these models. Introduction Dans la conception de systèmes de surveillance et de gestion de la sécurité globale, le besoin se présente de manière récurrente, d optimiser un processus de gestion d appels d urgence, susceptible d éviter une saturation du service et de limiter l attente des personnes en détresse. Nous passons en revue deux exemples d architectures permettant d assurer des performances opérationnelles avec des niveaux de réalisation différents. Une première série de simulations déterministes ne prenant pas en compte les modes de défaillance équipements ni les erreurs humaines ou logicielles permet déjà de mettre en évidence une meilleure résilience par rapport aux mécanismes de saturation de files d attente dans l acheminement des communications téléphoniques concernant les appels d urgences ou les appels administratifs : on alors affaire à la performance intrinsèque du système, qui permet déjà de comparer différentes architectures. Une deuxième série de simulations stochastiques permet de simuler les mêmes performances mais en prenant en compte tous les aléas de dysfonctionnement susceptibles de survenir sur les différents éléments du système, à savoir les modes de défaillances des composants hardware, les erreurs logicielles, les erreurs humaines, les agressions environnementales ou les menaces 1 Réalisation des modèles déterministes La simulation réalisée pour les deux schémas d architecture intègre la couverture de plusieurs régions territoriales. Dans la première architecture, le contrôle et la supervision des différents flux d appel sont centralisés pour toutes les régions. Dans la deuxième architecture, chaque région possède une Salle de Contrôle Centralisée (Room Control Central). Ces premières simulations ont été réalisées avec un logiciel de simulation appelé SIMUL8. Ce programme est un outil de planification, de conception, d optimisation et de réingénierie de production réelle, de logistique etc... L utilisateur peut créer un modèle informatique qui prend en compte les facteurs réels, les capacités, les taux d échec, cela englobe tous les facteurs de performance globale. Ce logiciel est développé par une entreprise privée, SIMUL8 Corporation. A partir de SIMUL8, on peut aujourd hui simuler des modèles réels grâce à des scénarios. Il utilise une dynamique de simulation discrète, cela permet de recevoir des résultats clairs et concrets ainsi que des preuves sur l efficacité du système. Il peut fournir des données statistiques en sortie ainsi que des valeurs de performance du système. Le logiciel utilise une succession de blocs, selon un schéma défini par l utilisateur pour simuler de processus. Un bloc est un outil emplacement dans la simulation, paramétrer par l utilisateur permettant de remplir une fonction simulant le plus possible la réalité. Au niveau des outils utilisés dans la simulation, il existe environ 5 types de bloc différents : Work Entry Point: Un Work Entry Point est un bloc qui génère de «flux initiaux». Il peut y avoir plusieurs points d entrée, chacun d eux pourra être défini suivant des distributions statistiques différentes. On peut aussi choisir d envoyer deux flux différents avec un unique bloc. Storage Bin: Un Storage Bin est une zone de stockage des flux, elle peut être caractérisée par différentes contraintes notamment une capacité de stockage maximum, ou une durée maximum de stockage ce qui permet une redirection éventuelle des flux par exemple. Il est possible de commencer la simulation avec une zone de stockage pré-remplis. Work Exit Point: Communication 7B-2 Page 1/11

2 Un Work Exit Point est un point de sortie de la simulation. Il peut y en avoir plusieurs suivant les différentes données que l on souhaite obtenir. On peut assimiler ce block à un compteur. On peut ainsi voir les différents résultats obtenus, pour ensuite les interpréter. Work Center: Un Work Center est une zone de travail qui permet de simuler une opération. On peut y paramétrer le temps de travail (variable ou non), la distribution des matériaux en sortie ainsi que l ordre de récupération des matériaux en entrée. Il permet aussi de créer une interface objet pouvant afficher les résultats de la simulation. Resource: Une Resource est un bloc de ressources. On peut définir le nombre de ressources dans le groupe. Il nous servira pour définir le nombre d opérateurs dans les différentes salles de contrôle. Une simulation repose sur la donnée d un temps déterminé, une horloge est présente durant la simulation, on ne peut cependant pas interagir dessus. Généralement les simulations durent 24h. Les flux initiaux sont représentés par un petit point rouge qui se déplace de bloc en bloc au cours de la simulation. En fin de processus, ils deviennent des produits. On peut utiliser le langage Visual Logic dans une simulation, notamment lorsque l on souhaite faire varier les paramètres des blocs en fonction de la saisie des données d entrée par l utilisateur, ou encore pour l acquisition des résultats. 2 Exploitation des modèles déterministes Le système d appel d urgence actuel pour la première architecture en Angleterre n est pas adapté pour des situations de crise de grande envergure. Le processus est simple, il y a de nombreuses salles de contrôle. Lorsqu une personne appelle le numéro d urgence, son appel est dirigé vers une zone d attente appelée «Call Queue», puis est transféré dans la salle de contrôle de sa localité dès qu un opérateur est disponible. Aucun transfert d appel n est possible. Voici un exemple représentant la région principale composée de 4 départements. Les points violets correspondent à l entrée d appel dans le service. Il existe deux types d entrée : les appels administratifs, les plus à gauche, et les appels d urgence les plus à droite. Tous ces appels sont directement envoyés dans la «Call Queue»(File d attente) de leur localité. Lorsqu un opérateur du standard est disponible, il reçoit l appel en attente le plus vieux. Le téléphone rouge représente le standard et le personnage vert représente les opérateurs du standard. Une fois l appel terminé, l appel est comptabilisé dans les «Calls Completed». Si une personne raccroche avant qu un opérateur ne réponde, l appel est envoyé vers l un des compteurs «Call Dropped» en passant par. Ce dernier permet simplement de regrouper les appels manqués et de le séparer suivant qu il soit d urgence ou administratif. Ce système correspondant à la première architecture n est pas fiable, car tous les standards sont indépendants. S il arrivait un accident important, le service local serait rapidement submergé d appels, tandis que les autres régions non sollicitées (pas d accident) autour auraient des flux normaux. L autre schéma d architecture envisagé consiste à remplacer tous les standards locaux par des grands centres régionaux. C est à dire qu au lieu d avoir de nombreux standards locaux à capacités très limitées, et qui peuvent être vite saturés, il y en a un moins grand nombre, chacun étant de capacité bien supérieure. Ce regroupement permet de faciliter les échanges et la communication. L idée supplémentaire de ce deuxième schéma d architecture du système est de permettre le transfert des appels vers un des autres centres régionaux, au cas où il serait saturé. Communication 7B-2 Page 2/11

3 Chaque cadre correspond au centre de contrôle d une région. Les premiers «calls queue» à gauche ne correspondent qu à une duplication des appels entrants de la simulation du premier schéma d architecture. Cela permet d avoir exactement les mêmes contraintes sur les deux systèmes. Les appels sont ensuite séparés entre les appels administratifs et les appels d urgence grâce à un système de Switch. Les appels d urgence et administratif sont stockés dans deux Call Queues. Les appels d urgence sont traités de manière prioritaire. Tous les appels sont ensuite renvoyés au standard par ordre chronologique, c est l appel le plus ancien qui est reçu en premier. Une fois l appel réalisé, il est comptabilisé parmi les appels traités entièrement. En ce qui concerne le traitement des appels d urgence, si l attente devient trop longue les appels sont envoyés dans une seconde zone d attente. Il y a ensuite autant de possibilités que de régions, l appel est en effet en attente d une réponse de la part d une des autres régions ; il n est plus spécifique à une région mais peut être transféré directement vers un opérateur du standard d une autre région. Si une personne raccroche avant que son appel soit reçu, alors elle est envoyé vers le compteur «Call Dropped». Un paramètre de donnée d entrée modifiable et concernant les centres de gestion des appels de régions consiste par exemple en le nombre d opérateurs au standard. Egalement pour chaque standard élémentaire du premier schéma, une variable d entrée modifiable est le nombre d opérateurs au standard, cette valeur est bornée entre 1 et 30. Pour définir la situation des appels dans chaque région, on dispose de 6 données d entrées : - La moyenne d appels en situation normale par heure. - La moyenne d appels en situation de crise par heure. - La date de début de crise en heure et minute. - La durée de la courbe croissante de la crise en heure et minute. - La durée de la crise à sa valeur maximale, en heure et minute. - La durée de la courbe décroissance de la crise avant le retour à la normale en heure et minute. Communication 7B-2 Page 3/11

4 La représentation graphique ci-dessous montre un exemple de variation des données d entrées. Ceci n est qu un exemple, il est possible d imaginer une courbe présentant d autres caractéristiques dynamiques. C est donc ainsi que peut être décrite ou paramétrée de manière pertinente une situation de crise pour un système d appel d urgence. Les valeurs suivantes sont issues d informations recueillies sur internet et correspondant à différents motifs d appel d urgences en Europe. Il résulte des résultats quantitatifs obtenus que le deuxième schéma B d architecture possède de nombreux avantages par rapport au premier schéma A. Le schéma B est plus performant que le système A car les centres d appels sont plus regroupés, la répartition des appels est donc plus centralisée, c est-à-dire qu au lieu d avoir par exemple 5 opérateurs pour un centre d appels local, il y a 25 opérateurs dans un centre d appel régional. Communication 7B-2 Page 4/11

5 Les opérateurs sont donc plus disponibles à répondre à une crise de grande envergure. De plus le principe de transfert d appels garantit une nouvelle fois l acheminement complet de tous les appels entrants. Le schéma B comprend cependant les inconvénients de ses avantages ; si l un des centres subit par exemple une attaque, ou rencontre un problème technique plus important, c est une région beaucoup plus grande qui semble affectée. Cependant les appels ont encore la possibilité d être transférés dans les autres centres régionaux. Le cycle de vie d un appel est représenté par le graphe d état suivant : 300 sec Completed by C01 staff 300 sec Completed by C01 staff 300 sec Completed by C02 staff Waiting_999 Transferred 300 sec Completed by C03 staff Incoming call Not transmitted 10 sec 300 sec 180 sec Dropped Completed Waiting admin Dropped 180 sec Communication 7B-2 Page 5/11

6 3 Réalisation des modèles stochastiques La réalisation de ces modèles est réalisée avec l atelier SIMFIA de la société APSYS. Le langage du module SIMUL est basé essentiellement sur le langage AltaRica Data-Flow. Ce dernier est basé sur le formalisme des automates à états finis. C est un langage hiérarchique, où presque toutes les constructions syntaxiques ont une représentation graphique analogue. Une série d expériences ont montré que le langage AltaRica est très approprié pour la description d un grand nombre de systèmes. Bien qu AltaRica soit principalement consacré aux études de fiabilité et de sécurité, c est un langage de description objet. Il généralise les formalismes de description les plus utilisés tels que les réseaux de Petri, ou les blocs diagramme. Le langage de SIMFIA est adapté à la description fonctionnelle et dysfonctionnelle nécessaire à une exploitation efficace des modèles. Il convient parfaitement à la simulation d'un modèle par l'utilisation d'automate à états finis. Ainsi sous SIMFIA, il est possible d'assimiler un bloc fonctionnel, ayant des états dégradés, à un automate dont le fonctionnement peut être directement simulé. L utilisation de ce langage permet de retrouver au sein du même modèle des comportements statiques ou dynamiques, déterministes ou aléatoires. Communication 7B-2 Page 6/11

7 Transitions d un modèle Une des caractéristiques les plus importantes de l'interface SIMUL est qu'elle permet de simuler pas à pas le comportement du modèle qui vient d être saisi. Il est ainsi plus facile de comprendre, de corriger ou d'expliquer un modèle. Exemple de simulation La simulation Monte-Carlo offre une approche différente de l'exploitation des modélisations SIMFIA. Elle permet d'effectuer les propagations en tenant compte de l'écoulement du temps (temps de reconfiguration notamment). La simulation Monte-Carlo en tiendra compte en tirant des durées au hasard, respectant la loi de distribution, et jouera ainsi un grand nombre d'histoires différentes. De plus, le langage AltaRica permet de créer un indicateur adapté au besoin : L évaluation temporelle, moyenne ou par période de tout indicateur créé par l utilisateur. Le nombre de fois où un indicateur ou un prédicat (qui est supposé booléen) est réalisé tout au long du scénario. L instant de la nième réalisation du prédicat. La valeur de l indicateur ou du prédicat à la fin du scénario. La valeur pondérée de l indicateur ou du prédicat à travers le scénario,.i.e l espérance mathématique de ses valeurs. Communication 7B-2 Page 7/11

8 Pour notre centre d appel les différentes serveurs d appels sont modélisés par des «automates semblables» : ils ont une stratégie de traitement différente pour les différents types d appels ; on peut configurer la loi temporelle décrivant le temps de traitement de ces appels ainsi que les temporisations conditionnant le transfert d un appel d un serveur à un autre, ou d une région à ne autre lorsque tous les serveurs d une région sont occupés. La figure suivante montre de manière «compressée» tous ces mécanismes de comportement à modéliser pour chacun des serveurs. Communication 7B-2 Page 8/11

9 En outre, en fonction du volume et de l intensité des flux d appels, le nombre de processus élémentaires ALTARICA utiles et nécessaires pour une simulation fidèle et cohérente de l ensemble des mécanismes élémentaires du système dépendant du temps peut connaître des variations importantes ; une approche algorithmique «amont» a donc été mise au point, afin de pouvoir optimiser la granulométrie et le découpage du modèle. Une heuristique, permettant de définir dynamiquement une configuration des objets du modèle, et utilisant le critère suivant a été mise en place : n N0 = Min( n / p( j, λ T) 1 ε ) {1} n j= 0 Où n est le nombre de sollicitations simultanées du système, et T est la fenêtre temporelle conditionnant une perte d appel du système. Lorsque cette condition est vérifiée, la région concernée se voit associer «n» objets modélisant un éventuel traitement d appel, et l on est sûr à ε près que des appels en nombre excédentaire par rapport en «n» mais n attendant néanmoins de bénéficier d un processus de traitement depuis un temps inférieur à T, ne sera pas détourné avec une autre région. Par rapport à ce qui suit, on désigne par K la valeur K = n + r où le modèle de région est assimilé à une file d attente M/M/r/K. µ Λ Min où Π K1 3 On peut chercher K 1 tel que ( K1/ Π K 1 10 ) saturée, c est-à-dire qu il y ait désigne la probabilité que la file d attente soit On peut chercher K 2 tel que K2 r 5 Timeout r µ K 2-r désigne alors le nombre de places d attentes. Ce qui fournit Timeout K = r Tservice 2 car µ = 1 Tservice Le coefficient 5 a été adopté ici au titre d un coefficient de sécurité. Cette heuristique préconise l adoption de la valeur K = min (K 1, K 2). 4 Exploitation des modèles stochastiques En prenant en compte les défaillances des équipements, pour chaque région modélisée on obtient : - le pourcentage d appels d urgence traités - le pourcentage d appels d urgence perdus - le pourcentage d appels administratifs traité Le listing suivant montre la comparaison entre la valeur des performances intrinsèques et celle des performances opérationnelles : Communication 7B-2 Page 9/11

10 Communication 7B-2 Page 10/11

11 Conclusion L avantage de cette approche basée sur la modélisation est la possibilité de pouvoir «débrayer» au sein du modèle des événements de nature différente : - sans prise en compte des défaillances ou des erreurs humaines, on a des limitations en performance dues au seul comportement hératique de la situation de crise : les résultats ont été compatibles avec les simulations effectués avec les concepteurs à partir d autres outils de simulation - sans prise en compte des erreurs humaines, on obtient des performances de sûreté de fonctionnement technique - avec prise en compte de tous les événements, on se rapproche de performances opérationnelles réelles du système ALTARICA présente également l avantage de donner accès à beaucoup d autres indicateurs de performance : - temps de reprise d une situation de crise d un centre à l autre - délai bout en bout de règlement de la crise - Il est particulièrement bien adapté pour évaluer et différencier les performances soumises à différents niveaux d aléas et en particulier les aléas exceptionnels dus à l environnement opérationnel dans le cadre du niveau de charge en utilisation, lié au dépassement des gabarits prévus par les concepteurs, ce qui nous ramène aux situations de crise Références Christophe Kehren. Motifs formels d'architectures de systèmes pour la sûreté de fonctionnement. Thèse de l'ecole Nationale Supérieure de l'aéronautique et de l'espace (SUPAERO), 2005 Claire Pagetti. Extension temps réel d'altarica. Thèse de l'ecole Centrale de Nantes - ECN Université de Nantes, 2004 André Arnold, Alain Griffault, Gérald Point and Antoine Rauzy. AltaRica: Manuel méthodologique, 2005 Communication 7B-2 Page 11/11