What is System on Module? How to develop SOM software

A System on Module has become the foundation of many modern embedded products - but selecting and integrating the right module is not always a straightforward decision. You've got to weigh up the pros and cons, which can be tough to get a handle on at first.

To get a better understanding of these trade-offs from a practical engineering point of view, we talked to Piotr Zbyśliński, CTO with years of hands-on experience in designing and deploying SoM platforms. His experience with real-world products highlights both the strengths and the limitations of this approach.

In this article, we're going to take a closer look at:

• why the industry is moving toward modular compute architectures,

• how SoMs reduce risk in complex MPU/SoC designs,

• realistic expectations around migration, compatibility and thermals,

• the role of BSPs, Yocto and software bring-up in project success,

• when a SoM is not the right choice for your application, and

• how hardware and software teams can collaborate effectively to build reliable products.

From a software and system integration perspective, companies like Somco can help out with SoM-based projects - they provide adaptation of BSPs, development of embedded Linux, automation of the CI/CD process, and long-term software maintenance. This gives you a software-focused view to go with Piotr's more hardware-focused perspective in this article.

What exactly is a System on Module (SoM)?

System on Module (SoM) is a small printed circuit board that packs all the key elements of a computer system (processor, memory, storage, etc.) into one ready-to-use module. It's a miniature computer core - the SoM hosts a microprocessor (often an SoC), along with RAM, flash storage, power management, and interface controllers for peripherals.

The market has been moving steadily towards SoM-based designs because modern MPUs and SoCs have become increasingly complex to integrate in custom hardware.

As Piotr points out, the shift towards SoMs is driven mainly by the growing performance and connectivity requirements of modern embedded systems. He explains that SoMs let teams avoid a lot of the difficult bits of chip-down design, especially the tricky aspects of high-speed memories like LPDDR4, LPDDR5, DDR4 and DDR3L, as well as interfaces such as PCIe, SDIO and USB 3.x.

For managers and CTOs, SoMs are not just another hardware option - they're a way to outsource the riskiest part of electronics and build products on a predictable, industrial-grade compute platform.

How Do System on Modules Work?

A System on Module connects to a carrier board through a standard interface (connectors or soldered pins) , and together they operate as a single integrated system. The SoM typically exposes a high-density connector that carries signals for power, data buses, and I/O interfaces to the carrier. When mounted on the carrier board, the SoM + carrier combination acts like a complete embedded computer: the SoM provides the computing functions (processor, memory, connectivity), while the carrier board provides the physical form factor and any specialized I/O . In essence, the carrier board extends the SoM's signals out to usable connectors (USB ports, HDMI display, Ethernet jacks, SD card slots, camera connectors, etc.) and implements any application-specific circuits (e.g. analog sensors, motor drivers, etc. that are required by the final product). This separation of concerns makes design easier: engineers can focus on customizing the carrier for their application's needs, knowing that the complex CPU, memory and OS functionality is handled by the off-the-shelf SoM.

Benefits of Using a System on Module in Embedded Applications

In practice, teams choose SoMs primarily to control technical risk and speed up the most fragile phases of hardware development. As Piotr explains, the biggest advantage is not performance, but predictability. Instead of spending months worrying about DDR routing, power sequencing, signal integrity and early boot stability, engineers can start from a platform that is already electrically proven and focus on product-level functionality.

Lower NRE and faster time-to-market

Piotr points out that for small and medium production volumes, the economics of SoMs are often counter-intuitive. The cost of a ready-made module is frequently comparable to the total cost of individual components, once PCB complexity, validation effort and engineering time are taken into account.

In such projects, SoMs significantly reduce NRE by removing the need for custom DDR validation, complex power design and early-stage bring-up debugging.

Reduced certification complexity

According to Piotr, certification is one of the most underestimated advantages of SoM platforms. Professionally designed modules usually undergo EMC pre-compliance testing and often integrate pre-certified radio components.

This means that a large part of the electromagnetic behavior of the final product is already characterized before the carrier board even exists, significantly reducing risk during formal certification.

Long-term availability and lifecycle stability

Piotr stresses that lifecycle management is a technical requirement, not a commercial detail. In long-lived products, the SoM must be built from industrial-grade components with clearly defined EOL guarantees and a controlled revision policy.

Without this, even a technically good module becomes a long-term risk for medical, industrial and automotive systems.

A ready software foundation

From Piotr’s perspective, the quality of the BSP is what truly defines a professional SoM platform. A mature module should come with a maintained bootloader, kernel, device-tree configuration and Yocto layers that allow software teams to start development immediately.

This shifts the focus from low-level bring-up to application development and system integration from day one.

Common Applications of System on Modules

System on Modules are widely adopted across industries that rely on compact, reliable and long-lifecycle embedded computing. They combine performance, power efficiency and maintainability in a really useful way, making them suitable for both consumer-grade and critical devices.

Medical tech relies on SoMs for portable diagnostics, patient monitoring, imaging and connected therapeutic devices. The tight certification landscape makes pre-validated compute modules especially valuable, as vendors often provide EMC test reports and radio certification packages that cut down on approval time.

Automotive systems use SoMs in infotainment, telematics and ADAS-related processing. GPU acceleration, high-speed interfaces and long-term availability work really well with automotive development cycles (plus you need secure boot, hardware crypto and robust connectivity to comply with all the regulations).

Industrial automation and Industry 4.0 deploy SoMs in PLC controllers, machine vision, robotics, gateways and edge AI devices. Reliability in harsh conditions, extended temperature options and long-term roadmap stability make modular compute platforms a no-brainer for factories, energy systems and transportation networks.

And that's not all - SoMs power aerospace payloads, comms gear, smart agriculture, defense subsystems and early-stage product innovations where rapid prototyping is a competitive advantage.

When NOT to Use a System on Module

While SoMs have loads of advantages in many embedded projects, they are not the right choice for every product. In some cases, a custom chip-down design or even a microcontroller-based architecture will give you better cost, performance or certification characteristics. Here are the cases where a SoM might not be the best fit:

• High-volume products with strict cost targets

• Simple or ultra-low-power devices

• Projects with extreme thermal or size constraints

• Applications requiring hard real-time behavior

• Solutions needing full control over the secure boot chain

• When absolute pin-compatibility across product generations is mandatory

Choosing the Right System on Module for Your Application

Selecting the right SoM is a strategic decision that impacts performance, certification, product cost and long-term maintainability. CTOs and engineering managers should evaluate several dimensions:

Migration and Scalability: A Realistic Perspective

One of the most commonly talked-up advantages of SoMs is the ability to easily migrate between modules that follow the same mechanical standard, like SMARC or Qseven or SODIMM. While this does support long-term product evolution, it should be treated as an engineering challenge rather than something that just happens magically.

As Piotr points out, pin compatibility across different SoM families is often more a marketing promise than a technical reality:

Standardizing the pinout across different MPU and SoC families on SoM connectors is purely a marketing argument rather than a technical one. Manufacturers who claim their modules are interchangeable rarely mention that this compatibility is only almost complete. And as we know, almost can make a very big difference.

In practice, SoMs still offer a far more predictable migration path than chip-down designs. However, true drop-in replacements are rare and require early planning, strict alignment with the module vendor, and careful validation of power domains, boot configuration, peripheral routing and thermal behavior—especially when moving between different MPU generations or performance classes.

Software Matters: BSP, OS Readiness and Project Bring-Up

In SoM-based projects, software development almost never starts with bare, unaided hardware. Instead, it starts with a Board Support Package (BSP) delivered by the module vendor - & that's a lifesaver. This BSP usually contains a bootloader, a Linux kernel, device-tree configuration, a batch of core drivers & a build environment based on Yocto.

This can be the single biggest speed bump you'll hit in the entire project. Instead of spending weeks on early boot debugging, getting DDR to play nice or bringing up peripherals, the system is up & running right from the start. This lets your team skip all that nonsense & focus on product functionality & system integration right away.

As Piotr explains, a mature SoM platform is all about the quality of its BSP. It needs to be kept up to date & provide a complete, reproducible build environment that lets engineers fire up evaluation hardware in no time & move smoothly onto their own custom carrier boards.

Once a custom carrier board is ready, the BSP needs to be tweaked to reflect the new hardware's differences - usually that means fiddling with the device-tree, driver configuration & power management adjustments.

Getting this right is crucial for a system to behave any way & becomes super important in regulated environments, where standards like IEC 62304 or automotive functional safety require deterministic behaviour, controlled config management & full traceability.

Building the final OS image typically involves Yocto or Buildroot, which lets teams integrate middleware like GUI frameworks (e.g. Qt), AI accelerators, comms stacks or real-time components.

For the really time-critical systems, Linux is often combined with a real-time OS ( RTOS) or extended with frameworks designed for mixed-criticality architectures.

At this point the software team starts implementing application logic, connectivity, UX & domain-specific algorithms. With a stable BSP in place, engineers can finally focus their attention on embedded software testing , performance profiling & integration instead of writing drivers from scratch. Experienced teams complement this with CI/CD pipelines for embedded systems , automated flashing & hardware-in-the-loop setups to test each software revision on real hardware. This speeds up release cycles & improves quality, especially in long-lived devices.

Security & maintainability are also key considerations. Integrating early features like Secure Boot , firmware signing & OTA update frameworks helps avoid expensive architectural changes later. A well-prepared SoM platform sets the foundation, but the responsibility for proper implementation lies with the software team - making strong engineering chops a must-have.

For CTOs & engineering managers, the key takeaway is that a SoM accelerates hardware, but it's the software process - BSP adaptation, OS integration, testing strategy, CI/CD, security & long-term maintenance - that determines whether the final product will be reliable, certifiable & future-proof.

Common Pitfalls and Best Practices

Even with a mature SoM platform, embedded projects often run into avoidable issues. Most of them are not caused by hardware limitations, but by architectural decisions made too early or without sufficient cooperation between hardware and software teams.

Common pitfalls include:

One of the most frequent problems is overestimating the required processing power. Teams often select the most powerful MPU “just in case”, which unnecessarily increases cost, power consumption and thermal complexity.

As Piotr frequently observes, many projects start with demands for “gigabytes of RAM, gigahertz of CPU frequency and everything included”, while in practice a simple platform with a modest MPU and a few hundred megabytes of DRAM would be fully sufficient.

Another recurring issue is insufficient thermal analysis. Designs may pass early validation but start throttling under continuous load because thermal budgets were not aligned with real software workloads or enclosure constraints.

Piotr warns that without a comprehensive system-level approach, devices often end up with an incorrect thermal balance, leading to performance throttling and unpredictable behavior in production conditions.

Best practices

First, they start with a precise definition of system requirements: CPU performance, RAM and Flash size, real-time constraints, GPU needs, cryptographic capabilities and communication interfaces.

VisionSOM-iMX93 (SLS26) - source: somlabs.com:

As Piotr stresses, clearly defined requirements are essential to maintain a balance between MPU capabilities, memory configuration and overall platform cost.

Second, teams should actively use vendor-provided reference carrier board designs and documentation. These significantly reduce hardware bring-up risk and simplify BSP adaptation.

Piotr strongly recommends this approach, as it shortens development time and minimizes the amount of trial-and-error during early hardware validation.

Finally, security and future regulatory requirements, such as the EU Cyber Resilience Act, should be considered from the very beginning of the project. The selected MPU family defines what cryptographic acceleration, isolation mechanisms and secure boot options are available, directly impacting long-term compliance and maintainability.

Conclusion

System on Module technology works best when treated not as a finished solution but as a shared foundation for close hardware-software collaboration. A SoM reduces electrical & layout risk, but the final quality of the product depends on how well hardware architecture, software design, thermal engineering, security & certification requirements are aligned from the very beginning.

In successful SoM-based systems, hardware and software teams work as one engineering unit. Power budgets are defined together with software workloads, BSP maturity is evaluated against regulatory needs, and security mechanisms are designed into the platform rather than added later. This tight integration is what turns a SoM from a convenient component into a reliable, production-ready computing platform.

Used this way, a SoM becomes a strong enabler of predictable development, scalable product families and long-term maintainability. Without this cooperation, it remains only a shortcut in hardware design, shifting complexity elsewhere instead of controlling it.

At Somco Software, we help teams build this hardware–software alignment by delivering robust embedded software on SoM platforms and supporting system architecture from the earliest design stages. If you want your SoM-based product to be reliable, secure and certifiable, we are ready to support you.