Blog 

What Is a SOM?

A SOM, or System on Module, is a small circuit board that concentrates the core computing subsystem of an embedded product. It usually includes the processor or SoC, RAM, flash or eMMC storage, clocking, power-management components, and high-density connectors that expose buses such as USB, PCIe, UART, SPI, I2C, GPIO, display, audio, and networking signals.

The important part is what a SOM intentionally leaves to the carrier board. Full-size connectors, field wiring, power jacks, display ports, enclosure mounting, and product-specific I/O usually live on a carrier or baseboard. That split lets the compute module stay reusable while the carrier adapts the system to a real product.

What Is an SBC?

An SBC, or Single Board Computer, is a complete computer on one board. It integrates the compute subsystem and the practical connectors needed to use it: power input, USB, Ethernet, display output, storage, GPIO headers, expansion slots, and sometimes wireless, audio, or camera interfaces.

An SBC is usually easier to evaluate because the board can boot, connect to peripherals, and run software without a custom carrier design. For embedded teams, this can shorten early prototyping.

This does not mean SBCs are limited to hobbyists or education. Many industrial products use SBCs successfully when the connector layout, board size, thermal behavior, and lifecycle fit the product. The difference is that an SBC gives you a more complete board upfront, while a SOM gives you a compute module that expects more system design around it.

SOM vs SBC: The Core Difference

The core difference between a SOM and an SBC is the boundary between compute and product integration. A SOM packages the compute engine and expects a carrier board. An SBC packages the compute engine and the carrier-like functions onto one board.

The table is not a ranking. A SOM is not automatically more professional, and an SBC is not automatically less production-ready. The right choice depends on where the hardware risk sits in your project.

Practical Differences Engineers Actually Feel

The SOM vs SBC decision becomes concrete when the team starts connecting real devices, building enclosures, and planning production support.

Compute Module vs SBC for Prototyping

In prototyping, the fastest path is not always the most production-ready path. A team may start with an SBC to validate software, user interface, networking, or sensor behavior, then move to a SOM or modular design when the mechanical and I/O requirements become clearer.

A practical prototyping path:

1. Start with the question the prototype must answer. If the risk is mostly software, use an SBC and begin testing.
2. List the non-negotiable hardware constraints: power input, display, network ports, sensor buses, mounting points, thermal envelope, and enclosure size.
3. Check whether an existing SBC can satisfy those constraints without awkward adapters or cabling.
4. If the answer is no, evaluate a SOM and carrier-board approach before the prototype becomes dependent on the wrong board shape.

Do not treat the initial prototype board as the final architecture by default. Either architecture can be right, but the decision should follow the product constraints, not the acronym.

When a SOM Makes More Sense

Choose a SOM-oriented path when several of these are true:

• The enclosure is fixed, thin, sealed, or cable-constrained.
• The product needs specific connectors in specific locations.
• The project needs industrial I/O, panel connectors, field wiring, or custom display interfaces.
• The team expects several product variants that can share one compute module.
• The compute module may need to be swapped or upgraded while keeping a carrier-board family.
• The hardware team can design and validate a carrier board.

The risk is that a SOM shifts more responsibility to the hardware team. Carrier-board design, signal integrity, power sequencing, mechanical layout, thermal validation, and software bring-up all need attention.

When an SBC Makes More Sense

Choose an SBC-oriented path when several of these are true:

• The team needs to boot the system and start coding immediately.
• The project is an internal tool, demo, test fixture, gateway, or low-volume deployment.
• The board already has the required USB, Ethernet, display, storage, and GPIO access.
• The enclosure can be designed around the board instead of the other way around.
• The hardware team is small or not available for carrier-board design.
• The product does not need unusual connector placement or a custom field-wiring layout.

The risk is that an SBC can hide future integration problems. If the board is too large, connectors face the wrong direction, or required interfaces are missing, the prototype can become expensive to reshape later.

Worked Example: Where an Intel N100 Modular SBC Fits

Some boards sit between a classic SOM and a fixed standalone SBC. The youyeetoo K1 is useful as a worked example because it combines an Intel N100 x86 compute core with a carrier-board configuration, so it can illustrate the compute-module-plus-carrier idea without turning this article into a product page.

According to the current K1 wiki and project knowledge base, K1 uses an 82x71mm core board and an optional 134x92mm carrier board. The platform is built around Intel N100, supports Windows and Linux, and can be configured with up to 16GB LPDDR5. The carrier-board side exposes practical interfaces such as dual Gigabit Ethernet, MIPI DSI/eDP display options, and native I/O access.

That does not make K1 the answer to every SOM vs SBC decision. It is an example of a modular x86 SBC approach:

• The core board shows why compute can be separated from the larger application board.
• The carrier board shows why connectors, display interfaces, networking, and I/O still matter.
• The x86 platform can matter when the project depends on Windows/Linux software compatibility.

SOM vs SBC Decision Checklist

Use this checklist before choosing the board architecture:

1. Do you need standard connectors immediately for software testing? If yes, start with an SBC or a vendor carrier kit.
2. Does the final enclosure force a specific board shape or connector location? If yes, evaluate a SOM and custom carrier.
3. Are your required interfaces already available on a production-ready SBC? If yes, an SBC may be enough.
4. Do you need custom field wiring, display routing, or industrial I/O? If yes, a carrier-board design may become necessary.
5. Does the team have hardware design and validation capacity? If no, avoid custom carrier work unless a partner or vendor can support it.
6. Will the same compute platform be reused across multiple products? If yes, a SOM can make the architecture easier to reuse.
7. Is the main project risk software, not hardware? If yes, an SBC can reduce early friction.
8. Is the main project risk mechanical fit, I/O layout, or lifecycle control? If yes, a SOM or modular carrier approach deserves early evaluation.

FAQ

Is a SOM the same as a compute module?

Often, yes in practical conversation. A compute module carries the compute subsystem, and many compute modules are used as SOMs. Always check vendor documentation because naming is not fully consistent.

Is an SBC always easier than a SOM?

An SBC is usually easier to start with because it already has power input and connectors. It may become harder later if the final product needs a different shape, connector layout, display path, or field wiring design.

Can I start with an SBC and move to a SOM later?

Yes. Many teams use an SBC to validate software and system behavior, then move to a SOM or modular carrier-board architecture when product constraints become clearer.

Does a SOM always reduce product cost?

No. A SOM can improve reuse and customization, but total cost depends on module pricing, carrier-board design, engineering time, validation, order volume, and lifecycle requirements.

When should an industrial product avoid a generic SBC?

Avoid a generic SBC when the product needs controlled connector placement, unusual display routing, field wiring, strict enclosure fit, lifecycle planning, or interfaces that the SBC does not expose cleanly.

Where does a modular Intel N100 board fit in the SOM vs SBC decision?

A modular Intel N100 board can fit when the team wants x86 software compatibility and a carrier-board-style integration path. It should still be evaluated against the project's I/O, enclosure, thermal, OS, and lifecycle requirements.

Terms