Connecting a vendor's fleet software to the pool

Most systems in a facility are connected to something the moment they are powered on. They call home, check for updates, and open a path to a vendor's cloud before anyone has decided whether they should. A Czar does not do this. A node arrives with no path out, and a connection to anything, including a robot vendor's fleet software, is a route someone at the site has to declare.

This article is about that declaration: who makes it, what it allows, and what it can never be made to allow.

The default is nothing

Substrate, the serving system on the Grid, includes a governed connectivity layer called Local Bridge. Its rule is simple. Only declared routes are permitted, and egress is denied by default. A pool that has had no routes declared serves the robots on the floor over the facility's own network and talks to nothing else.

That is a complete and supported way to run a Czar Grid. An air-gapped site stays that way. Updates arrive as signed bundles carried in by media, the robots use the pool over the floor network, and the record stays on the rack. A vendor's fleet software, in that posture, has no connection to the pool at all, and the robots still get served.

What a declared route is

A declared route is a specific permission: this system, in this building, may exchange this with the pool. The site declares it. The systems a site typically has in mind are the ones it already secures: the robot vendors' fleet software, the warehouse system, and the PLCs on the line.

A route to a vendor's fleet software is one such declaration. It lets the fleet software and the pool exchange what the site allowed, which might be task context, status, or whatever the integration between them calls for. It does not open a path from the pool to the vendor's cloud, because that is a different system and would need its own declaration, and it does not open the pool to anything else on the vendor's network.

The important property is that the route is the exception and silence is the rule. A system that has not been declared cannot reach the pool, and the pool cannot reach it. There is nothing to misconfigure into openness.

How the decision gets made

In practice the declaration is a conversation between the site's automation team, its network and security owners, the integrator, and the vendor whose software is in question. The question on the table is narrow: what does this vendor's fleet software need from the pool, and what does the pool need from it, for the robots to do their work well. The answer becomes the route.

E31 Consulting puts Element 31 engineers on site for this. They install the pool with the automation team, the integrator, and the robot vendors in the room, and the routes get declared as part of the installation rather than discovered afterward. The vendor's position in that conversation is a comfortable one. The vendor's software is being connected to, not replaced, and the vendor can say precisely what it needs.

Mixed estates on one Grid

A building rarely has one posture. The pick cells may be allowed a declared route to their vendor's fleet software because that vendor's software runs in the building. The humanoid trial at the far end may be air-gapped by policy until the safety officer is satisfied. The mobile robots may sit somewhere between.

A Grid runs all of that at once. Posture is a choice per site, not a different appliance, and within a site it is a choice per route. One pool can serve robots whose vendor systems are connected by declared routes and robots whose vendor systems are not, with the same models and the same record. Moving a fleet from one posture to the other is a change of declaration, not a change of hardware.

What a connection never changes

A declared route to fleet software changes what the pool may exchange with that software. It does not change what leaves the building. Camera feeds, captures, task records, adapted model weights, and the record of every decision stay on the operator's hardware inside the operator's network, whatever routes are declared.

It also does not change where safety lives. Stops, speed limits, reflexes, and motion limits stay on the robot as the vendor shipped them, and no route to fleet software or anything else puts the pool in that loop. A connection is a decision, not a default, and it is a decision about data between systems the site already trusts, not about who holds the stop.

For how the postures look across the three kinds of facility Element 31 talks about, see solutions, and for the vendor's side of the same decision, read what a robot vendor keeps when a site adds a pool.