What is the difference between a SoM and an SBC?
A system-on-module packages a processor and supporting functions on a module that connects to a carrier or application board. The exact boundary varies by product: memory, storage, power management and wireless functions may be included. The carrier supplies the application-specific connections and circuitry that are outside that boundary.
A single-board computer provides a more complete board with a defined set of interfaces and connectors. Some SBCs are built around a SoM internally. Both approaches can support commercial products; the form factor alone does not establish reliability, lifecycle support or environmental qualification. Inspect the actual vendor commitments and evidence for the selected hardware.
| Decision | Off-the-shelf SBC | SoM with custom carrier |
|---|---|---|
| Initial hardware work | Integrate the supplied board, power and enclosure | Design, build and validate an application board |
| Interfaces | Use available connectors or add adapters | Place the required transceivers, connectors and protection |
| Mechanical fit | Accommodate the existing outline and connector positions | Design the carrier around enclosure and harness constraints |
| Software | Validate the supplied software for the application | Adapt the BSP and drivers for the carrier as required |
| Unit economics | Lower custom development spend can suit small runs | Custom engineering may be justified by repeated system-level savings |
| Change control | Depends on the board supplier's revision policy | Carrier changes are controlled by your project; the module still has a supplier lifecycle |
Start with the interface and installation constraints
Describe each external connection as a complete interface, not just a processor feature. A CAN controller does not by itself provide an isolated CAN connector, protection, termination or a verified harness. Similarly, an Ethernet-capable processor does not specify connector placement, magnetics, cable routing or the environmental rating of the enclosure.
Make a one-page installation drawing. Mark the supply input, camera cables, network, storage access, mounting holes and cooling surface. Add the required cable bend radius and service access. This often reveals whether an apparently inexpensive board needs a collection of adapters and mounting parts that outweigh its initial advantage.
For edge AI, also freeze a first workload description: model, input resolution, number of active streams and required result rate. Check the accelerator and software path before designing around the module. The RK3588 deployment guide describes how to establish a repeatable model test.
Compare complete system cost
Use the same boundary for both alternatives. Include the compute board, carrier or interface hardware, power conversion, connectors, enclosure, cooling, assembly and production test. Record software adaptation and engineering separately from recurring cost. Comparing a bare SoM price with a complete enclosed computer obscures the actual decision.
Additional custom-development cost ÷ recurring saving per unit = a simple break-even quantity.
For example, an illustrative $20,000 additional engineering cost and a $40 saving per complete unit would imply 500 units before those engineering costs are recovered. These are hypothetical inputs, not an ALVEXIS quotation. The calculation excludes financing, schedule risk, support and changes in production yield.
If the recurring saving is zero or negative, this simple cost calculation provides no break-even volume. A custom carrier may still be justified by a necessary interface, a smaller enclosure or a deployment constraint, but that benefit should be stated explicitly. Evaluate low, expected and high production volumes rather than treating one forecast as certain.
Request quotes with the same deliverables and acceptance tests. One proposal may include only PCB design, while another includes BSP changes, prototypes, test fixtures and production documentation. Those are different scopes even if both are described as a carrier-board project.
Include software ownership and maintenance
Identify who will maintain the operating-system image, drivers, boot configuration and application after the prototype is accepted. Ask which components are supplied as source, which depend on binary packages and how updates are tested. Keep a reproducible image build or a documented release procedure appropriate to the product.
A custom carrier can require changes to pin configuration, the device tree, power sequencing and peripheral drivers. Reusing a processor module reduces some hardware work, but does not remove application-board software validation. Test the actual attached devices and recovery paths, including startup with a missing peripheral.
Plan for service operations: software recovery, replacement storage, device identity, log retrieval and update rollback. These requirements influence connectors and debug access, so they belong in the hardware brief before the enclosure is finalised.
Evaluate lifecycle and environmental evidence
- Availability: ask about supply horizon, revision notices, order constraints and end-of-life procedures.
- Thermals: validate the workload with the actual cooling path and ambient conditions.
- Power: define input range, startup behaviour and the disturbances the installation can impose.
- Service: decide how a failed module, carrier or complete unit is identified and replaced.
- Qualification: distinguish component ratings, design targets and completed tests for the assembled product.
Do not assume that changing to a compatible-looking module is a drop-in upgrade. Check the electrical interface, power demand, thermal solution, boot chain and software support. Even a connector-compatible replacement needs a documented validation scope.
Three practical selection patterns
An application that fits an existing board
For a pilot or production installation whose interfaces, enclosure and environmental needs fit an available SBC, start by validating that platform. The reduced custom hardware work can allow the team to focus on the application and installation.
A product with specialised field connections
When the design needs particular connectors, isolated interfaces, a constrained outline or a tailored input supply, a SoM plus carrier can provide a cleaner integration. Define those needs in the carrier-board requirements brief before selecting the final module.
A product family with different I/O variants
A shared compute module may support several carriers. To make that useful, establish a common software baseline and explicit variant identification. The engineering saving depends on controlling differences across the family, not simply reusing the same processor.
SoM and SBC questions
Is a SoM always cheaper at higher volume?
No. Compare the complete unit cost and additional engineering cost using actual quotations, manufacturing assumptions and forecast quantities. The right answer depends on the application and existing alternatives.
Can an SBC be used in a production product?
Yes, if the particular board, software, supply arrangement and assembled product meet the requirements. A development board and a production-supported SBC should be evaluated on their documented characteristics.
What should be decided before a carrier board starts?
Define the module, interfaces, power, enclosure, operating environment, software scope, expected quantities and acceptance tests. Identify any unresolved item that could change the schematic or layout.
Choose the platform around the complete embedded system
A single-board computer (SBC) can help evaluate software and interfaces quickly. A system-on-module (SoM) can become the compute element of a custom carrier-board design when connector placement, power or mechanics need to change. The production decision should account for embedded Linux support, available drivers, update responsibility and component lifecycle as well as board price.
For an industrial PC or sensor gateway, list the installation constraints before choosing either format. If the project also uses an RTOS-based controller for time-sensitive I/O, define its interface to the application processor explicitly. A prototype that runs the application is the starting point for production validation, not the end of it.
Plan custom PCB and carrier-board development
Technical references
- Digi: selecting an embedded-system starting point
- Digi: examples of module-based embedded platforms
- NVIDIA: hardware and software bring-up checklist example
Manufacturer references illustrate their own platforms. Use the design guide for the exact module selected for your project.
Choose a practical path to your product.
Share your interfaces, enclosure constraints, target quantities and software needs. We can compare a ready platform with a module and custom carrier approach.