La modélisation de la partie opérative par les automates à états finis

La modélisation par l’outil mathématique que sont les automates à états finis, passe nécessairement par l’interprétation et l’association entre les possibilités formelles de l’outil et le sens que l’on veut donner au modèle vis-à-vis du comportement observé. Les automates à états, dans leur définition originelle, ne comportent que des états et des transitions et sont destinés à générer des langages. Dans ces conditions, la modélisation de la partie opérative avec cet outil est considérée comme une énumération des situations que la partie opérative est susceptible d’atteindre et une association entre les évènements et les évolutions de la partie opérative.

a. Hypothèses de modélisation

Dans une telle modélisation, il n’est pas possible de faire intervenir le temps autrement que par l’ordre séquentiel des évolutions. Ce dernier point pose problème lorsque des évolutions simultanées de la partie opérative sont susceptibles de survenir. L’outil de modélisation n’est pas capable d’assimiler un tel comportement. Les travaux d’élaboration de la commande tels que la synthèse et la vérification utilise également l’automate à états finis pour décrire le comportement de la commande. L’interaction entre ces deux modèles est naturelle et se fait par synchronisation. Les délais entre les évolutions ne peuvent pas être pris en considération dans ce type de modélisation. Comme évoqués dans le chapitre précédent, les modèles représentés par ces outils sont souvent attachés au comportement fonctionnel du système. Le modèle de partie opérative ne prend alors pas en considération l’instrumentation présente sur le système. Les évènements sont associés à des évolutions perceptibles par observation du comportement mais le lien avec les signaux échangés entre les API et la partie opérative n’est pas établi. Nous proposons dans la suite du document, une approche de modélisation reposant sur l’analyse comportementale des constituants physiques de la partie opérative.

b. Contexte de la modélisation par les

automates à états finis

La modélisation comportementale de la partie opérative par les automates à états finis nécessite de définir quelles sont les interactions entre les données disponibles et l’outil de

modélisation. Dans le cas de systèmes réels et en prenant un faible niveau d’abstraction, les données sont échangées entre la partie opérative et la partie commande au travers les entrées/sorties TOR. Cet ensemble de données booléennes sont associées avec les évènements des automates à états finis. Les évènements correspondant à des évolutions, il est nécessaire de prendre en considération non pas uniquement les signaux échangés mais leurs évolutions. Pour chaque signal booléen échangé, on associe deux événements correspondant aux changements d’un niveau du signal à l’autre niveau. Chaque signal est réalisé sur la partie opérative par une tension électrique associé à un seuil. Ainsi, le front montant décrit le passage du niveau bas du signal au niveau haut du seuil et le front descendant un passage du niveau haut au niveau bas. Le modèle de la partie opérative représente alors une représentation formelle des évolutions de ces signaux. Dans un fonctionnement normal du système, il est possible de prévoir comment les signaux issus des capteurs vont réagir face aux commandes qui ont été envoyées. Le fonctionnement normal du système suppose notamment que l’énergie permettant aux préactionneurs d’alimenter les actionneurs soit disponible, que le câblage du système et le positionnement des actionneurs et des capteurs soient corrects, qu’il n’y a pas de blocages ou de mouvements contraires exercés sur l’actionneur.

La Figure 3.4 illustre comment le comportement de la partie opérative peut être modélisé par un modèle à états. Les signaux échangés entre l’API et la partie opérative sont des signaux électriques dont la tension varie dans le temps pour échanger les données (Figure 3.4a). Ces

signaux sont nommés « Ei » pour les capteurs connectés aux entrées de la partie commande

et « Si » pour les commandes reliées aux sorties de la partie commande. Ces signaux sont

continus et contiennent du bruit de fonctionnement. Les seuils de changement de niveau logique permettent de déterminer une donnée booléenne contenue dans chaque signal continu. L’ensemble de ces données booléennes peut être représenté sur un graphe temporel d’évolution au cours du temps (Figure 3.4b). Ce graphe ne peut pas représenter l’ensemble des évolutions susceptibles de se produire. Le comportement représenté sur ce graphe est un exemple de comportement susceptible de se produire sur le système en cours de fonctionnement. Cela signifie que pour une telle sollicitation de l’API, le comportement de la partie opérative est connu. Ce comportement peut également être représenté sous la forme d’un mot provenant d’un langage. Un événement représente un changement d’une variable booléenne. Les changements de valeur d’une variable booléenne sont représentés par une

flèche ( ou ). La flèche montante  représente le front montant d’une variable booléenne

passant du niveau bas au niveau haut. La flèche descendante  représente également le front

descendant d’une variable booléenne passant du niveau haut au niveau bas. L’ordre d’occurrence de ces évènements les uns après les autres peut être pris en compte pour l’établissement du modèle. L’évolution continue du temps n’est pas conservée. Seul l’ordre d’occurrence des évènements est pris en compte, les délais entre occurrence d’évènements ne pouvant être pris en compte dans ce modèle. Cette séquence d’évènements peut être représentée par un mot (Figure 3.4c).

API partie opérative S1 S₂ S₃ E₁ E₂ E₃ U(S1) (V) temps (s) U(E1) (V) temps (s)

a) Signaux échangés entre l’API et la partie opérative

b) Scénario de comportement attendu de la partie opérative soumise à une commande

t S₁

S₂

E₁

c) Traduction du scénario dans un modèle de type langage

↑S₁↓E₁↑S₂↑E₁↓S₁↓S₂

d) Traduction du scénario dans un modèle automate à états (modèle partiel) ↑S₁ ↓E₁ ↑S₂ ↑E₁ ↓S₁ ↓S₂

Figure 3.4 : modélisation comportementale de la partie opérative par un automate à états

Le modèle de partie opérative représente l’ensemble des séquences d’événements susceptibles de se produire sur le système. Les automates à états finis permettent de générer un langage décrivant l’ensemble des séquences d’évènements susceptibles de se produire. L’ensemble des évènements ∑ inclut tous les fronts des variables d’entrées/sorties de l’API (

   





  U ). La Figure 3.4d représente un automate à états finis A





lequel le mot admissible par le système au cours de son fonctionnement, est admissible.

L’ensemble d’états Q ^{permet d’énumérer toutes les situations que le modèle est capable de}

distinguer. L’ensemble des transitions  ^{autorise l’occurrence des évènements acceptables}

depuis les états considérés. L’état _q0 permet de décrire l’état initial décrivant la situation de la

partiel associé au scénario qui a été présenté sur la Figure 3.4. Ce modèle fait également l’hypothèse que la situation atteinte à la fin du scénario permet de le reproduire à l’infini. Par cette illustration, nous avons montré que la partie opérative était susceptible d’être représentée par un modèle sous la forme d’un automate à états finis. Des conditions doivent néanmoins être appliquées puisque ce modèle comporte des limitations notamment du point de vue de la gestion temporelle.

La représentation d’un système automatisé par les automates à états finis permet d’utiliser les résultats des travaux de recherche et les applications associées basés sur cet outil de modélisation. Dans ce contexte, nous proposons de modéliser la partie opérative de manière modulaire en fonction des constituants de la partie opérative. Il s’agit à terme de proposer un catalogue de constituants pouvant être mis en œuvre sur une partie opérative.

La distinction des chaînes d’action et d’acquisition de la partie opérative peut être reprise dans la démarche de modélisation de la partie opérative en exploitant la construction de la partie opérative réelle à partir de composants mécaniques standards. Les composants technologiques que sont les préactionneurs, les actionneurs et les capteurs peuvent ainsi être modélisés individuellement avant d’être assemblés pour réaliser méthodiquement le modèle de la partie opérative. La démarche de modélisation proposée consiste donc à modéliser la partie opérative par une décomposition en chaînes fonctionnelles.