Modélisations de solutions séquentielles destinées à piloter une chaîne d'énergie publié le 20/07/2020  - mis à jour le 17/11/2020

3- Création de composants de la bibliothèque et de prototypes de composants pour réaliser des séquenceurs

Comme indiqué précédemment, la modélisation d’un séquenceur n’est utile que si la création ou l’utilisation d’un stimulus ne suffit pas. Cela correspond généralement à la nécessité de surveiller l’état du système (prise en compte de la distance ou de la hauteur parcourue ou gestion des butées, par exemple)

Rappel : Différence entre logique combinatoire et logique séquentielle :

• En logique combinatoire, les sorties ne dépendent que de l’état des entrées. Il n’y a pas d’effet mémoire.
• On réalisera donc une fonction combinatoire à l’aide d’une équation logique reliant une sortie à une ou plusieurs entrées, que ce soit dans un composant Sinusphy ou dans un script Python.
  
• Ci-dessous, l’équation logique de Y [ Y = /(R or /S) ⇔ Y = S and /R ] permet de forcer Y à 1 si S = 1 lorsque R = 0. Dans tous les autres cas, Y = 0. (Cette fonction logique, dans sa version simplifiée sous forme d’un ET et d’un inverseur, est parfois appelée fonction Inhibition).
  
  

• En logique séquentielle, les sorties dépendent également de l’état précédent du séquenceur, par conséquent, des anciennes valeurs des sorties. Il y a ainsi possibilité de voir différents états des sorties pour une même combinaison des entrées.
• Application : On cherchera à avoir un effet mémoire (voire un cycle de comptage ou autre), non pas par une ou des équations logiques mais par un ou plusieurs tests logiques (si tel événement, modifier, ainsi, telle sortie), que ce soit dans un composant Sinusphy ou dans un script Python.
  
• Ci-dessous, deux variantes du schéma du plus simple de tous les séquenceurs (la mémoire RS) réalisé avec des portes logiques NON OU. Comme on peut le voir, le schéma est une variante de la fonction précédente avec une nouvelle liaison permettant de tenir compte de l’état de la sortie. La sortie Q dépend alors de S, de R et de Qp (l’état précédent de Q) [ Q = /(R or /(S or Qp)) ]. Cela permet de tenir compte de l’ancienne valeur de Q lorsque S et R ne sont pas actifs. Cet état sera appelé : l’état mémoire. (Qp = 1 si seul S était à 1 avant de passer à 0 ou Qp = 0 si R était seul à 1 avant de passer à 0). Il apparaît ainsi la notion d’état précédent et cette notion servira pour gérer les entrées, les sorties et les variables internes.
  
  

Modélisation, simulation et analyse de fonctionnement de la mémoire RS :

• Soit le cahier des charges : « Démarrer le moteur par un appui sur un bouton Marche et arrêter le moteur par un appui sur le bouton Arrêt d’Urgence (ou tout autre événement lié à l’état de la machine comme un fin de course et modélisable par un simple composant comparant (utiliser un test ou Heaviside) l’intégrale de la vitesse à une valeur limite...). Le moteur doit rester dans l’état imposé par le dernier ordre reçu, ce qui nécessite d’utiliser le phénomène mémoire vu précédemment. »
• Nous allons modéliser, simuler et analyser le fonctionnement de diverses modélisations d’une mémoire RS. Pour des raisons évidentes de sécurité, il faudra bien vérifier que l’Arrêt d’Urgence ⇔ Reset, sera bien prioritaire sur le bouton Marche ⇔ Set.
• Pour les 3 modélisations suivantes, les stimuli seront définis ainsi :
  • entrée S : impulsion n°1 de 0.2 s à 0.25 s et impulsion n°2 de 1 s à 1.4 s
  • entrée R : impulsion n°1 de 0.6 s à 0.65 s et impulsion n°2 de 1.2 s à 1.3 s

Trois exemples :

• La solution câblée classique, vue auparavant, à deux 2 portes logiques NON OU (Nor Gate). Ce n’est, évidemment, pas la solution préconisée pour la suite mais elle est toujours utilisée, tout comme le câblage auto maintien (qui réalise la même fonction mémoire, à l’aide d’un relais et de contacts de boutons poussoirs, dans la partie commande de machines en électrotechnique) et mérite d’être étudiée pour aider à la compréhension de la suite.
  

• La réalisation d’un composant spécifique mémoire RS. Cette mémoire RS sera commandée par les niveaux "high" des entrées S et R. Le cœur de la mémoire RS est une imbrication de 2 tests complets (du type si... alors... sinon...) avec l’utilisation de la valeur précédente de la sortie Q lorsque R et S ne sont pas à l’état actif. Pour rendre l’état de R prioritaire sur celui de S, il suffit, ici, de commencer par tester l’entrée R afin de ne tester l’entrée S que si l’entrée R est inactive.
  

On voit, ci-dessous, comment se fait la traduction des tensions (niveau haut défini par l’utilisateur) en niveaux logiques 1 ou 0 grâce à la fonction Heaviside ainsi que la solution pour réagir à R et à S ou maintenir l’état précédent. A noter qu’ici, comme dans d’autres langages, la valeur "1" est équivalente au booléen True, et par conséquent :
Q = Vh * if(R_, 0, if(S_, Vh, Q) ) ⇔ Q = Vh * if(R_==1, 0, if(S_==1, Vh, Q) )

• La réalisation d’un simple script memoireRSPython.py. Cette mémoire RS sera commandée par les niveaux "high" des entrées Set et Reset. Le cœur de ce script est, ici, une succession de 2 alternatives simples. Cette solution a l’avantage d’être très lisible. Pour rendre l’état de Reset prioritaire sur celui de Set, il suffira, ainsi, de tester Reset en dernier. A noter que la solution de deux alternatives imbriquées reste parfaitement valable (en testant, alors, Reset en premier...), surtout, que sur le papier, elle devrait être plus rapide mais cela se fait au prix de plusieurs indentations et d’une perte de lisibilité.
  

On voit, ci-dessous, comment se déclarent les entrées et sorties dans le composant Script et comment le lien se fait avec le script et la fonction principale appelée à chaque pas de calcul (cette fonction principale a été volontairement appelée, ici, loop en référence à la structure de base d’un programme sous Arduino et afin de conserver la notion d’unique "boucle" obtenue par l’appel de Sinusphy à chaque pas).

Et dans le script, ci-dessous, on repère les points importants :

1. La lecture des signaux (set = value("Set"))
2. La conversion (En fait, il n’est pas nécessaire de la gérer car c’est automatique en Python car le booléen True correspond à une valeur non nulle)
3. Le cœur du script (Les 2 tests des variables set et reset, sous forme d’alternatives simples, suffisent car le maintien de l’état précédent s’obtient par défaut si aucun test n’est validé).
   

A noter que les 3 solutions donnent exactement le même résultat (jusqu’à l’état initial de Q qui égal à 0).

• Pour le composant mémoire RS, c’est SinusPhy qui initialise la variable Q à 0.
• Pour le script Python, la variable globale marche associée à la sortie doit être déclarée et initialisée à 0.
• Pour les portes logiques NON OU, afin d’obtenir l’état initial voulu, l’une des 2 portes logiques a été simplement optimisée (on peut toutefois vérifier que, s’il y a eu une première simulation, l’état mémoire initial est logiquement le dernier état obtenu à la simulation précédente).
  

Note : Comme on peut le voir, à l’instant t = 1.3 s, cette solution basique montre tout de même ses limites car on peut voir que lorsque R repasse à 0 avant S après qu’ils aient été tous les deux à 1, la sécurité n’est pas assurée car, visiblement, le moteur redémarre... Il est vrai que le cahier des charges n’abordait pas le temps d’appui sur les boutons !
Nous allons voir comment y remédier au paragraphe suivant en prenant en compte les fronts (c’est à dire les variations des entrées) au lieu des niveaux !