SoM, CoM, or SBC: Choosing the Right Embedded Architecture for Your Industrial IoT Project

Most IoT projects in manufacturing don't fail because of bad hardware. They fail because the team tries to do too much, too fast. Equipment gets replaced before anyone has solved the more fundamental problem: getting usable data out of what they already have.

This is a pattern we've seen across multiple deployments. And it's exactly what we helped one electronics manufacturer avoid.

This article walks through the embedded architecture framework we used: how we decide between SoM, CoM, and SBC based on project scale, and why getting your data architecture right matters more than any hardware choice.

 

The Real Problem Isn't Missing Hardware

When our team first engaged with this client (a mid-sized electronics manufacturer running SMT and assembly lines), the instinct from their operations team was to look at new equipment. More sensors, more endpoints, more hardware.

But a closer look at their environment told a different story. Their machines were already generating data. The problem was that none of it was talking to anything else. Each system was an island.

 

The challenges were familiar:

• Machine data locked in proprietary formats with no integration layer

• No real-time visibility into OEE or line status

• Maintenance teams responding reactively rather than predictively

• Management decisions based on end-of-shift reports, not live data

 

💡The first step wasn't adding hardware. It was making existing equipment data accessible, normalized, and actionable.

This reframing changed the entire deployment strategy and ultimately led to a much faster, lower-risk rollout.

 

Project Scale Determines Architecture: SoM or CoM for Smaller Projects, SBC at Volume

When we work with a new client, the first question we ask isn't which hardware to use. It's how many units they need to deploy. That number shapes the architecture recommendation more than any other variable.

 

Smaller Projects: SoM or CoM

For lower-volume projects, System on Modules (SoM) and Computer on Modules (CoM) are the right starting point. Both architectures separate the compute layer from the carrier board, which gives you room to adjust integration and connectivity without redesigning the whole system.

In factory environments with heterogeneous equipment and mixed communication protocols, that flexibility is hard to replicate:

 

• Straightforward integration across different devices and protocols (OPC-UA, Modbus, MQTT)

• Specs can be revised without a full hardware redesign

• Faster development cycles, especially when requirements aren't fully locked down

• Per-unit cost remains manageable at lower volumes

 

In practice, CoM modules are commonly used in x86-based industrial systems, while SoM typically runs on ARM architectures and is well-suited for IoT and edge computing workloads. Either way, both give you the integration headroom you need at lower volumes.

 

Higher-Volume Projects: SBC

When a project calls for large-scale deployment, the priorities shift. Flexibility matters less. What you need is consistency, cost efficiency, and hardware that's easy to maintain across hundreds or thousands of nodes.

SBCs are the right fit here:

 

• Lower per-unit cost at volume compared to SoM or CoM designs

• Uniform hardware across every node makes firmware updates, troubleshooting, and replacements straightforward

• No ongoing carrier board iteration once the design is production-ready

• Easier supply chain planning at scale

 

The short version: SoM and CoM answer the question of how to build it. SBC answers the question of how to build a lot of them.

 

Project Scale vs. Recommended Architecture

 

 

Choosing the Right SoM Standard: SMARC, Qseven, or OSM?

Once you've committed to a SoM-based architecture, the next decision is which module standard to adopt. This matters more than it might seem: it affects your long-term ecosystem support, thermal constraints, and whether you can source replacement modules years down the line.

 

SMARC (Smart Mobility Architecture)

• Optimized for low-power, thermally constrained environments

• Strong ecosystem support for both ARM and x86 processors

• The go-to standard for IoT and AIoT edge applications

• Well-suited for industrial environments with strict power budgets

 

Qseven

• A mature standard with a broad ecosystem of carriers and peripherals

• Particularly strong for x86-based industrial control applications

• Good choice when you need wide vendor support and long supply lifecycle

 

OSM (Open Standard Module)

• Solderable directly onto the carrier board, which eliminates connector reliability concerns

• Smallest form factor among the major standards

• Ideal when space is the primary constraint and volumes are high enough to justify the carrier board investment

• Increasingly popular for high-volume AIoT endpoint devices

 

 

Platform Selection: MediaTek vs. NXP for Industrial IoT

Beyond the module standard, the processor platform shapes the long-term capability and support lifecycle of your deployment.

 

MediaTek — for AIoT and Edge Inference

• Strong performance-per-watt for edge AI workloads

• Native support for edge AI inference pipelines

• Well-suited for smart retail, vision analytics, and service automation use cases

 

NXP Semiconductors — for Industrial Reliability

• Long-term supply commitment (often 10+ years for industrial-grade parts)

• Proven reliability in harsh factory environments

• Strong ecosystem for factory automation, robotics, and automotive-adjacent applications

 

💡Our selection principle: optimize for the right balance of performance, stability, and lifecycle support. No single metric should drive the decision in isolation.

 

The Layer That Determines Project Success: Data Architecture

In our experience, the IoT deployments that actually deliver ROI have one thing in common: they treat data architecture as seriously as hardware selection.

Hardware is solvable. The harder problem is making sure data from different machines, lines, and systems can actually be compared, aggregated, and acted upon.

 

In every deployment we run, we prioritize three things at the data layer:

 

• Data normalization: a unified schema that every edge device writes to, regardless of source protocol

• Standardized APIs, so upstream systems (MES, ERP, dashboards) can consume data without custom integration for each source

• Fragmentation prevention, which means avoiding the pattern where each line or factory evolves its own data format independently

 

Getting this right rarely makes it into the project pitch. But it's consistently the factor that determines whether a deployment grows or gets stuck.

 

Results from the Field

With this architecture approach in place, the client reported measurable improvements across three areas (figures are client-reported metrics from their internal tracking):

 

Production Efficiency

• +15% improvement in Overall Equipment Effectiveness (OEE)

• −30% reduction in unplanned downtime events

 

Maintenance Operations

• 40% faster average maintenance response time

• Shift from reactive to predictive maintenance posture

 

Management and Visibility

• Real-time production dashboards replacing end-of-shift manual reporting

• Remote monitoring capability across multiple lines

• Data-driven capacity planning replacing intuition-based decisions

 

How to Apply This Framework to Your Deployment

If you're evaluating IoT deployment for a manufacturing environment, here's how to use this framework as a starting point:

 

• Start with your data problem, not your hardware problem. Identify where data is being generated and why it's not usable today.

• Nail down your project scale first. Lower-volume projects should start with SoM or CoM for integration flexibility. High-volume projects should evaluate SBC from the outset for cost and consistency.

• Pick your module standard early. SMARC, Qseven, or OSM: the right choice depends on your volume, power budget, and supply requirements. It's also harder to change later than most teams expect.

• Build your data architecture in parallel with your hardware design. Treating it as an afterthought is one of the most common reasons IoT projects stall after the pilot.

 

Working Through a Similar Architecture Decision?

Every manufacturing environment is different. If you're in the early stages of evaluating embedded architecture for IoT, or you're stuck in a pilot that's not scaling the way you expected, we're happy to talk through your specific situation.

Reach out to InnoComm's engineering team to start the conversation.