Rethinking Embedded Architecture for Industrial IoT Success #
Most industrial IoT (IIoT) projects in manufacturing do not fail due to inadequate hardware. Instead, they often stumble because teams attempt to overhaul systems too quickly, overlooking the foundational challenge: making existing machine data accessible and actionable. This article outlines a practical framework for choosing between System on Module (SoM), Computer on Module (CoM), and Single Board Computer (SBC) architectures, emphasizing why robust data architecture is more critical than hardware selection alone.
The Real Challenge: Unlocking Existing Data #
When engaging with a mid-sized electronics manufacturer operating SMT and assembly lines, the initial instinct was to invest in new equipment—more sensors, more endpoints, more hardware. However, a closer assessment revealed that the real issue was data silos:
- Machine data was trapped in proprietary formats without integration layers.
- There was no real-time visibility into Overall Equipment Effectiveness (OEE) or line status.
- Maintenance was reactive, not predictive.
- Management decisions relied on end-of-shift reports rather than live data.
Key Insight: The first step was not to add hardware, but to make existing equipment data accessible, normalized, and actionable. This shift in perspective led to a faster, lower-risk deployment.
Project Scale as the Primary Driver of Architecture #
The most important question when starting a new IIoT project is not which hardware to use, but how many units will be deployed. Project scale directly influences the recommended architecture.
For Smaller Projects: SoM or CoM #
For lower-volume deployments, System on Modules (SoM) and Computer on Modules (CoM) are ideal. These architectures separate the compute layer from the carrier board, allowing for flexible integration and connectivity adjustments without a complete redesign. In environments with diverse equipment and communication protocols, this flexibility is invaluable:
- Simplified integration across devices and protocols (OPC-UA, Modbus, MQTT)
- Ability to revise specifications without full hardware redesign
- Accelerated development cycles, especially when requirements are evolving
- Manageable per-unit costs at lower volumes
Typically, CoM modules are used in x86-based industrial systems, while SoM modules run on ARM architectures, making them well-suited for IoT and edge computing workloads.
For High-Volume Projects: SBC #
When scaling to hundreds or thousands of nodes, priorities shift toward consistency, cost efficiency, and ease of maintenance. SBCs become the preferred choice:
- Lower per-unit cost at scale compared to SoM or CoM
- Uniform hardware simplifies firmware updates, troubleshooting, and replacements
- No need for ongoing carrier board iterations once production-ready
- Streamlined supply chain planning
Summary Table:
| Project Scale | Recommended Architecture | Primary Reason |
|---|---|---|
| PoC / Pilot | SoM / CoM | High integration flexibility, low cost of change |
| Small-scale deployment | SoM / CoM | Specs can still evolve; flexibility is key |
| High-volume production | SBC | Cost efficiency and deployment consistency |
Selecting the Right SoM Standard: SMARC, Qseven, or OSM #
After choosing a SoM-based approach, the next step is selecting the appropriate module standard. This decision impacts long-term ecosystem support, thermal management, and module availability.
SMARC (Smart Mobility Architecture) #
- Optimized for low-power, thermally constrained environments
- Strong ecosystem support for both ARM and x86 processors
- Preferred for IoT and AIoT edge applications
- Suitable for industrial settings with strict power budgets
Qseven #
- Mature standard with a broad ecosystem of carriers and peripherals
- Especially strong for x86-based industrial control
- Good for projects needing wide vendor support and long supply lifecycles
OSM (Open Standard Module) #
- Solderable directly onto the carrier board, eliminating connector reliability issues
- Smallest form factor among major standards
- Ideal for space-constrained, high-volume designs
- Increasingly popular for AIoT endpoint devices
Standard Selection Table:
| Requirement | Recommended Standard |
|---|---|
| Industrial control / cross-platform flexibility | SMARC or Qseven |
| Space-constrained, high-volume production | OSM |
| IoT/AIoT edge node with power constraints | SMARC |
Platform Choices: MediaTek vs. NXP for Industrial IoT #
Beyond module standards, the processor platform determines long-term capability and support.
MediaTek — Optimized for AIoT and Edge Inference #
- High performance-per-watt for edge AI workloads
- Native support for edge AI inference pipelines
- Well-suited for smart retail, vision analytics, and service automation
NXP Semiconductors — Focused on Industrial Reliability #
- Long-term supply commitment (often 10+ years)
- Proven reliability in harsh environments
- Strong ecosystem for factory automation, robotics, and automotive applications
Selection Principle: Optimize for a balance of performance, stability, and lifecycle support. No single metric should dictate the decision.
The Critical Layer: Data Architecture #
Successful IoT deployments prioritize data architecture as much as hardware. The real challenge is ensuring data from various machines and systems can be compared, aggregated, and acted upon. Key priorities at the data layer include:
- Data normalization: Unified schema for all edge devices, regardless of protocol
- Standardized APIs: Upstream systems (MES, ERP, dashboards) can consume data without custom integrations
- Fragmentation prevention: Avoiding divergent data formats across lines or factories
Getting this right is often overlooked but is crucial for scalable, ROI-driven deployments.
Field Results: Measurable Improvements #
With this architecture in place, the client achieved significant gains (as reported by their internal metrics):
Production Efficiency #
- 15% improvement in Overall Equipment Effectiveness (OEE)
- 30% reduction in unplanned downtime
Maintenance Operations #
- 40% faster average maintenance response time
- Transition from reactive to predictive maintenance
Management and Visibility #
- Real-time dashboards replaced manual end-of-shift reporting
- Remote monitoring across multiple lines
- Data-driven capacity planning
Applying This Framework to Your IIoT Deployment #
For those evaluating IoT deployments in manufacturing, consider the following steps:
- Begin with your data challenges, not hardware. Identify where data is generated and why it is not currently usable.
- Define your project scale early. Use SoM or CoM for lower volumes and integration flexibility; consider SBC for high-volume, consistent deployments.
- Select your module standard (SMARC, Qseven, or OSM) early, as changing later is difficult.
- Develop your data architecture in parallel with hardware design to avoid common pitfalls that stall projects after pilot phases.
Every manufacturing environment is unique. If you are navigating embedded architecture decisions or facing challenges scaling your pilot, consider consulting with experienced engineering teams for tailored guidance.