Avant de dérouler le reste de notre cas d’étude (réponse simplifiée à un accident nucléaire civil), nous allons nous pencher sur le paramétrage du Service d’Agilité dans ce cadre de cet exemple.
VI.3.1 L’abonnement aux événements
Dans notre cas d’étude, nous souhaitons collecter les données provenant du terrain pour suivre l’évolution de la crise (risques, populations impactées, etc.), et celles prove- nant des processus (état de l’activité, état des décisions, etc.).
Précisons que lorsque nous disons que tel élément logiciel va s’abonner à un sujet, il faut comprendre que l’abonnement est décidé et paramétré manuellement par l’uti- lisateur. Comme nous l’avons vu en Section II.2.1.4, des pistes d’automatisation des abonnements sont à l’étude.
Le moteur de CEP va s’abonner aux sujets concernant la surveillance des taux de radioactivités, de l’activité éolienne, de la température dans l’air ambiant, des états des activités des processus, etc. Les EPA du moteur de CEP (cf. Chapitre II, Section II.2.1.4) vont traiter les événements par filtrage, transformation ou application de motifs. Le détail des règles de traitement des événements est donné dans la section suivante. Les événements filtrés et/ou dérivés par les EPA vont être émis par le CEP sur deux sujets distincts : « eventField » et « eventExpected ».
L’outil de mise à jour des modèles terrain et attendu va quant à lui s’abonner aux événements dont les sujets sont « eventField » et « eventExpected ». Les événements issus de « eventField » (respectivement « eventExpected ») vont être utilisés par l’outil afin de mettre à jour le modèle terrain (respectivement attendu) de la situation collaborative. Enfin, les activités des processus vont s’abonner aux sujets d’événements qui les in- téressent : décisions du préfet, conseils de l’IRSN, etc. Les événements concernés par ces sujets vont marquer le déclenchement ou l’arrêt de certaines activités des processus.
D’autre part, le moteur de CEP ne peut traiter les types d’événement dont il ne connaît pas la structure. Ainsi, un des aspects essentiels du paramétrage d’Esper est de lui communiquer le format des événements qu’il aura à analyser (en entrée) et à générer (en sortie). Pour cela, chaque type d’événement est décrit dans le fichier es-
per.mise.cfg.xml (disponible en Annexe L). Ce fichier réalise une correspondance entre les
composants du type de l’événement (éléments, attributs) —via des expressions XPath— et les alias qui seront utilisés dans les règles CEP.
1 <xpath-property property-name="alertGravity"
2 xpath="ns18:NotificationMessage/ns18:Message/ns2:alertEvent/ns2:gravity" 3 type="string" />
CodeVI.1 – Exemple de correspondance entre composant du type d’événement et alias Le code VI.1 présente un extrait de esper.mise.cfg.xml et montre la correspondance entre l’élément gravity, fils de l’élément AlertEvent9 (décrivant le type d’événement
Alert) avec l’alias alertGravity. Cet alias va récupérer la valeur de l’élément dans l’évé-
nement et sera utilisé dans les règles portées par les EPA, permettant ainsi à Esper d’analyser l’événement reçu.
VI.3.2 Les règles métier de traitement des événements
Seule la règle métier Détection d’un incendie est détaillée dans cette section : c’est la seule concernée par les « zooms » effectués à différents moments de la situation colla- borative (t0+ 20min, t0+ 40min et t0+ 70min).
9. D’après l’expression XPath, on constate que AlertEvent est contenu dans Message, lui-même fils de NotificationMessage (qui est la notification de l’événement).
Détection d’un incendie La détection d’un incendie peut se faire en corrélant les
mesures de températures relevées par plusieurs capteurs situés à une distance raisonnable les uns des autres. La règle ci-dessous indique au service MISECep (qui encapsule le moteur de CEP Esper) qu’en cas de réception d’événements de type Mesure faisant état d’une température supérieure à 100°C et émis par deux capteurs différents (donc d’identifiants uniques différents), ces capteurs étant situés à proximité les uns des autres, dans un laps de temps de 10 minutes, alors MISECep doit créer et émettre un nouvel événement de type Alerte, indiquant une conséquence10 nommée incendie et localisée
dans le même secteur que les capteurs. A et B représentent deux événements de type
Mesure reçus par MISECep.
SI A.id �= B.id ET A.localisation ∼ B.localisation ET A.unit = °C ET B.unit = °C ET A.value � 100 ET B.value � 100
TOUTES LES 10 minutes
==>Alerte{Consequence ; Incendie_secteur_A.localisation ; A.localisation ; gra-
vite haute}
Les autres règles mises en place sont détaillées en Annexe N. La règle de détection d’un incendie est injectée dans Esper, sous la forme suivante (Figure VI.6). La règle
Figure VI.6 – Règle de détection d’un incendie écrite en EQL
écrite en EQL créé (partie (1)) un événement de type Alerte, que l’on peuple (partie
(2)) à l’aide de données statiques (comme le type) et dynamiques qui proviennent des
événements Mesure (partie (3)) qui ont satisfait les conditions de la règle. La règle est 10. Pour pouvoir ensuite faire le lien avec le modèle de la crise et mettre à jour le modèle terrain
ensuite injectée dans le moteur de traitement des événements complexes (partie (4)). Nous pouvons noter que le langage EQL est extrêmement proche du langage SQL.
VI.3.3 Les matrices de coût et d’importance, le seuil
Nous avons vu précédemment que nous définissons la divergence globale entre les modèles terrain et attendu comme étant la somme de toutes les différences δi détectées
entre les points des deux modèles. Chaque δi est le produit du coût de la différence (la
suppression d’un partenaire, l’ajout d’un risque, la modification d’une activité, etc.) et de son importance (entre un risque d’incendie nucléaire et un risque de feu de poubelle, le premier est plus important que le second).
Dans le cas de notre cas d’étude, nous avons fixé l’importance de toutes les instances à 1 étant donné le peu d’instances mises en jeu dans les modèles. Les coûts de chaque différence est défini dans le tableau ci-après (Table VI.2).
Opération
Concept Insertion Suppression Modification
Actor 1 4 3 Service 1 3 1 Risk 2 1 2 Consequence 3 1 2 Gravity Factor 2 1 2 Complexity Factor 2 1 1 Goods 1 1 2 Civilian Society 1 1 2 People 2 1 2 Natural Site 1 1 1
Table VI.2 – Matrice des coûts {opération × concept} D’autre part, les acteurs de la cellule de crise ont fixé δseuil égal à 2.
Notons que le contenu de la matrice des coûts a été décidé de façon totalement arbitraire. Il est donc possible (et même souhaitable) de faire appel à des méthodes permettant de justifier ces choix (algorithmes génétiques par exemple).