EC-20.5 A Device in the Field: Protocols, Identity and Updates

What this is and why it exists

One device on your bench and ten thousand devices in other people's buildings are different engineering problems.

The second one needs answers to four questions the first never asks. How is a unit identified? How is it reached through somebody else's network? How is it updated when nobody can touch it? And what happens when an update fails halfway through?

The last question is the one that ends companies. A release that leaves remote units unable to boot turns a fleet into scrap, and there is no recovery except sending people to every site.

The vocabulary

• Publish and subscribe — a pattern where senders post to a named topic and receivers ask for it.
• Broker — the server that routes published messages to subscribers.
• Constrained device — one limited in memory, processing or energy, and often on an unreliable link.
• Provisioning — putting a unit's identity and keys onto it during manufacture.
• Certificate — a signed statement binding an identity to a public key.
• Fleet — every deployed unit, managed as groups rather than individually.
• Over-the-air update — replacing a unit's software over its network connection.
• Rollback — returning to the previous working image after a failed update.

The mental model

Start with the shape of the connection. A device that publishes to a named topic does not need to know who is listening, and does not need to accept incoming connections. That matters enormously, because a device behind somebody else's router usually cannot accept them anyway. This is why publish-and-subscribe dominates connected-device work.

Protocols for constrained links trade features for header bytes and for tolerance of an unreliable network. Comparing two of them honestly means comparing message size, delivery guarantee and energy cost per exchange, rather than reading a feature list.

Identity is a factory problem. A server can only trust a message if the device proves which unit sent it. That proof has to be placed on the unit during production. How the key gets there, who generates it, and what happens if the line is compromised are all design questions. They are settled long before the first unit ships.

Fleet management starts the moment there are more units than a person can list. Everything then works by group: configure a group, update a group, ask what state a group is in. That requirement usually changes the data model on the device itself, because a unit has to be able to report its own state compactly.

Updating over the air has one non-negotiable property: it must survive the power failing halfway through. The standard design writes a second image to a separate area, verifies it, and only then switches which image boots. If the switch never happens, the old image still runs. Without that, one bad release is unrecoverable.

Finally, connectivity is intermittent everywhere. A device needs a local store and a retry pattern that does not flood the network when it returns. It also needs a rule for what to discard when the store fills. Designing that behaviour late usually means designing it wrong.

What you should now be able to explain or do

• Explain why publish-and-subscribe suits a device behind somebody else's network.
• Compare two constrained protocols on message size, delivery guarantee and energy.
• Describe how a device proves its identity, and where that proof came from.
• Say what changes about a system once units are managed as groups.
• Design an update mechanism that survives a power failure at any moment.
• Decide what a device should do after a week with no network.

Check yourself