Was ist ein System on Module? Wie entwickelt man SoM-Software

Ein System on Module ist zur Grundlage vieler moderner Embedded-Produkte geworden – doch die Auswahl und Integration des richtigen Moduls ist nicht immer eine einfache Entscheidung. Man muss die Vor- und Nachteile gegeneinander abwägen, was anfangs schwer zu überblicken sein kann.

Um diese Trade-offs aus einer praxisnahen Engineering-Perspektive besser zu verstehen, haben wir mit Piotr Zybiński gesprochen, einem CTO mit langjähriger praktischer Erfahrung in der Entwicklung und Implementierung von SoM-Plattformen. Seine Erfahrung mit realen Produkten zeigt sowohl die Stärken als auch die Grenzen dieses Ansatzes auf.

In diesem Artikel schauen wir uns genauer an:

• warum sich die Branche in Richtung modularer Rechenarchitekturen bewegt,

• wie SoMs das Risiko bei komplexen MPU-/SoC-Designs reduzieren,

• welche realistischen Erwartungen man in Bezug auf Migration, Kompatibilität und Thermik haben sollte,

• welche Rolle BSPs, Yocto und das Software-Bring-up für den Projekterfolg spielen,

• wann ein SoM nicht die richtige Wahl für Ihre Anwendung ist, und

• wie Hardware- und Softwareteams effektiv zusammenarbeiten können, um zuverlässige Produkte zu entwickeln.

Aus der Perspektive von Software und Systemintegration können Unternehmen wie Somo bei SoM-basierten Projekten unterstützen – sie bieten die Anpassung von BSPs, die Entwicklung von Embedded Linux, die Automatisierung des CI/CD-Prozesses und die langfristige Softwarewartung. Dadurch erhalten Sie eine softwarefokussierte Perspektive als Ergänzung zu Piotrs stärker hardwareorientierter Sichtweise in diesem Artikel.

Was genau ist ein System on Module (SoM)?

System on Module (SoM) ist eine kleine Leiterplatte, die alle wesentlichen Elemente eines Computersystems in sich vereint (Prozessor, Speicher, Massenspeicher usw.) und zu einem sofort einsatzbereiten Modul zusammenfasst. Es ist ein miniaturisierter Computer-Kern – das SoM beherbergt einen Mikroprozessor (oft ein SoC) sowie RAM, Flash-Speicher, Power-Management und Schnittstellencontroller für Peripheriegeräte.

Der Markt bewegt sich zunehmend in Richtung SoM-basierter Designs, weil moderne MPUs und SoCs immer komplexer in kundenspezifische Hardware zu integrieren sind.

Wie Piotr hervorhebt, wird dieser Wandel hin zu SoMs vor allem durch die steigenden Anforderungen moderner Embedded-Systeme an Leistung und Konnektivität getrieben. Er erklärt, dass SoMs es Teams ermöglichen, viele der schwierigsten Aspekte von Chip-Down-Designs zu vermeiden, insbesondere die heiklen Bereiche rund um High-Speed-Speicher wie LPDDR4, LPDDR5, DDR4 und DDR3L sowie Schnittstellen wie PCIe, SDIO und USB 3.x.

Für Manager und CTOs sind SoMs nicht nur eine weitere Hardwareoption – sie sind eine Möglichkeit, den riskantesten Teil der Elektronikentwicklung auszulagern und Produkte auf einer berechenbaren, industrietauglichen Computing-Plattform aufzubauen.

Wie funktionieren System-on-Module?

Ein System on Module wird über eine Standardschnittstelle (Steckverbinder oder eingelötete Pins) mit einem Carrier-Board verbunden, und zusammen arbeiten beide als ein integriertes Gesamtsystem. Das SoM stellt typischerweise einen hochdichten Anschluss bereit, der Signale für Stromversorgung, Datenbusse und I/O-Schnittstellen an das Carrier-Board führt. Wenn es auf dem Carrier-Board montiert ist, funktioniert die Kombination aus SoM und Carrier wie ein vollständiger Embedded-Computer: Das SoM stellt die Rechenfunktionen bereit (Prozessor, Speicher, Konnektivität), während das Carrier-Board die physische Bauform und alle spezialisierten I/Os bereitstellt . Im Wesentlichen führt das Carrier-Board die Signale des SoM zu nutzbaren Anschlüssen weiter (USB-Ports, HDMI-Anschluss, Ethernet-Buchsen, SD-Karten-Slots, Kamerastecker usw.) und implementiert alle anwendungsspezifischen Schaltungen (z. B. analoge Sensoren, Motortreiber usw.), die für das Endprodukt erforderlich sind. Diese Aufgabentrennung vereinfacht das Design: Ingenieure können sich auf die Anpassung des Carriers an die Anforderungen ihrer Anwendung konzentrieren, in dem Wissen, dass die komplexe CPU-, Speicher- und Betriebssystemfunktionalität vom Standard-SoM übernommen wird.

Vorteile der Verwendung eines System on Module in Embedded-Anwendungen

In der Praxis entscheiden sich Teams in erster Linie für SoMs, um technische Risiken zu beherrschen und die anfälligsten Phasen der Hardwareentwicklung zu beschleunigen. Wie Piotr erklärt, ist der größte Vorteil nicht die Leistung, sondern die Vorhersehbarkeit. Anstatt sich monatelang mit DDR-Routing, Power-Sequencing, Signalintegrität und Early-Boot-Stabilität zu beschäftigen, können Ingenieure von einer Plattform ausgehen, die elektrisch bereits erprobt ist, und sich auf die Produktfunktionalität konzentrieren.

Geringere NRE und schnellere Time-to-Market

Piotr weist darauf hin, dass die Wirtschaftlichkeit von SoMs bei kleinen und mittleren Produktionsvolumina oft kontraintuitiv ist. Die Kosten eines fertigen Moduls sind häufig mit den Gesamtkosten einzelner Komponenten vergleichbar, wenn man die PCB-Komplexität, den Validierungsaufwand und die Engineering-Zeit berücksichtigt.

In solchen Projekten reduzieren SoMs die NRE erheblich, da kundenspezifische DDR-Validierung, komplexes Power-Design und Bring-up-Debugging in frühen Phasen entfallen.

Geringere Zertifizierungskomplexität

Laut Piotr ist die Zertifizierung einer der am meisten unterschätzten Vorteile von SoM-Plattformen. Professionell entwickelte Module durchlaufen in der Regel EMC-Pre-Compliance-Tests und integrieren häufig bereits vorzertifizierte Funkkomponenten.

Das bedeutet, dass ein großer Teil des elektromagnetischen Verhaltens des Endprodukts bereits charakterisiert ist, noch bevor das Carrier-Board überhaupt existiert, was das Risiko während der formalen Zertifizierung erheblich reduziert.

Langfristige Verfügbarkeit und Stabilität des Lebenszyklus

Piotr betont, dass Lifecycle-Management eine technische Anforderung und kein kommerzielles Detail ist. Bei langlebigen Produkten muss das SoM aus industrietauglichen Komponenten aufgebaut sein, mit klar definierten EOL-Zusagen und einer kontrollierten Revisionspolitik.

Ohne dies wird selbst ein technisch gutes Modul zu einem langfristigen Risiko für medizinische, industrielle und automotive Systeme.

Eine sofort nutzbare Softwarebasis

Aus Piotrs Sicht ist die Qualität des BSP der entscheidende Faktor für eine professionelle SoM-Plattform. Ein ausgereiftes Modul sollte mit einem gepflegten Bootloader, Kernel, Device-Tree-Konfiguration und Yocto-Layern geliefert werden, damit Softwareteams sofort mit der Entwicklung beginnen können.

Dadurch verlagert sich der Fokus vom Low-Level-Bring-up hin zur Anwendungsentwicklung und Systemintegration ab dem ersten Tag.

Häufige Anwendungsbereiche von System on Modules

System on Modules werden in vielen Branchen eingesetzt, die auf kompakte, zuverlässige und langlebige Embedded-Rechenplattformen angewiesen sind. Sie kombinieren Leistung, Energieeffizienz und Wartbarkeit auf sehr praktische Weise und eignen sich dadurch sowohl für Consumer-Geräte als auch für kritische Anwendungen.

Medizintechnik setzt SoMs für portable Diagnostik, Patientenüberwachung, Bildgebung und vernetzte Therapiegeräte ein. Die strengen Zertifizierungsanforderungen machen vorvalidierte Rechenmodule besonders wertvoll, da Anbieter häufig EMC-Testberichte und Funkzertifizierungspakete bereitstellen, die die Zulassungszeit verkürzen.

Automobilsysteme nutzen SoMs für Infotainment, Telematik und ADAS-bezogene Verarbeitung. GPU-Beschleunigung, High-Speed-Schnittstellen und langfristige Verfügbarkeit passen sehr gut zu den Entwicklungszyklen im Automotive-Bereich (außerdem werden Secure Boot, Hardware-Kryptografie und robuste Konnektivität benötigt, um alle regulatorischen Anforderungen zu erfüllen).

Industrieautomation und Industrie 4.0 setzen SoMs in SPS-Steuerungen, Machine Vision, Robotik, Gateways und Edge-AI-Geräten ein. Zuverlässigkeit unter rauen Bedingungen, erweiterte Temperaturbereiche und eine langfristig stabile Roadmap machen modulare Rechenplattformen zu einer naheliegenden Wahl für Fabriken, Energiesysteme und Verkehrsnetze.

Und das ist noch nicht alles – SoMs treiben auch Aerospace-Nutzlasten, Kommunikationstechnik, Smart Agriculture, Verteidigungssubsysteme und Produktinnovationen in frühen Phasen an, bei denen schnelles Prototyping ein Wettbewerbsvorteil ist.

Wann man ein System on Module NICHT verwenden sollte

Obwohl SoMs in vielen Embedded-Projekten zahlreiche Vorteile bieten, sind sie nicht für jedes Produkt die richtige Wahl. In manchen Fällen bietet ein kundenspezifisches Chip-Down-Design oder sogar eine mikrocontrollerbasierte Architektur bessere Eigenschaften in Bezug auf Kosten, Leistung oder Zertifizierung. Hier sind die Fälle, in denen ein SoM möglicherweise nicht die beste Wahl ist:

• Produkte in hohen Stückzahlen mit strengen Kostenzielen

• Einfache oder extrem stromsparende Geräte

• Projekte mit extremen thermischen oder baulichen Einschränkungen

• Anwendungen, die hartes Echtzeitverhalten erfordern

• Lösungen, die die vollständige Kontrolle über die Secure-Boot-Kette benötigen

• Wenn absolute Pin-Kompatibilität über mehrere Produktgenerationen hinweg zwingend erforderlich ist

Das richtige System on Module für Ihre Anwendung auswählen

Die Auswahl des richtigen SoM ist eine strategische Entscheidung, die sich auf Leistung, Zertifizierung, Produktkosten und die langfristige Wartbarkeit auswirkt. CTOs und Engineering-Manager sollten mehrere Dimensionen bewerten:

Migration und Skalierbarkeit: Eine realistische Perspektive

Einer der am häufigsten genannten Vorteile von SoMs ist die Möglichkeit, relativ einfach zwischen Modulen zu migrieren, die demselben mechanischen Standard folgen, etwa SMARC, Qseven oder SODIMM. Obwohl dies die langfristige Produktweiterentwicklung unterstützt, sollte es eher als technische Herausforderung betrachtet werden als als etwas, das quasi von selbst geschieht.

Wie Piotr hervorhebt, ist die Pin-Kompatibilität zwischen verschiedenen SoM-Familien oft eher ein Marketingversprechen als eine technische Realität.

In der Praxis bieten SoMs dennoch einen deutlich besser vorhersehbaren Migrationspfad als Chip-Down-Designs. Echte Drop-in-Ersatzlösungen sind jedoch selten und erfordern eine frühzeitige Planung, eine enge Abstimmung mit dem Modulhersteller sowie eine sorgfältige Validierung von Power-Domains, Boot-Konfiguration, Peripherie-Routing und thermischem Verhalten – insbesondere beim Wechsel zwischen verschiedenen MPU-Generationen oder Leistungsklassen.

Software ist entscheidend: BSP, OS-Readiness und Projekt-Bring-up

In SoM-basierten Projekten beginnt die Softwareentwicklung fast nie mit nackter, unvorbereiteter Hardware. Stattdessen startet sie mit einem Board Support Package (BSP), das vom Modulhersteller bereitgestellt wird – und das ist ein echter Vorteil. Dieses BSP enthält in der Regel einen Bootloader, einen Linux-Kernel, eine Device-Tree-Konfiguration, eine Reihe zentraler Treiber und eine auf Yocto basierende Build-Umgebung.

Das kann die mit Abstand größte Hürde im gesamten Projekt sein. Statt Wochen mit Early-Boot-Debugging zu verbringen, DDR zum Laufen zu bringen oder Peripherie in Betrieb zu nehmen, läuft das System von Anfang an. Dadurch kann Ihr Team sich all diesen Aufwand sparen und sich sofort auf Produktfunktionalität und Systemintegration konzentrieren.

Wie Piotr erklärt, steht und fällt eine ausgereifte SoM-Plattform mit der Qualität ihres BSP. Es muss aktuell gehalten werden und eine vollständige, reproduzierbare Build-Umgebung bereitstellen, mit der Ingenieure Evaluierungshardware in kürzester Zeit in Betrieb nehmen und anschließend reibungslos auf ihre eigenen kundenspezifischen Carrier-Boards wechseln können.

Sobald ein kundenspezifisches Carrier-Board bereit ist, muss das BSP angepasst werden, um die Unterschiede der neuen Hardware abzubilden – in der Regel bedeutet das, am Device-Tree, an der Treiberkonfiguration und an den Power-Management-Anpassungen zu arbeiten.

Das ist entscheidend, damit sich ein System wie vorgesehen verhält, und wird in regulierten Umgebungen besonders wichtig, in denen Standards wie IEC 62304 oder die funktionale Sicherheit im Automotive-Bereich deterministisches Verhalten, kontrolliertes Konfigurationsmanagement und vollständige Rückverfolgbarkeit verlangen.

Das Erstellen des finalen OS-Images erfolgt typischerweise mit Yocto oder Buildroot, wodurch Teams Middleware wie GUI-Frameworks (z. B. Qt), AI-Beschleuniger, Kommunikations-Stacks oder Echtzeitkomponenten integrieren können.

Für wirklich zeitkritische Systeme wird Linux oft mit einem Echtzeitbetriebssystem ( RTOS) kombiniert oder durch Frameworks erweitert, die für Mixed-Criticality-Architekturen entwickelt wurden.

Ab diesem Punkt beginnt das Softwareteam mit der Umsetzung von Anwendungslogik, Konnektivität, UX und domänenspezifischen Algorithmen. Mit einem stabilen BSP können sich Ingenieure endlich auf Embedded-Software-Testing, Performance-Profiling und Integration konzentrieren, anstatt Treiber von Grund auf neu zu schreiben. Erfahrene Teams ergänzen dies durch CI/CD-Pipelines für Embedded-Systeme, automatisiertes Flashing und Hardware-in-the-Loop-Setups, um jede Software-Revision auf realer Hardware zu testen. Das beschleunigt die Release-Zyklen und verbessert die Qualität, insbesondere bei langlebigen Geräten.

Sicherheit und Wartbarkeit sind ebenfalls zentrale Aspekte. Die frühzeitige Integration von Funktionen wie Secure Boot, Firmware-Signierung und OTA-Update-Frameworks hilft, später teure Architekturänderungen zu vermeiden. Eine gut vorbereitete SoM-Plattform schafft die Grundlage, aber die Verantwortung für die korrekte Implementierung liegt beim Softwareteam – weshalb fundierte Engineering-Kompetenz unverzichtbar ist.

Für CTOs und Engineering-Manager ist die wichtigste Erkenntnis, dass ein SoM zwar die Hardwareentwicklung beschleunigt, letztlich aber der Softwareprozess – BSP-Anpassung, OS-Integration, Teststrategie, CI/CD, Sicherheit und langfristige Wartung – darüber entscheidet, ob das Endprodukt zuverlässig, zertifizierbar und zukunftssicher sein wird.

Häufige Fallstricke und Best Practices

Selbst mit einer ausgereiften SoM-Plattform stoßen Embedded-Projekte häufig auf vermeidbare Probleme. Die meisten davon werden nicht durch Hardwarebeschränkungen verursacht, sondern durch Architekturentscheidungen, die zu früh oder ohne ausreichende Zusammenarbeit zwischen Hardware- und Softwareteams getroffen wurden.

Häufige Fallstricke sind:

Eines der häufigsten Probleme ist die Überschätzung der erforderlichen Rechenleistung. Teams wählen oft vorsorglich die leistungsstärkste MPU, was Kosten, Stromverbrauch und thermische Komplexität unnötig erhöht.

Wie Piotr häufig beobachtet, beginnen viele Projekte mit Anforderungen nach „Gigabytes an RAM, Gigahertz an CPU-Takt und allem drum und dran“, obwohl in der Praxis eine einfache Plattform mit einer moderaten MPU und einigen Hundert Megabyte DRAM völlig ausreichen würde.

Ein weiteres wiederkehrendes Problem ist eine unzureichende thermische Analyse. Designs können die frühe Validierung bestehen, unter Dauerlast jedoch zu throtteln beginnen, weil thermische Budgets nicht mit den realen Software-Workloads oder den Gehäusegrenzen abgestimmt wurden.

Piotr warnt davor, dass Geräte ohne einen umfassenden Ansatz auf Systemebene oft mit einer falschen thermischen Balance enden, was unter Produktionsbedingungen zu Performance-Throttling und unvorhersehbarem Verhalten führt.

Best Practices

Zunächst sollten die Systemanforderungen präzise definiert werden: CPU-Leistung, RAM- und Flash-Größe, Echtzeit-Anforderungen, GPU-Bedarf, kryptografische Fähigkeiten und Kommunikationsschnittstellen.

VisionSOM-IMX93 (SLS26) – Quelle: somlabs.com:

Wie Piotr betont, sind klar definierte Anforderungen entscheidend, um ein Gleichgewicht zwischen den Fähigkeiten der MPU, der Speicherkonfiguration und den gesamten Plattformkosten zu wahren.

Zweitens sollten Teams aktiv die vom Anbieter bereitgestellten Referenzdesigns für Carrier-Boards und die zugehörige Dokumentation nutzen. Diese reduzieren das Risiko beim Hardware-Bring-up erheblich und vereinfachen die BSP-Anpassung.

Piotr empfiehlt diesen Ansatz nachdrücklich, da er die Entwicklungszeit verkürzt und den Umfang von Trial-and-Error während der frühen Hardwarevalidierung minimiert.

Schließlich sollten Sicherheitsaspekte und zukünftige regulatorische Anforderungen, wie etwa der EU Cyber Resilience Act, von Beginn des Projekts an berücksichtigt werden. Die gewählte MPU-Familie bestimmt, welche kryptografische Beschleunigung, Isolationsmechanismen und Secure-Boot-Optionen verfügbar sind, und wirkt sich damit direkt auf die langfristige Compliance und Wartbarkeit aus.

Fazit

Die System-on-Module-Technologie funktioniert am besten, wenn sie nicht als fertige Lösung, sondern als gemeinsame Grundlage für eine enge Zusammenarbeit zwischen Hardware und Software verstanden wird. Ein SoM reduziert elektrische Risiken und Layout-Risiken, doch die endgültige Qualität des Produkts hängt davon ab, wie gut Hardwarearchitektur, Softwaredesign, Thermik-Engineering sowie Sicherheits- und Zertifizierungsanforderungen von Anfang an aufeinander abgestimmt sind.

In erfolgreichen SoM-basierten Systemen arbeiten Hardware- und Softwareteams als eine gemeinsame Engineering-Einheit. Power-Budgets werden zusammen mit den Software-Workloads definiert, die Reife des BSP wird anhand regulatorischer Anforderungen bewertet, und Sicherheitsmechanismen werden von Anfang an in die Plattform integriert, statt erst später hinzugefügt zu werden. Diese enge Integration macht aus einem SoM eine zuverlässige, produktionsreife Computing-Plattform statt nur einer praktischen Komponente.

So eingesetzt wird ein SoM zu einem starken Enabler für vorhersehbare Entwicklung, skalierbare Produktfamilien und langfristige Wartbarkeit. Ohne diese Zusammenarbeit bleibt es lediglich eine Abkürzung im Hardwaredesign, die die Komplexität nur verlagert, statt sie zu beherrschen.

Bei Somco Software unterstützen wir Teams dabei, diese Abstimmung zwischen Hardware und Software zu erreichen, indem wir robuste Embedded-Software auf SoM-Plattformen liefern und die Systemarchitektur bereits ab den frühesten Designphasen begleiten. Wenn Ihr SoM-basiertes Produkt zuverlässig, sicher und zertifizierbar sein soll, stehen wir bereit, Sie zu unterstützen.