4.3.2 Travaux relatifs au filtre de commande

a interdire. D`es qu’une contrainte de s´ecurit´e est viol´ee, le filtre change la commande et

bloque le syst`eme dans un ´etat de repli pr´ed´etermin´e.

Ces travaux (Cruette et al., 1991; Marang´e, 2008) ´etaient appliqu´es dans un cadre de

commande sˆure de fonctionnement, et de d´etection d’erreurs de la partie commande. Des

travaux dans ce sens ont continu´e d’ˆetre d´evelopp´es au CReSTIC et sont pr´esent´es dans la

section I-4.3.2. Il est `a noter que des applications li´ees `a la cybers´ecurit´e sont par ailleurs

actuellement ´etudi´es par la communaut´e scientifique :

— Sicardet al.(2017) se base sur la notion de filtre, mais utilise une notion de distance

entre ´etats pour la d´etection d’une cyberattaque. Une attaque est d´etect´ee lorsque

l’´etat actuel de la partie commande s’´eloigne trop de la trajectoire attendue des

´etats.

— Toublanc et al. (2017) sp´ecialise la notion de filtre en d´efinissant des gardiens.

Trois gardiens diff´erents sont d´efinis, chacun devant d´etecter une erreur de la partie

commande, de la partie op´erative ou du r´eseau de communication. Ces gardiens

sont organis´es dans une passerelle entre la partie commande (PC) et la partie

op´erative (PO), cette passerelle est positionn´ee au niveau de la communication

entre la PO et la PC.

I-4.3.2 Travaux relatifs au filtre de commande

Plusieurs travaux ont ´etendu et compl´et´e les travaux de Marang´e (2008), cette partie

pr´esente les diff´erentes ´evolutions de ces travaux.

Initialement, le filtre de commande ´etait constitu´e d’un ensemble de contraintes logiques

appel´ees contraintes de s´ecurit´e (Marang´eet al., 2007). Deux types de contrainte ´etaient

d´efinis :

— les contraintesstatiques : faisant apparaˆıtre uniquement des variables ;

et de d´esactivation de variables).

Ces contraintes ´etaient impl´ement´ees de mani`ere s´equentielle, `a la fin du cycle automate,

avant la mise `a jour des sorties (Fig. 17). Si au moins une contrainte ´etait viol´ee (´evalu´ee

`

a vraie), alors les valeurs des sorties ´etaient modifi´ees pour atteindre un ´etat de repli

pr´ed´etermin´e et stable. Ce filtre peut donc ˆetre qualifi´e de bloquant.

c

a

b

S1

S2

Entrées

Sorties

Initialisation

Lecture des entrées Exécution du programme

Mise à jour des sorties Filtre de commande

contrainte₁:= équation₁; contrainte₂:= équation₂; ...

contrainte_n:= équation_n;

Si au moins une contrainte est violée alors bloquer le système;

Figure 17 – Principe d’impl´ementation du filtre bloquant dans un API

Marang´e a ´egalement propos´e une approche hors-ligne `a base de model-checking

permet-tant de valider un ensemble de contraintes logiques par rapport aux exigences (Fig. 18).

En se basant sur une mod´elisation de la partie op´erative `a l’aide d’automates `a ´etats finis,

ainsi que sur une liste d’´etats et de comportements interdits, il est possible de v´erifier par

model-checking la propri´et´e de suffisance : quelle que soit la valeur des capteurs et le

programme pr´ec´edent le filtre, l’ensemble de contraintes est suffisant pour garantir

qu’au-cun ´etat interdit ou comportement interdit ne soit atteignable. Dans le cas o`u la propri´et´e

n’est pas v´erifi´ee, un contre-exemple est remont´e pour aider le concepteur du filtre.

L’approche par filtre bloquant permet la v´erification formelle hors-ligne de programme

automate existant, ainsi que la d´etection en-ligne d’erreurs provenant de la partie

com-mande. N´eanmoins, le blocage syst´ematique du syst`eme lors de la d´etection d’une erreur

peut entrainer des arrˆets de production trop fr´equents. Afin de diminuer le risque de

blocage du syst`eme, Benlorhfar et al. (2011) ont propos´e la notion de filtre correcteur.

Le principe est de modifier l’impl´ementation du filtre afin de proposer en-ligne des

va-leurs de sortie alternative, bas´ees sur les valeurs envoy´ees par la partie commande, qui ne

violent aucune contrainte de s´ecurit´e (Fig. 19). Dans ces conditions, le syst`eme n’est pas

forc´ement bloqu´e et peut potentiellement continuer la production dans un mode d´egrad´e.

I-4 Approches de commande des SED par contraintes logiques 59

Figure18 – Approche par model-checking de v´erification de la suffisance (Marang´e, 2008)

Riera et al. (2015) ont montr´e que le filtre correcteur pouvait ˆetre utilis´e de deux fa¸cons

diff´erentes : «filtre correcteur superviseur » et «filtre correcteur contrˆoleur». Dans le

premier cas, le programme fonctionnel est r´ealis´e sans avoir connaissance de l’existence

du filtre correcteur en aval. Dans le second cas, la connaissance du filtre est prise en compte

dans la conception du programme fonctionnel. En d’autres termes, dans le cas du filtre

correcteur contrˆoleur, violer une contrainte peut ˆetre consid´er´e comme un fonctionnement

«normal»du filtre. A contrario, dans le cas du filtre correcteur superviseur, la violation

d’une contrainte signifie que le programme fonctionnel comporte au moins une erreur de

conception.

c

a

b

S1

S2

Entrées

Sorties

Initialisation

Lecture des entrées

Exécution du programme

Mise à jour des sorties

Filtre de commande

contrainte

₁

:= équation

₁

;

...

contrainte

_n

:= équation

_n

;

Pour toute les contraintes

Si la contrainte est violée alors

résoudre la contrainte;

Figure 19 – Principe d’impl´ementation du filtre correcteur dans un API

sans pour autant forcement bloquer le syst`eme. N´eanmoins avec l’impl´ementation s´

equen-tielle propos´ee dans Benlorhfar et al. (2011), la r´esolution d’une contrainte peut violer

une contrainte pr´ec´edemment non-viol´ee ou r´esolue. De plus, en fonction de l’ordre dans

lequel les contraintes sont impl´ement´ees, la solution n’est pas obligatoirement la mˆeme,

la r´esolution n’est donc pas d´eterministe.

Afin de r´esoudre ces probl`emes, Coupat (2014) a propos´e un algorithme it´eratif permettant

la r´esolution d´eterministe d’un ensemble de contraintes de s´ecurit´e. Un algorithme succin

est pr´esent´e Fig. 20, l’algorithme d´etaill´e est pr´esent´e dans Coupat (2014) (Fig. 55, p. 141).

Enfin, dans les travaux de Coupat, une red´efinition des contraintes a ´et´e propos´ee dans

le but d’´etendre l’approche par filtre `a la commande sˆure de fonctionnement. Les deux

nouveaux types de contraintes, rempla¸cant ceux d´efinis par Marang´e, sont les suivants :

— les contraintessimples : ne contiennent qu’une seule variable de sortie ;

— les contraintescombin´ees : contiennent plusieurs variables de sorties.

En plus de ces diff´erences structurelles, Coupat propose d’utiliser ces contraintes pour

deux notions diff´erentes : les contraintes de s´ecurit´e et les contraintes fonctionnelles.

Les premi`eres ont pour objectif de formaliser les exigences de s´ecurit´e du cahier des charges

(configurations interdites du syst`eme), les secondes ont pour objectif de formaliser la partie

fonctionnelle (configurations souhait´ees du syst`eme).

c

a

b

S1

S2

Entrées

Sorties

Initialisation

Lecture des entrées

Exécution du programme

Mise à jour des sorties Filtre de commande

calculer les contraintes;

Si au moins une contrainte est violée alors chercher des solutions;

Si au moins une solution existe alors choisir une solution;

Sinon

bloquer le système;

Figure 20 – Principe de l’algorithme it´eratif

Les travaux de Coupat ont permis une premi`ere application industrielle de l’approche par

filtre de commande avec la SNCF. Le probl`eme ´etait de garantir que des programmes API

existants ´etaient corrects du point de vue de la s´ecurit´e, dans le cas contraire, la s´ecurit´e

devait ˆetre garantie en n’effectuant aucune modification sur le programme API existant.

Coupat a propos´e une approche `a base de model-checking pour tester les programmes API.

I-4 Approches de commande des SED par contraintes logiques 61

Afin de mettre en s´ecurit´e un programme «erron´e», l’approche par filtre de commande

a ´et´e propos´ee. Coupat a finalement montr´e par model-checking que dans le cas d’un

programme initial«erron´e», l’association d’un filtre de commande au programme permet

de garantir la s´ecurit´e et de garantir un fonctionnement correct du contrˆoleur.

Dans les travaux de Marang´e une propri´et´e de suffisance de l’ensemble des contraintes a

´

et´e propos´ee. Dans l’algorithme propos´e par Coupat (Fig. 20), s’il n’existe pas de solution

lors de la r´esolution, alors une solution arbitraire va ˆetre appliqu´ee, mais cette solution ne

v´erifie pas l’ensemble des contraintes. L’expression d’une propri´et´e d’existence de solution

est donc n´ecessaire.

La notion de coh´erence d’un ensemble de contraintes de s´ecurit´e a donc ´et´e propos´ee

(Rieraet al., 2015). Un ensemble de contraintes de s´ecurit´e est coh´erent si et seulement si,

quelle que soit la valeur des entr´ees du filtre (capteurs, variables internes, commandes

en-voy´ees par le programme amont), il existe toujours une solution (valeurs des commandes)

v´erifiant l’ensemble des contraintes. Rieraet al.(2015) ont ´egalement propos´e un ensemble

de conditions n´ecessaires `a la coh´erence d’un ensemble de contraintes de s´ecurit´e.

Dans le document Contribution à la Commande des Systèmes à Événements Discrets par Filtre Logique (Page 58-62)