Auf zwei Wegen zum Ziel
Embedded-Geräte mit SoC oder SoM
Wer Controller und andere Embedded-Geräte auf den Markt bringen will, hat die Wahl zwischen unterschiedlichen CPU- und Systemarchitekturen. Doch die Entscheidung zwischen SoC und SoM muss keine Qual sein, wenn man Hardware, Software und Kostenseite kompetent, langfristig und ganzheitlich betrachtet.
Vorab die gute und zugleich schlechte Nachricht: Bei der Neu- oder Weiterentwicklung eines Controllers oder Geräts für Embedded-Anwendungen ist die Auswahl potenziell geeigneter CPUs größer denn je. Dazu tragen nicht zuletzt steigende Stückzahlen bei, die es den Chipherstellern ermöglichen, die Variantenvielfalt weiter zu erhöhen. Für Anwendungen in der Industrie oder in der Medizintechnik stellen sich damit jedoch erst recht zahlreiche Fragen, die bei der strategischen Auswahl der CPU zu berücksichtigen sind. Auf deren Beantwortung sind Unternehmen wie Grossenbacher Systeme spezialisiert. Als Entwicklungspartner von OEMs hat man Erfahrung darin, Themen wie Kostenskalierbarkeit und eine CPU- sowie konzeptübergreifende Entwicklung kompetent zu berücksichtigen. Das gilt für Automatisierungssysteme ebenso wie für Medizingeräte, die beide in zunehmendem Maße via IoT vernetzt, cybersicher und KI/ML-fähig sein müssen.
Eine naheliegende Antwort bieten Arm-basierte CPUs, die in vielfältiger Form als System-on-a-Chip (SoC) oder System-on-Module (SoM) zur Verfügung stehen, wobei die SoM-Varianten quasi von Haus aus ein SoC plus notwendige Peripherie als integralen Bestandteil umfassen. Beide Varianten haben besondere Eigenschaften und Vorzüge, die es für die Anwendung und die jeweilige Produktstrategie abzuwägen gilt. Dabei spielen nicht nur die harten technischen Eigenschaften eine Rolle, sondern auch Einflüsse, die von der Software und von Erwartungen an diese herrühren.
Jobangebote+ passend zum Thema
Möglichkeiten zur Produktdifferenzierung berücksichtigen
Interessant wird es besonders, wenn man eine Produktfamilie mit beiden Systemwelten konzipieren will und deshalb Performance und Kosten für die Produktdifferenzierung berücksichtigen muss. Produkte einer Familie weisen in der Applikationssoftware meist viele Gemeinsamkeiten auf. Die Differenzierung ergibt sich eher durch verschiedene Displays oder Schnittstellen. Der Kern der Software ist deshalb weitgehend identisch. Um die Entwicklungskosten und die Total Cost of Ownership (TCO) im Optimum zu halten, ist deshalb ein einheitlicher »Software-Branch« erstrebenswert, auch wenn man den SoM-Ansatz für die Medium/High-End-Variante (z. B. hohe Performance, niedrigere Stückzahlen) und die SoC-Version für die Low-End-Variante (überschaubare Leistung, hohe Stückzahlen) einsetzen möchte.
Software am besten einheitlich
Dieser einheitliche Software-Branch ist möglich, wenn eine geeignete Hardware-Abstraktionsschicht (HAL, Hardware Abstraction Layer), ein konsistentes Yocto-Set-up und eine Containerisierung der Applikationssoftware implementiert werden. Um eine gute Softwareabstrahierung und vereinheitlichte Softwareentwicklung zu erreichen, ist speziell der Einsatz der Containertechnologie (z. B. mit Podman) von entscheidender Bedeutung.
Eine HAL ermöglicht es, die Unterschiede zwischen SoC- und SoM-Hardware zu abstrahieren und eine gemeinsame Schnittstelle für die Software bereitzustellen. Dadurch kann der gleiche Softwarecode auf beiden Plattformen laufen, ohne dass größere An- passungen erforderlich sind.
Bei der Entwicklung der Systemsoftware empfiehlt es sich, auf eine Containerumgebung zu setzen. Sie sollte aus einem Linux-Betriebssystem auf Yocto-Basis und einem Werkzeug für Containermanagement bestehen – beispielsweise Podman. Letzteres ist ein Open-Source-Tool für das Management von Containergruppen, sogenannten Pods. Mit Podman lassen sich Container in Yocto-Linux komfortabel, effizient und cybersicher entwickeln, managen und ausführen.
Die Verwendung von Yocto als Entwicklungsplattform ermöglicht es, Linux-Distributionen für beide Plattformen zu erstellen, während die Software auf einem gemeinsamen Kernel und gemeinsamen Paketen beruht. Durch die Containerisierung der Applikationssoftware lassen sich Anwendungen auf unterschiedlichen Hardwareplattformen ohne größere Anpassungen bereitstellen.
| Mikrocontroller vom Typ ESP32 – eine attraktive Arm-Alternative? |
|---|
| Natürlich existieren Alternativen zu SoC oder SoM, die nicht auf Arm beruhen. Von sich reden gemacht hat in den vergangenen Jahren beispielsweise die ESP32, eine kostengünstige und mit geringem Leistungsbedarf ausgeführte 32-bit-Mikrocontrollerfamilie des chinesischen Anbieters Espressif Systems. Nach Erfahrung von Grossenbacher Systeme gilt dabei folgendes: Mikrocontroller vom Typ ESP32 sind in bestimmten Szenarien eine spannende Alternative, besonders bei IoT-Anwendungen. Schließlich bieten sie integriertes WLAN und Bluetooth sowie eine einfache Entwicklungsumgebung, die besonders für Produkte im unteren Preisbereich interessant ist. Mit ihrer 32-bit-Architektur und begrenztem internem RAM ist die ESP32-Mikrocontrollerfamilie aber kaum geeignet für komplexe industrielle oder medizintechnische Anwendungen, bei denen höhere Leistungen oder umfangreiche Peripherieunterstützung erforderlich sind. |
Doch auch diesen Vorteil gibt es nicht umsonst: Die Containerisierung erfordert eine bestimmte Leistungsfähigkeit der Hardware. Konkret sind eine 64-Bit-CPU und ein RAM von mindestens 1 GB – besser 2 GB – erforderlich, um Container effektiv umsetzen zu können. Diese Basis ermöglicht folglich die Applikationssoftware für die Container und damit die systemübergreifende Softwareentwicklung in einer Branch oder zumindest das effektive Pflegen und Weiterentwickeln in einer Umgebung wie GitHub.
KI und Cybersecurity von Anfang an »mitdenken«
Gemeinsam ermöglichen HAL, Yocto und Containerisierung eine übergreifende Softwareentwicklung und verringern den Aufwand für Tests und Updates über die gesamte Produktlebensdauer. Gerade der letztgenannte Punkt ist vor dem Hintergrund steigender Anforderungen an die Cybersecurity von entscheidender Bedeutung – wer möchte im sicherheitskritischen industriellen oder medizintechnischen Umfeld künftig auf die Möglichkeit von Remote-Updates verzichten? Auch KI- und ML-Funktionen erfordern zwingend eine Update-Fähigkeit. Damit das funktioniert, ist jedoch eine beträchtliche Speicherkapazität und eine leistungsfähige CPU erforderlich. Dies bedeutet, dass die Wahl eines entsprechend ausgestatteten SoCs zwar zunächst höhere Stückkosten mit sich bringt, die TCO für die geplante Produktfamilie auf lange Sicht aber verringert.
Architekturentscheidung als strategische Weichenstellung
Die Entscheidung zwischen SoM und SoC bei der Entwicklung von Steuerungen und Embedded-Systemen stellt für Unternehmen der Industrie- oder Medizintechnik mithin eine Herausforderung dar. Sie beeinflusst sowohl die technischen als auch die wirtschaftlichen Aspekte eines Projekts.
Angesichts der Vielfalt der Arm-basierten CPUs, die als SoM oder SoC verfügbar sind, ergibt sich für Systemarchitekten die Herausforderung, die bestmögliche Wahl zu treffen – nicht nur auf technischer Ebene, sondern auch in Hinblick auf eine langfristige Produktstrategie mit differenzierten Produkten. Diese sind zwar auf spezifische Zielmärkte ausgerichtet, sollten aber möglichst eine einheitliche Wartung und Versorgung mit Updates erlauben.
Nicht zuletzt wirkt sich die Wahl des SoC oder SoM nicht nur auf die Entwicklungskosten, sondern auch auf die TCO aus. Zwar lassen sich die Stückkosten durch günstigere SoCs deutlich senken, doch die Einsparungen werden oft durch einen erhöhten Entwicklungsaufwand bei der Integration und Wartung wieder ausgeglichen. Ein stärkeres SoC mit mehr Funktionen kann deshalb langfristig die bessere Wahl sein, um Entwicklungskosten niedrig zu halten und die Softwareentwicklung zu vereinheitlichen.
Balance zwischen SoM und SoC gefragt
Die Wahl zwischen SoM und SoC auf Basis von Arm-CPUs hängt von der spezifischen Produktstrategie ab. In einem Low-Cost-Szenario mit hohen Stückzahlen bietet ein SoC klare Kostenvorteile. Für Mid-Range- und High-End-Varianten kann ein SoM durch seine Skalierbarkeit – nicht zuletzt im Hinblick auf künftige KI-Funktionen – sowie durch einfache Integration punkten. Ein gemeinsamer Software-Branch für SoM- und SoC-basierte Produkte einer Familie ist durchaus möglich, wenn Yocto, Containertechnologie und eine Hardwareabstraktionsschicht sinnvoll eingesetzt und von Anfang an SoCs mit 64-bit-CPU und ausreichend RAM eingeplant werden.
OEM, die bei der Konzeption von neuen Controllern oder anderen Embedded-Geräten bei diesen Aspekten kein Risiko eingehen wollen, sollten die Kompetenz und Erfahrung ihrer Entwicklungspartner bei der Identifikation geeigneter SoM und SoC kritisch prüfen, damit die getroffene Wahl auch auf lange Sicht nicht zur Qual wird.
Der Autor
Oliver Roth ist CEO bei Grossenbacher Systeme.
Lesen Sie mehr zum Thema
