Three dreams for a different factory

There are three things that anyone who has ever operated an industrial machine has wondered at least once. Three things that are not said out loud because they seem like utopias. This article lines them up.

A scene, just to start

Night shift, department X. A line stops. The HMI panel shows a code: E-1423. The manual is in a cabinet three buildings away. The technician who knows that machine is on vacation. The operator has two options: call technical support—who might only answer in the morning—or guess. In the industrialized world, scenes like this repeat hundreds of times a night.

The problem isn't that a manual is missing. There are too many manuals. The problem is that the machine knows exactly what it needs—the pressure sensor has been telling it for thirty seconds that something is wrong—but it can't speak a language the operator can understand, and when it can speak, it reports the problem instead of the solution. "Pressure out of range" is not a useful phrase at three in the morning. "Check valve V12 on the air circuit, it's probably stuck" is.

This is where the work we are doing begins. Not a new PLC. Not a more beautiful HMI. A different way of thinking about what the software that moves a machine should be in 2026. And three fixed ideas — call them dreams — that we are trying to hold together.

Dream number one: automate without programming

Industrial automation, as it is today, requires a very specific figure: someone who knows how to program in a language — the IEC 61131-3 family, with its ladder, function block, structured text dialects — that is practically not used anywhere else in the software world. Those who know these languages are rare, are expensive, and are almost always three weeks behind schedule.

The paradox is that those who really know the machine are often not the programmer. It's the department head, the senior maintenance worker, the integrator who has installed twenty similar plants. These people know what the machine has to do. They have no desire to learn a programming language born in the 90s to explain it.

The idea is to flip the chain. Software developers write reusable components — motion control, sensor management, operational sequences — once, in modern and general-purpose languages. The machine integrator doesn't program them: they compose them, specifying verbally or in writing what the machine must do. A large language model — an LLM — acts as a translator: it takes the integrator's functional specification and transforms it into an executable configuration, assembling the components that have already been written and tested.

It's not the fantasy of "AI that writes the code for you". It's something more modest and more realistic: AI that reads your specification and chooses, from certified components, how to combine them. Critical code — the one that moves an axis with a 5-millisecond cycle — continues to be written by a human, in a language that guarantees determinism and reliability. But that code is written once and for all and reused a hundred times.

Dream number two: the machine that knows itself

Today, machines talk little, and poorly. An alarm is a numerical code. A diagnostic is a series of LEDs. A log is a binary file that only the manufacturer knows how to open. The knowledge of how that machine works, with those tolerances, after those two thousand cycles, is in the head of a person, or in a PDF somewhere.

The second dream is that the machine knows itself. Not in a mystical sense — in a very concrete sense: the technical documentation, process parameters, typical failure cases, and intervention procedures are no longer in a cabinet or a separate document server, but inside the machine itself, readable by its own software. And when something goes wrong, the machine doesn't say "error 1423". It says "valve V12 is likely stuck, you should check it; in the meantime, I can continue in degraded mode at 60% speed".

The difference is between a passive object that signals and an active object that proposes. The first leaves the problem to the operator. The second tackles it together with him.

This requires two things that are not to be taken for granted. First, that the knowledge of the machine — historically kept in manuals, electrical diagrams, CAD drawings and the minds of technicians — is formalized and integrated into the system. Second, that the system has an interlocutor capable of holding a conversation: again, an LLM, used here not to generate code but to translate symptoms into understandable actions, in the language of the person in front of the panel.

Once again, it's not magic. It's better written, better indexed documentation, and a conversational interface on top of it. But it changes everything for those doing the night shift.

Dream number three: software that runs everywhere

The third dream is the most technical and, paradoxically, the most political. Today, industrial automation is a world of closed ecosystems. Every major PLC manufacturer has its own language, its own development environment, its own hardware, its own drivers, its own network of resellers. Switching suppliers means rewriting everything.

The ambition here is to build a software system that runs on generic hardware — an industrial mini-PC, an embedded controller, a server in the basement — choosing the hardware based on budget and required performance, not based on which brand of PLC won the negotiation. A Linux operating system in real-time version, communication cards based on open standards (EtherCAT throughout), software components in modern languages for the deterministic parts and in more agile languages for those that are not.

The rule, and this is where utopia becomes concrete: hardware must affect performance, never reliability. The same logic, on a less powerful machine, must work identically — only more slowly. If the cycle time goes from 5 to 10 milliseconds, the axis moves with the same precision but at half speed. Never "almost the same". Never "it works except in that case". Same system, same decisions, same guarantees.

This is where experienced engineers start to laugh. They know very well that real-time is difficult, that Linux wasn't born as a real-time system, that LLMs don't run on a Raspberry Pi, that mixing different languages in the same stack has more pitfalls than tutorials promise. They are right. But the direction is that, and the building blocks to build it — the real-time extensions of the Linux kernel, mature open source EtherCAT stacks, LLMs that are starting to run on modest hardware — exist, today, for the first time all together.

Why "Utopia"

Utopia is an honest word. None of these three things is, today, a finished product. The first requires LLMs reliable enough to be used in a production context, and we are at the beginning. The second requires an enormous amount of work to formalize industrial knowledge, which today is almost all informal. The third requires building open alternatives against closed ecosystems that have a twenty-year head start.

But the three dreams together, if lined up, draw a precise direction: an automation where hardware is commodity, software is reusable, knowledge is embedded in the machine, and the figure of the PLC programmer — today a bottleneck for an entire industry — does not disappear, but moves to where it is really needed, that is, to write the basic components once and for all.

In the articles that will follow, we will tell you about the pieces we are building of this puzzle. One at a time, without promising that the puzzle is complete. It isn't. But the design is starting to emerge.