Designing Embedded Industrial Control Systems: From Web UI to Hardware - I/O
Modern industrial control systems increasingly span multiple layers, from web-based user interfaces to deeply embedded hardware I/O interacting with physical processes. While web technologies provide powerful tools for visualization and remote interaction, they also introduce latency, nondeterminism, and new failure modes that directly impact system safety and reliability.
This talk examines the end-to-end design structure of embedded industrial control systems, tracing how operator intent flows from a web UI through networking, application logic, and real-time firmware to the final hardware actuation. Research-based solutions will be presented in the presentation.
Rather than focusing on specific frameworks or tools, this talk provides transferable design principles that apply across microcontrollers, PLCs, and industrial edge devices. The goal is to equip engineers with a clear mental model for building web-connected embedded control systems that remain predictable, debuggable, and safe in real-world industrial environments. To illustrate the high-level data flow of an embedded industrial control system, the Arduino Uno Q will be the physical demonstrator of this talk.
What this presentation is about and why it matters
How do you keep an industrial control system predictable when the path runs from a web UI through networked logic to motors, sensors, and other hardware? Dr. Don Wilcher approaches that question with a research-backed talk grounded in PLC examples, a microcontroller temperature controller, and an Arduino UNO Q lab demonstrator. He walks through the contrast between deterministic and nondeterministic behavior, then shifts into Internet based control architectures and a hands-on setup that lets you see timing problems surface in code. This is a good fit for engineers, educators, and builders who want a practical way to think about timing, control flow, and safety in embedded industrial systems.
Who will benefit the most from this presentation
- Industrial automation engineer, if you work on control logic where timing and repeatability affect machine behavior.
- Embedded engineer, if your system includes sensors, actuators, or networked control paths.
- PLC programmer, if you want a bridge between ladder logic, structured text, and embedded software thinking.
- Robotics or motion control developer, if inconsistent response could affect safety or product quality.
- Engineering educator, if you teach control systems and want a demonstrator you can adapt for learners.
What you need to know
A basic familiarity with embedded control systems will help. The talk moves across a few domains and uses several control concepts and terms.
- General idea of sensors, actuators, and feedback loops
- Some exposure to PLCs or microcontroller based control
- Comfort reading simple timing or logic diagrams
- Awareness of web based or remote control interfaces
Glossary (terms used in this talk)
- RTOS (Real-Time Operating System): An operating system designed to provide predictable timing behavior for real-time applications.
- Deterministic behavior: A system property where the same input under the same conditions produces the same response within a known time bound. It is commonly used to reason about repeatability, timing, and safety in control systems.
- Non-deterministic behavior: Behavior in which the timing or outcome can vary under similar conditions. In control systems, this can show up as inconsistent response, jitter, or missed actions.
- Digital twin: A digital representation of a physical system that can be used to observe, test, or coordinate the real-world asset. It is often paired with remote operation or simulation workflows.
- Structured Text: A high-level PLC programming language defined in the IEC 61131-3 family. It is used to express control logic in a textual form that can complement ladder diagrams and other PLC languages.
- State machine: A model that defines how a system moves between named states in response to inputs, events, or timeouts. It is often used to make protocol behavior explicit and predictable.
- Programmable Logic Controller (PLC): A ruggedized industrial digital computer used for automation of electromechanical processes such as control of machinery on factory assembly lines. PLCs typically provide I/O, deterministic scan cycles, and support for industrial programming languages.
- IEC 61131-3: The international standard that defines programming languages and a programming model for programmable controllers, including languages such as Structured Text, Ladder Diagram, and Function Block Diagram.
Toolbox (mentioned in this talk)
- GitHub: A web-based platform for hosting Git repositories and collaborating on software development.
- Arduino UNO Q: An Arduino board that combines a Linux-capable processor with a microcontroller for control tasks. It supports app-based workflows that can connect user interfaces to onboard I/O.
- Arduino App Lab: An environment for building and running applications on supported Arduino hardware. It is used to connect UI elements, logic, and device I/O in a single workflow.
- STM32: A family of microcontrollers commonly used for embedded control and hardware interfacing. They are often used to drive peripherals such as LEDs, motors, and sensors.
- Snapdragon: A processor family used in embedded and mobile computing, including Linux-capable single-board style designs. It can host higher-level software alongside lower-level control components.
- YouTube: A video hosting platform used for publishing demonstrations, tutorials, and recorded walkthroughs. It is often used to show runtime behavior that is hard to capture in slides alone.
Final thoughts
Practical and example driven, this talk gives viewers a useful way to think about timing as a design concern instead of an afterthought. The value is a clearer mental model for tracing behavior from software decisions to physical outputs, plus a vocabulary for discussing predictable control in industrial settings. It will help people who build, teach, or maintain embedded control systems. The through line is simple, if timing matters, the architecture matters too.
This overview is AI-generated from the session transcript. Spot an issue? Let us know.
Hi John,
Thanks for joining the panel discussion. The book's title is called Embedded System Design - Embedded Systems Foundations of Cyber-Physical Systems, and the Internet of Things. Here is the archive.org link to obtain the book.
Hi Otzen,
Good observation and yes the control-loop delay may present delays in the switch to device actuation due to transmission latency. Partitioning control loop delays locally as described in your example would minimize such latencies. The Internet Controller Architectures presented are researched based systems that allow remote distribution for the operator to engaged with plant. Therefore, additional experimentation and testing will be needed to improve the timing to mimimize or eliminate non-determinstic behavior in the system.
Hi
I don't think you touch upon it, but I kept thinking that the biggest hurdle I would see in having something like the internet between controller and actuator/sensor, is the control-loop delay.
This I would address by attempting to split the control-loop into an inner and an outer loop.
Example: A robot grass mover, using a lidar for navigation. And the Navigation has to happen on a remote controller. i would have a local controller with fast feedback loop controlling the wheel motors, ensuring the desired speed or rotation count, based on the setpoint received from the remote controler.
The remote control-loop would receive the lidar data as feedback, and see the remote controller as an actuator, sending it control info in form of speed and curvature or rpm count.
If the remote controller should control the wheel motor directly, it would have to be very damped to not overshoot, or in other words slow down the mover speed significantly to not get too much out of course between loop iterations.
Not sure what I am asking, it was just what confused me watching the talk.








Dr. Wilcher, what was the system design book that you recommended in the panel discussion?