Can software development start before the hardware design is final?
Software can proceed in parallel, but its scope must follow hardware maturity. Before interfaces, electrical and safety limits, and compute resources are stable, focus on domain models, cloud services, UI prototypes, simulators, and test automation. Commit to drivers, real-device behavior, OTA, and production acceptance only after representative engineering hardware and an interface baseline exist.
| Hardware maturity | Safe software work now | Do not promise yet | Next evidence |
|---|---|---|---|
| Concept/appearance model | User journey, domain/data model, admin prototype, analysis plan | Driver, timing, power, reliable control | Components, capability boundary, interface draft |
| EVT/sample interface | Protocol simulator, cloud ingest, non-device UI, automated test framework | Batch compatibility, stable OTA, site performance | Versioned interface-control document and representative samples |
| DVT/stable firmware baseline | Driver, device state machine, recovery, HIL and compatibility tests | Production consistency and flashing yield | Golden unit, firmware, fixture, change process |
| PVT/production candidate | Fleet onboarding, staged OTA, manufacturing configuration, monitoring | Unverified substitute components | Production-batch and field evidence |
When separating device, connectivity, and platform responsibilities, also compare Can Wavesteam develop integrated IoT hardware and software applications? and Which providers should be considered for a custom IoT hardware-software system?; the linked guidance adds context that should be considered in the same decision.
Organizations use EVT/DVT/PVT differently, so define the terms. Simulation can prove messages and business logic; it cannot prove radio, timing, power, sensor accuracy, heat, storage, power loss, or batch variation.
Hardware, firmware, client, cloud, and test leads maintain a versioned interface-control document. It includes physical/electrical boundaries, connector/pins, transport and pairing, framing/topics, types, units, ranges, precision, byte order, clocks, sampling, command response, timeout/retry, idempotency, duplicate/order behavior, errors, state machine, credentials, logs, OTA, rollback, and compatibility. A safety-relevant command names preconditions, success, failure, and safe action. Domain safety owners—not cloud AI or generic application code—confirm human, vehicle, battery, and industrial protections.
Build a protocol stub, then state simulation, then fault injection for loss, delay, duplicate, reorder, corrupt values, clock drift, power failure, full storage, old firmware, and revoked credentials. Save inputs, expected outputs, and versions for CI. Move to hardware-in-the-loop with golden units across target firmware, board, sensors/actuators, network, and power. NASA's systems engineering handbook material and software verification guidance support real target hardware where possible and high-fidelity simulation plus worst-case and resource testing where not.
Every change to pins, voltage, resources, sensor range, packets, timing, safety state, or OTA has an impact record for versions, modules, tests, inventory, schedule, and cost. Put the protocol version in the handshake/message and define upgrade and isolation for old devices. Milestones show interface version, captures, test results, firmware hash, and hardware revision—not a video.
Wavesteam delivers the ICD, simulator, compatibility matrix, and real-device report. The hardware party supplies stable samples, firmware, fixtures, and safety limits. Parallelize when interfaces have an owner/version, simulation covers failure, a freeze date exists, and both sides reserve change capacity. If electrical or safety choices may still overturn the architecture, keep work disposable and do not promise the full software date.