Summary: Engineers often ask whether a controller is deterministic. The more important question is why they ask. This article examines determinism not as an end in itself, but as a measure of confidence, predictability, and trust in real-world automation systems.
It has been nearly 80 years since the first successful execution of a computer program. When that first program written by Tom Kilburn at the University of Manchester ran on June 21st, 1948, every form of existing industrial control relied solely on hardware. Today, nearly every controller leverages software/firmware in the performance of its tasks. That has been a highly beneficial transition.
Back then, each control task was handled by its own independent hardware circuit or mechanical system. When the hardware had more than one control responsibility separate hardware components handled each task. The cost increased incrementally. However, there were still efficiencies in sharing power supplies, enclosures, etc.
The introduction of the microprocessor firmware-based controller created a huge advantage. This allowed algorithms to be easily tuned and expanded to automatically adapt as the parameters of the task varied. A single processor not only had the ability to accurately control a task; it had the capacity to manage multiple tasks. This was another huge efficiency gain.
The inherent control loop grew in complexity and dutifully handled each task in a repeated sequence. But not all tasks are of uniform complexity. Some required more effort on the part of the processor than others. Larger control systems trying to utilize a single processor were challenged by the competition over that resource. Performance measurements demonstrated concerns. The determinism of the software implementation was questioned.
That question is still valid today as Edge Controllers take on more and more responsibility.
Every control and automation engineer has in their vocabulary words like: deterministic. We know what it means.
Or do we?
The concept is there, but its meaning does depend on the situation. Think about how you would quantify it. You need something that you can measure and that takes you immediately to the specifics of the individual application. We would look to measure how closely a monitored parameter is held to setpoint. Perhaps we would look at its response to a step change. Look for the worst-case response times.
Those are certainly valid measures in quantifying the performance of a specific system. Perhaps even invaluable in comparing systems with identical responsibilities.
In a comparison, you might conclude that one system performs better than another. If there are multiple points of comparison then it is possible that one system does better at one thing and the other at another. And, are the results acceptable at all? What are the criteria?
That depends on the purpose. Before asking whether an automation platform is deterministic, we first need to understand what the platform is expected to do. A motion controller, a PID controller, a theater automation controller, and an MQTT gateway all have very different responsibilities. It follows that they are judged using different performance metrics.
An industrial controller tasked with controlling water temperature for a critical process must maintain that temperature within specific bounds. What we need to measure is obvious. From experience we know that some statistics will be required in that evaluation. The target performance should be very precisely defined in the documentation.
An automation controller tasked with managing lighting, curtains, and audio amplifiers in a cinema on the other hand, doesn’t immediately have metrics to measure. The question for that is whether it does its tasks reliably or not? Or, do the actions occur on cue? The latter speaking to a different form of response time. There is a different sort of determinism that applies in this situation.
In questioning the “determinism” of a particular device over another there must be a frame of reference. You need to consider suitability for a very specific and precise purpose. Without that, the concept truly becomes subjective.
Is our use of the word determinism really a proxy for another? Perhaps we truly look to measure our confidence in the device.
In the selection of an automation controller, you cannot rely on hardware specifications alone. General specifications such as clock frequency, memory capacity and storage space are useful but do not correlate directly with success. A lot depends on how those resources are applied and managed. Architecture matters. Design matters.
Consider that the first software-based industrial controllers performed admirably not with GHz multi-core processors. Not with MHz microcontrollers. But with very limited processors, implemented with discrete components, running with KHz clocks. And, handling that with ridiculously little memory capacity.
Those early controllers were purpose-built. They were successful because care was taken in insuring that the architecture addressed the performance characteristics that mattered. The engineers had confidence in their designs knowing that they were developed from the bottom up with attention to every detail. Everything contributed precisely as predicted. It had to.
That philosophy has influenced purpose-built industrial controllers for decades. It also became the guiding principle behind JNIOR. Our confidence comes from an architecture intentionally designed to deliver predictable behavior across the kinds of automation tasks it was built to perform.
As edge controllers assumed more responsibility, that confidence became increasingly dependent upon the architecture rather than hardware specifications. It might be tempting to think of an edge controller as simply another embedded computer running an application.
It is not.
The architecture of an edge controller is inherently interdisciplinary.
An industrial edge controller lives at the intersection of several very different worlds. It communicates downward to sensors, relays, motors, and instruments. It communicates sideways to neighboring controllers and equipment on the plant floor. It communicates upward to supervisory systems, databases, cloud services, and enterprise software.
While doing all of that, it stores configuration, records events, manages users, secures communications, serves web pages, hosts applications, schedules work, and responds to changing physical inputs.
Viewed individually, each of these responsibilities appears straightforward. Together, they become inseparable.
A web browser requests a status page while an application is recording an event. A secure network connection negotiates encryption while a relay changes state. Configuration data is updated while a serial device is delivering information. At the same time, digital inputs continue to change, timers expire, applications awaken, and network packets continue to arrive.
None of these activities exists in isolation. Every one competes for processor time, memory, storage, and communication bandwidth. A seemingly insignificant change in one subsystem can unexpectedly influence the behavior of another.
This is where industrial control differs from general-purpose computing.
Success is not measured by how quickly a single task completes. It is measured by how predictably the entire system behaves while many unrelated activities occur simultaneously.
That predictability is not an accident.
It is the product of architecture.
Confidence was not merely a goal for JNIOR. It had to become part of the development process itself.
Designing the hardware was relatively straightforward. A microcontroller, network interface, relay drivers, digital inputs, serial channels, and supporting electronics could all be analyzed, tested, and understood. Software presented a very different challenge.
An operating system eventually grows into hundreds of thousands of lines of code. Every function interacts with others. Every interface becomes another opportunity for unintended consequences. The question was not whether existing software components were good—they often were. The question was whether we could develop genuine confidence in third-party software whose internal assumptions, implementation decisions, and long-term interactions were only partially understood.
For us, the answer was no.
That realization led us to adopt the Cleanroom software engineering methodology originally developed at IBM. Its emphasis is not on finding defects after the fact, but on preventing them through disciplined design, careful implementation, and complete understanding of the software being created.
If confidence was to become a design objective rather than a marketing claim, then the development process itself had to reflect that objective.
JANOS was therefore developed from the ground up with a single architectural vision. The design requirements intentionally excluded third-party software at every level. Every subsystem—from the scheduler and networking stack to security, storage, and the Java Virtual Machine—would be developed under the same philosophy and with full knowledge of how it would interact with the rest of the system.
That decision demanded considerably more engineering effort than assembling proven software components. It also required us to independently develop many capabilities that were already available elsewhere, sometimes because licensing, patents, or architectural constraints left no practical alternative.
The reward was not simply complete ownership of the source code.
It was confidence. That confidence became part of the architecture itself. It remains one of the foundations upon which JANOS continues to evolve today.
Modern software is often assembled rather than designed. Every engineering project begins in roughly the same way.
That isn’t a criticism. It is one of the greatest strengths of our industry. We build upon decades of engineering rather than reinventing every component ourselves. Operating systems, communication stacks, databases, web servers, security libraries, messaging frameworks, and countless other building blocks allow remarkably sophisticated systems to be created in a fraction of the time it once required.
Requirements are gathered. A processor is selected. An operating system is chosen. Libraries are added. Drivers are installed. A web server is configured. Security is enabled. A database is integrated. Messaging is bolted on. A dashboard is built.
Individually, each decision is reasonable. Every one of those components flexibly solves a real problem. Every one also arrives with its own assumptions, interfaces, resource requirements, configuration, update cycle, and priorities.
Individually, those decisions are entirely reasonable.
Collectively, they create something that no one actually designed.
This is particularly true in the world of industrial edge computing. An edge controller is expected to perform a very wide variety of activities all while responding to changing inputs — while remaining deterministic enough to control real equipment.
When these capabilities are assembled from independent software modules, the result is often a carefully balanced ecosystem. Every addition introduces another relationship that must be understood, configured, tested, maintained, and eventually updated. Success depends not only on selecting the right components, but on ensuring they coexist without compromising the reliability of the system as a whole.
None of this is inherently wrong. In fact, for many classes of products it is exactly the right approach. That’s simply the way modern embedded systems are built.
But it raises an interesting architectural question.
Is an industrial edge controller simply another application running on a general-purpose software stack?
Or should the responsibilities that define an edge controller become part of the core operating system itself?
That question became central during the development of JANOS.
JANOS followed a different path. Its networking, security, web server, registry, application environment, scheduler, and event model were never independent products. They were conceived as parts of the same operating system and evolved together over time. No subsystem had a prior life of its own. Each was developed with full knowledge of the others, allowing the system to be delivered as a balanced whole rather than a collection of independently developed parts.
The result was a cohesive operating system as a single entity. Validated in total to achieve optimized performance. Updated in total with each release to avoid versioning issues.
Every new capability added to JANOS still begins with that same architectural philosophy.
We began by asking whether an edge controller is deterministic.
Perhaps that was never quite the right question.
Determinism has no universal definition. It depends on what a controller is expected to accomplish and how its performance is measured. A motion controller, a process controller, a theater automation controller, and an industrial edge controller all earn confidence in different ways because they shoulder very different responsibilities.
Maybe determinism really is in the eye of the beholder.
The controls engineer sees response time. The network administrator sees reliable communications. The software developer sees repeatable behavior. The plant operator simply expects the system to work, day after day, without surprises.
Viewed from these different perspectives, determinism becomes less an absolute property than a measure of confidence.
Confidence that the controller will respond when it should.
Confidence that adding new capabilities will not unexpectedly compromise existing ones.
Confidence that the responsibilities entrusted to the controller have been anticipated, understood, and carefully balanced by design.
That confidence is not created by clock frequency, memory capacity, or the length of a feature list. Those are resources, not assurances.
Confidence is earned through architecture.
The philosophy behind JANOS and JNIOR has never been to build the fastest edge controller, nor to prove that every industrial problem can be solved with a modest microcontroller. It has been to demonstrate that a purpose-built architecture can deliver the reliable functionality of an industrial edge controller with a level of confidence appropriate to the task.
Nearly eighty years after software first became an option, engineers have access to processing power, software libraries, and development tools that the pioneers of 1948 could scarcely have imagined. Yet the fundamental engineering question has changed remarkably little.
Can we have confidence that the controller will continue to perform the
responsibilities entrusted to it?
In the end, perhaps determinism is simply confidence made measurable.
And perhaps that is what has been in the eye of the beholder all along.
“How JNIOR Got Its Own Operating System”
Products Have Lifecycles. Platforms Have Careers.