AIoT: inference where the network is not a given

Cloud-first designs assume the network. Industrial sites do not get to. A line running at 120 parts a minute needs a decision in tens of milliseconds and needs it during the hour the uplink is down. Once you accept that, the split between edge and cloud stops being a preference and becomes an engineering requirement.

Decide locally, learn centrally

Put the model that stops the line on the device. Put the model that improves it in the cloud. The edge runtime holds a quantized model sized for the hardware you actually have on the floor, which is usually older and more constrained than anyone would choose.

# Greengrass component. Inference stays local; the cloud is where
# evidence and the next model version live.
def on_frame(frame):
    result = local_model.predict(frame)          # tens of milliseconds
    if result.confidence < THRESHOLD:
        buffer.append(frame, result)             # survives a link outage
    if result.defect:
        plc.stop_line()                          # never waits on the cloud
    return result

def on_link_restored():
    for batch in buffer.drain(max_bytes=8_000_000):
        iot.publish("plant/inspection/v1", batch, qos=1)

The buffer is the part teams underestimate. A site that loses connectivity for six hours produces six hours of evidence that has to arrive intact, in order, without duplicating records that the lakehouse will later treat as separate events.

Fleet operations is the real project

Training a defect classifier is a few weeks. Running 300 of them across sites with different lighting, different camera mounts, and different definitions of a defect is the program. Plan for it:

1. Version models like software, with a build that pins the runtime and the preprocessing.
2. Roll out to one line, then one site, then the fleet. Keep the previous version on the device so a rollback does not need the network.
3. Measure drift per site rather than per fleet. A model that holds overall can be failing at three plants.
4. Give each site a way to flag a wrong call that reaches the training set with its context attached.

Where Cumulocity fits

Greengrass gives you the runtime and the deployment mechanism. A device management platform such as Cumulocity gives you the operational view: what firmware each device runs, which are unhealthy, and what changed before an incident. On brownfield estates with mixed vendors that view is usually the thing the operations team already trusts, and building a second one alongside it is a common way to lose them.

More field notes