Product capability
Embedded software testing uses SPX as a repeatable virtual device lab for firmware, protocol clients, and integration workflows. Teams can exercise real communication behavior, control scenarios, and reproduce failures without waiting for every physical device or lab setup.
Common use cases
- Test firmware integration against virtual devices before hardware is available.
- Validate MQTT, Modbus, OPC UA, SCPI, and other protocol interactions.
- Reproduce reconnects, timeouts, bad values, and timing-sensitive failures.
- Run deterministic regression and stress scenarios in CI/CD.
- Keep local developer environments aligned with automated test stacks.
Related protocol examples
Related quickstarts
Why embedded testing is hard
Embedded teams often depend on scarce hardware, incomplete labs, and environments that are difficult to reset. A test can pass on one developer machine and fail in CI because a device, timing condition, or protocol response is not reproduced consistently.
The cost is not limited to a failed test. Hardware bottlenecks delay integration, obscure the source of a regression, and make edge cases expensive to exercise.
How SPX supports embedded testing
SPX provides a structured path from model definition to repeatable test evidence:
- Code-defined models remain reviewable and version-controlled.
- Virtual devices expose protocol behavior instead of static mock responses.
- Scenarios make timing, state transitions, and failure handling reproducible.
- Runtime control and logs provide evidence for debugging and regression review.
- Python, Docker, and CI workflows make setup and teardown automatable.
From local development to CI
A practical workflow is to start the same virtual stack locally and in CI, run a known scenario, probe the protocol surface, and keep logs when the result differs from the expected behavior. This gives firmware and integration teams a test surface they can use before a physical device is available and alongside hardware testing when it is.
SPX is intended to complement final hardware validation, not hide differences between a simulator and a product. The benefit is a repeatable first line of integration evidence that can run on every change.