Implementing IoT Systems
The Implementing domain covers moving from a build to an accepted, running system on a real site: installation, provisioning, network integration, hardening, verification, and handover. Items ask what step comes next or why a deployment failed acceptance.
Sequence the deployment
Typical order: site readiness check → physical installation and labelling → power and network connection → enrolment and identity binding → configuration → calibration → enterprise integration → acceptance test → handover. Each stage needs a checkpoint. Defects found at calibration are cheap; defects found after 500 devices are mounted are not.
Enrol devices, don't just connect them
Provisioning binds a physical asset to a digital identity: register the device ID and certificate in the platform, assign it to a site or tenant, apply the configuration template, confirm telemetry arrives. Then confirm a revoked or unregistered device is rejected - that is the test proving enrolment actually works.
Harden at handover
Change default credentials, disable unused services and ports, restrict management access to a jump host or VPN, place OT traffic on its own VLAN with a firewall to IT, forward logs to a central collector, and verify the certificate trust chain and NTP.
Verify with acceptance tests
Define objective pass criteria before installation: measurement accuracy against a reference, end-to-end latency, message delivery over 24 hours, failover behaviour, alert routing. Record evidence per device.
Worked example. A temperature node is specified at ±0.5 °C. At commissioning it reads 22.9 °C while a calibrated reference reads 22.0 °C. The 0.9 °C error exceeds tolerance, so it fails - do not average the two readings or widen the tolerance. Check probe placement first (direct sun, nearby heat source, insufficient immersion), then wiring and configuration (wrong sensor type selected), then apply a calibration offset. Re-test against the reference and record the before and after values.
Traps
- Commissioning with default passwords because security will "fix it later".
- Testing one device and assuming fleet-wide behaviour.
- No rollback or parallel-run plan at cutover.
- Forgetting NTP and certificate validity, which break TLS silently.
- Unlabelled devices and missing as-built documentation.