The title is deliberately provocative, and I’ll attempt to convince you it’s true in a few paragraphs as well as give some real depth into cyber-physical control systems.


The NIST definition of Cyber-Physical Systems:

Cyber-Physical Systems or “smart” systems are co-engineered interacting networks of physical and computational components. These systems will provide the foundation of our critical infrastructure, form the basis of emerging and future smart services, and improve our quality of life in many areas.


This is the important phrase in the definition, ‘interacting networks of physical and computational components,’ and it’s the physical I want to talk about first. Take a look at The International Federation of Automation and Control, IFAC, and their 2020 World Congress. Note that this congress is six days. I had the pleasure of giving a track keynote a few years back and I was astounded at the breath, depth, and general size of this event. Much of the material at IFAC-WC is about control theory. This is a branch of mathematics developing models, algorithms, and processes that can be used to control physical systems. One of the earliest examples of control is the governor of a steam engine. Two weights on a rotating shaft connected to the main shaft of the engine and allowed to pivot outward as the shaft increased its rotational speed. These weights were then connected via various linkages to the valve that let more or less steam into the piston chamber. By adjusting the weights, one could set a speed on the engine. If the engine slowed, the weights would fall inward, opening the valve and letting in more steam and oppositely if the engine sped up too much.


Controllers progressed from mechanical as above through different technologies ending up in digital systems. The main component of a controller, in whatever technology, is the ‘control loop’. Here’s a naively simplified version in a digital controller.


targetRPM = 2400

while (while_machine_is_operating) {

sensorVector = read(sensors)

if sensorVector.RPM < targetRPM {

output(sensorVector, moreEnergy)

{ else }

output(sensorVector, lessEnergy)





Control loops have a period that’s typically expressed as an interval, e.g., 1 millisecond, or a frequency, e.g., 1KHz. If the above had a 1KHz frequency, it would loop every millisecond to check the revolutions per minute (RPM) and apply a correction if necessary. Now, the function ‘output’ would, in practice, be very complex and potentially take in lots of inputs including what the loop itself did in a number of previous iterations.


Temporal Requirements

The main observation I’d like the reader to take away from the above is that control loops have a Temporal Requirement. These temporal requirements are functional requirements in that if the system does not meet them, then the system is considered to have failed. The loop above must execute every single millisecond, forever. No if’s, no and’s, no maybe’s, or but’s! Saying that the temporal requirement is functional is as strong as saying that the ‘plus’ operator give a correct mathematical answer when given two operands. Yes, missing one of the iterations can be as bad as computing that 2 + 2 = 6.


I hope everyone reading this now has some understanding of how difficult is it to meet the temporal requirements of many controllers using, what’s known as, a general-purpose computing machine, i.e., your laptop, your phone, enterprise servers, the web, etc. I’ll make one ask of you, think of this as homework :). Be aware of every time your browser, phone, laptop, or random app, does not return in a typical amount of time after you asked it to do something. You will be amazed at how inured you have become to the wildly erratic response times of typical general-purpose computing machines.


Fundamental Components of an IoT System

Now that you have a background into the hard real-time control loop of the computational component of a cyber-physical system, let’s expand our view and include some IoT pieces of the computational components.


I’ll make my first assertion of this blog now:

Any IoT system fundamentally only comprises of three phases: get some data, analyze that data, and produce value.


I would expect every reader to agree that these three fundamental components of an IoT system, although in practice really, really complex, are all implemented by general-purpose systems. Thus, the statistical distribution of the interval between the time a datum comes into existence and the time value produced from it has a very long tail and is poorly defined. Real-time systems have a much shorter and well-defined tail and in the case of hard real-time systems, an upper bound on the length of the interval between data acquisition and control output.


General-Purpose vs. Real-Time Systems

I’ll jump aside now with an interesting example to provide just a little more insight into the difference between general-purpose and real-time systems. The specification for the display of video is expressed as a hard real-time system. The specification states the display rates for video are expressed as an integer number of frames per second, e.g., 30 fps. This is a hard real-time temporal requirement. It’s not given as ‘about’ 30 fps but exactly 30 fps. Of course, everyone knows we play video on general-purpose systems and the system cannot guarantee that the display rate is exact, e.g., 30 fps, but, the consequences of not getting the display rate are inconsequential. However, if the real-time system is controlling a rocket engine, the consequences of missing hard real-time deadlines can be very consequential.


My second assertion:

An IoT system’s output must never affect the temporal requirement of a hard real-time control loop for which the consequences of missing a deadline are significant.


I hope that now, the above assertion is obvious to everyone. However, let’s look at an example of how the output of an IoT system might offer a suggestion to a safety-critical hard real-time control loop for which the violation of safety and/or temporal requirements could be disastrous, traffic signals (my personal pet peeve).


My final assertion:

An IoT traffic optimization system will never control the individual lights of traffic signals but rather make suggestions to the safety-critical hard real-time control loop to alter the ratio of the green intervals among the various directions of travel based on (more) global knowledge of the traffic situation.


It should be clear now that we don’t ever want to control the on/off cycles of the individual lights of a traffic signal with outputs from a general-purpose IoT system. It may seem to be a subtle difference between ‘affecting the temporal requirement’ and ‘making a suggestion for alternative behavior’ to control loops but it is, as we have seen, not. And externally the lay person would certainly say that the traffic signals are better behaved because of the newly installed IoT system ‘controlling’ them, but we know better!