When one Czar is enough, and when a Grid is

The appliance is Czar. A single Czar in the rack is a pool for a small floor. Several Czars joined are a Czar Grid, one pool for a whole facility. The choice between them is not a choice between products; it is a reading of the site. This article sets out what to read.

What one Czar covers

One Czar is the right answer for a floor whose robots, at their busiest hour, can be served within their latency budgets by one node with capacity to spare. That describes a lot of real places: a single-building fulfillment operation, a trial area where a site is bringing in its first humanoids beside its existing arms, one section of a larger plant that runs its own automation, a yard where inspection vehicles cover a bounded area.

A single node is a complete pool. It runs Substrate, holds each robot's budget, keeps the record, serves every vendor's robots on the floor, and runs air-gapped or connected as the site chooses. Nothing about a one-node pool is provisional. Many sites will never need more.

What pushes a site to a Grid

Three things push a site from one Czar to a Grid. The first is size. A facility with several floors, or a large outdoor site such as a terminal, has robots on parts of the network far from each other. A Grid places capacity where the robots are so that the path from floor to rack stays short everywhere.

The second is concurrency. A large mixed fleet at shift change, or a line changeover with humanoids and mobile manipulators all meeting unfamiliar parts at once, generates more simultaneous demand than one node can serve inside the tightest budget. A Grid spreads that demand across nodes and keeps the tight-budget requests on time.

The third is continuity. Every node needs updating eventually, and on a one-node pool an update means the robots run on their on-board models until it is done. That is safe, but it is a reduction in capability on the floor. On a Grid, one node can be taken out while the others keep serving, so an update does not have to wait for a quiet shift.

Still Czar

A Czar Grid is not a different machine. It is the same sealed node, installed several times in the facility's rack or racks, joined by Substrate into one pool. Each node attests what it is running before it joins the Grid. Each has its provenance on record. The posture, air-gapped or connected to the systems the site already secures, is set for the site and applies to every node.

What the site gets from a Grid is what it gets from one Czar, at the scale of the whole facility: every robot served from any vendor, one record of every decision, nothing leaving the building. The robots do not know whether they are being served by one node or several. They see one pool.

Starting with one and growing

A site does not have to decide its final shape at the beginning. It can begin with one Czar on the floor where the need is clearest and add nodes as the fleet grows or as more of the building comes under automation. Capacity is added in the rack, and the robots are not touched. Adding capacity to a Grid without stopping the floor describes how.

The commercial model fits this. The subscription is for the configured Grid, hardware, platform license, and sustainment in one line, fixed for the term. Adding robots to a pool that is already in place does not change it. Changing the configuration, from one node to several, is a change to what the site subscribes to, worked through with E31 Consulting and the operator's automation team.

Reading your own site

The things to establish are concrete: where on the network the robots are and how far the farthest is from the rack; when the busiest hour falls and how many robots will meet something unfamiliar in it; which robot on the floor has the shortest budget; and whether an update window during which the pool is unavailable is acceptable to operations. One Czar answers those for a small floor. A Grid answers them for a facility. For the method, see Sizing an inference pool for a facility.