How a C++ industrial gateway simulator handles corrupted and stale telemetry

The engineering problem: a supervisory system should not treat a damaged packet or silent sensor as a trustworthy measurement. I explored that boundary in a C++17 software-only MCU and Linux-oriented edge-gateway simulation. This is not a physical-board test.

The virtual MCU schedules sensor samples, assembles a binary frame and appends CRC-32. A transport interface carries the frames over local TCP to emulate a serial/UART link. Keeping transport separate is intentional: a future hardware adapter could replace the simulator without rewriting all gateway logic.

The gateway validates the frame and monitors freshness before using readings in a control decision. The documented design uses a 1.5-second sensor-staleness threshold and a 2-second watchdog heartbeat limit; unsafe conditions lead to SAFE_STOP or latched EMERGENCY_STOP states. Hysteresis prevents rapid switching between warning and normal conditions.

It exposes register data through Modbus TCP and publishes MQTT v3.1.1 telemetry. These are different interfaces to the same simulated device state, which is useful for testing how supervisory clients observe a failure.

The repository documents ./build.sh or build.bat for compilation and unit tests, and python tools/fault_injector.py --temperature-high for fault injection during a running demo. A useful review asks whether corrupted frames are rejected and whether the reported state changes are visible to clients. These are reproducible instructions, not claims that this site itself is running an industrial device.

The boundary matters: a digital twin can demonstrate systems organization, networking, and failure logic, but it does not prove timing guarantees, actual sensor accuracy, or physical plant safety. Hardware integration would need separate electrical, real-time, and field testing.