Skip to content
ELEMENT 31

Bringing a pool into a plant that already runs PLCs and vision

A plant with a mature control layer does not need the pool to change anything that works. Here is how an inference pool is commissioned beside PLCs and machine vision, and what the controls team keeps.

· 4 min read

IN SHORT

A pool enters a plant that already runs PLCs and vision as a new consumer on the plant segment, not as a new controller. The PLCs keep every interlock, the vision systems keep every inspection, and the pool serves perception and decisions to the plant's general-purpose robots over declared routes only. Commissioning is done with the controls team and the integrator, and each node attests before it joins.

A plant that already runs PLCs and machine vision has earned a certain suspicion of new boxes on the network. Every one of them wanted to be in the loop. Every one of them had a reason the interlock should consult it first. The controls team has spent years keeping the scan clean, and the first thing it needs to hear about an inference pool is that the pool does not want in.

It does not. The pool is a consumer on the plant segment, not a controller. It serves perception and decision models to the general-purpose robots the plant is adding, over the plant's own network, within those robots' latency budgets. It has no output to a PLC. It does not gate a station, release a part, or close a safety circuit. If it disappeared mid-shift, the line would not notice, and the robots it serves would stop or fall back to their own models.

What stays exactly as it is

The PLCs keep every interlock, every mode, every safety circuit. The machine vision systems keep every inspection they run today: the fit check at a station, the presence check on a fastener, the read on a part mark. Those systems are good at their jobs, they are tuned to the line, and the pool has no reason to replace them.

The arms welded to the line keep their controllers and their programs. The fences stay where they are. The pool is for the new class of machine, humanoids and mobile manipulators moving between stations, and the harder perception those machines need is a different problem from the inspections the line already does.

What the pool connects to

The plant's controls team declares what the pool may reach. Through Local Bridge, the Czar Grid permits only declared routes and denies egress by default. In most plants the declared routes are the robot vendors' fleet software, so the vendors can manage their machines, and the plant's execution system, so the robots know the build sequence. That is often the whole list.

A plant that wants the pool to see a signal from the control layer, a line-state flag for instance, can declare that route. A plant that does not can leave it undeclared, and it is unreachable. The declaration is a decision the plant makes and can read back later, not a default the pool arrived with.

Commissioning beside a running line

Element 31 engineers install the pool on site with the plant's automation team, the integrator who built the cells, and the robot vendors whose machines will consume it. The order of work is deliberate.

The node goes into the plant's own rack inside the plant segment. Before it joins the Grid or accepts any task, it attests what it is running. The software image is sealed, signed, and read-only, and the integration, sealing, and software load of every node are on record. The controls team gets to see that record before anything else happens.

Routes are declared next, by the plant. Then the robots are introduced, one vendor at a time, each with its fallback behavior walked through with the safety officer present: what the robot does when the pool is late, when it is unavailable, and when it is deliberately offline for an update. Only then are site tasks authored in Agency Studio, bounded by zone, speed, and distance from the line, and approved by a named role. Every run from the first one is recorded and replayable.

The integrator's position

Integrators are used to being the party who makes new equipment fit the plant. That does not change. The integrator who built the cells knows where the robots can go and where they cannot, and that knowledge becomes the bounds on the tasks. In some arrangements the integrator ships the pool under their own name as Czar Chassis, with their fleet, so the plant receives one system from one party, with Element 31 providing sustainment and attestation underneath. It is the same Grid either way.

Updates on a plant schedule

Plants update on their own calendar, in planned windows, with the controls team present. The pool respects that. On a connected plant, signed updates are downloaded when the plant initiates them. On an air-gapped area, updates arrive as signed bundles carried in. Customer appliances never connect to Element 31's portal on their own; every session is customer-initiated. Watchman verifies the integrity of what is running, and the record shows what version served which shift.

For the plant-level picture of what the pool is for, see An inference pool for an automotive plant. For the first bounded step most plants take, see Running a humanoid pilot inside the plant segment.

Questions this raises

Will the pool need to talk to our PLCs?
Only if the plant declares a route for it, and most plants do not. The pool serves robots, and the robots' fleet software is what typically talks to the plant's systems. Nothing is reachable from the pool that the plant did not declare.
Who commissions the pool?
Element 31 engineers install it on site with the plant's automation team, the integrator, and the robot vendors. The controls team owns the segment, the routes, and the acceptance; the vendors own their robots' behavior.
How does the plant know the node is running what it should?
Each node runs a sealed, signed, read-only software image and attests what it is running before it joins the Grid or accepts a task. Integration, sealing, and software load are on record for every node, so provenance is answered from a record.

KEEP READING