When Controllers Must Command: The Mathematics of Mandatory Actions Under Imperfect Observation

The Gap Between How We Program Machines and How Machines Actually Work

In 1987, a pair of researchers named Ramadge and Wonham introduced a revolutionary way to think about controlling machines. Their framework, called supervisory control theory, treated the relationship between a controller and a machine as a kind of negotiation: the controller would enable certain actions and disable others, but ultimately, the machine itself would decide which of the enabled actions to take. The controller sets the menu; the machine chooses what to eat.

This abstraction proved enormously useful. It let engineers design controllers for manufacturing robots, traffic systems, communication networks, and automated production lines with mathematical rigor. For nearly four decades, it has been the backbone of formal approaches to discrete-event systems—systems that move through states by responding to discrete events like "door opens," "sensor detects object," or "emergency stop pressed."

But here's the problem: the Ramadge-Wonham model doesn't always match reality.

When a pilot pushes a throttle forward, that engine doesn't get to decide whether to accelerate. When an automated system sends a command to a robot arm, that arm doesn't have the option to ignore the instruction. When a safety system triggers an emergency shutdown, nothing in the machinery gets to vote on whether to comply. In the real world, controllers don't just permit and forbid—they command.

This gap between theory and practice has bothered researchers for years. A recent paper by Yin Tong of Southwest Jiaotong University and Kai Cai of Osaka Metropolitan University takes direct aim at it. Their work, "Supervisory Control with Event Forcing Under Partial Observation," doesn't just identify the problem—it solves it. They introduce a new mathematical concept called forcing consistency that finally allows engineers to design controllers that can issue mandatory commands, even when the controller can only see part of what's happening in the system.

The implications stretch from factory floors to spacecraft. Anywhere a machine needs to do more than passively accept permissions—anywhere it must actively compel behavior—this work provides the theoretical foundation for making that possible.

When Controllers Can't See Everything

Before diving into the paper's contributions, we need to understand why partial observation matters so much.

In an ideal world, a controller would have perfect information. It would see every event that happens, know exactly what state the system is in, and make decisions based on complete knowledge. But real systems don't work that way. Sensors have limitations. Some events are too fast to capture; others happen in parts of the system that aren't instrumented. A temperature sensor might detect that something went wrong, but not which specific component failed. A network monitor might know that data was lost, but not which packet in which stream.

This creates a fundamental challenge: the controller might observe the same thing from two completely different underlying situations. Imagine you're supervising a system where two different strings of events—call them $s_1$ and $s_2$—both look identical from the controller's perspective. After observing this indistinguishable sequence, the controller must make a decision about what to do next. But that decision needs to work for both $s_1$ and $s_2$, even though one might be perfectly safe and the other might be dangerously wrong.

This is the classic problem of observability in control theory. The controller can't distinguish between different scenarios, so its decisions must be consistent across all scenarios that look the same.

Under traditional supervisory control, where the controller simply enables or disables events, this problem is well-understood. The controller's decision for a given observation is simply the union of all safe actions across all possible underlying scenarios—excluding anything that would be unsafe for any of them. If two scenarios disagree about whether a particular event is safe, you can't include it in your decision, because including it would be unsafe for at least one scenario.

But when you move from enable/disable to forcing—when the controller can actively compel events to happen—the mathematics becomes much messier. And that's exactly what Tong and Cai's paper addresses.

The Forcing Mechanism: When Commands Must Be Obeyed

Event forcing represents a fundamentally different relationship between controller and machine. In the traditional Ramadge-Wonham framework, the controller says "you may do these things" and the machine says "I choose this one." In a forcing framework, the controller says "this will happen now," and the machine has no choice.

Think of it this way: in traditional control, disabling an event is like removing an option from a menu. The machine can still choose among the remaining options. In forcing control, forcing an event is like the chef coming out of the kitchen and putting a specific dish on your table. Other dishes aren't just unavailable—they're actively preempted.

This distinction matters enormously in safety-critical systems. If you're designing an emergency shutdown system, you don't want to simply disable unsafe events and hope the machine cooperates. You want to force the shutdown event to happen, preempting everything else, guaranteeing that the system transitions to a safe state regardless of what it was doing before.

The technical setup works like this: the system has a set of forcible events—actions that the controller can command. When the controller forces one of these events, it happens immediately, and any other events that were enabled at that moment are preempted. The controller can force multiple events in its decision, but only one will actually execute; the others get preempted by the one that does execute.

This creates a more powerful control mechanism, but also a more complex one. With enable/disable, preventing something is straightforward: just don't include it in your enabled set. With forcing, things get tangled. Forcing event A might prevent event B not because B is explicitly disabled, but because A took precedence. And forcing event C might prevent event D, even though D is perfectly safe, just because C happened to be forced instead.

Tong and Cai's earlier work, published jointly with Reniers, established the theoretical foundation for forcing control under full observation—where the controller sees everything. They introduced the concept of forcibility: a property that specifies when a desired behavior can be achieved by a forcing controller. Forcibility, like its counterpart controllability in traditional control, is closed under union, which means that for any specification, there's a unique "supremal" forcible sublanguage—the largest safe behavior that can be achieved.

But full observation is a luxury. Real systems have blind spots. And when those blind spots exist, the forcing mechanism faces new challenges that didn't arise before.

The Consistency Problem Nobody Had Solved

Here is the core difficulty that Tong and Cai identify.

Under traditional supervisory control with partial observation, the concept of observability ensures that when the controller sees the same thing from different scenarios, it makes consistent decisions. Specifically, for any observable event (an event the controller can see), the decision to enable or disable it must be the same across all scenarios that produce the same observation.

With forcing, the analogous requirement would be that for any forcible event, the decision to force it or not must be consistent across indistinguishable scenarios. But the researchers discovered something surprising: this consistency condition, even when satisfied, isn't enough.

Consider two plant automata, $G_1$ and $G_2$, shown in

. Both have the same event set: two regular events $e_1$ and $e_2$, and two forcible events $f_1$ and $f_2$. All events are observable. The specification $K_1$ removes just one transition—$s_2 e_1$—from the language of $G_1$.

Here's what happens. After observing $w$, three different strings are possible: $s_1$, $s_2$, and $s_3$. The controller needs to prevent $e_1$ after $s_2$. The forcible event $f_1$ can do this—it preempts $e_1$ while keeping $s_2 f_1$ within the specification.

Now, is the decision to force $f_1$ consistent across all scenarios? Yes, it is. For $s_1$, $s_2$, and $s_3$, forcing $f_1$ keeps everything within the specification. So the natural thing to do would be to force $f_1$ after observing $w$: $S(w) = {f_1}$.

But this creates a problem. After $s_1$, forcing $f_1$ preempts $f_2$. So even though $s_1 f_2$ is perfectly safe and allowed by the specification, it can never happen, because forcing $f_1$ preempts it. The closed-loop behavior ends up excluding both $s_2 e_1$ (what we wanted to exclude) and $s_1 f_2$ (what we didn't want to exclude).

What if the controller forces both $f_1$ and $f_2$? Then $e_2$ gets preempted after $s_3$, excluding another safe behavior. What if it forces neither? Then $e_1$ can happen after $s_2$, violating the specification.

The specification $K_1$ is forcible—that is, under full observation, a forcing controller could achieve it. But under partial observation (or in this case, even with full observation, when multiple indistinguishable strings exist), no forcing decision exists that achieves exactly $K_1$ while preserving all other safe behaviors.

This is a fundamentally different problem than in traditional control, where the decision to disable an event never inadvertently prevents other events from happening. With forcing, forcing one event can preempt others, creating dependencies that don't exist in the enable/disable framework.

Tong and Cai found that the problem gets worse under partial observation. In the second plant $G_2$, the specification $K_2$ (removing the same $s_2 e_1$ transition) is forcible. But the naive control decision—force everything that could preempt unsafe transitions, minus anything that would itself be unsafe—doesn't work. Following that logic would suggest $S(w) = {f_1}$, but this still excludes $s_1 f_2$, which is safe. To actually achieve $K_2$, the controller would need to force both $f_1$ and $f_2$, even though $f_2$ isn't needed to prevent any unsafe transitions after $s_2$.

The intuition from traditional control—that you simply exclude what would be unsafe and include what would be safe—breaks down completely.

Forcing Consistency: A New Mathematical Property

The solution Tong and Cai develop is elegant but technical. They introduce forcing consistency as a new property that language specifications must satisfy for a forcing controller under partial observation to exist.

The key insight is that forcing decisions can't be thought of as per-event choices. Instead, you need to think about a common set of forcible events, $E_f^{cd}(w)$, that gets forced together after observation $w$. This set must satisfy a condition for every indistinguishable string in the observation's preimage:

For each $s$ in the set of strings that look like $w$ from the controller's perspective:

Either forcing at least one event in the common set will keep the continuation within the specification while forcing any event outside it would violate the specification, OR

Not forcing anything is itself safe—meaning no active event can lead outside the specification.

In formal terms, the specification $K$ is forcing consistent if for every observation $w$, there exists a subset $E_f^{cd}(w) \subseteq E_f$ such that for all strings $s$ consistent with $w$:

$$\text{If }\Gamma (s)\cap E_f^{cd}(w)\ne \varnothing \Rightarrow {\Gamma }_K(s)=E_f^{cd}(w)\cap \Gamma (s)$$$$\text{or}$$$$\text{If }\Gamma (s)\cap E_f^{cd}(w)=\varnothing \Rightarrow \Gamma (s)={\Gamma }_K(s)$$

Where $\Gamma(s)$ represents all events active after $s$, and $\Gamma_K(s)$ represents only those events whose occurrence would keep the system within the specification.

This is dense mathematics, but the intuition is clear: for every observation, there must exist a single forcing decision that works consistently across all underlying scenarios. The decision might involve forcing some events, or it might involve forcing nothing, but it can't be a mix-and-match approach where different scenarios require different decisions.

The researchers prove that forcing consistency is necessary and sufficient for the existence of a supervisor achieving a given specification. That is, a forcing controller under partial observation exists if and only if the specification is forcing consistent.

This is a strong result. It gives engineers a clear condition to check when designing such systems. If the specification isn't forcing consistent, no forcing controller can achieve it under partial observation—full stop.

How Forcing Consistency Relates to Forcibility

The paper establishes an important relationship between forcing consistency and the previously studied property of forcibility.

Forcibility, remember, is the condition needed for forcing control under full observation. It's the equivalent of controllability in traditional supervisory control. If a specification is forcible, a forcing controller can achieve it when the controller sees everything.

Tong and Cai prove that forcing consistency is strictly stronger than forcibility. Every forcing-consistent specification is also forcible. But the converse isn't true. The example with $K_1$ demonstrates this: $K_1$ is forcible (it can be achieved under full observation), but it's not forcing consistent (no forcing decision exists that achieves it while preserving all other safe behaviors).

This makes intuitive sense. Forcibility ensures that some forcing action could keep the system within the specification. Forcing consistency ensures that the same forcing action works uniformly across all indistinguishable scenarios. The latter is a stricter requirement.

Here's why this matters: under full observation, forcibility is a necessary and sufficient condition for supervisor synthesis. The property is also closed under union, which means that for any specification, there's a unique "supremal forcible sublanguage"—the largest safe behavior that can be achieved. This supremal sublanguage represents the maximally permissive controller, which gives the system as much freedom as possible while still guaranteeing safety.

But under partial observation, the supremal property disappears. Forcing consistency is not closed under union. This has profound implications.

Why the Supremal Supervisor Doesn't Exist

In traditional supervisory control, the supremal controllable sublanguage always exists. Given any specification, there is a unique largest sublanguage that is controllable. This supremal sublanguage can be computed algorithmically, and it represents the most permissive safe controller.

Tong and Cai show that no equivalent exists for forcing consistency. The property fails to be closed under union: if two specifications are forcing consistent, their union might not be.

Consider the plant $G$ shown in

. It has two special forcible events, $f_{u1}$ and $f_{u2}$, that can only be forced before the system branches. The controller can observe the forcible event $f$ but not the uncontrollable branching events.

Two forcing-consistent sublanguages exist: $K_1 = \overline{{f_{u1} f, f_{u1} e_1}}$ and $K_2 = \overline{{f_{u2} f}}$. Both can be achieved by forcing controllers. But their union isn't forcing consistent.

Why? Because after observing nothing (the empty string $\varepsilon$), $K_1$ requires forcing $f_{u1}$ to preempt the $e_2$ branch, while $K_2$ requires forcing $f_{u2}$ to preempt the $e_3$ branch. But only one of these can be forced, since forcing one preempts the other. There's no single forcing decision that works for both specifications simultaneously.

This matters enormously for applications. In traditional control, if you have two safe behaviors and want to implement the union (giving the system the most freedom), you can always compute the supremal controllable sublanguage and implement that. But in forcing control under partial observation, combining even safe behaviors can create problems.

The absence of closure under union means there is no unique maximally permissive forcing-consistent sublanguage in general. Engineers designing systems must think more carefully about what specifications are truly achievable.

A Visual Framework for Thinking About Forcing Consistency

To make these concepts concrete, consider the decision structure that forcing consistency imposes.

Relationship Between Forcibility and Forcing Consistency

Label	Value
Forcibility (Full Observation)	100
Forcing Consistency (Partial Observation)	60
Both Properties	60

Forcing consistency is strictly stronger than forcibility. All forcing-consistent specifications are forcible, but the converse does not hold. This means fewer specifications can be achieved under partial observation.

This diagram shows the relationship between different control properties in the forcing framework. Forcibility, under full observation, is necessary and sufficient for supervisor existence, and it's closed under union, ensuring a supremal solution. Forcing consistency, under partial observation, is also necessary and sufficient—but it's strictly stronger than forcibility and NOT closed under union, breaking the supremal guarantee.

Why the Classical Logic Fails: Example from Plant G2

Label	Value
Force $f_1$ only (naive approach)	2
Force $f_1$ and $f_2$ (correct approach)	0

Under the classical 'include preemptors, exclude preemptees' logic, forcing only $f_1$ would be the natural choice. However, this excludes safe behavior $s_1 f_2$. The correct decision forces both events.

This second visualization shows the key insight from Example III.4. Under the traditional enable/disable logic (force all preemptors, exclude all preemptees), the natural decision after observing $w$ would be $S(w) = {f_1}$. But this fails to achieve the specification $K_2$ because it excludes $s_1 f_2$, a safe transition. The correct decision is actually $S(w) = {f_1, f_2}$—forcing an event that isn't necessary for preemption, just to avoid inadvertently preempting something that should be allowed.

Closure Properties: Full vs. Partial Observation

Label	Value
Forcibility (Full Observation)	100
Forcing Consistency (Partial Observation)	100

Under full observation with forcing, a supremal forcible sublanguage always exists. Under partial observation, the lack of union closure means no unique supremal forcing-consistent sublanguage generally exists.

This third chart shows the properties of forcing consistency compared to related concepts. Forcibility under full observation has a supremal element (closed under union). Observability under partial observation in traditional control also has a supremal (via controllability). But forcing consistency breaks this pattern—neither union nor intersection closure, meaning no supremal forcing-consistent sublanguage in general.

What This Means for Real Systems

The implications of this work extend across any domain where controllers need to issue mandatory commands rather than just permissions.

Consider a manufacturing robot arm. Under traditional supervisory control, the controller might disable certain unsafe configurations. But if the robot can choose among multiple enabled actions, it might pick one that, combined with environmental factors the controller can't see, leads to a dangerous state. With forcing control, the controller could preemptively command the arm to move to a safe configuration, guaranteeing safety regardless of what the robot was doing.

Or consider an autonomous vehicle in an emergency situation. Traditional control might disable certain maneuvers that could be unsafe. But if the vehicle has multiple options, it might pick one that, combined with factors the controller can't observe, leads to a collision. A forcing controller could actively command the vehicle to execute an emergency stop, preempting all other actions and guaranteeing the safe state.

The partial observation aspect matters because in real systems, sensors are never perfect. A factory floor might have cameras monitoring most areas but blind spots in others. A vehicle might have LiDAR that detects obstacles but can't always classify them precisely. A network system might detect that traffic is flowing but not which specific packets are being dropped.

Tong and Cai's framework gives engineers a mathematical condition—forcing consistency—that they can check when designing systems. If the desired behavior isn't forcing consistent, they know immediately that no forcing controller under partial observation can achieve it. They can then either revise the specification, improve the observability of the system (add more sensors), or accept that forcing control isn't appropriate for this particular requirement.

The framework also suggests a verification approach. The researchers mention that forcing consistency can be checked using an observer-based method—transforming the specification into a state-based representation and constructing the observer automaton, similar to methods used in traditional supervisory control. This makes the theory computationally tractable, at least in principle.

The Road Ahead: Open Questions and Future Work

The paper is careful to acknowledge its limitations and point toward future research.

First, the current framework focuses exclusively on forcing. Traditional supervisory control has both enable/disable and forcing mechanisms available, and the paper explicitly excludes their combination "to avoid the additional complication that arises when multiple control mechanisms overlap under partial observation." Extending the framework to handle both types of control simultaneously is explicitly identified as future work.

Second, while the paper establishes existence conditions (forcing consistency is necessary and sufficient for a supervisor to exist), it doesn't provide a synthesis algorithm. The earlier work on full-observation forcing control included a polynomial-time algorithm for computing the supremal forcible sublanguage. The partial-observation case, complicated by the lack of supremal closure, may require different approaches.

Third, the computational complexity of checking forcing consistency remains an open question. For traditional observability, checking the condition is polynomial in the size of the automaton representing the plant and specification. The forcing consistency condition, involving all indistinguishable strings and common forcing decisions across them, may be more demanding.

There's also the question of how forcing consistency interacts with other properties engineers care about—marking specifications (where certain states represent completed tasks), live specifications (where the system should keep doing things), and combinations thereof.

Finally, the paper's examples are deliberately simple automata. Real systems are larger, more complex, and often have timing constraints that aren't captured in the untimed model. Translating these theoretical results into tools that engineers can apply to industrial-scale systems will require additional development.

The Broader Significance

Tong and Cai's work matters beyond its immediate technical contributions. It represents a maturation of the forcing control paradigm from an interesting theoretical idea into a practical framework.

The earlier work on full-observation forcing control established that the concept was coherent—that there was a reasonable notion of forcibility, a synthesis algorithm, and a supremal solution. But practical systems rarely have perfect observation. By directly addressing partial observation, the new paper moves the framework closer to real-world applicability.

The forcing consistency concept itself is intellectually satisfying. It captures exactly the right condition: not just that forcing decisions could be made consistently, but that there's a common forcing decision that works uniformly across all indistinguishable scenarios. This is a subtle but crucial distinction, and the paper does an excellent job of motivating it through carefully chosen examples.

The negative results—the failure of closure under union, the non-existence of a supremal forcing-consistent sublanguage—might seem like setbacks. But they're actually valuable engineering guidance. They tell designers that forcing control under partial observation requires more careful specification than its traditional counterpart. They're not bugs; they're features of the model that reflect genuine constraints.

In the long run, this work contributes to a larger project: making control theory match how control actually works in engineered systems. Controllers issue commands. Sensors have limits. The world is messy and partially observed. Theory that ignores these realities is elegant but incomplete. Theory that embraces them is harder but more useful.

Tong and Cai have taken an important step toward that harder, more useful theory. Their forcing consistency condition gives practitioners a clear target, their examples illuminate the subtle pitfalls, and their negative results prevent false expectations. For anyone building systems where controllers must compel rather than merely permit, this is essential groundwork.

The next time you fly on an airplane with automated systems, or drive behind a vehicle with advanced driver assistance, or work near a collaborative robot—systems where controllers issue commands that must be obeyed—remember that somewhere in the background, mathematicians are working out exactly when those commands can be trusted, exactly what they can guarantee, and exactly what happens when the controller can't see everything.

This paper is a contribution to that ongoing effort. It's technical, it's abstract, and it won't make headlines. But for the engineers building the systems that keep us safe, it's the kind of theoretical foundation that makes reliable systems possible.