# Novel Supervisor-Based Architecture for Logic Controller Design

Dimitri Renard, David Annebicque, Ramla Saddem, Bernard Riera

► To cite this version:

Dimitri Renard, David Annebicque, Ramla Saddem, Bernard Riera. Novel Supervisor-Based Architecture for Logic Controller Design. MIM 2025 - 11th IFAC Conference on Manufacturing Modelling, Management and Control, Jun 2025, Trondheim, Norway. hal-05189381

HAL Id: hal-05189381

https://hal.science/hal-05189381v1

Submitted on 28 Jul 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Novel Supervisor-Based Architecture for Logic Controller Design

Dimitri Renard*, **, David Annebicque**, Ramla Saddem**, Bernard Riera**

* Prosys, 30 rue des Frères Danna, Valenciennes, France

** Université de Reims Champagne-Ardenne, CReSTIC, Reims, France (e-mail: name.surname@univ-reims.fr)

**Abstract:** This paper presents a novel supervisor-based architecture for designing a reliable logic controller, which integrates the cyclic operation of programmable logic controllers (PLCs) with the formal advantages of supervisory control theory (SCT). By combining these two paradigms, this architecture delivers a comprehensive approach to control and monitoring, overcoming the inherent challenges associated with synchronization issues. Through abstractions in task modeling, sensor integration, and constraint handling, this integrated framework resolves complexities, ensuring seamless interaction between control and monitoring processes. A proof-of-concept is presented, demonstrating the effectiveness of this integrated approach in a real-world context.

**Keywords:** Supervisory Control Theory, Discrete Event Systems, Implementation, Programmable Logic Controller

## 1. INTRODUCTION

The industrial sector focuses on the possibilities of Industry 4.0 technologies to enhance its manufacturing processes. Data is at the center of this industrial change. Investment priorities include energy usage, availability, reconfiguration options, and part quality. Recent technologies, like Virtual Commissioning, Digital Twins, and Artificial Intelligence, are appealing for tackling many process challenges. The Programmable Logic Controller (PLC) program contains knowledge. However, program specifications must be formally defined and communicated for use in the system life cycle. This part is a current lack of design and use of most production lines, which has been observed for many years (Frey and Litz, 2000). The design, integration, and uses of Digital Twin suffer from these current formal shortcomings in logic controllers. Control design approaches such as Supervisory Control Theory (SCT) and task-structured analysis have been performed in academia (Zaytoon and Riera, 2017). However, the industrialized world has not yet adopted that because there still exists a gap between the theoretical foundations (which are difficult to adopt) and its application in a PLC.

This article presents a novel supervisor-based architecture for dependable logic controller design with indirect physical system control and explains how this architecture addresses the problems of implementing a supervisor in a PLC.

This paper is structured as follows: section 2 presents the supervisory control theory, and the implementation supervisor challenges, and section 3 explains the proposed architecture and the associated models. Section 4 shows the proof-of-concept, and the last section summarizes the work and suggests directions for future research.

## 2. SUPERVISORY CONTROL THEORY

### 2.1 *Supervisory Control Theory*

The SCT has its roots in the work of (Ramadge and Wonham, 1989), and more broadly, it is rooted in the theory of Discrete Event Systems (DES) (Cassandras and Lafortune, 2021). The SCT draws upon this foundation to develop a formal framework for controlling complex systems. At the heart of the SCT lies the concept of finite state machines (FSM). The Extended Finite State Machine (EFSM) introduces guard transitions and actions connected to variables. In an EFSM, a transition cannot be made unless the corresponding guard condition is satisfied. Moreover, the relevant variables are updated when passing through a transition with actions.

The SCT describes the system in plant models and specifications. The plant models encapsulate the entire range of behaviors of the system. The specifications establish bounds on each of the plant models. Defining the system as an FSM of the system in the form of plants and specifications is a complex task requiring expertise in DES modeling. The optimal supervisor concept enables the maximization of the supervisor's choices according to specific criteria in offline mode, thereby transforming it into a controller (Hu et al., 2025). In complex systems with many states or variable operation times, online approaches based on N-step windows are also employed. These approaches provide an alternative solution for analyzing and controlling such systems (Hill and Lafortune, 2017).

Software tools have been developed to study DES and SCT. The Supremica tool (Malik et al., 2017) is one of the most commonly used tools, which enables the design of FSMs, EFSMs, and the application of supervisory synthesis algorithms used in this article.
## 2.2 Supervisor Implementation

The implementation of a supervisor in a PLC (Reijnen et al., 2022) is subject to four significant challenges that have been identified in the literature on SCT (Fabian and Hellgren, 1998):

* Signal and events: In SCT events occur asynchronously whereas in a PLC the inputs evolve synchronously.

* Causality: "Who generates what?"

* Choice: The supervisor includes an alternative path, so the controller must make a choice.

* Inexact synchronization: Exact synchronization in real life does not exist.

An implementation framework coupled with its modeling and generation tool SynTACS is proposed for applying SCT and export to the ST program (Göbe et al., 2016). In their case, it uses SCT to safeguard existing controllers, which differs from the original framework aim. DEScMaker (Possato et al., 2024) enables the transformation of a Supremica project (.wmod) containing a supervisor modeled in simple FSM in Python language. This open-source tool is used to implement our supervisor-based architecture.

## 3. MODELS AND CONCEPT

The supervisory-based architecture proposed in this article used the supervisor inside the controller to authorize or not tasks. This section discusses the architecture, and the models used to design the supervisor (Figure 1). SCT serves as the formal foundation for this architecture. By abstracting operative tasks, significant constraints are released concerning sensors and actuators. The supervisor incorporates the logical filter concept, formalizing the description and applying security constraints. The subsequent sections 3.1 and 3.2 provide an in-depth exploration of models chosen to abstract the challenges associated with the modeling of plants and filters and to respond to the "Causality" problem. Section 3.3 develops the supervisor-based architecture for logic controller design that responds to "Signal and events" and "Inexact synchronization" problems. Section 3.4 explains how this architecture can be used with task priorities to respond to the "Choice" problem.

<figure><img src="image_2.png" /><figcaption>Figure 1: Supervisor architecture design workflow.</figcaption></figure>

### 3.1 PLC Modeling

When designing a supervisor for use in a PLC, it is essential to understand how the PLC operates and model its behavior accordingly. The PLC's cyclical nature, comprising three main

stages - input reading, program execution, and output writing - must be considered during the design phase (Figure 8).

The Multiple Input Multiple Output (MIMO) model depicted in Figure 2 accurately represents the PLC's operation. This model is divided into two distinct states: the Wait state and the Exe state. The Wait state corresponds to the input reading stage, where uncontrollable events ($Σ_{ue}$) can only occur, whereas the Exe state encompasses both the program execution and output writing stages, during which controllable events ($Σ_{ce}$) are possible.

<figure><img src="image_3.png" /><figcaption>Figure 2: MIMO automaton model (Cantarelli and Roussel, 2008)</figcaption></figure>

### 3.2 Task Model

To model the system, the operative task abstraction is used (Taillard, 2010; Ranger, Philippot and Riera, 2021). An operative task is a function of the system triggered by an event and cannot be stopped once it is in progress. An operative task is autonomous, waiting, or executing. Modeling features streamline controller development by decoupling functionality. When developing the coordination between tasks, these features focus on specifically addressing interactions. An operative task produces a unique event when it is completed. It corresponds to the rising edge of the initial state. It is represented in the GRAFCET by clearing the End_Condition transition (see Figure 3).

An authorization event allows triggering an operative task. It is conditionally defined as functional static conditions and security static conditions, representing the initial condition to trigger the task. The authorization event ($AUT_T[X]$) can only be triggered if the $Initial_Condition[X]$ is true (X the unique identifier task). So $AUT_T[X] \Rightarrow Initial_Condition[X]$.

To specify the functional behavior of our tasks, GRAFCET defined in IEC-60848 (International Electrotechnical Commission, 2013) is chosen. However, in our abstract model, the functional aspects of tasks are decoupled from the supervisory control. So, an operative task can be specified by any other formalism. Figure 3 shows the waiting state of each task with a transition composed of the $AUT_T[X]$. A macro-step MTX incorporates all the functionality of the operative task. Given the lack of synchronization management, the design of operational tasks becomes relatively straightforward for automation engineers.

<figure><img src="image_4.png" /><figcaption>Figure 3: Start GRAFCET functional specification of task.</figcaption></figure>
The modeling of an operative task for synthesizing a supervisor is achievable by a two-state FSM: the waiting state and the active task state (Figure 4). The transition between these states is triggered by the occurrence of two specific events: AUT_T[X] and END_T[X]. Upon receipt of the AUT_T[X] event, the FSM transitions from the waiting state to the active task state, initiating the execution of the task. Conversely, at the end of the task, the system returns to the waiting state and issues the END_T[X] event.

The addition of a marked state to the task goal template introduces the concept of co-accessibility, allowing for non-blocking supervisor functionality. This enables the system to accommodate tasks that represent the goal of the overall system, thereby facilitating more efficient control and optimization.

<figure><img src="image_5.png" /><figcaption>Figure 4: Built-in PLC task template instantiated for task 9 with marked state.</figcaption></figure>

By doing so, actuators are controlled solely based on the evolution of tasks as specified, while sensor values are directly incorporated into task programs. However, when modeling the supervisor, it is necessary to construct observers from knowledge that appends just after task start or with known information at the end-of-tasks, which allows for decoupling from the real sensors. The key events that need to be considered in this context are:

* Task authorization (task start event), which is a controllable event.

* End-of-task, an uncontrollable event calculated (generated) by the PLC.

The controllable events (AUT_T[X]) are strictly confined to a predefined region of the PLC program. Execution of this code segment triggers the transition from the Wait state to the Exe state of the MIMO model, thereby initiating the task execution process. Following successful completion of the authorizations, the FSM returns to the Wait state.

The proposed EFSM model integrates task-specific information directly into its guards and actions (Figure 5). This includes the initial conditions of each task, which are explicitly defined within the authorization guard. Moreover, tasks are accompanied by knowledge of specific sensors or internal observers that evolve independently in the plant models, regardless of their real-world connections. The execution of a task must leave a residual trace on the process execution. Consequently, each operative task necessitates modifying at least one observer through an action within the model's task. Therefore, the proposed model necessitates the use of a single observer to transmit the same information to the supervisor. The transition from Idle to Busy is conditionally allowed with either actions or guards. In contrast, the transition from Busy to Idle is restricted to allowing only actions, not guards.

Indeed, a guard could block the evolution of task model with the event END_T[X] and thus not be able to restart the task.

<figure><img src="image_6.png" /><figcaption>Figure 5: Task models with guard and action of tasks 1 and 12.</figcaption></figure>

The proposed EFSM models enable automatic generation by Supremica into FSMs (Sköldstam, Akesson and Fabian, 2007). These FSMs, in turn, allow Supremica to synthesize a nonblocking and controllable supervisor.

Task modeling enables the addressing of causality issues. The controller can issue task authorization (AUT_T[X]) permits that are either accepted or rejected by the supervisor. Upon completion of the task, the supervisor receives the end-of-tack event (END_T[X]). No other uncontrollable events must be defined.

## 3.2 Filter Model

A logic filter is a validation block added in a control program to detect and correct constraint violations. To incorporate the logical filter notion (Marangé, 2008) into our specifications, a template is proposed to mirroring the concept of a logical filter as used in process control systems, which enforces constraints between operative tasks.

Let T1 and T2 be two tasks that cannot be executed together by an automaton. The constraints modeling between these two tasks are shown in Figure 6. In our previous work, these constraints were implemented in the form of a logical filter (Renard et al., 2024). The proposed modeling replicates the logic filter behavior. When allowing T1 or T2, the filter FSM between the two tasks changes state from S0 to S1. T1 or T2 that has been authorized with AUT_T[X] event, ends with its events END_T[X] with $X \in \{1, 2\}$ and allows the return to the S0 state. After a task is authorized, its status is in progress, and it can no longer be allowed until its end event occurs. However, T2 authorization is also inhibited because its authorization is present in the filter automaton but not possible in the S1 state. By adding an event AUT_[T] (and END_T[T]), then all combinations between these tasks present in the filter are prohibited. For example, for a filter with three tasks, only one filter model is needed compared to three in an unbundled way.

<figure><img src="image_7.png" /><figcaption>Figure 6: Filter for 2 tasks that cannot be executed simultaneously.</figcaption></figure>
### 3.3 Supervisor

With all the system models, tasks, initial conditions, and constraints, it is possible to generate a supervisor via the SCT algorithms. However, the system must fulfill one or more needs defined by tasks or a defined sequence of tasks. For multiple needs, an automaton representing diverse goals is then represented to bring it to a marked state. Thus, a controllable and maximum permissive non-blocking supervisor can be generated with Supremica algorithms to achieve a defined goal.

Figure 7 shows our use of the SCT in the architecture proposed. The supervisor is embedded within the controller. Upon receiving an AUT_T[X] event from the controller, the supervisor assesses the validity of the event based on its current state. If the event is available in the current state, the supervisor evolves and responds to the controller with the task authorization; otherwise, the current state remains unchanged, and the supervisor responds to the controller that the task can't be authorized. At the end of the PLC program, the controller sends uncontrollable events (END_T[X]) to the supervisor, which correspond to the last operative task transition and are linked to the actual sensor values.

<figure><img src="image_8.png" /><figcaption>Figure 7: Supervisory-based proposed architecture.</figcaption></figure>

This implementation of the supervisor permits management based solely on events. Each AUT_T[X] and END_T[X] event is generated, indirectly by the evolution of the real sensors, in the PLC code. Thus, these events are non-stealthy. The architecture respects asynchronism in the processing of computations within the PLC, meaning that events are necessarily processed at different times. Furthermore, this implementation also addresses the synchronization problem by ensuring that events are processed directly after their occurrence by the supervisor in the PLC.

The novel architecture views supervision not as direct monitoring of the physical installation but rather as supervision of the abstract representation of the installation in the PLC by means of operative tasks.

### 3.4 A use of this architecture

This paragraph proposes to demonstrate the use of this supervisor-based architecture with the addition of task priority to address the choice problem. The focus is only on normal

operation with reconfiguration possibility. Figure 8 illustrates the PLC implementation structure with its distinct components.

At each PLC cycle, the authorization phase tests all AUT_T[X] events in order of priority. If the authorization event is possible, the supervisor's state is updated, but the task will be authorized at the end of the authorization phase. This approach enables the execution of multiple tasks within a single PLC cycle without complicating the modeling by managing concurrency. The sequential testing of task permissions, as well as unique task permission checks, eliminates concurrency issues.

Following the authorization phase, the task programs are executed. Allowed tasks are triggered, while running operative tasks (allowed in a previous PLC cycle) evolve independently according to their macro-step specification, and other waiting tasks remain dormant.

<figure><img src="image_9.png" /><figcaption>Figure 8: PLC implementation structure of Supervisor with priorities.</figcaption></figure>

At the end of the PLC program, for each operative task if the final transition of an operational task is activated in this cycle, end-of-task events END_T[X] is sent to the supervisor. The supervisor necessarily evolves by the transition from Busy to Idle state of task X.

DEScMaker facilitates the connection between the modeling of the supervisor using Supremica and its implementation. Our approach targets the implementation of a PLC in Python. The automatically generated Python code, derived from the functional specification in GRAFCET of the operative tasks, is attached to the supervisory controller. This is made possible by our internal tool GReSTIC, which converts among others GRAFCET specifications into a PLC Python program. This supervisor provides possibilities to control the system through task authorizations but not make decisions in this form.

## 4. MODELLING AND RESULT

This section demonstrates the proposed architecture as a proof-of-concept. The Factory IO software is used as an operative part simulator and as a simulated real system. It is dedicated to its simplicity and its library of predefined components for research and pedagogical activities (Riera and Vigário, 2017). DEScMaker tool (Possato et al., 2024) is also used to
transform the Supremica project (.wmod) containing a supervisor modeled in simple FSM in Python language. The automatically generated Python code, derived from the functional specification in GRAFCET of the operative tasks, is attached to the supervisory controller. Figure 9 shows the methodology workflow with the tools used to specify and deploy a proof-of-concept.

<figure><img src="image_10.png" /><figcaption>Figure 9: Workflow deployment methodology.</figcaption></figure>

The proof-of-concept is based on the same system as our work on state control (Renard et al., 2024). It is composed of two infeed conveyors, an outfeed conveyor, and a robotic arm allowing transfer between the infeed and discharge conveyors (Figure 10). For each episode, four parts are generated on each conveyor with random time delays.

<table><caption>Table 1: Table description</caption><thead><tr><th>Task</th><th>Description</th><th>Non-parallel tasks</th><th>compatible</th></tr></thead><tbody><tr><td>T1</td><td>Feed parts to position 1</td><td>T12</td><td></td></tr><tr><td>T2</td><td>Feed parts to position 3</td><td>T13</td><td></td></tr><tr><td>T3</td><td>Rotation without parts 0 to 1</td><td>T6</td><td></td></tr><tr><td>T4</td><td>Rotation with parts 1 to 2</td><td>T12</td><td></td></tr><tr><td>T5</td><td>Deposit parts</td><td>T8, T9, T10, T11</td><td></td></tr><tr><td>T6</td><td>Rotation without parts 0 to 3</td><td>T3</td><td></td></tr><tr><td>T7</td><td>Rotation with parts 3 to 2</td><td>T8, T13</td><td></td></tr><tr><td>T8</td><td>Rotation without parts 2 to 0</td><td>T5, T7, T10, T11</td><td></td></tr><tr><td>T9</td><td>Evacuate parts</td><td>T5</td><td></td></tr><tr><td>T10</td><td>Rotation without part 2 to 1</td><td>T5, T8, T11</td><td></td></tr><tr><td>T11</td><td>Rotation without parts 2 to 3</td><td>T5, T8, T10</td><td></td></tr><tr><td>T12</td><td>Take parts in position 1</td><td>T1, T4, T8</td><td></td></tr><tr><td>T13</td><td>Take parts in position 3</td><td>T2, T7, T8</td><td></td></tr></tbody></table>

<figure><img src="image_11.png" /><figcaption>Figure 10: Proof-of-concept System</figcaption></figure>

The system was broken down into thirteen operative tasks, with (Taillard, 2010) method, corresponding to the functions necessary for evacuating the parts (Table 1). Task programs are available in a GitHub repository<fnref n="1" />. A safety constraint is added when running 2 tasks in parallel can cause security issues. Thirteen safety constraints between operative tasks have been defined. The function of each task is specified in GRAFCET (International Electrotechnical Commission, 2013) and automatically generated in Python. Each task is evaluated separately within the simulation. For each task, a corresponding template is incorporated into the Supremica project (Figure 11). Task 9, which involves removing parts, serves as the final system task (Figure 4). This task represents the sole objective of the system, with its marked state directly fed into the task FSM. A specific initial state must be defined for each observer.

Constraints between tasks are integrated in the form of eight filter instances. The "FILTER_5_8_10_11" filter corresponds to constraints between tasks 5-8, 5-10, 5-11, 8-10, 8-11, and 10-11, which are combined into a single model. The observers used in the tasks EFSM models are instantiated in variable type. Each observer has a fixed definition domain (4 observers [0,1] and 1 observer [0,1,2,3]). From these models, a monolithic supervisor is generated from the SCT algorithms of Supremica. Table 2 shows the impact of using filter templates in the supervisor generation.

<figure><img src="image_12.png" /><figcaption>Figure 11: Tasks, Filters, Observers</figcaption></figure>

<table><caption>Table 2: Supervisor comparison</caption><thead><tr><th>Name</th><th>States</th><th>Transitions</th></tr></thead><tbody><tr><td>Tasks</td><td>52704</td><td>317896</td></tr><tr><td>Tasks + Filters</td><td>306</td><td>858</td></tr></tbody></table>

The generated supervisor is translated into Python code and linked to both the task programs and the automation engineer-defined priority settings like explain in the PLC implementation structure. Furthermore, task authorization events are evaluated in accordance with the priority order specified by the engineer (Figure 12). If the event is feasible within the supervisor, the task will be initiated via the variable task[X].AUT. Otherwise, the event is ignored and has no impact on the task.

<figure><img src="image_13.png" /><figcaption>Figure 12: Interactions with the supervisor and Task 1 GRAFCET.</figcaption></figure>

<footnote n="1">¹ https://github.com/DimitriRenard/RL-ST-Logic-Controller</footnote>
The uncontrolled events are computed at the end of the program (Figure 13). They have an indirect relationship with the sensor, as illustrated by task 1 ending up in state X11 with the sensor wait1. The transition function FTX11 represents the end of the task. However, it is only when the task is completed that the supervisor undergoes a change, rather than through changes to the sensor value itself.

```c
if FTX11:
    trigger_event(Events['END_T[1]'])
if FTX21:
    trigger_event(Events['END_T[2]'])
```

<caption>Figure 13: Trigger of uncontrollable events.</caption>

Factory IO in this phase is used like the real system to assess the logic controller design methodology.

## 6. CONCLUSIONS

In conclusion, our paper proposes supervisory-based architecture for logic controller design. This architecture is based on indirect actuator control and indirect sensor collection, that solve supervisory implementation problematics. This novel approach addresses the implementation challenges associated with PLCs, offering a more efficient and effective method for designing control systems. Future research plans involve integrating this supervisor-based architecture with artificial intelligence to enable automatic learning and implementation of controllers in PLCs using standardized languages such as ST (Structured Text) from IEC 61131-3 but also to consider different initial states. We plan to apply this architecture to an industrial case to confront scaling problems.

## ACKNOWLEDGEMENTS

This research and development undertaking is conducted in the context of an industrial and academic collaboration (CIFRE convention) between Prosys and the CReSTIC laboratory of the University of Reims Champagne Ardennes, financed by Prosys and the National Association of Research and Technology.

## REFERENCES

* Cantarelli, M. and Roussel, J.-M. (2008) ‘Reactive control system design using the Supervisory Control Theory: Evaluation of possibilities and limits’, in. *WODES*, Gothenburg, Sweden: IEEE, pp. 200–205.
https://doi.org/10.1109/WODES.2008.4605945.

* Cassandras, C.G. and Lafortune, S. (2021) *Introduction to discrete event systems*. Third edition. Cham: Springer.

* Fabian, M. and Hellgren, A. (1998) ‘PLC-based implementation of supervisory control for discrete event systems’, in. *Proceedings of the 37th IEEE Conference on Decision and Control (Cat. No.98CH36171)*, pp. 3305–3310
vol.3.
https://doi.org/10.1109/CDC.1998.758209.

* Frey, G. and Litz, L. (2000) ‘Formal methods in PLC programming’, in. *Smc 2000 conference proceedings*, Nashville, USA, pp. 2431–2436 vol.4.
https://doi.org/10.1109/ICSMC.2000.884356.

* Göbe, F. et al. (2016) ‘Synthesis Tool for Automation Controller Supervision’, in. *2016 13th International Workshop on Discrete Event Systems (WODES)*, pp. 424–431.
https://doi.org/10.1109/WODES.2016.7497883.

* Hill, R.C. and Lafortune, S. (2017) ‘Scaling the formal synthesis of supervisory control software for multiple robot systems’, in. *2017 American Control Conference (ACC)*, pp. 3840–3847.
https://doi.org/10.23919/ACC.2017.7963543.

* Hu, Y. et al. (2025) ‘Integrating reinforcement learning and supervisory control theory for optimal directed control of discrete-event systems’, *Neurocomputing*, 613, p. 128720.
https://doi.org/10.1016/j.neucom.2024.128720.

* International Electrotechnical Commission (2013) ‘GRAFCET specification language for sequential function charts, IEC 60848’.

* Malik, R. et al. (2017) ‘Supremica–An Efficient Tool for Large-Scale Discrete Event Systems’, *IFAC-PapersOnLine*, 50(1), pp. 5794–5799.
https://doi.org/10.1016/j.ifacol.2017.08.427.

* Marangé, P. (2008) *Synthesis and robust filtering of control for dependable manufacturing systems*. PhD thesis. Université de Reims Champagne-Ardenne.

* Possato, T. et al. (2024) ‘Automated Code Generation for DES Controllers Modeled as Finite State Machines’, in H. Barbosa and Y. Zohar (eds) *Formal Methods: Foundations and Applications*. Cham: Springer Nature Switzerland, pp. 113–130.
https://doi.org/10.1007/978-3-031-49342-3_7.

* Ramadge, P.J.G. and Wonham, W.M. (1989) ‘The control of discrete event systems’, *Proceedings of the IEEE*, 77(1), pp. 81–98.
https://doi.org/10.1109/5.21072.

* Ranger, T., Philippot, A. and Riera, B. (2021) ‘Manufacturing Tasks Synchronization by Algebraic Synthesis’, *IFAC-PapersOnLine*, 54(4), pp. 226–231.
how
https://doi.org/10.1016/j.ifacol.2021.10.038.

* Reijnen, F.F.H. et al. (2022) ‘Supervisory controller synthesis and implementation for safety PLCs’, *Discrete Event Dynamic Systems*, 32(1), pp. 115–141.
https://doi.org/10.1007/s10626-021-00350-4.

* Renard, D. et al. (2024) ‘From Reinforcement Learning to Reality: Generating Structured Text Logic Controller’, in. *CODIT 2024*, Valetta, Malte.

* Riera, B. and Vigário, B. (2017) ‘HOME I/O and FACTORY I/O: a virtual house and a virtual plant for control education’, in. *IFAC World Congress*, Toulouse, France, pp.
9144–9149.
https://doi.org/10.1016/j.ifacol.2017.08.1719.

* Sköldstam, M., Akesson, K. and Fabian, M. (2007) ‘Modeling of discrete event systems using finite automata with variables’, in. *2007 46th IEEE Conference on Decision and Control*, pp. 3387–3392.
https://doi.org/10.1109/CDC.2007.4434894.

* Taillard, P. (2010) ‘L’analyse structurée par tâches’, *technologie*, 170, pp. 38–43.

* Zaytoon, J. and Riera, B. (2017) ‘Synthesis and implementation of logic controllers – A review’, *Annual Reviews in Control*, 43, pp. 152–168.
https://doi.org/10.1016/j.arcontrol.2017.03.004.