EC-20.5 A Device in the Field: Protocols, Identity and Updates
You can choose a messaging protocol for a constrained device and defend the choice, describe how a device proves who it is to a server, and design an update mechanism that cannot leave a remote unit unbootable.
Before:EC-11. Data Communications and Computer NetworksEC-16. Ethics, Safety, Sustainability and Standards
One device on your bench and ten thousand devices in other people's buildings are different engineering problems. The second one needs an answer to how a unit is identified, how it is reached through somebody else's network, how it is updated when you cannot touch it, and what happens when the update fails halfway. This topic is those four questions, and the last one is the one that ends companies.
Work through these
Publish-and-subscribe messaging, and why constrained devices favour it
A device that publishes to a topic does not need to know who is listening, which removes the need for it to hold addresses or accept incoming connections. That property is why this shape dominates connected-device work.
NPTEL: Introduction to Internet of Things (IIT Kharagpur) · CourseProtocols for constrained links, and what each one gives up
Lightweight protocols trade features for header bytes and for the ability to run over an unreliable link. Comparing two of them on message size, delivery guarantee and power cost is the honest way to choose between them.
NPTEL: Introduction to Internet of Things (IIT Kharagpur) · CourseDevice identity: keys, certificates and provisioning at manufacture
A server can only trust a message if the device can prove which unit it is, and that proof has to be put on the unit during production. Deciding how it gets there is a factory problem as much as a software one.
NPTEL: Design for Internet of Things (IISc Bangalore) · CourseFleet management: naming, grouping, configuring and observing units
Once there are more units than a person can list, everything has to work by group rather than by unit, and there must be a way to ask what state the fleet is in. That requirement usually changes the on-device data model.
Updating over the air: dual images, rollback and the interrupted write
An update must survive the power failing halfway through, which is why the standard design writes a second image and switches only after it verifies. Without that, one bad release turns every remote unit into scrap.
NPTEL: Design for Internet of Things (IISc Bangalore) · CourseWhat a device does when the network is gone for a week
Connectivity is intermittent in every real deployment, so the device needs a local store, a sensible retry pattern and a rule for what to discard. Designing that behaviour late usually means designing it wrong.
Sign in to keep your progress.
Free resources
We haven't checked most of these for screen reader use yet.
Links last checked 4 Sept 2026.
Stuck here?
Ask a mentor. A real person answers, and they can see exactly which topic you're on. Usually within a couple of working days.
Checking your session…
Topics shown in module order.