CIoTP study materials
CIoTP study resources

CIoTP cheat sheet

CIoTP · Keep the key ideas within reach.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.