What hardware information is required before starting an IoT software project?
Before formal planning, the hardware side should provide a working sample; a versioned communication protocol; field, command, and error dictionaries; connectivity, provisioning, and device-identity design; offline and OTA behaviour; target environment and scale; and a firmware owner available for continuing integration. With only a product deck or oral protocol, Wavesteam can perform research but cannot responsibly commit to a fixed price and schedule.
The aim is to reproduce a device lifecycle from manufacturing and activation through normal operation, failure, update, transfer, and retirement. Missing evidence becomes a named assumption and owner before contract—not an assumed input during pricing and a later change dispute.
When separating device, connectivity, and platform responsibilities, also compare Can one IoT platform support several hardware vendors and incompatible protocols? and Can Wavesteam develop integrated IoT hardware and software applications?; the linked guidance adds context that should be considered in the same decision.
| Gate | Minimum hardware evidence | Software decision | If missing |
|---|---|---|---|
| Worth a proof? | Purpose, model, connection, initial protocol, one sample, technical contact | Can it connect, read, and execute one safe command? | Research only |
| Ready to quote? | Frozen protocol, fields/commands/errors, identity/provisioning, volume/frequency, network, OTA, sample batch | Effort for integration, platform, apps, tests, operations | Range with explicit risk or pause |
| Ready for pilot build? | Several production samples, provisioning, certificate injection, logs, release/rollback, fixtures | Activation, endurance, fleet update, support process | No fleet deployment |
| Ready to scale? | Certification, supply/version plan, capacity, vulnerability response, end-of-life | Operating, security, cost, lifecycle decision | Constrain rollout |
There is no universal requirement for two or three samples. One can prove a path; stability and batch variation need enough production devices for the failure modes and evidence objective. Label hardware/firmware version, serial, SIM/certificate, and known faults; uncontrolled reflashing invalidates comparisons.
The protocol specifies transport and endpoint, authentication, encoding, byte order, checks, fragmentation, topics/paths, heartbeat, reconnect, and timeout. Fields define type, unit, scale, range, enum, missing/error value, collection/reporting, and time source. Commands define prerequisite state, bounds, idempotency, interim/final acknowledgement, timeout, retry, and fail-safe outcome. Normal and abnormal captures or a simulator are stronger than one JSON example.
MQTT projects can use OASIS MQTT 5.0 for QoS, sessions, will, expiry, and reason codes, while business topics and idempotency remain project-specific. Every protocol has a version, release date, compatibility, and change history. Unit, enum, and command-semantic changes are breaking changes and cannot silently overwrite prior definitions.
Hardware documentation also covers unique identity injection, shared passwords, rotation/revocation, debug access, signed firmware, rollback protection and recovery, logs, transfer, and data removal. NIST IR 8259 Rev. 1 describes foundational cybersecurity activities before and after sale. Quantify environment, power, vibration, protection, carrier/signal, bandwidth, latency, and outage; provide calibration, certification, hazard, and interlock evidence where sensing or control requires it.
Wavesteam turns the inputs into a capability matrix, field/command contract tests, simulator, issue register, and frozen baseline. The first proof covers activation, telemetry, backfill, duplicate/order, clock drift, invalid values, command timeout, restart, and credential revocation. The fastest responsible start is one version-labelled sample, protocol, and firmware contact completing one minimum loop before formal quotation.