5x faster boot for an industrial HMI display
How we cut the boot time of a Linux-based HMI panel from about 55–60 to 10 seconds with software alone, so operators never lose sight of live production data after a restart.
- Industry
- Industrial Automation
A European OEM builds Linux-based industrial HMI displays. One of its customers, a food factory producing peanut butter in tubes, uses the panels to monitor roasting, grinding, mixing and filling in real time, next to high-frequency temperature, level and flow sensors.
Even small deviations in temperature or viscosity can cause texture defects, separation or contamination, so operators watch the panels continuously and act as soon as values drift.
At a glance
- Industry
- Industrial Automation
Planning something similar? A senior engineer replies within one business day.
The challenge
After power losses, maintenance or shift changes, sensors and controllers came back almost instantly, but the HMI panels needed about 55–60 seconds to become operational, far beyond the 15-second target expected in production. That left gaps in live data and alarms during every restart.
The manufacturer could move to a faster, more expensive hardware platform, or optimise the software on the existing hardware. It chose software, and asked us to analyse and optimise the Linux startup sequence.
Our approach
Boot-time profiling: using system logs, systemd-analyze and bootchart, we found latency at every stage, from U-Boot delays to systemd service ordering.
Bootloader and kernel: removed U-Boot delays and simplified init (about 3 s saved); disabled unused drivers and debug options in the kernel (about 3 s).
Root filesystem: moved from ext4 to a compressed SquashFS (LZ4) image with an OverlayFS layer, chosen for very fast decompression and low CPU overhead on a read-only system (about 14 s).
User space: restructured systemd so fieldbus, OPC UA and network communication start first, and deferred logs and diagnostics until the HMI interface is up (about 30 s).
Verification: more than 100 cold boot cycles with consistent startup, and five HMIs tested in the field in synchronised operation with no data delays and stable recovery after power cycles.
Tech stack: U-Boot (custom-tuned), Buildroot (Linux 4.x), SquashFS + OverlayFS (LZ4), systemd with custom targets, OPC UA, MQTT and Modbus TCP, on ARM Cortex-A7 with eMMC.
The challenge
After power losses, maintenance or shift changes, sensors and controllers came back almost instantly, but the HMI panels needed about 55–60 seconds to become operational, far beyond the 15-second target expected in production. That left gaps in live data and alarms during every restart.
The manufacturer could move to a faster, more expensive hardware platform, or optimise the software on the existing hardware. It chose software, and asked us to analyse and optimise the Linux startup sequence.
Our approach
Boot-time profiling: using system logs, systemd-analyze and bootchart, we found latency at every stage, from U-Boot delays to systemd service ordering.
Bootloader and kernel: removed U-Boot delays and simplified init (about 3 s saved); disabled unused drivers and debug options in the kernel (about 3 s).
Root filesystem: moved from ext4 to a compressed SquashFS (LZ4) image with an OverlayFS layer, chosen for very fast decompression and low CPU overhead on a read-only system (about 14 s).
User space: restructured systemd so fieldbus, OPC UA and network communication start first, and deferred logs and diagnostics until the HMI interface is up (about 30 s).
Verification: more than 100 cold boot cycles with consistent startup, and five HMIs tested in the field in synchronised operation with no data delays and stable recovery after power cycles.
Tech stack: U-Boot (custom-tuned), Buildroot (Linux 4.x), SquashFS + OverlayFS (LZ4), systemd with custom targets, OPC UA, MQTT and Modbus TCP, on ARM Cortex-A7 with eMMC.
Our approach
What it means for you: boot time is fixed in software first, so you keep your hardware and BOM and still meet the target.
Tech stack: U-Boot (custom-tuned), Buildroot (Linux 4.x), SquashFS + OverlayFS (LZ4), systemd with custom targets, OPC UA, MQTT and Modbus TCP, on ARM Cortex-A7 with eMMC.
Boot-time profiling
Using system logs, systemd-analyze and bootchart, we found latency at every stage, from U-Boot delays to systemd service ordering.
Bootloader and kernel
Removed U-Boot delays and simplified init (about 3 s saved); disabled unused drivers and debug options in the kernel (about 3 s).
Root filesystem
Moved from ext4 to a compressed SquashFS (LZ4) image with an OverlayFS layer, chosen for very fast decompression and low CPU overhead on a read-only system (about 14 s).
User space
Restructured systemd so fieldbus, OPC UA and network communication start first, and deferred logs and diagnostics until the HMI interface is up (about 30 s).
Verification
More than 100 cold boot cycles with consistent startup, and five HMIs tested in the field in synchronised operation with no data delays and stable recovery after power cycles.
Results
- Boot time cut from about 55–60 to 10 seconds, with no hardware changes
- Operators see live data within seconds of power-on
- No missed telemetry or alarms during restarts
- More competitive in the HMI market on price and boot time
The optimised software lets the existing hardware start as fast as higher-end, more expensive displays, giving the manufacturer a clear advantage in price-to-boot-time and a longer life for the current product line.
Planning something similar?
Tell us where you are. A senior engineer replies within one business day.
Services used
Production-grade embedded Linux for connected devices: from board bring-up to a maintained, updatable OS image.
Board support packages that boot reliably, support all your peripherals and can be upgraded for the life of the product.
An independent review of your device, edge and cloud architecture by engineers who have shipped and operated a connected product at fleet scale.
Talk to an engineer, not a salesperson
Idea, prototype, production or a fleet in the field: tell us where you are. A senior engineer replies within one business day.
Your benefits:
- Senior embedded engineers
- Hardware, firmware and cloud
- From prototype to fleet
- Clear scope and next steps
- Direct technical answers
- No sales pitch
What happens next?
A free 30-minute call with a senior engineer
A short technical discovery
A proposal with scope, timeline and cost
