Das macht ein Computer-on-Module nicht automatisch CRA-konform. Eine modulare Architektur kann jedoch helfen, Dokumentation, Updateprozesse und Lifecycle-Management klarer zu strukturieren. Eine modulare Architektur ändert nichts an der Verantwortung des Herstellers für die Konformität des Endprodukts, das unter seinem eigenen Namen oder seiner eigenen Marke in Verkehr gebracht wird.
Dieser Beitrag dient ausschließlich der technischen Orientierung. Er stellt keine Rechtsberatung und keine vollständige technische oder regulatorische Konformitätsbewertung dar. Ob eine bestimmte Architektur geeignet ist und welche CRA-Auswirkungen sich daraus ergeben, muss für das jeweilige Produkt und den konkreten Anwendungsfall bewertet werden.
Wie trennt ein Computer-on-Module Recheneinheit und Systemdesign?
Ein Computer-on-Module, kurz COM, integriert zentrale Rechenfunktionen wie Prozessor, Arbeitsspeicher und grundlegende Schnittstellen auf einem kompakten Modul. Bei standardisierten Formfaktoren wie COM Express oder COM-HPC erfolgt die Anbindung an ein anwendungsspezifisches Carrier Board über definierte Schnittstellen.
Dadurch können anwendungsspezifische Funktionen auf dem Carrier Board und Teile des Systemdesigns von der zugrunde liegenden Prozessorplattform getrennt werden. Ein Wechsel auf ein neueres kompatibles Modul betrifft daher häufig einen kleineren Teil des Hardwaredesigns als bei einem vollständig kundenspezifischen Board.
Vollständig unabhängig wird die Anwendung dadurch jedoch nicht. Betriebssystemintegration, BIOS beziehungsweise Firmware, Treiber, Leistungsaufnahme, Kühlung und Security-Funktionen müssen bei einem Modulwechsel weiterhin auf Kompatibilität und ihre Auswirkungen auf das Gesamtsystem geprüft werden.
Bei einem vollständig kundenspezifischen Board sind Prozessor, Speicher und zentrale I/O-Funktionen direkt in das Boarddesign integriert. Ein Plattformwechsel betrifft deshalb häufig einen größeren Teil der Hardwareentwicklung und Systemvalidierung. Unveränderte Software- und Dokumentationsbestandteile können weiterhin wiederverwendbar sein, der Migrationsaufwand ist jedoch häufig höher.
Wo kann eine COM-Dokumentation und Neubewertung erleichtern?
Abhängig von Lieferant und Produkt können auf Modulebene beispielsweise folgende Informationen verfügbar sein:
- SBOM-Daten
- Security Advisories
- Informationen zu BIOS, Firmware und Board Support Package (BSP)
- Angaben zu verfügbaren Sicherheitsfunktionen
- Support- und Lifecycle-Informationen
Diese Informationen können in die technische Dokumentation und die Cybersicherheitsrisikobewertung des Endprodukts einfließen. Sie ersetzen nicht die Bewertung des Gesamtsystems.
Bei einem kompatiblen Modulwechsel können Teile der bestehenden technischen Dokumentation weiterhin anwendbar sein, sofern sich das zugrunde liegende Design und die relevanten Annahmen nicht geändert haben. Die Dokumentation sollte dennoch überall dort überprüft und aktualisiert werden, wo sich der Modulwechsel auf das Produkt oder dessen Cybersicherheitsbewertung auswirkt.
Die Auswirkungen des neuen Moduls auf Angriffsfläche, Treiber, Firmware, Updateprozess, Leistungsaufnahme, thermische Auslegung und Schnittstellen müssen weiterhin bewertet werden.
Bei Änderungen an bereits in Verkehr gebrachten Produkten ist außerdem zu bewerten, ob sie eine „wesentliche Änderung“ im Sinne von Artikel 3 Nummer 30 CRA darstellen.
Ein wesentlicher Vorteil einer modularen Architektur ist die klarere Trennung technischer Ebenen. Dadurch lässt sich leichter erkennen, welche Bestandteile unverändert bleiben und welche neu bewertet werden müssen.
Wie kann eine gemeinsame Plattform Updates und Lifecycle-Management unterstützen?
Nutzen mehrere Endprodukte dieselbe Modul- und Softwarebasis, kann eine gemeinsame Update-Infrastruktur aufgebaut werden. Prozesse für Signierung, Verteilung, Versionierung und Wiederherstellung müssen dann nicht zwangsläufig für jede Produktlinie vollständig neu entwickelt werden.
Produktspezifische Tests, Freigaben und Rollout-Regeln bleiben weiterhin erforderlich. Unterschiedliche Betriebssystemstände, Konfigurationen oder Einsatzumgebungen können auch bei gemeinsamer Hardwarebasis eine separate Validierung notwendig machen.
Eine gemeinsame Plattform kann außerdem helfen, bei einer neu entdeckten Schwachstelle betroffene Produktvarianten zu identifizieren und Korrekturmaßnahmen über verwandte Produkte hinweg zu koordinieren. Die gesetzlichen Meldepflichten bleiben davon unberührt.
Auch für das Lifecycle-Management kann ein COM Vorteile bieten. Wird eine eingesetzte Prozessor-, Firmware- oder Betriebssystemplattform während des geplanten Supportzeitraums abgekündigt oder nicht mehr mit Sicherheitsupdates versorgt, kann der Wechsel auf ein neueres, weiterhin unterstütztes Modul eine mögliche Migrationsstrategie sein.
Standardisierte Modul- und Carrier-Board-Schnittstellen können eine Grundlage dafür schaffen, ein Carrier Board über mehrere kompatible Modulgenerationen hinweg weiterzuverwenden. Ob dies in einem konkreten Projekt möglich ist, hängt unter anderem von Pinout, Leistungsaufnahme, Kühlung, Firmware, Treibern und den benötigten I/Os ab.
Welche Sicherheitskonzepte lassen sich vereinheitlichen?
Sicherheitskonzepte wie Secure Boot, Hardware Root of Trust oder signierte Updates können auf einer gemeinsamen Systemarchitektur aufbauen. Teile der Update- und Schlüsselmanagementprozesse lassen sich dadurch über mehrere Produktvarianten hinweg vereinheitlichen.
Bei einem Modulwechsel muss jedoch geprüft werden, welche Bestandteile der Vertrauenskette tatsächlich unverändert bleiben. Secure Boot umfasst beispielsweise nicht nur das Carrier Board, sondern auch Prozessorplattform, BIOS beziehungsweise UEFI, Bootloader, Schlüsselverwaltung und Betriebssystem.
Eine früh definierte Security-Architektur kann die Migration erleichtern. Sie ersetzt keine erneute Validierung der geänderten Komponenten.
Wer trägt welche CRA-Verantwortung?
Ein COM-Ansatz kann die technische und organisatorische Zuordnung von Aufgaben erleichtern.
Der Modullieferant kann Updates und Informationen für modulspezifische Komponenten wie BIOS, Firmware oder Board Support Package bereitstellen. Der Hersteller des Endprodukts muss die relevanten Informationen bewerten, sie gegebenenfalls in die Systemkonzeption einbeziehen und in seiner eigenen technischen Dokumentation berücksichtigen.
Ein Systemintegrator kann diesen Prozess auf technischer Ebene unterstützen.
Für die Konformität des Endprodukts, das unter dem eigenen Namen oder der eigenen Marke in Verkehr gebracht wird, bleibt der Hersteller verantwortlich. Die Auswahl eines Moduls überträgt diese Verantwortung nicht auf den Lieferanten.
Die technische Kompatibilität ist nur ein Aspekt bei der Modulauswahl. Ebenso relevant ist, welche SBOM-Daten, Security Advisories, Supportzeiträume und Updateinformationen der Lieferant über den geplanten Produktlebenszyklus bereitstellt.
Wie beeinflusst der CRA die Plattformstrategie?
Für ein bestimmtes Endprodukt ändert die Wahl zwischen COM, SBC und Custom Design für sich genommen nichts an den grundlegenden Cybersicherheitsanforderungen des CRA. Unterschiede liegen vor allem in der technischen Umsetzung, den Lieferantenabhängigkeiten sowie im Aufwand für Wartung und spätere Plattformmigration.
Ein COM kann sinnvoll sein, wenn eine kundenspezifische Trägerplatine benötigt wird und die Recheneinheit später austauschbar bleiben soll. Ein SBC bietet eine stärker integrierte Standardplattform, während ein Custom Design die größte Gestaltungsfreiheit bietet, in der Regel aber einen höheren initialen Entwicklungs- und Validierungsaufwand erfordert.
Für die Entscheidung bleiben daher vor allem Produktlebensdauer, Stückzahl, Individualisierungsgrad, verfügbare Security-Informationen und der Aufwand für spätere Plattformwechsel relevant.
Quellen
In den zurückliegenden 30 Jahren haben wir uns vom Distributor zu einem erfolgreichen System Integrator entwickelt, der gemeinsam mit den Kunden individuelle Embedded-Lösungen erarbeitet.
Unser Produktspektrum umfasst Embedded PCs unterschiedlichster Bauformen, industrielle Display-Lösungen inklusive verschiedenster Touchtechnologien und 19" Rackmount Server mit redundanten Komponenten zur Sicherstellung der maximalen Ausfalls-, Funktions-, und Betriebssicherheit. Passende Accessories, wie Memories, SSDs und Starterkits, runden unser Angebot ab.
Wir beraten und unterstützen von der Systemanalyse über die Produktauswahl und der Prototypenentwicklung bis hin zur Serienfertigung. Mit unserem einzigartigen Service erhalten Sie alles aus einer Hand. Wir begleiten Sie lückenlos vom Pre- bis zum After-Sales persönlich, individuell und flexibel. Weitere Informationen über Aaronn Electronic GmbH finden Sie unter www.aaronn.de
Aaronn Electronic GmbH
Lilienthalstraße 1
82178 Puchheim
Telefon: +49 (89) 894577-0
Telefax: +49 (89) 894577-29
http://www.aaronn.de
Marketing
Telefon: 0898945770
E-Mail: info@aaronn.de
