Scope
For simplicity, this article treats stability as a binary property. In practice, stability can be analyzed at different levels, including static stability, dynamic stability, performance and robustness considerations. Real control systems also exhibit a broad range of dynamic behaviors, including underdamped, critically damped and overdamped responses. These topics are important, but they are beyond the scope of this article.
The purpose of this article is not to teach control theory, but to demonstrate a simpler point:
Meeting a timing deadline does not guarantee correct closed-loop behavior.
A Useful Simplification
I’ve heard it often enough that I no longer treat it as an anecdote:
«In embedded systems, all that matters is the deadline.»
The idea is familiar:
- A task is scheduled
- Its WCET is measured
- Jitter is under control
- Deadlines are met
Correct system. End of discussion.
The statement is not wrong. In fact, in some domains it is entirely correct. The problem begins when it is applied outside the domain where it was originally valid.
This article argues that deadlines are an important property of a control system, but they are only one property among many.
When The Deadline Is Enough
There are many embedded applications where timing constraints are effectively the entire problem. Examples include:
- Data acquisition tasks
- Communication gateways
- Protocol converters
- Logging systems
- Message dispatchers
In these systems:
Input -> Computation -> Output
- No physical plant is being controlled.
- No feedback loop exists.
- No dynamic stability must be preserved.
For such systems, the question «did the task complete before its deadline?» is often enough. It is often the primary metric.
The Hidden Assumption
Closed-loop control systems are fundamentally different.
A controller does not interact exclusively with software. It interacts with physics.
The plant has its own dynamics, the feedback path introduces delays, actuators have limits, sensors contain noise… The controller is only one component in a much larger system. As such, meeting the deadline does not automatically guarantee that the resulting closed-loop behavior is acceptable.
Two Different Questions
Control systems live in two different domains.
Timing Analysis
Timing analysis answers:
When does the controller execute?
Typical concerns include:
- Deadline
- WCET
- Scheduling
- CPU utilization
- Jitter
Control Analysis
Control analysis answers:
What happens after the controller executes?
Typical concerns include:
- Bandwidth
- Phase margin
- Gain margin
- Disturbance rejection
- Robustness
Both analyses are necessary. Neither replaces the other. The mistake is assuming that success in one automatically guarantees success in the other.
Four Possible Outcomes
A useful experiment is to separate timing correctness from dynamic correctness.
| Deadline Met | Stable | ✅Desired Outcome |
| Deadline Met | Unstable | ❌ Dangerous Outcome |
| Deadline Missed | Stable | ❌ Timing Violation |
| Deadline Missed | Unstable | ❌ Complete Failure |
Notice that:
Deadline met ≠ Stable System
The two properties are often related, but they are not equivalent.
What Deadlines Cannot See
Meeting a deadline tells us that the computation completed in time. It tells us nothing about:
- Stability: Whether the closed-loop system remains stable.
- Phase margin: How much additional phase lag the system can tolerate before becoming unstable.
- Gain margin: How much loop gain variation the system can tolerate before instability occurs.
- Control Bandwidth: Whether the system can adequately respond to the dynamics of the plant.
- Robustness: How the system behaves when parameters, sensors, or operating conditions change.
None of these quantities appear in a scheduler log. A scheduling trace cannot tell us any of these things. A timing log can look perfect while the control system is only a few degrees away from oscillation.
When Timing Is Not The Problem
Similar situations have appeared repeatedly in aerospace systems.
The software executes exactly as expected.
The closed-loop dynamics are the problem.
Timing correctness and control correctness are not the same thing.
Deadline Reductionism
Definition of Deadline Reductionism:
The reduction of control-system correctness to the sole satisfaction of timing constraints while ignoring the stability and robustness properties of the closed-loop system.
The concept does not argue against:
- Deadlines
- WCET analysis
- Scheduling theory
All of these remain necessary. The criticism targets the belief that they are enough.
The Missing Requirement
Many embedded requirements look like this:
- The control loop shall execute every 10 ms.
This requirement is useful.
But it is incomplete.
A more complete specification could be:
- The control loop shall execute every 10 ms.
- The closed-loop system shall satisfy the specified phase margin requirements (for example, 45°).
- The closed-loop system shall satisfy the specified gain margin requirements (for example, 6 dB).
- The closed-loop system shall remain stable across the specified range of plant parameter variation (for example, ±20%).
- The closed-loop system shall satisfy the specified disturbance rejection requirements (for example, settling time below 500 ms).
The first requirement describes timing. The remaining requirements describe behavior.
Both are required.
Conclusion
The deadline was never the problem.
The problem is treating the deadline as the whole problem.
Meeting a deadline tells us:
The controller executed on time.
It does not tell us:
The control system is stable.
It does not tell us:
The control system is robust.
It does not tell us:
The control system will remain stable under real operating conditions.
Timing correctness is an important property of a control system.
It is simply not the only one. A controller that executes perfectly on time can still drive a system directly into instability.
The deadline is necessary. It was never sufficient.
This is why I become skeptical when somebody introduces a system as either hard real-time or soft real-time and assumes the discussion is over.
Those labels describe timing properties.
They do not describe stability.
They do not describe robustness.
They do not describe whether the closed-loop system is actually viable.
When timing classification is presented as a complete system analysis, I start wondering what aspects of the control problem have not been analyzed.