CIoTP cheat sheet
CIoTP · Keep the key ideas within reach.
Planning IoT Systems
Requirement triage: separate functional needs (sensing rate, actuation latency) from non-functional constraints (power, cost, physical size, environmental rating) before selecting hardware.
Latency budget formula: end-to-end latency = sensor sampling period + network transit (hops × per-hop delay) + processing/queueing + actuation time. Sum worst-case values, not averages, for safety-critical paths.
Power budget: average current = (I_active × t_active + I_sleep × t_sleep) / (t_active + t_sleep). Battery life ≈ battery capacity (mAh) / average current (mA), then derate 20–30% for temperature and aging.
Data volume estimate: bytes/day = payload bytes × samples per day × number of devices. Use this to size backhaul, storage retention, and cloud ingest cost before choosing a protocol.
Device count and address plan: /64 per subnet is standard for IPv6; for IPv4 plan subnets by function (sensors, gateways, management) and reserve DHCP ranges for non-static nodes.
Site survey inputs: RF coverage map, interference sources (2.4 GHz Wi-Fi/microwave, metal racking), cable routes, and power availability at each mounting point.
Regulatory and compliance planning: radio certification (FCC/CE), data residency, privacy impact assessment for personally identifiable sensor data (cameras, badges), and industry rules (e.g., medical, utility).
Total cost of ownership model: hardware + installation labor + connectivity subscription + cloud/storage + maintenance visits over the depreciation period; installation often exceeds device cost in retrofit projects.
Risk register for IoT: single points of failure (one gateway, one power feed), firmware end-of-life, spectrum congestion, and physical tamper exposure; each entry needs a mitigation and owner.
Designing IoT Systems
Layered reference model: device (sensor/actuator + MCU), edge/gateway (protocol translation, local rules), network (access + backhaul), platform (ingest, storage, rules), application (dashboards, APIs).
Protocol selection rule: use MQTT for many-to-broker telemetry over TCP; CoAP for constrained UDP devices; HTTP/REST for low-frequency, request-response integrations; LoRaWAN/NB-IoT for long-range low-power; BLE/Zigbee/Thread for short-range mesh or personal area.
MQTT design facts: QoS 0 at-most-once, QoS 1 at-least-once (duplicates possible), QoS 2 exactly-once (higher overhead). Retained messages deliver last known state to new subscribers; last will and testament flags ungraceful disconnect.
Topic hierarchy pattern: site/building/device-type/device-id/measurement. Design subscriptions to avoid wildcard fan-out that overloads the broker.
CoAP facts: runs over UDP, uses confirmable/non-confirmable messages, observe option for push, block-wise transfer for large payloads; pair with DTLS for security.
Edge vs cloud split: put safety interlocks, closed-loop control, and bandwidth-heavy filtering at the edge; put long-term analytics, cross-site correlation, and ML training in the cloud.
Security design baseline: unique per-device credentials (no shared keys), mutual TLS or DTLS, encrypted at rest and in transit, signed OTA images, least-privilege broker ACLs, and network segmentation of the OT/IoT VLAN.
Idempotency and ordering: design message handlers to tolerate duplicate delivery and out-of-order arrival by including device timestamp and message sequence number in payloads.
Scalability design: size broker connections (persistent sessions consume memory), use horizontal partitioning by device ID, and plan backpressure/queueing for bursty telemetry.
Developing IoT Systems
Firmware structure: bootloader with secure boot, application partition, OTA staging partition, and persistent configuration store with wear leveling on flash.
Sensor acquisition: match sampling rate to Nyquist (sample > 2× highest signal frequency of interest); apply digital filtering and calibration coefficients stored per device.
Payload efficiency: use compact binary encodings (CBOR, protobuf, packed structs) instead of JSON on constrained links; a float in JSON can cost 10+ bytes versus 4 bytes binary.
Time handling: synchronize devices via NTP/SNTP or GPS; store UTC with a monotonic sequence number, and let the platform convert to local time for display.
Idempotent command handling: include a command ID and expiry in downlink messages so retries do not double-actuate a valve or relay.
Testing layers: unit tests for parsing/encoding, hardware-in-the-loop tests for sensor drivers, protocol conformance tests against the broker, and fault injection (packet loss, power cut) for recovery paths.
CI/CD for firmware: build artifacts versioned and signed, automated size and static-analysis gates, staged rollout (canary devices → fleet) with rollback image retained.
Local buffering: queue telemetry to non-volatile storage when connectivity drops, with a circular buffer and defined drop policy (oldest-first) to bound storage.
API design for device management: expose device registry, shadow/desired-state, and command endpoints; version APIs and document rate limits.
Implementing IoT Systems
Provisioning steps: identity creation, credential injection (secure element or encrypted store), network join, registration in device registry, and assignment to site/tenant.
Commissioning checks: RF signal strength at installed position, power/battery voltage, time sync, round-trip latency to broker, and successful publish/subscribe on each required topic.
Network configuration: static reservations or DHCP with long leases for fixed gateways; separate VLANs for IoT devices and management; firewall rules allowing only required outbound ports (e.g., 8883 MQTT/TLS, 5684 CoAP/DTLS).
Gateway placement rule: mount above obstructions, keep antenna clearance, and verify coverage with a site survey tool after installation rather than relying on the design model.
Zero-touch enrollment: use a bootstrap mechanism (claim certificate, manufacturer serial allowlist) so devices self-register; revoke the bootstrap credential after first enrollment.
Rollout strategy: pilot a small representative site, compare measured latency/power against plan, then scale in batches with a defined acceptance checklist per batch.
Integration implementation: map device data models to platform schemas at ingest, validate with schema registry, and make downstream consumers tolerant of missing fields.
Cutover and rollback: keep legacy and new paths running in parallel during validation; define the exact rollback trigger and the procedure to restore previous firmware or routing.
Maintaining IoT Systems
Health metrics to monitor: device online/offline count, last-seen age, message rate per topic, error/NACK rate, battery voltage trend, signal strength, and gateway CPU/memory/queue depth.
Alerting rule: alert on absence of expected data (dead-man/heartbeat timeout) rather than only on error codes, since silent failures are the most common IoT fault.
Fleet firmware management: track firmware inventory, stage updates by cohort, verify post-update health checks, and keep a rollback path to the last known-good signed image.
Credential lifecycle: rotate certificates and keys on a defined schedule, revoke compromised device identities in the registry and broker ACLs, and audit for shared or default credentials.
Predictive maintenance: use battery discharge slope, error-rate drift, and sensor drift against reference measurements to schedule service before failure.
Backup and retention: back up device registry, configuration, and rules; define telemetry retention by tier (raw short-term, aggregated long-term) to control storage cost.
Incident runbook contents: symptom, affected scope query, diagnostic commands, mitigation, escalation contact, and post-incident review action items.
Change management: log every configuration, firmware, and ACL change with who/when/why; require review for changes affecting safety interlocks or security policy.
Decommissioning: revoke credentials, remove device from registry and DNS, wipe stored keys, and archive its historical data per retention policy.