Von der CPU bis zur Security
Embedded-Hardware richtig auswählen – ein Leitfaden
Die Auswahl der für ein bestimmtes Systemprojekt optimal geeigneten Embedded-Hardware ist alles andere als trivial. Zu beachten sind dabei viele verschiedene Aspekte. Welche sind das, welche Rolle spielen sie, und wie greifen sie ineinander?
In modernen Embedded-Systemen treffen unterschiedlichste Anforderungen aufeinander: Grafische Benutzeroberflächen, Wireless-Connectivity, energieeffizienter 24/7-Betrieb, Echtzeitverarbeitung und nicht zuletzt wachsende Anforderungen an IT-Sicherheit. Die richtige Wahl der Hardwareplattform beeinflusst dabei nicht nur die technische Leistungsfähigkeit, sondern auch Entwicklungsaufwand, Time-to-Market, Zertifizierungsprozesse und langfristige Wartbarkeit. Für Embedded-Engineers stellt sich eine zentrale Frage: Wie lässt sich eine fundierte, zukunftsfähige und wirtschaftlich sinnvolle Entscheidung bei der Auswahl von CPU, Modul und Gesamtsystem treffen? Der Beitrag richtet sich an Entwickler und technische Entscheider, die vor einer Auswahlentscheidung für eine Embedded-Plattform stehen. Ziel ist es, die wichtigsten technischen, regulatorischen und wirtschaftlichen Einflussgrößen darzustellen – ohne Herstellerfokus, aber zur Illustration mit Beispielen aus gängigen Plattformen, wie etwa der NXP-i.MX-Familie.
Prozessorwahl als zentrales Entscheidungskriterium
Die Auswahl beginnt häufig mit dem Prozessor. Dabei stehen heutzutage zahlreiche Plattformen zur Verfügung – mit verschiedenen Architekturvarianten (z.B. ARM Cortex-A/M, RISC-V), Leistungsniveaus, Energieprofilen und unterstützten Schnittstellen. Prozessorfamilien wie NXP i.MX, Renesas RZ, TI Sitara oder STM32MP sind in vielen Embedded-Projekten etabliert und bieten skalierbare Plattformen für unterschiedliche Anwendungsklassen. Die Wahl innerhalb der Familien ermöglicht es, unterschiedliche Anforderungen (Performance, Security, Energie) auf kompatibler Plattformebene zu lösen – etwa durch pinkompatible SoMs. Vom in Tabelle 1 aufgeführten Beispiel der i.MX-CPU-Familien von NXP lassen sich einige typische Fragen ableiten: Welche Anforderungen stellt die Anwendung an Grafikleistung, Peripherieintegration, Energieverbrauch und Sicherheitsfunktionen? Wie lässt sich das Design langfristig pflegen und erweitern? Und wie wirken sich Softwareverfügbarkeit und Ecosystem auf den Projekterfolg aus?
Zwei typische Anwendungsszenarien aus der Industrie seien nachfolgend skizziert:
- Human-Machine-Interfaces (HMI): Systeme mit Touch-Display und grafischer Oberfläche. Hier stehen Grafikleistung, Reaktionszeit und Usability im Vordergrund – oft ergänzt durch Anforderungen an Designfreiheit und Multimediaschnittstellen.
- Industrielle Steuerungen mit Display (TFT oder E-Paper): Geräte, bei denen das Display primär zur Statusanzeige dient – z. B. in der Gebäudeautomation, Medizintechnik oder Industrie. Häufig dominieren Anforderungen wie niedriger Energieverbrauch, robuste Kommunikation, EMV-Konformität oder Schutzklasse.
Die Hardwareplattform muss dabei nicht nur funktional sein, sondern auch über den kompletten Lebenszyklus des Produkts hinweg tragfähig sein – technisch wie kommerziell.
Systemanforderungen realistisch bewerten
Bei der Auswahl einer geeigneten Embedded-Hardwareplattform ist eine systematische Bewertung der technischen Anforderungen entscheidend. Fehlentscheidungen führen nicht selten zu überdimensionierten, ineffizienten oder schlecht wartbaren Systemen. Im Folgenden werden zentrale technische Einflussfaktoren vorgestellt.
Jobangebote+ passend zum Thema
Ein wesentlicher Entscheidungsfaktor ist die benötigte Rechenleistung. Diese ergibt sich nicht nur aus der Applikation, sondern auch aus nicht offensichtlichen Rahmenbedingungen wie Softwarearchitektur, Echtzeitanforderungen oder Multitasking-Fähigkeit. Typische Leistungsfragen hierbei sind:
- Wird ein Betriebssystem wie Linux benötigt oder reicht ein Bare-Metal-Ansatz?
- Sind Multimedia-Inhalte (Video, Audio) zu verarbeiten?
- Welche Latenz- und Reaktionszeiten sind zwingend gefordert?
- Wird eine Trennung von HMI und eigentlicher Applikationsanwendung benötigt (z.B. Cortex-A + Cortex-M-Kombinationen)?
Moderne Prozessoren bieten hier eine große Auswahl: Vom stromsparenden Single-Core ARM Cortex-A7 mit wenigen Hundert MHz bis zu Multicore-Varianten mit mehreren GHz, dedizierten Echtzeitkernen und integrierten GPU und VPU.
Benchmarks allein sind aber nicht immer entscheidend. Oft ist der Energieverbrauch in Ruhe- oder Teillastzuständen wesentlich relevanter, besonders bei batteriebetriebenen Geräten.
In einigen Anwendungen – z. B. Bild- oder Spracherkennung, Predictive Maintenance oder Objekterkennung – spielt KI an der Edge, also Auswertung direkt am Gerät, eine zunehmende Rolle. Prozessoren mit integrierter NPU (Neural Processing Unit), etwa i.MX 8M Plus mit 2,3 TOPS oder CPUs mit optimierter GPU-Architektur, versprechen hier Vorteile. Allerdings ist die Integration nicht trivial. Einige typische Stolpersteine seien hier genannt:
- Unterstützung von Frameworks (z.B. TensorFlow Lite, ONNX, PyTorch)
- Format- und Speicherkompatibilität (z.B. INT8-Quantisierung)
- Treiber und Runtime-Umgebungen für die Zielplattform
- Toolchain zur Modellkonvertierung
Ein Embedded-System mit KI-Unterstützung erfordert daher oft enge Zusammenarbeit zwischen Hardwareentwicklung, Softwareengineering und Data Science. Gerade Entwickler stehen hier im Zugzwang, weil seitens Geschäftsleitung, Marketing oder Vertrieb das Thema KI gefordert wird, ohne dass eine sinnvolle Anwendung definiert wird. Das ist ein wenig mit dem Hype um Multitouch vor einigen Jahren vergleichbar.
Ein weiterer zentraler Aspekt ist die Anbindung des Displays. Je nach Größe, Auflösung und Farbtiefe ergeben sich unterschiedliche Anforderungen an die Prozessor-Grafikeinheit und die physikalische Schnittstelle. Zu den typischen Hardware-Schnittstellen zählen:
- Parallel RGB: Günstig, einfach, aber bei höheren Auflösungen limitiert
- LVDS: Robuste, störsichere Punkt-zu-Punkt-Verbindung, gängig in der Industrie
- MIPI-DSI: Platzsparend, hohe Bandbreite – ideal für kleine, hochauflösende Displays
- HDMI/eDP: Für größere oder externe Bildschirme, aber selten in Embedded-Umgebungen
Darüber hinaus ist zu beachten:
- Unterstützt der Prozessor mehrere Displays mit evtl. unterschiedlichen Inhalten gleichzeitig?
- Muss ein kapazitiver Touch integriert werden (USB, I2C oder SPI)?
- Gibt es Softwarebibliotheken (z.B. LVGL) mit nativer Unterstützung?
Nicht zuletzt beeinflussen Displaywahl und Interface den Stromverbrauch, die EMV und die thermische Auslegung des Systems. Oft hat man ein passendes Display gefunden, das kostengünstig und auch langzeitverfügbar ist, allerdings in Kombination mit einer angedachten CPU einen Konflikt verursacht, weil die Display-Schnittstelle nicht nativ von der CPU unterstützt wird.
Die scheinbar triviale Frage nach der Displaygröße und Auslösung hat weitreichende Auswirkungen:
- RAM-Bedarf: Ein 800x480-Display benötigt etwa 1,5 MB pro Framebuffer – bei 24 Bit Farbtiefe.
- Grafikbandbreite: Je höher die Auflösung, desto mehr Last auf internen Bussen.
- Touchbedienung: Bei größeren Displays steigt die Anforderung an Touchpräzision und Responsiveness.
- Benutzerinteraktion: Multitouch, Gestensteuerung oder Softwaretastaturen verändern die Usability.
Ein zu kleines Display erschwert die Bedienung, ein zu großes erfordert überdimensionierte Hardware – auch im Bereich Stromversorgung und Kühlung.
Die üblichen Schnittstellen in der Industrie (UART, I2C, SPI, USB) sind auf fast allen Plattformen vorhanden. Viel entscheidender ist oft deren Anzahl und die Flexibilität bei der Pin-Belegung. Wichtige Überlegungen hierbei:
- Werden mehrere serielle Geräte gleichzeitig benötigt?
- Gibt es Anforderungen an galvanische Trennung (z.B. für RS-485)?
- Ist CAN oder CAN FD zwingend erforderlich?
- Reicht 10/100-Mbit/s-Ethernet oder ist Gigabit nötig?
- Muss ein PCIe-Slot für Erweiterungen vorhanden sein?
Gerade bei SoM-basierten Designs ist sorgfältig zu prüfen, ob alle benötigten Schnittstellen auf den Carrier herausgeführt werden können oder ob Einschränkungen bestehen. Grundsätzlich lassen sich einige Schnittstellen per Einstellungen z. B. im Device-Tree anpassen, allerdings kann dies zu Konflikten mit dem ausgewählten SoM-Formfaktor führen.
Viele Embedded-Systeme benötigen heutzutage drahtlose Kommunikation: WLAN, Bluetooth, LTE, NB-IoT, LoRa, ZigBee, Thread, Matter – die Liste ist lang. Häufig ist aber nicht die Technik, sondern die Zertifizierungs- und Integrationsfähigkeit das entscheidende Kriterium. Was zu prüfen ist:
- Wird ein Funkmodul mit vorkonfiguriertem Treiber und Zertifizierung verwendet?
- Muss eine externe Antenne integriert werden (z.B. für medizinische Anwendungen)?
- Wie ist die Antennengeometrie im Gehäuse gelöst?
- Sind OTA-Updates vorgesehen, um Sicherheitslücken zu schließen?
In vielen Fällen ist ein integriertes und vorzertifiziertes Funkmodul die sicherste Wahl – trotz Mehrkosten –, weil es CE, FCC oder IC bereits erfüllt und Entwicklungszeit spart.
Früher war Security oft ein optionales Feature, heute ist sie eine gesetzliche Anforderung. Verordnungen wie der EU Cyber Resilience Act (CRA), die RED-Richtlinie oder die EN 18031 verpflichten Hersteller, bereits auf Hardwareebene geeignete Schutzmechanismen zu implementieren.
Typische Security-Features auf Hardwareebene:
- Secure Boot und Chain-of-Trust
- Verschlüsselte Datenbereiche im Flash
- Secure Key Storage (z.B. über TPM oder Secure Enclave)
- Unterstützung von Secure Firmware Updates (signiert, fail-safe)
Viele moderne Prozessoren bieten solche Features, jedoch ist ihre korrekte Implementierung komplex. Entscheidend ist die funktionierende Integration ins Gesamtsystem.
Moderne SoCs wie die i.MX-9-Serie von NXP bieten hier integrierte Funktionen wie Secure Boot, TrustZone und eine Secure Enclave. Sie bieten aber nur dann echten Schutz, wenn sie korrekt konfiguriert und verwaltet werden.
Gerade bei lüfterlosen Systemen im 24/7-Betrieb ist die Wärmeabfuhr ein zentrales Thema. Selbst ein scheinbar stromsparender Prozessor kann in typischer Last schnell 3 bis 5 W verbrauchen, was bei kleinem Gehäuse ohne aktive Kühlung kritisch werden kann. Dabei ist zu beachten:
- Gibt es einen Heatsink, eine Gehäuseanbindung oder ist aktive Kühlung nötig?
- Wie wird die Verlustleistung abgeleitet - Heatspreader?
- Gibt es Temperatur-Überwachung auf der CPU?
- Wie reagiert das System auf thermische Überlast (Throttling, Abschaltung)?
Ein solides Wärmekonzept erhöht die Zuverlässigkeit, verlängert die Lebensdauer und vermeidet spätere Designänderungen.
EMV (elektromagnetische Verträglichkeit) ist für viele Projekte eine der größten Hürden. Bereits die Wahl der Hardwareplattform beeinflusst, wie gut ein System abschirmbar und entstörbar ist.
Wichtige Einflussfaktoren:
- Pin-Layout des SoM (z. B. verdrillbare Leitungen, dedizierte Masseführung)
- Art der Displayanbindung (LVDS versus Parallel)
- Taktleitungen und Entkopplungskondensatoren
- Layout von USB, Ethernet, CAN – mit oder ohne Magnetics
- Anzahl und Position von Massepunkten
Bereits bei der Auswahl von Modul und Carrier sind diese Punkte zu berücksichtigen – andernfalls droht später ein teurer und zeitintensiver Redesign-Prozess zur Erlangung der Zertifizierungen. Die sogenannte Ott-Grafik (Bild 1) zeigt sehr gut, dass es in jedem Fall günstiger ist, gleich am Projektstart das Thema EMV zu bedenken, wenn noch viele Möglichkeiten vorhanden und Maßnahmen mit geringen Kosten möglich sind.
Die technische Bewertung von Embedded-Hardware ist eine interdisziplinäre Aufgabe, die nicht nur CPU-Benchmarks umfasst. Grafik, Schnittstellen, Funk, Security und EMV beeinflussen einander wechselseitig. Eine strukturierte Anforderungsanalyse hilft dabei, die optimale Plattform zu finden. Besonders in Embedded-Systemen gilt: Stabilität, Wartbarkeit und Realisierbarkeit wiegen oft schwerer als maximale Performance und geringste Kosten.
Wirtschaftlichkeit und Strategie – zwischen Time-to-Market und Total Cost of Ownership
Während technische Kriterien die grundsätzliche Machbarkeit eines Embedded-Designs definieren, entscheiden kommerzielle und strategische Überlegungen häufig über die wirtschaftliche Tragfähigkeit eines Projekts. Besonders in Märkten mit langen Produktlebenszyklen, hohem Zulassungsaufwand oder knapp kalkulierten Margen sind Planungs- sicherheit und Flexibilität mindestens so wichtig wie Performance oder Energieverbrauch.
Eine der grundlegendsten Entscheidungen betrifft die Architektur des Hardwaredesigns: Soll eine komplette Embedded-Plattform als Single Board Computer (SBC) verwendet werden oder setzt man auf ein System-on-Module (SoM), das mit einem Carrierboard kombiniert wird?
Die Vorteile eines SBC:
- Sofort einsatzbereit – ideal für Prototypen und Kleinserien
- Zertifizierungen oft bereits vorhanden (EMV, Funk)
- Minimaler Entwicklungsaufwand für die Hardware
- Die Vorteile eines SoM:
- Maximale Designfreiheit beim Carrier
- Bessere Integrationsmöglichkeiten für kundenspezifische Peripherie
- Geringeres Risiko bei CPU-Wechsel (z.B. bei Obsoleszenz)
- Oft längere Verfügbarkeit als Komplett-SBCs
Strategisch entscheidend ist die Frage nach dem Zeithorizont: Wer ein flexibles, langlebiges Produkt mit Variantenfähigkeit entwickeln will, wird mit einem SoM-Ansatz besser fahren – trotz der höheren Anfangskomplexität. Für kurzfristige Produktstarts oder Proof-of-Concepts kann ein SBC dagegen die pragmatischere Wahl darstellen.
Viele Hardwareplattformen scheitern in der Praxis nicht an der CPU-Leistung, sondern an schlecht gepflegten oder unausgereiften Board Support Packages (BSP). Selbst leistungsfähige Prozessoren werden wertlos, wenn sie nicht sauber in ein Embedded Linux oder RTOS integriert sind.
Wichtige Fragen zur Softwarebasis:
- Wird das BSP aktiv gepflegt und mit Sicherheitspatches versorgt?
- Welche Yocto-Version ist Grundlage des Linux-Systems?
- Gibt es Langzeitpflege (LTS) für Kernel und Middleware?
- Wie steht es um Bootzeit, Echtzeitanforderungen oder OTA-Fähigkeit?
- Existiert eine Teststrategie für neue Releases?
Ein gutes BSP reduziert drastisch den Aufwand bei Integration, Test und Wartung. Achten sollte man auch auf Verfügbarkeit von Device Tree Overlays, Qualität der Dokumentation und Responsivität des Supports bei Problemen. Plattformanbieter, die regelmäßig Sicherheitsupdates und Upstream-Kompatibilität pflegen, ermöglichen langfristig stabile Produkte – auch über mehrere CPU-Generationen hinweg.
Viele Embedded-Produkte unterliegen regulatorischen Anforderungen: CE-Kennzeichnung in Europa, FCC-Zulassung in den USA, Funkfreigaben, Medizinnormen (z.B. EN 60601), Bahnstandards (z.B. EN 50155) oder Sicherheitsrichtlinien nach ISO 26262 (Automotive). Die Wahl der Hardwareplattform kann hier großen Einfluss haben. Relevante Aspekte sind:
- Gibt es Vorerfahrungen des Anbieters mit regulatorischen Märkten?
- Sind Funkmodule vorzertifiziert?
- Wird EMV-konformes Layout unterstützt (Referenzdesigns)?
- Wie ist das System gegen Manipulation und unautorisierten Zugriff abgesichert (Security by Design)?
Wichtig: Viele Zertifizierungen erfordern, dass während des gesamten Lebenszyklus die verwendeten Bauteile und Softwareversionen dokumentiert und kontrolliert werden. Plattformen mit starkem Lifecycle-Management sparen erheblich Kosten und Aufwand.
Die vergangenen Jahre haben gezeigt, wie empfindlich Embedded-Projekte auf Störungen in der Lieferkette reagieren. Lange CPU-Lieferzeiten, knappe Power-Management-ICs, nicht verfügbare Speicherbausteine – alles Faktoren, die Projekte verzögern oder verwerfen können.
Empfehlungen zur Absicherung:
- Plattformen mit langfristiger Verfügbarkeit (mindestens zehn Jahre)
- Varianten mit alternativen Speicherausstattungen oder Gehäuseformen
- Klare Aussagen zur Lieferplanung und End-of-Life-Vorwarnzeit
- Möglichkeit zur qualifizierten Second-Source (z.B. über formkompatible SoMs)
Prozessoren, die in mehreren Baugruppen oder Produktlinien verwendet werden, sollten bevorzugt werden, allein schon wegen der höheren Stückzahlen und Verhandlungsmacht in Engpasssituationen.
Der Stückpreis eines Prozessors oder Moduls ist ein sichtbarer, aber nicht der entscheidende Kostenfaktor. Total Cost of Ownership umfasst den kompletten Aufwand über den gesamten Lebenszyklus eines Produkts. Zu den typischen versteckten Kosten gehören:
- Softwarewartung, Patches, CVE-Monitoring
- Entwicklungszeit für Custom-Carriers oder BSP-Anpassung
- Zertifizierungskosten (z.B. für Wi-Fi oder LTE)
- Redesign bei Obsoleszenz oder Performance-Engpässen
- Interne Aufwände für Security, Logging, OTA-Management
Ein System mit höherem Initialpreis, aber starker Toolchain, Supportstruktur und Updatefähigkeit kann langfristig günstiger sein als ein billigeres System mit hohem Integrations- und Wartungsaufwand.
Viele Embedded-Projekte starten mit einem begrenzten Anforderungsprofil, wachsen jedoch im Laufe ihrer Entwicklung oder bei Variantenprojekten. Eine skalierbare Plattformfamilie ermöglicht es, innerhalb eines SoM- oder CPU-Portfolios verschiedene Leistungs- oder Ausstattungsstufen zu nutzen, ohne die gesamte Architektur umstellen zu müssen. Beispiele für Skalierbarkeit:
- Pin-kompatible Module mit unterschiedlichen CPUs
- Gleiche Carrier-Platine für verschiedene Leistungsklassen
- Einheitliches BSP über mehrere Plattformen hinweg
- Varianten mit oder ohne GPU, NPU, Wireless und konfigurierbarem Speicher
Ein gutes Family-Konzept erhöht die Wiederverwendbarkeit, reduziert den Entwicklungsaufwand bei Produktvarianten und ermöglicht einen modularen Produktbaukasten. F&S bietet sowohl Single-Board-Lösungen wie etwa die armStone-Familie als auch SoMs wie die steckbaren PicoCore-Module an.
Entscheidend für ein erfolgreiches Embedded-Projekt ist nicht nur die Qualität der Hardware, sondern auch die Qualität der Zusammenarbeit mit dem Anbieter. Technische Kompetenz, Verfügbarkeit von Support, Reaktionsgeschwindigkeit und transparente Kommunikation sind oft erfolgskritischer als Datenblätter und Benchmarks.
Worauf es dabei ankommt:
- Gibt es direkte Ansprechpartner für technische Fragen?
- Ist der Support-Workflow dokumentiert (z.B. Ticketsystem)?
- Werden kundenspezifische Anpassungen unterstützt (z.B. Custom-Carriers, BSP-Tuning)?
- Gibt es Schulungen oder Workshops?
Manche Anbieter begleiten Kunden aktiv über Jahre hinweg, andere reagieren gar nicht oder nur verspätet. Embedded Engineering ist Teamarbeit, auch mit dem Hardwarepartner.
Die kommerzielle Perspektive auf Embedded-Hardware ist ebenso entscheidend wie die technische. Wer zu kurzfristig plant oder nur auf Datenblattwerte achtet, läuft Gefahr, im Laufe des Produktlebenszyklus in Sackgassen zu geraten – sei es bei Softwarepflege, Versorgungssicherheit, Zertifizierung oder Variantenbildung. Strategische Weitsicht und sorgfältige Plattformwahl zahlen sich immer aus, auch wenn sie zu Beginn aufwändiger erscheinen.
Praxisbeispiele – aus Erfahrung lernen
Nachfolgend exemplarisch einige Beispiele aus dem Alltag von F&S, die zeigen, wie Embedded Engineers durch gute Entscheidungen Projekte beschleunigen oder durch Fehlannahmen ausbremsen. Die Beispiele stammen aus typischen HMI- und Steuerungsprojekten, die auf Plattformen mit NXP-i.MX-Prozessoren beruhen.
Praxisbeispiel 1: HMI-Bediengerät mit kapazitivem 7-Zoll-Touch und WLAN
Anwendung: Ein Hersteller von Smart-Home-Komponenten entwickelt ein wandmontiertes Touchpanel zur Heizungssteuerung. Ziel ist ein reaktionsschnelles UI, integriertes WLAN und ein moderater Preis.
Technische Anforderungen:
- 7-Zoll-TFT mit kapazitivem Touch (1024 x 800)
- WLAN für lokale Integration (kein Cloud-Zwang)
- Wake-on-Touch, energieeffizienter Standby-Modus
- Benutzerfreundliches UI auf LVGL-Basis
- OTA-Updatefähigkeit
- Zertifizierbarkeit (CE, Funk)
Entscheidung und Umsetzung: Man entschied sich für ein SoM mit ARM Cortex-A55, RGB-Display und vorzertifiziertem Wi-Fi/BT-Modul. Das BSP beruhte auf Yocto LTS 5, Touch-Integration via I2C. Der Fokus bei der Entwicklung lag auf geringer Wärmeentwicklung und robuster EMV.
Lessons learned:
- Gute Integration von Funkmodul (mit CE-Zertifikat) sparte mehr als acht Wochen im Test.
- RGB-Display nutzt die native Unterstützung des i.MX 93 zusammen mit wenig EMV-Problemen.
- Sleep-Modi der CPU ließen sich problemlos nutzen: >90 Prozent Zeit im Standby.
Fazit: Die Entscheidung für ein stromsparendes, grafikorientiertes SoM mit vorkonfiguriertem Funkmodul war wirtschaftlich und technisch erfolgreich. Das Projekt konnte unter zwölf Monate nach Kickoff serienreif ausgeliefert werden.
Praxisbeispiel 2: Steuerungseinheit mit 2,7-Zoll-E-Paper, CAN und zehn Jahren Laufzeit
Ein Hersteller von Messgeräten entwickelt eine Steuerungseinheit mit E-Paper-Anzeige und extrem langer Batterielebensdauer. Eingesetzt werden soll sie in dezentralen Sensorboxen mit CAN-Kommunikation.
Technische Anforderungen:
- E-Paper mit minimalem Energieverbrauch (128 x 296 Pixel)
- i.MX 8ULP mit Cortex-33M und 2x Cortex-A35 mit Deep Sleep und Wake-on-Interrupt
- RS-485 galvanisch getrennt, CAN und digitale I/Os
- Robuste Kommunikation, -30 °C bis +85 °C
- Keine WLAN- oder Multimedia-Anforderung
Entscheidung und Umsetzung: Man entschied sich für die Ultra-Low-Power-CPU i.MX 8ULP, die direkt E-Paper ohne dedizierten Controller ansteuern kann. Das System bootet ein Minimal-Linux zur Konfiguration und wechselt dann in ultratiefen Sleep-Modus.
Lessons Learned:
- Initial wurde der Energieverbrauch stark unterschätzt (z.B. durch Power-LEDs, LDOs mit hohem IQ).
- E-Paper-Refresh erzeugte überraschende EMV-Spitzen, die ein Redesign des Layouts erforderten.
- Secure Boot wurde nachträglich ergänzt – erhöhte Aufwand massiv.
Fazit: Technisch machbar, aber wirtschaftlich hart kalkuliert. Ein frühzeitigeres Power-Design und Security-by-Design hätten Entwicklungszeit gespart.
Häufige Fehler und Fehlentscheidungen in der Praxis
Fehler 1: CPU überdimensioniert. Oft wird »auf Nummer sicher« eine zu leistungsfähige CPU gewählt – mit höherem Stromverbrauch, größerem Layout, komplexerer Software. Das erhöht unnötig BOM-Kosten und EMV-Risiken.
Fehler 2: Funkintegration ohne Zertifizierungsstrategie. Projektstart, ohne CE oder FCC im Blick zu haben. Eigenes Antennendesign scheitert oft an EMV, Tuning oder Positionierung.
Fehler 3: Unterschätzung von Softwarepflege. Das BSP ist oft ein Snapshot bei Projektstart – Updates, CVE-Patches, Kernelwechsel kommen später und treffen auf ungenügend gepflegte Softwarebasis.
Fehler 4: EMV erst ganz am Schluss. Erste Muster bestehen EMV-Prüfung zufällig, das zweite Layout fällt komplett durch. Ursache: Ungünstige Masseführung, ungeschirmte Leitungen oder schlecht entkoppelte Clock-Signale.
Fehler 5: Keine Skalierungsstrategie. Ein Gerät wird um weitere Varianten ergänzt, aber der SoM oder das Carrier-Design lässt keine Erweiterungen zu (z.B. PCIe, USB Host, mehr GPIOs).
Regulatorische Anforderungen – von RED bis CRA
RED-Richtlinie (Radio Equipment Directive): Seit 2022 umfasst die RED-Richtlinie auch Anforderungen an die Cybersicherheit von Funkgeräten. Geräte mit WLAN, Bluetooth oder LTE müssen gewährleisten, dass:
- nur autorisierte Software installiert werden kann (Secure Boot),
- personenbezogene Daten geschützt sind,
- unautorisierte Kommunikation verhindert wird.
Cyber Resilience Act (CRA): Die CRA-Verordnung der EU definiert Cybersicherheits-Anforderungen für alle »digitalen Produkte«. Im Zentrum steht:
- eine durchgängige Sicherheitsarchitektur,
- regelmäßige Updates (mindestens fünf Jahre),
- CVE-Management und Schwachstellenbehandlung,
- Konformitätserklärung durch den Hersteller.
Norm EN 18031: Diese Norm dient als technischer Bezugsrahmen für viele regulatorische Anforderungen. Sie umfasst Themen wie:
- Kryptografische Absicherung,
- Zugriffskontrollen,
- sichere Updates,
- Schutz vor Manipulation auf Hardware- und Softwareebene.
Fazit: Cybersicherheit ist keine Option mehr, sondern Teil der Produkthaftung.
Architekturprinzipien für ein sicheres Embedded-System
Ein sicheres Embedded-System beginnt nicht bei der Software, sondern bei der Hardwarearchitektur. Die folgenden Prinzipien bilden den Kern von Security by Design:
- Durchdachtes Boot-Konzept
- Sicherer Bootloader mit Signaturprüfung (Secure Boot)
- Physische Root of Trust (TPM, Secure Element, Secure Enclave)
- Separation von Instanzen
- Trennung von Userland und Kernel-Modulen
- Nutzung von TrustZone (ARMv8-M/A) zur Absicherung sensibler Funktionen
- Minimaler Software-Footprint
- Reduktion potenzieller Angriffsflächen
- Entfernung nicht benötigter Dienste, Treiber und Daemons
- Minimal notwendige Komplexität der SBOM (Software Bill of Material)
- Sicheres Updatekonzept
- Signierte OTA-Updates mit Rollback-Schutz
- Fail-Safe-Mechanismen für unterbrochene Updates
- Schutz sensibler Daten
- Verschlüsselung von Konfigurationsdaten, Schlüsseln und Logs
- Secure Key Storage (z.B. über HSM, SE, oder SoC-integrierte Funktionen)
Sicherheitsfeatures heutiger Embedded-Plattformen
Viele aktuelle Prozessoren, etwa die i.MX-9-Serie von NXP mit ihrem integrierten EdgeLock Secure Enclave, bieten bereits grundlegende Sicherheitsfunktionen, doch diese müssen korrekt implementiert werden.
Typische Sicherheitsfunktionen sind:
- Secure Boot: Verifiziert die Integrität der Firmware beim Start
- Hardware Unique Key: Vom SoC erzeugter, nicht auslesbarer Schlüssel
- TrustZone: Trennung von Secure/Non-Secure-Codebereichen
- Secure Enclave: Isolierte Ausführungsumgebung für Schlüssel/Krypto
- JTAG Lock: Verhindert Debugging nach Deployment
- eFuses/OTP: Unveränderliche Hardwarekonfiguration (z. B. Bootmodus)
Fazit und Ausblick – Navigieren im Embedded-Dschungel
Die Auswahl einer geeigneten Embedded-Hardwareplattform ist heutzutage eine vielschichtige Aufgabe, die weit über reine Datenblattvergleiche hinausgeht. Embedded Engineers bewegen sich in einem Spannungsfeld aus technischen Anforderungen, regulatorischen Vorgaben, wirtschaftlichen Rahmenbedingungen und strategischen Entscheidungen. Der Prozess erfordert nicht nur Systemverständnis, sondern auch interdisziplinäres Denken, Risikobewusstsein und vorausschauende Planung. Hierzu ist folgendes zwingend notwendig:
- Eine saubere Anforderungsanalyse ist unentbehrlich. Wer die Displaygröße, Schnittstellenvielfalt, Sicherheitsanforderungen oder Bootzeiten erst während der Entwicklung konkretisiert, zahlt später mit Redesigns, Zeitverzögerung und erhöhtem Aufwand.
- Die Prozessorwahl ist keine Bauchentscheidung. Plattformen mit integriertem Grafik- oder KI-Beschleuniger bieten viele Vorteile, sind aber nur dann sinnvoll, wenn diese Funktionen wirklich gebraucht werden und in die Systemarchitektur integriert werden können.
- Security und EMV gehören von Anfang an in den Architekturentwurf. Sie lassen sich später nicht ohne massive technische und wirtschaftliche Folgen »nachrüsten«.
- Total Cost of Ownership schlägt Einzelpreis. Eine Plattform mit guten Softwarepaketen, verlässlichem Support und starker Dokumentation kann teurer sein, lohnt sich aber durch reduzierte Integrations-, Wartungs- und Zertifizierungskosten.
- Make-or-Buy-Entscheidungen müssen langfristig gedacht werden. Ein SBC kann Projekte schnell starten, ein SoM mit eigenem Carrier schafft dagegen Freiheit, Kontrolle und Skalierbarkeit.
- Lieferfähigkeit und Lifecycle-Strategien sichern Projekte ab. Die Zeit billiger und jederzeit verfügbarer Bauteile ist vorbei. Wer frühzeitig Varianten und Alternativen bedenkt, bleibt handlungsfähig.
- Klassische Embedded Engineers waren lange vor allem Entwickler. Heutzutage sind sie zugleich Systemarchitekten, Security-Verantwortliche, Integratoren, manchmal auch Projektstrategen. Die Auswahl von Hardwareplattformen ist ein gutes Beispiel dafür: Sie verlangt technische Tiefe, regulatorisches Verständnis und strategisches Denken.
- Embedded-Systeme werden intelligenter, vernetzter und – leider – auch angreifbarer. Gleichzeitig steigen die Erwartungen an UX, Performance und Updatefähigkeit. Dies alles erfordert ein neues Denken in Modularität, Wartbarkeit und Lebenszyklus – bereits bei der Wahl von CPU und Modul.
Die nächsten Jahre werden von mehreren Trends geprägt sein:
- Security by Design wird Standard. Systeme ohne echte Absicherung werden regulatorisch unzulässig oder wirtschaftlich nicht mehr tragfähig.
- KI an der Edge wird spezialisierter. Nicht jedes System braucht eine NPU, aber immer mehr Systeme profitieren von gezielten Inferenzen direkt im Gerät.
- OTA wird zur Grundanforderung. Software lebt – und mit ihr das Produkt. Ohne sichere Update-Infrastruktur verliert jede Embedded-Plattform an Zukunftsfähigkeit.
- Plattformstrategien gewinnen an Bedeutung. Unternehmen, die auf wiederverwendbare Architekturkonzepte, Variantenfähigkeit und Partnernetzwerke setzen, haben die besseren Karten.
Die Auswahl einer Embedded-Plattform ist komplex, aber lösbar, wenn technische Tiefe, regulatorisches Wissen und zuverlässige Partner zusammentreffen. F&S Elektronik Systeme versteht sich dabei nicht als reiner Modulhersteller, sondern als langfristiger Engineering-Partner, der Kunden befähigt, robuste, skalierbare und zukunftssichere Embedded-Produkte zu entwickeln – vom Prototyp bis zur zertifizierten Serie.
Der Autor:
Andreas Kopietz ist Key Account Manager bei F&S Elektronik Systeme.
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Batteriezellen-Controller
NXP senkt BMS-Kosten mit neuer IC-Architektur
Industrieroboter leichter umsetzen
Ein Mikroprozessor genügt für Industrieroboter mit 9 Achsen
