AMResume
Back to featured work

Public C++ simulation · no physical hardware

Industrial Edge Controller & Digital Twin

C++17 industrial gateway simulation with sensor framing, watchdogs, Modbus TCP, MQTT, and fault injection.

C++17LinuxCMakeSocketsConcurrencyModbus TCPMQTTCRC-32

Overview

A software-only C++17 industrial edge gateway and simulated MCU. Virtual sensors feed a transport abstraction; the gateway validates frames, monitors sensor freshness, controls safety states, and exposes supervisory and telemetry interfaces.

Problem

A gateway linking device readings with SCADA systems must identify corrupt frames, stale telemetry, and hazardous states without treating missing data as a safe reading.

Architecture

Virtual sensors → simulated MCU (sampling and CRC-32) → TCP/UART transport abstraction → C++ edge gateway → Modbus TCP, MQTT, and SCADA tools.

My implementation

The simulation models sampling, serialized binary frames, concurrent network handling, staleness monitoring, watchdog decisions, and a fault-aware control state machine.

Tradeoffs and safety

A decoupled transport isolates simulation from potential hardware adapters. CRC-32 catches damaged frames, staleness tracking handles silence, and hysteresis limits oscillation between warning and normal states.

Verification and limits

The public source documents builds, diagnostics, and fault-injection scenarios. This is workstation software, not an actual industrial deployment or physical embedded-hardware validation.

System architecture

How the components connect

  1. 01

    Virtual sensors

  2. 02

    MCU simulator

  3. 03

    TCP / UART abstraction

  4. 04

    C++ edge gateway

  5. 05

    Modbus TCP / MQTT

Architecture is derived from the project's public documentation. It is a conceptual flow, not a live system diagram.

Engineering decision

Use transport abstraction, CRC-32 framing, staleness monitoring and state-machine hysteresis to model fault-aware gateway behavior.

Failure mode

A bad CRC must not corrupt state; a silent sensor must not remain healthy; abnormal readings must trigger safety states.

How to examine the evidence

Verified on Windows, 14 October 2026: build.bat compiled successfully and 15 of 15 tests passed, including CRC, state-machine, watchdog and virtual GPIO tests.

Windows: build.bat | Linux: ./build.sh
Build, tests, and fault scenarios

Software-only digital twin. There is no evidence of physical hardware, field deployment or hard real-time certification.