Designing IoT Systems
The Designing domain tests whether you can translate approved requirements into an architecture: layers, protocol choices, topology, power and bandwidth budgets, data contracts, and security controls. Questions typically ask you to justify a choice against a stated constraint.
Choose a reference architecture
Separate the device/perception layer, network layer, edge or fog layer, and application layer, with management and security as cross-cutting concerns. Decide deliberately where processing happens: cloud for long-term analytics and cross-site correlation, edge for latency, bandwidth, offline autonomy, and privacy.
Match the protocol to the constraint
- MQTT: publish/subscribe over TCP through a broker; QoS 0/1/2; strong fit for many devices over constrained or intermittent links.
- CoAP: UDP-based request/response with DTLS; suited to very constrained devices and small payloads.
- HTTP/REST: simple integration and infrequent polling, but heavy per-message overhead.
- LoRaWAN and NB-IoT: long range, low power, low data rate; LoRaWAN imposes duty-cycle limits.
- Zigbee, Thread, BLE: local mesh or short-range links needing a gateway. Selection criteria are range, data rate, payload size, power, topology, duty cycle, existing infrastructure, and security support - in that order of constraint.
Size power and bandwidth before committing
Compute average current from the duty cycle, then divide battery capacity by it. Model uplink volume per day from message size × frequency × device count.
Worked example. A node transmits for 2 s at 40 mA every 15 minutes and sleeps at 5 µA. Duty cycle = 2 ÷ 900 = 0.00222, so transmit average = 40 mA × 0.00222 ≈ 0.089 mA; add 0.005 mA sleep = 0.094 mA. A 2,000 mAh cell lasts 2,000 ÷ 0.094 ≈ 21,300 h ≈ 2.4 years. Halving the interval to 5 minutes triples the transmit term to 0.267 mA, total 0.272 mA, giving ≈ 7,350 h ≈ 10 months. The requirement change, not the radio, broke the battery target.
Design security in, not on
Device identity in a secure element or TPM, X.509 certificates rather than shared keys, TLS on every hop, OT traffic segmented behind a firewall or DMZ, least-privilege platform roles, secure boot, and signed over-the-air updates. Define the data schema (IDs, units, timestamps, version) and retention at design time.
Traps
- Choosing a protocol by familiarity rather than by range, power, and duty-cycle fit.
- Assuming MQTT QoS guarantees exactly-once processing at the application.
- Leaving the broker or gateway as an unplanned single point of failure.
- Ignoring time synchronisation, which corrupts correlation and certificate validation.