CIoTP study materials
CIoTP study resources

CIoTP: Developing IoT Systems

CIoTP · Work through your exam, one topic at a time.

All guide sections

Developing IoT Systems

The Developing domain tests how a designed architecture becomes working firmware, edge logic, and cloud-side integration. Questions focus on the acquisition chain, edge processing trade-offs, provisioning and identity, message contracts, and test strategy.

Get the data path right first

Acquisition chain: sensor → signal conditioning → ADC → engineering units → validation → publish. Every step can lose accuracy. Convert raw counts using the datasheet or bench calibration coefficients, attach the unit and timestamp at the source, and reject out-of-range values before they enter the pipeline. A reading without a timestamp and device identifier is not data.

Push logic to the edge deliberately

Edge processing buys latency, bandwidth, offline autonomy, and privacy; it costs compute, power, and update effort. Practical rule: filter, debounce, and aggregate at the edge; analyse and correlate in the cloud.

Worked example. 2,000 devices each publish a 1 KB reading every 10 seconds. Per device per day: 86,400 ÷ 10 = 8,640 messages; fleet total = 17.28 million messages ≈ 17.3 GB/day. If firmware aggregates on the gateway to one 2 KB summary every 5 minutes, each device sends 288 messages a day: 576,000 messages × 2 KB ≈ 1.1 GB/day. That is roughly a 93% cut in uplink and storage. The reasoning that earns marks is that the change is justified by measured volume, not by preference.

Treat provisioning and identity as code

Use zero-touch enrolment: devices obtain unique credentials from a secure element or bootstrap service, never a shared key embedded in an image. Register the identity, bind it to a site or tenant, apply a configuration template, then confirm telemetry. Verify that an unregistered device is rejected.

Version the contract, then test the failures

Version message schemas and make consumers tolerant of added fields. Make handlers idempotent, because QoS 1 delivers at least once. Test conversion logic with unit tests, broker integration with a live broker, sensors and radios with hardware-in-the-loop rigs, and behaviour when the network drops, the clock is wrong, the certificate expires, or the queue fills.

Traps

  • Hard-coding secrets or Wi-Fi credentials in firmware images.
  • Shipping raw ADC values without calibration.
  • Testing only on a desk with perfect connectivity.
  • Changing payload structure without a schema version.
  • Assuming at-least-once delivery means single processing.