Industrial automation systems are rarely built around one processor. A production machine may contain a safety controller, PLC, servo drives, remote I/O, vision equipment, and an operator panel. An industrial single-board computer often sits between these components, handling work that is too complex for a basic controller but does not justify a full industrial PC.
This position makes an SBC useful, but it can also create confusion about its role. Since the board runs Linux or Android and provides GPIO, serial ports, and network interfaces, it may appear capable of controlling the entire machine. Technically, it probably can control many parts of it. Whether it should is a different question.
A practical design uses the SBC for communication, visualization, data management, and high-level coordination. Deterministic control, safety functions, and precise motion timing remain on hardware designed for those tasks.
What Is an Industrial SBC?
An industrial SBC is a compact computer with its processor, memory, storage, power circuits, and interfaces mounted on one printed circuit board. Most modern models use an ARM or x86 processor and can run a full operating system.
The word “industrial” does not describe a formal performance class. In practice, it suggests that the board is intended for integration into commercial equipment and operation under more demanding conditions than a hobby development board.
Useful industrial features may include:
- Wide-range DC input power
- Locking or pluggable connectors
- Soldered eMMC storage
- Hardware watchdog timers
- Multiple Ethernet controllers
- CAN, RS-485, and isolated I/O
- Extended-temperature components
- Defined mounting holes and mechanical drawings
- Long-term product availability
- Vendor-supported Linux or Android images
These features must be verified rather than assumed. A board may be marketed for industrial use because it has an aluminum heatsink, even though its power input, storage, and software-support policy remain similar to those of a consumer product.
The processor is only one part of the platform. Power design, connector quality, flash endurance, kernel support, and thermal behavior often have a greater influence on field reliability.
Where the SBC Fits in an Automation Architecture
An SBC is best viewed as the application computer inside a larger control system. It can collect information from controllers, present it to an operator, store production history, communicate with management systems, and perform calculations that would be awkward to implement in PLC logic.
It should not automatically replace the PLC or microcontroller. A general-purpose operating system runs many background activities, and its scheduling delay is not always predictable. Storage access, network traffic, memory management, or another process can temporarily delay an application.
A sensible allocation might look like this:
| Function | Preferred platform | Engineering reason |
|---|---|---|
| Emergency-stop processing | Certified safety controller or hardwired circuit | Must meet defined safety behavior |
| Servo and motion timing | Motion controller, PLC, or dedicated MCU | Requires deterministic execution |
| Basic sequence control | PLC | Easy to validate and maintain on the factory floor |
| Operator touchscreen | Industrial SBC | Benefits from rich graphics and UI frameworks |
| Recipe management | SBC or PLC, depending on complexity | Often requires structured data and file handling |
| Production database | Industrial SBC | Better suited to storage and database software |
| Vision inspection | SBC with GPU, NPU, or accelerator | Requires substantial processing power |
| Cloud connection | Industrial SBC | Supports encryption, VPNs, and modern protocols |
| Equipment status dashboard | Industrial SBC | Can serve browser-based or native interfaces |
| Safety interlock | Safety PLC | Must not depend on non-certified application code |
In many installations, the PLC and SBC communicate over industrial Ethernet, Modbus TCP, CAN, or a serial connection. The protocol should include more than commands and values. It should also carry state information, message counters, validity flags, and heartbeat signals.
If the connection fails, both sides need defined behavior. The PLC may reject further commands and keep the machine in a safe state. The SBC should mark displayed values as unavailable rather than leaving old data on the screen.
Designing an Equipment Interface That Operators Can Trust
An industrial HMI is not simply a consumer interface installed in a metal enclosure. It is used by people who may be wearing gloves, working under poor lighting, or responding to a machine fault under time pressure.
Android offers mature touch handling and a familiar application environment. Linux supports frameworks such as Qt, GTK, browser-based interfaces, and Wayland compositors. Either platform can produce a good HMI when the design reflects actual operating conditions.
The most important information should be visible without navigating through several pages. Machine mode, active alarms, communication status, and operating permission deserve clear presentation. Small decorative animations are less valuable than consistent controls and readable text.
Colors should support the information rather than carry it alone. A red and green distinction may be difficult for some users, and screen colors can look different under factory lighting. Adding text, shapes, or icons makes the state easier to identify.
Command feedback also needs care. When an operator presses a Start button, the interface knows only that a request was sent. It should not show “Running” until the controller confirms that state. This difference prevents a polished interface from presenting an incorrect picture of the machine.
A useful HMI also exposes enough diagnostic information for maintenance personnel. Communication counters, controller versions, I/O states, temperatures, and storage usage can shorten troubleshooting without cluttering the normal operator screen.
Industrial Interfaces Are More Than Pin Headers
Many SBCs advertise UART, SPI, GPIO, CAN, and other expansion interfaces. Those signals may exist only at processor logic levels and may not be ready for a factory environment.
For example, a UART pin is not an RS-485 port. A complete RS-485 interface requires a transceiver and usually needs termination, biasing, transient protection, and direction control. Galvanic isolation may be necessary when devices are separated by long cables or powered from different sources.
GPIO pins normally operate at 1.8 V or 3.3 V. Connecting them directly to a 24 V proximity sensor will damage the processor. Industrial digital inputs require level conversion, filtering, protection, and often isolation. Outputs may need drivers capable of handling relays, lamps, or solenoids.
When reviewing a board, ask detailed questions:
- Are serial ports electrically protected?
- Does the CAN interface include a transceiver?
- Is isolation provided, and what voltage rating does it have?
- Can RS-485 direction switching occur automatically?
- Are termination resistors fixed, selectable, or absent?
- What happens if field wiring is reversed?
- Are interface drivers included in the supported OS image?
- Is software access documented with working examples?
A connector count does not reveal how dependable the interfaces will be in a real control cabinet.
Power Design and Unexpected Shutdowns
Factory equipment rarely gives an operating system time to shut down politely. Main power may be removed at the isolator, or a protective device may disconnect the control supply during a fault.
An SBC may be updating filesystem metadata, writing a database transaction, or rotating logs when power disappears. One interruption might cause no visible problem, while repeated interruptions gradually corrupt data or leave the system unable to boot.
Several strategies can reduce this risk. The root filesystem can be mounted read-only, with changing data placed on a separate partition. Applications can use transactional writes and avoid continuously rewriting configuration files. A power-failure signal can warn the SBC to stop accepting new work.
A small UPS or supercapacitor circuit may provide enough hold-up time for an orderly shutdown. This requires more than adding capacitance. The system must detect the failing input, prevent heavy new loads, complete critical writes, and turn off before the stored energy is exhausted.
Storage endurance matters as well. An application that writes one record every second creates more than 31 million records per year. Debug logs, database journals, and system services add more traffic. Industrial eMMC or SSD storage can help, but software still needs log rotation, retention limits, and sensible write intervals.
Thermal Performance Inside the Finished Machine
An open SBC on a laboratory bench receives convenient airflow. The same board inside a sealed cabinet may sit close to a power converter, display backlight, or motor drive.
As processor temperature rises, the system may reduce its clock frequency. This thermal throttling protects the silicon, but application performance becomes inconsistent. A vision task that completes in 80 milliseconds when cold may require much longer after the enclosure reaches equilibrium.
Thermal validation should reproduce the actual installation:
- Use the production enclosure or a mechanically representative sample
- Include neighboring heat sources
- Run CPU, GPU, storage, and network workloads together
- Test at the specified maximum ambient temperature
- Monitor both temperature and clock frequency
- Continue until the internal temperature stops rising
A passive heatsink does not remove heat by itself; it transfers heat to the surrounding air. In a sealed enclosure, a heat spreader connected to the metal chassis may be more effective. Pad thickness, surface flatness, contact pressure, and assembly tolerance all affect the thermal path.
Fans can lower temperature but introduce dust, noise, maintenance, and a wear component. If a fan is unavoidable, its failure should be detected before overheating disrupts production.
Watchdogs and Recovery Behavior
A hardware watchdog can restart an SBC if software stops responding. That is useful, but merely rebooting the board does not make the overall system recover correctly.
The watchdog service should be fed only after essential application functions have been checked. A process that continues feeding the watchdog while the network stack or database is frozen defeats much of its purpose.
After rebooting, the SBC must determine the real state of the machine. It should not assume that a command sent before the failure completed successfully. It may need to reconnect to the PLC, request current states, verify software versions, and reconcile unfinished production records.
Repeated failures should also be visible. A board that silently restarts every few hours may appear functional while hiding a serious problem. Restart counters and failure reasons should be stored carefully and made available to maintenance staff.
Software Support Determines the Useful Lifetime
Industrial SBC software usually depends on a board support package containing the bootloader, kernel, device tree, drivers, firmware, and system configuration. Some hardware functions may require vendor-specific code that is not available in a standard Linux distribution.
Before approving a board, the engineering team should build the operating-system image from source in a clean environment. This exercise reveals missing repositories, undocumented binary files, obsolete compilers, and incomplete instructions while alternatives are still available.
The supplier should explain how security patches are handled, how long the BSP will be maintained, and whether hardware revisions will remain compatible. A downloadable factory image is convenient during evaluation but insufficient for a product expected to remain operational for ten years.
Updates must also survive failure. An A/B partition scheme writes the new system into an inactive partition and switches to it only after installation. If the new system cannot boot correctly, the device can return to the previous version.
The recovery procedure should be tested with interrupted downloads, interrupted writes, full storage, and incorrect images. Recovery tools and documentation should be archived with the project rather than left on a supplier website.
Selecting a Board for Production
The right industrial SBC is rarely the model with the highest benchmark score. Selection should begin with application requirements and failure behavior.
| Evaluation area | Questions worth answering |
|---|---|
| Computing performance | Can it run the full workload continuously without throttling? |
| Interfaces | Are field connections protected, isolated, and documented? |
| Power | Can it tolerate input variation and recover from brief interruptions? |
| Storage | Is endurance sufficient for expected logs and production data? |
| Software | Can the complete image be rebuilt and maintained internally? |
| Recovery | Will it recover after application failure or an interrupted update? |
| Temperature | Has it been tested inside the production enclosure? |
| Lifecycle | Will the same board remain available for the required period? |
| Vendor support | Can the supplier investigate kernel, driver, and hardware faults? |
Preproduction testing should include repeated power removal, network interruption, nearly full storage, peripheral disconnection, high-temperature operation, watchdog resets, and failed updates. These tests are less impressive than a graphical demonstration, but they reveal the faults most likely to stop real equipment.
An industrial SBC is most effective when its responsibilities are clearly bounded. Let certified and deterministic hardware protect people and control time-sensitive machinery. Use the SBC where a full operating system adds genuine value: visualization, data processing, equipment connectivity, diagnostics, storage, and integration.
That architecture may involve more than one processor, but it usually produces a machine that is safer, easier to service, and more predictable over a long production life.
Top comments (0)