SLX FlowControl: an edge controller that makes the process readable, verifiable and ready to evolve
SLX FlowControl is a Silicon LogiX technology demonstrator built around a concrete industrial use case: a cooling-water buffer tank placed between an upstream source and a downstream consumer. It runs on an STM32H750B-DK with a touch display, while Factory I/O reproduces the process with tank, level, flow, valves and a signal tower.
The result is not a screen connected to a simulation. It is an edge controller with its own process logic, a real-time control cycle, industrial communication, local HMI, alarms, operator roles, diagnostics and a repeatable commissioning procedure. Each layer describes the same situation: what happens in the digital twin, what the firmware decides and what the operator sees on the panel.
Demonstrator scope. SLX FlowControl was validated in simulation with Factory I/O and firmware on target hardware. It does not replace risk analysis, hardwired safety functions, physical-process validation, personal authentication, OT firewalls or persistent logging required by a real machine.
For an engineering team, the value of this kind of demonstrator is reaching the product phase with fewer unknowns. Before selecting final electronics or connecting a physical machine, it is already possible to review behaviour, operational priorities, interface design and diagnostic paths.
Industrial HMI, Modbus and digital twin: what to validate before the machine
SLX FlowControl is aimed at teams developing an industrial HMI alongside control logic and field integration. The demonstrator exposes the same scenario on three observable layers: the Factory I/O virtual process, the STM32 real-time firmware and the touch panel used by the operator.
- Operator interface: dashboard, process diagram, control, session recipes, alarms with cause and required action, setup and diagnostics expose state and decisions without relying on colour alone.
- Real-time logic: a FreeRTOS task running every 100 ms manages priorities, target level, interlocks and safe state, keeping fill and discharge mutually exclusive.
- Modbus TCP/IP integration: Factory I/O acts as client and the STM32 as server; the documented map keeps measurements, field commands, actuation and diagnostics separate.
- Commissioning and diagnosis: communication loss or stale sensor data bring outputs to a safe state within 1.5 seconds when control is requested; alarms remain latched until the cause is removed and the operator acknowledges them locally.
This approach fits compact machines, test benches, pilot plants, dosing systems and embedded products with a local HMI. It is not a substitute for plant PLC/SCADA design or validation of the real machine: it makes the architecture, UX, data contract and sequences testable before industrialization.
Validated sequence: from a field command back to the target level
The digital twin is not only used to show a screen. It makes it possible to observe an end-to-end sequence, from a command originating in the field to the next stable process condition.
- Clean startup: the controller starts in STOPPED. Before the first Modbus cycle, the HMI reports sensors as pending instead of turning the initial absence of data into a blocking process alarm.
- Field command: when Factory I/O requests FILL or DISCHARGE, the command has priority in the digital test bench. Firmware, virtual valve, signal tower and touch panel show the same state; if both commands overlap, valves remain closed and the conflict is explicit.
- Automatic recovery: two seconds after both commands are released, AUTO moves the level back toward the target with a ±1% deadband. After another two seconds with both valves closed, the system accepts field commands again.
- Verifiable watchdog: when control is requested, communication loss or stale sensor data drive outputs to a safe state within 1.5 seconds. The HMI retains the cause, required action and reset path.
This sequence reduces uncertainty before physical integration: it gives engineers and operators a shared way to discuss sequencing, responsibility, data contracts and stop conditions before committing final hardware and commissioning time.
When process control must do more than react to a command
In a buffer tank, the source and the consumer do not always run at the same rate. The system must receive water, supply it when required and keep an operating reserve around a target level. The hard part is not commanding a valve: it is defining what happens when commands overlap, when a sensor is not yet available at boot, when the network stops updating data, or when an operator needs to understand why the process will not restart.
SLX FlowControl treats these situations as explicit machine states rather than hidden firmware exceptions. It makes field demand, automatic phase, conflict, alarm and recovery path observable. This is the approach that turns a technical experiment into a useful development base for compact machines, test benches and pilot systems.
Real-time architecture: FreeRTOS separates control, networking and interface work
The firmware is organized so that process control does not depend on display refreshes or network timing. A periodic FreeRTOS control task runs every 100 ms, while communication, HMI rendering and diagnostics have their own responsibilities. This keeps the control decision visible and testable instead of burying it inside a monolithic main loop.
The controller keeps filling and discharging mutually exclusive, evaluates limits and interlocks before actuation, and exposes the resulting state to both the HMI and the digital twin. A real product would extend this base with the safety architecture, I/O hardware and commissioning plan appropriate to its machine.
An HMI that helps an operator decide, not just see
The HMI contains a dashboard, process diagram, control page, session recipes, alarm view, setup and system diagnostics. The design goal is not a decorative dashboard: it is to make the current phase, field demand, valve status, communication status and required operator action understandable at a glance.
Alarms provide severity, first-out context, cause, required action and a guided reset path. Acknowledge does not force a restart while the cause is still present. This is deliberately more useful than a generic red indicator because it supports diagnosis under operational pressure.
Time, audit and diagnostics: understanding what happened
Time synchronization, an in-memory audit trail of 64 events and an in-memory history of 16 alarms help reconstruct the sequence seen during a test session. The purpose is diagnostic clarity during development and commissioning, not a claim of persistent production traceability.
The system also makes network status, sensor freshness and configuration validity visible. This matters because a process controller should explain why it is waiting, stopped or inhibited instead of leaving the operator to infer it from colours or a missing output.
Digital twin and Modbus TCP/IP: simulation talks to real firmware
Factory I/O simulates the Fill Tank process while the STM32 exposes a Modbus TCP/IP server. The project documents analog measurements, digital field requests, valve outputs, diagnostics and local parameters separately, making the contract between simulation and firmware explicit.
The point is not to claim that Factory I/O is part of the final product. It is a digital twin used to test sequences, conflicts, feedback and operator UX before the physical process is available.
Sequences and abnormal conditions already checked before field integration
The demonstrator was used to exercise normal fill and discharge behaviour, overlapping field commands, alarm latching, acknowledgement conditions, startup with pending sensors, target recovery and communication watchdog behaviour. These tests make assumptions visible early, when changing a state transition is still cheaper than changing a delivered machine.
Validation in a digital twin does not remove the need for field commissioning. It gives that commissioning a clearer starting point: expected states, documented data mapping, repeatable sequences and explicit limits.
OT integration: operational continuity, clear boundaries and an evolvable design
The current build is a demonstrator, so its security boundaries are intentionally stated. Modbus TCP does not provide authentication or encryption in this implementation. A production deployment needs network segmentation, appropriate OT firewalls, controlled access, firmware lifecycle measures and a risk-based architecture for the specific machine.
Making that boundary explicit is an engineering choice. It prevents a simulation result from being misread as a certified safety or cybersecurity claim, while preserving the value of the validated firmware, HMI and process-design work.
From an STM32H750B-DK to a controller or finished product
The STM32H750B-DK is the demonstrator target, not a constraint on the final product. The next phase can move the architecture toward a custom controller, different I/O, a production display, persistent logs, authenticated services, fieldbus integration or a test fixture tailored to the machine.
The important asset is the explicit behaviour: periodic control, data mapping, HMI conventions, alarm response, diagnostics and a test sequence that engineering, commissioning and product stakeholders can inspect together.
Technical FAQ
- Does SLX FlowControl replace a plant PLC or SCADA system? No. It is an edge demonstrator for validating logic, HMI, data contracts and sequences before the real machine. It does not replace plant design, validation or machine safety functions.
- Is Factory I/O part of the final product? No. In this project it is the process digital twin used to reproduce the tank, sensors, valves and signal tower while verifying firmware behaviour and interface feedback.
- Is the demonstrator Modbus TCP/IP stack ready for a production OT network? No. The current build does not add authentication or encryption to Modbus TCP. A real machine needs segmentation, OT firewalls and security controls suited to its context.
Technical and methodological references
- FreeRTOS documentation for task-based real-time application design.
- LVGL for the embedded touch user interface.
- Factory I/O for the process digital twin.
- CISA OT cybersecurity principles for production-side operational technology considerations.
When you need custom control engineering, not just firmware integration
A project like SLX FlowControl is useful when firmware, HMI, I/O, communication and serviceability must be designed together. Silicon LogiX can start from an idea, a prototype, existing firmware or a machine that needs an upgrade, turning the technical problem into a concrete path with clear priorities and verifiable outcomes.
Need to validate a machine, embedded product or control sequence?
We can define architecture, real-time firmware, HMI, field integration, digital twin and a test plan before committing time and budget to the final product.
Contact Silicon LogiX for an initial technical assessment.
