Etude du comportement en-ligne

La section précédente nous a permis de voir comment l’on pouvait précalculer le test de la violation de la propriété d’accessibilité des états finals. Un plus petit symptôme d’erreur correspond à une trace dont tout préfixe stricte est exécutable et telle soit la trace est non exécutable sur l’automate, soit son état de destination est non co-accessible.

Le détecteur est naturellement activé chaque fois qu’un événement se produit. En effet, tout événement provoque a priori un changement de classe. Ceci correspond poten- tiellement à l’observation d’un plus petit symptôme d’erreur. Le détecteur peut alors véri- fier que l’événement observé correspond à une transition autorisée de l’automate grâce à l’abstraction temporelle. Il reste à s’assurer du réveil du détecteur lorsque l’exécution en cours correspond à un plus petit symptôme d’erreur finissant par une durée. Pour pallier le fait que le processus d’observation ne se réveille qu’à chaque occurrence d’un événe- ment, il est possible de plannifier dans le bloc d’analyse la capture et le signalement d’un tel symptôme en utilisant une projection dans le futur.

Cette approche est relativement similaire à la génération d’un contrôleur permettant de résoudre des objectifs de sûreté, et des objectifs d’accessibilité. Habituellement l’en- semble des événements est coupé en deux : des événements contrôlables d’une part et d’autres non contrôlable d’autre part. Puis, l’objectif de contrôle est défini en spécifiant une liste d’états à atteindre ou éviter en toute circonstances. Le rôle du contrôleur est de forcer l’occurrence des événements contrôlable pour satisfaire l’objectif de contrôle. Un détecteur au plus tôt peut être vu comme un contrôleur assurant la propriété de détection au plus tôt. Cependant, il nous semble que l’objectif de contrôle du détecteur ne peut s’ex- primer d’une manière simple. Tout d’abord, il faut déterminer les actions contrôlables. En tout lieu de l’automate, il existe un unique arc contrôlable étiqueté par l’événement si- gnalant l’erreur, noté ERR, dont la destination est un lieu puits noté R (pas de transitions sortantes). Le problème de contrôle se pose en des termes assez inhabituels : trouver la stratégie de contrôle spécifiant l’occurrence des événements ERR telle que dès qu’au- cun état final n’est plus accessible, le lieu R doit être atteint au plus tôt. La génération de contrôleur temporellement optimaux a déjà été résolue dans [AM99, BHPR07] mais ne peut directement être appliquée ici. Dans notre cas, le problème provient du fait que les arcs ERR sont tout le temps actifs. il faudrait conditionner leur franchissement par la condition « dès qu’aucun état final n’est plus accessible» pour pouvoir utiliser les algo- rithmes déjà proposés. Il nous semble que les objectifs de contrôle considérées sont assez simples, mais que les conditions sur l’activation des actions de contrôle sont plus com- plexes que celles considérées dans les résultats connus sur la synthèse de contrôleur. Pour ces raisons nous avons développé notre propre stratégie pour déclencher l’occurrence des signaux d’erreur. Cependant, il est normal que notre solution ait de fortes ressemblances avec les contributions existantes dans ce domaine puisque nous utilisons exactement les

mêmes concepts fondamentaux.

Revenons au problème de la capture des plus petits symptômes d’erreur terminés par une durée et non un événement. Supposons que le processus d’observation correspond à un état correct de l’automate. En bref, si à partir d’un état correct, il est possible par simple écoulement du temps d’atteindre un état erroné, alors il existe une unique durée ddl qui ajoutée à la trace représentant l’état «correct» forme un plus petit symptôme d’erreur. Chaque fois que l’état du bloc d’observation est mis à jour, le bloc d’analyse va véri- fier la validité de l’événement nouvellement observé. Notons u la trace modélisant l’état du processus d’observation après sa mise à jour. Si l’événement est validé, alors la trace u correspond à un état correct de l’automate. Il est alors possible de vérifier l’existence d’une durée, noté ddl, telle que u.ddl est un plus petit symptôme d’erreur. Cette durée n’existe pas nécessairement. Par exemple, lorsque u place le système dans un lieu final, alors le système peut y rester a priori indéfiniment. Lorsque cette durée existe, elle est ajoutée à la date courante pour programmer une alarme utilisée pour signaler l’apparition de l’erreur correspondant à u.ddl dans le cas où effectivement aucun événement ne serait observé entre la date courante, et la date de réveil de l’alarme. Si un événement se produit entre la mise en place de l’alarme et son expiration, cela signifie que l’exécution justifiant le signalement de l’erreur ne se produira pas. Il est impératif de désactiver l’alarme pré- cédemment configurée en attendant le calcul de la nouvelle échéance. Ainsi après chaque événement valide trois choses peuvent se produire dans un futur proche.

1. Un événement valide est à nouveau observé avant expiration de l’alarme. Puisque l’événement est valide, il faut mettre à jour l’alarme en fonction du nouvel état de l’automate.

2. Un événement invalide est observé avant expiration de l’alarme et déclenche un signal d’erreur. L’erreur ayant déjà eu lieu il faut désactiver l’alarme pour éviter tout effet "d’écho" pour le signalement des erreurs.

3. Aucun événement n’a eu lieu depuis la configuration de l’alarme et cette dernière expire. Cela signifie qu’un plus petit symptôme d’erreur finissant par une durée non nulle a été atteint (cf figure3.4).

Ainsi, le processus d’analyse des événements et l’alarme sont en concurrence. Ils s’exécutent tous les deux en parallèle et collabore pour capturer les deux types de symp- tômes d’erreur. Le scénario d’exécution représenté dans la figure 3.5 représente le pre- mier cas tout d’abord un événement correct est perçu et place l’automate dans un état où il existe une échéance. Heureusement, un événement valide est observé avant l’expiration de l’alarme précédemment configurée. Lors de l’occurrence d’un événement, il faudra successivement réaliser les étapes suivantes :

3.2. SYNTHÈSE DU DÉTECTEUR AU PLUS TÔT 71

F. 3.4: Expiration de l’alarme permettant la détection d’une erreur temporelle

2. tester la validité de l’événement reçu. En cas d’échec à ce test, déclencher l’émis- sion du signal ERR et bloquer l’exécution de l’application en attente d’un recou- vrement.

3. calculer la nouvelle échéance et régler une alarme en conséquence

Ce principe de vérification en ligne fait l’hypothèse d’un traitement atomique des trois étapes décrites ci-dessus. En fait puisque l’on raisonne sur un état instantané et que l’on configure une alarme, l’hypothèse exacte est celle d’une exécution atomique en temps nul. Pour implémenter ce principe de vérification, il faudra tenir compte du temps de calcul de chaque étape dans la configuration de l’alarme. Les deux sous-sections suivantes détaillent comment sont réalisés le test de validité d’un événement, et le calcul de la durée servant de base pour la configuration de l’alarme.