An IoT system is often presented as a simple chain: a sensor collects information, the internet carries it, and a cloud platform displays the result. Real installations are rarely that clean. Sensors may use RS-485, factory equipment may expose Modbus registers, and older controllers may communicate through proprietary serial protocols. Someone still has to validate, store, translate, and forward that data.
This is where an embedded single-board computer, or embedded SBC, becomes useful. Positioned between field equipment and cloud services, it can perform protocol conversion, local processing, storage, security, and device management. It offers more computing capability than a microcontroller while remaining smaller and less power-hungry than a conventional industrial PC.
However, selecting an SBC by comparing processor speeds is a common mistake. In deployed IoT equipment, reliable power recovery, storage endurance, software maintenance, and interface support usually matter more than a slightly faster CPU.
What Makes an SBC “Embedded”?
An SBC places the major components of a computer on one circuit board. A typical model includes a processor, RAM, flash storage, power-management circuitry, Ethernet, USB, and several low-level interfaces.
The word “embedded” normally indicates that the board is intended to operate as a component inside a larger product. Unlike a hobby board, it may offer locking power connectors, soldered eMMC storage, wide-temperature components, hardware watchdogs, and a longer production lifetime.
An embedded SBC may provide:
- Ethernet, Wi-Fi, Bluetooth, or cellular networking
- UART, SPI, I2C, GPIO, CAN, and RS-485 interfaces
- eMMC, microSD, SATA, or NVMe storage
- HDMI, LVDS, MIPI-DSI, or embedded DisplayPort
- Camera inputs and hardware video processing
- A GPU or NPU for local inference
- Secure boot and hardware key storage
The available connector is only half the story. Engineers must also verify voltage levels, isolation, Linux driver support, and access from user-space software.
The SBC as an IoT Gateway
One of the most common jobs for an embedded SBC is operating as an edge gateway. On the field side, it communicates with sensors, meters, PLCs, cameras, and controllers. On the network side, it connects to an MQTT broker, REST service, private server, or public cloud platform.
Suppose a production line has several energy meters connected over Modbus RTU. The SBC can poll their registers, convert raw values into engineering units, attach equipment identifiers and timestamps, and publish the resulting records through MQTT.
The gateway can also check whether a reading is plausible. A sudden temperature of 8,000°C is more likely to be a communication error than an actual event. Filtering that result locally prevents it from triggering a misleading cloud alarm.
Network connections cannot be assumed to remain available. A practical gateway stores records locally when the uplink fails and forwards them after connectivity returns. That behavior requires careful handling of timestamps, duplicates, storage limits, and transmission order.
SBC, Microcontroller, or Industrial PC?
No single computing platform is correct for every layer of an IoT product.
| Requirement | Microcontroller | Embedded SBC | Industrial PC |
|---|---|---|---|
| Precise real-time control | Excellent | Limited with standard Linux | Limited without real-time support |
| Power consumption | Very low | Low to moderate | Moderate to high |
| Linux or Android applications | Generally unsuitable | Well suited | Well suited |
| Local database | Limited | Practical | Practical |
| AI and image processing | Limited | Possible with GPU or NPU | Strong, depending on hardware |
| Legacy PC software | Poor fit | Architecture-dependent | Usually the best fit |
| Size and integration | Excellent | Excellent | Larger and more expensive |
| Expansion capability | Limited | Board-dependent | Usually extensive |
A microcontroller is normally better for motor control, safety interlocks, high-speed sampling, and other deterministic tasks. An SBC is better for networking, databases, user interfaces, and complex application logic.
Many reliable products use both. The microcontroller keeps essential control functions running, while the SBC manages communication and higher-level processing. If Linux needs to reboot, the real-time controller can place the machine in a known state instead of leaving outputs uncontrolled.
Local Processing at the Edge
Sending every raw sample to the cloud is not always practical. Camera streams, vibration waveforms, and high-frequency measurements can consume substantial bandwidth. Cloud processing also introduces latency and makes the system dependent on an external connection.
An SBC can reduce the data before transmission. A vibration-monitoring gateway might calculate RMS values, peak levels, and frequency-domain features locally. Under normal conditions, it uploads only these results. Raw data can be retained briefly and transmitted when an abnormal pattern is detected.
Camera systems can follow a similar design. Rather than streaming video continuously, an SBC with a supported NPU can perform local object detection and send an event message with a cropped image.
NPU specifications require caution. A figure such as 6 TOPS does not guarantee that a particular neural network will run correctly or quickly. Model conversion tools, supported operations, quantization requirements, memory bandwidth, and runtime maturity all affect real performance. Testing the actual model is more useful than comparing theoretical numbers.
Interfaces Require Electrical Engineering
A UART exposed on a header is not automatically an industrial RS-485 port. RS-485 requires a transceiver and may also need termination, biasing, surge protection, and galvanic isolation. Those details become important around motors, long cables, and different ground potentials.
Wireless connections have their own problems. A Wi-Fi module that works well on an open test bench may perform poorly after the board is installed behind an LCD or inside a metal cabinet. Final validation must use the production enclosure, antenna, cable, and mounting position.
Cellular modules can create short but significant current peaks. If the power supply cannot handle them, the SBC may restart during transmission. This failure is easily mistaken for an operating-system problem because it appears only under certain network conditions.
Choosing the Software Platform
Linux is the usual choice for an IoT gateway. Debian and Ubuntu offer familiar development environments and extensive package repositories. Buildroot and Yocto are useful when a team wants a controlled image with fewer unnecessary components and a defined update process.
Android makes sense for equipment centered on a touchscreen, such as an operator panel, medical terminal, or self-service machine. Its UI and multimedia frameworks can reduce application-development time. It should not be responsible for strict machine timing or safety functions.
Containers can separate data collection, protocol conversion, cloud communication, and local user interfaces. This makes deployment more manageable, but it also increases RAM and storage requirements. Image versions, update rollbacks, persistent data, and log growth must be planned before production.
Whatever OS is selected, the quality of the board support package matters. A powerful SoC is of little value if its Ethernet driver occasionally locks up or its vendor kernel no longer receives security fixes.
Storage and Unexpected Power Loss
IoT equipment is frequently switched off without a controlled shutdown. Linux may be updating logs, databases, or filesystem metadata when power disappears. Repeated interruptions can eventually corrupt data or prevent the device from booting.
Possible protections include:
- A read-only root filesystem
- A separate writable data partition
- Journaling and transactional database settings
- An A/B system-image layout
- A power-failure detection circuit
- A small UPS or supercapacitor
- Reduced and rate-limited logging
Flash endurance must also be considered. Writing a status record every second produces more than 31 million writes per year. Buffering records in RAM, writing them in batches, and rotating logs can substantially reduce wear.
For demanding applications, industrial eMMC or SSD storage may be justified. Engineers should monitor available capacity and, where supported, the storage device’s remaining-life indicators.
Thermal Performance Is Sustained Performance
Processor benchmarks are commonly run on an uncovered board at room temperature. A deployed SBC may sit inside a sealed enclosure beside a power converter, cellular modem, and LCD backlight. Its actual internal temperature can be much higher.
When the SoC reaches its thermal limit, it reduces its clock speed. The system does not necessarily crash; it simply becomes slower. This can produce confusing faults, such as delayed image processing or an unresponsive interface after several hours.
Thermal tests should use the final enclosure and a realistic workload. CPU, GPU, NPU, storage, and networking should be active together. If heat is transferred to the enclosure, the thermal pad thickness, contact pressure, and assembly tolerances also require verification.
Security and Field Updates
An IoT device may remain connected for years, so security cannot be treated as a one-time configuration task. Each device should have unique credentials. Unused services should be disabled, external communication should be encrypted, and secrets should be stored in a secure element, TPM, or protected SoC area where possible.
Secure boot helps prevent unauthorized firmware from running, but it also creates operational responsibilities. Signing keys must be backed up and protected. A documented recovery procedure is necessary in case an incorrect image is released.
Remote updates should survive network loss and power interruption. An A/B layout allows the device to install a new system in an inactive partition, test it during boot, and return to the previous version if startup fails.
A Practical Selection Checklist
Before approving an embedded SBC for production, evaluate the complete platform rather than the processor alone.
| Area | Questions to answer |
|---|---|
| Performance | Can it run the real workload continuously without throttling? |
| Connectivity | Are the required interfaces electrically protected and fully supported? |
| Storage | Is capacity sufficient for data, logs, and two update images? |
| Recovery | Can the unit recover after power failure or a failed update? |
| Security | Does it support secure boot, protected keys, and signed updates? |
| Software | Are kernel sources, drivers, and build instructions available? |
| Lifecycle | Will the same board configuration remain available for years? |
| Support | Can the vendor investigate low-level hardware and BSP problems? |
The best embedded SBC is rarely the newest board with the highest benchmark result. It is the one that continues collecting data during poor connectivity, survives uncontrolled shutdowns, operates inside the real enclosure, and can still be maintained several years after installation.
In a successful IoT product, the SBC is almost invisible. It quietly connects incompatible equipment, processes local information, protects data, and keeps the cloud service informed. Achieving that apparent simplicity requires treating hardware, software, power, thermal design, security, and lifecycle support as one engineering problem.
Top comments (0)