OSM-Module mit i.MX 91 & i.MX 93: 13 Module im Vergleich (2026)

Das Wichtigste in Kurzform

• Das Silizium unterscheidet die Module kaum. Zehn der zwölf OSM-Module teilen denselben Rahmen: i.MX 9x, bei allen Modulen mit Angabe maximal 2 GB LPDDR4/4X, eine einzige 5-V-Versorgung, 30 × 30 mm. Die eMMC-Obergrenzen streuen von 16 bis 256 GB, bei einem Modul ist keine genannt. Wer nach Datenblattzeilen auswählt, vergleicht nahezu identische Produkte.
• Die Unterschiede liegen in Dokumentation, BSP und Lebenszyklus — und dort sind sie erheblich: Nur ein Anbieter liefert ein vollständiges BSP-Handbuch, nur drei dokumentieren ein Carrier-Board, nur zwei nennen ein Verfügbarkeitsdatum.
• OSM 1.2 ist zu 1.1 aufwärtskompatibel (SGET, 11.11.2024). Das Kompatibilitätsrisiko liegt nicht in der Revision, sondern in der Umsetzung: Ein Anbieter belegt nur 202 der 332 Kontakte, mehrere nennen ihre Kontaktzahl gar nicht.
• Der Cyber Resilience Act verschiebt die Auswahlkriterien. Ab 11.09.2026 gelten Meldepflichten für ausgenutzte Schwachstellen, ab 11.12.2027 die vollen Anforderungen. Kein Anbieter im Vergleich nennt eine Support-Dauer für Sicherheitsupdates.
• i.MX 93 ist die Voreinstellung. Der i.MX 91 ist derselbe Baustein ohne Display, Kamera, NPU und Echtzeitkern — ein bewusster Verzicht, kein günstigerer Einstieg.

Wer heute ein industrielles Linux-Gerät auf einem lötbaren System-on-Module aufsetzt, entscheidet nicht mehr nur über Rechenleistung. Ab 11. September 2026 greifen die Meldepflichten des EU Cyber Resilience Act für aktiv ausgenutzte Schwachstellen, ab 11. Dezember 2027 die vollen Anforderungen an Produkte mit digitalen Elementen (Verordnung (EU) 2024/2847, Europäische Kommission, abgerufen am 26.07.2026). Ein Modul, das 2026 ins Design geht, muss also über Jahre mit Sicherheitsupdates versorgt werden — und genau darüber schweigen die Datenblätter am lautesten.

Das erzeugt eine unangenehme Spannung. Die Hardware dieser Module ist weitgehend austauschbar; das, was über die Produktlebensdauer entscheidet, steht nicht in der Spezifikationstabelle. Dieser Vergleich betrachtet daher sieben Achsen: Silizium, Formfaktor und Second-Sourcing, Dokumentationstiefe, Leistungsaufnahme, Software und BSP, Langzeitverfügbarkeit sowie Carrier-Design und Thermik.

Grundlage: 32 Herstellerdokumente zu 13 Modulen von neun Anbietern — Datenblätter, User Guides, Design Guides, Schaltpläne und BSP-Handbücher — wurden vollständig ausgewertet und Zeile für Zeile gegenübergestellt. Wo ein Hersteller eine Angabe nicht veröffentlicht, steht in diesem Vergleich „nicht angegeben“ statt eines Schätzwerts. Details dazu stehen im Abschnitt Methodik und Quellen am Ende des Artikels.

Welche SoC-Plattformen und Schnittstellen Teleconnect in Kundenprojekten einsetzt, fasst die Seite Technologien und Expertise zusammen.

Die 13 Module auf einen Blick

Zwölf der 13 Module sind OSM-konform; das TQ-Systems TQMa93xxLA ist ein proprietäres LGA-Modul (38 × 38 mm, 281 Pads) und dient hier als Vergleichsmaßstab dafür, was OSM-Konformität praktisch wert ist.

Alle 13 Module werden aus einer einzigen 5-V-Versorgung betrieben (typisch ± 5 %), und zehn der zwölf OSM-Module nutzen den 30 × 30 mm großen Size-S-Footprint. Auch der Temperaturbereich konvergiert: Wo ein Anbieter überhaupt Zahlen nennt, sind es meist bis zu drei Klassen — 0 bis +70 °C (kommerziell), −25 bis +85 °C (erweitert) und −40 bis +85 °C (industriell), wobei die industrielle Variante bei praktisch allen Herstellern verfügbar ist. Auf der Spezifikationsebene sind diese Module also weitgehend gegeneinander tauschbar — was die Auswahl auf die weichen Faktoren verlagert.

Zur Benennung: Mehrere Anbieter vermarkten ihr Size-S-Modul als „OSM-SF“. Das ist keine eigene Größenklasse, sondern die voll bestückte Variante von Size-S — mehr dazu im Abschnitt zum OSM-Standard. In der Tabelle steht deshalb durchgängig die Größenklasse, nicht die Marketingbezeichnung.

Und dort öffnet sich die Schere. Die folgende Auswertung zählt, wie viele der neun Anbieter eine gegebene Angabe überhaupt veröffentlichen. „Vollständiges Pinout“ heißt dabei: eine Kontaktliste, aus der sich jedes Signal einem Kontakt zuordnen lässt — nicht nur eine Blockübersicht der Schnittstellen.

Die untersten drei Balken sind die eigentliche Nachricht: Software- und Lebenszyklus-Dokumentation ist im Markt die Ausnahme, nicht die Regel.

i.MX 91 oder i.MX 93: welcher SoC?

Der i.MX 93 ist die Voreinstellung. Zum i.MX 91 sollte man nur greifen, wenn sicher ist, dass weder Display noch Kamera, NPU oder Echtzeitkern benötigt werden — denn genau diese Blöcke entfernt NXP, und sonst nichts.

Beide SoCs teilen die EdgeLock Secure Enclave, zwei Gigabit-Ethernet-Ports (einer davon TSN-fähig), LPDDR4 mit Inline-ECC und dieselbe Cortex-A55-Architektur. Der i.MX 91 ist keine andere Plattform, sondern ein i.MX 93 ohne Multimedia-, ML- und Echtzeitblöcke und mit niedrigeren Takten.

Die Ethos-U65 im i.MX 93 läuft mit bis zu 1 GHz und liefert 0,5 TOPS bei 256 MAC-Operationen pro Takt (NXP, abgerufen am 26.07.2026).

Zwei Fallen, die regelmäßig zuschlagen

1. Keiner der beiden SoCs hat eine 3D-GPU. Das überrascht alle, die den i.MX 93 für „den grafischen“ halten. Er hat eine 2D-PXP-Engine und nichts darüber hinaus. Jede 3D-gerenderte Oberfläche, jede OpenGL-ES-Last und jede GPU-Compute-Aufgabe schließt beide SoCs aus — dafür braucht es eine andere i.MX-Familie.

2. Die NPU ist eine Teilenummern-Entscheidung, keine Familien-Entscheidung. Innerhalb des i.MX 93 tragen nur die -5x-Teile (i.MX 9352, 9351) die Ethos-U65. Ein Modul mit i.MX 9332 oder 9331 ist ein i.MX 93 ohne jede NPU. Mehrere Anbieter im Vergleich nennen gar nicht, welches bestellbare i.MX-93-Teil sie bestücken. Wer On-Device-Inferenz plant, muss die exakte Teilenummer bestätigen lassen, bevor er das Modul einplant.

Typische Einsatzfälle, die die Hersteller selbst nennen: Zähler, Ladeinfrastruktur und HVAC-Steuerung, Smart-Home- und Matter-Geräte, VoIP-Sprechstellen sowie Headless-Gateways.

Wer innerhalb der i.MX-9-Reihe noch unentschieden ist, sollte die Entscheidung an den vier Blöcken oben festmachen — Display, Kamera, NPU, Echtzeitkern — und nicht an der Taktfrequenz.

Was der OSM-Standard tatsächlich regelt

OSM (Open Standard Module) definiert lötbare, steckverbinderlose Module — das Modul wird per LGA-Kontaktfeld direkt auf das Carrier-Board reflow-gelötet. Das macht die Bestückung vollständig maschinell verarbeitbar und entfernt Bauhöhe, Steckverbinder-BOM und eine mechanische Ausfallursache.

Der Standard wird von der SGET (Standardization Group for Embedded Technologies) gepflegt und definiert vier aufeinander aufbauende Größenklassen:

Die elektrischen Randbedingungen des Kontaktfeldes sind knapp gefasst: eine einzige 5-V-Primärversorgung, mindestens 0,5 A pro gelötetem Kontakt, und ein Leistungsbudget, das mit der Zahl der VCC_IN_5V-Kontakte skaliert (1 / 5 / 9 / 17 für Size-0 / S / M / L). Spannungsanstiegsraten über 50 V/ms sollten vermieden werden. Für diese SoC-Familie ist die Size-S-Obergrenze von 12,5 W komfortabel — die i.MX-93-Module liegen bei rund 2 W.

Das Kürzel „F“ in Bezeichnungen wie OSM-SF und OSM-LF steht für die voll bestückte Variante der Größenklasse: OSM-SF meint Size-S mit allen 332 Kontakten, OSM-LF Size-L mit 662. Wichtig: Das beschreibt die Bezeichnung, nicht eine geprüfte Zusage — wie weit ein konkretes Modul die Kontakte wirklich belegt, ist eine eigene Frage (siehe den Befund zu 202 von 332 Kontakten weiter unten).

Der Preis dieser Bauform steht in mehreren der ausgewerteten Dokumente unmissverständlich: Das Modul ist nicht entnehmbar. TQ formuliert es für sein eigenes LGA-Teil so, dass ein Entfernen „nicht trivial und nicht empfohlen“ sei. Rework, Feldtausch und Prototypen-Iteration werden dadurch aufwendiger — ein Punkt, der bei der Kalkulation der Entwicklungsphase gern untergeht.

Ist Second Sourcing über OSM realistisch?

Auf Spezifikationsebene ja, auf Umsetzungsebene noch nicht. Diese Unterscheidung ist der wichtigste Befund dieses Vergleichs, und sie wird häufig vermischt.

Die gute Nachricht zuerst: Die SGET hat OSM-Spezifikation 1.2 am 11. November 2024 zusammen mit dem Design Guide 1.1 veröffentlicht und erklärt dabei ausdrücklich die volle Kompatibilität zu Modulen auf Basis von OSM 1.1. Die Änderungen sind additiv: eine einkanalige LVDS-Schnittstelle jetzt auch auf Size-S (vorher Size-L vorbehalten), eine zweite CSI-Schnittstelle auf Size-M und eine zweite I2S-Schnittstelle auf Size-0 (SGET, abgerufen am 26.07.2026). Zusätzlich hält der Standard bis zu 58 Pins für künftige Erweiterungen reserviert, damit diese aufwärtskompatibel bleiben (SGET, abgerufen am 26.07.2026).

Die Revisionsfrage ist damit entschärft — auch wenn die Anbieter im Feld auf unterschiedliche Stände verweisen:

Die schlechte Nachricht liegt eine Ebene tiefer. Der Standard garantiert ein Pinout — er garantiert nicht, dass zwei Hersteller es identisch bestücken. Drei Beobachtungen aus den Dokumenten:

• Die Kontaktbelegung unterscheidet sich. Ein Anbieter dokumentiert offen, nur 202 der 332 Kontakte zu belegen. Ein anderer nennt nicht, wie viele der 662 Kontakte seines Size-L-Moduls bestückt sind. Mehrere veröffentlichen überhaupt keine Kontaktzahl.
• Mindestens ein Hersteller weicht bewusst ab. In einer Fußnote seines eigenen Datenblatts hält ein Anbieter fest, dass das Signal CARRIER_STBY# auf seinem i.MX-93-Modul gegenüber dem OSM-Standard invertiert ist. Wer dieses Modul gegen ein anderes tauscht, tauscht die Polarität eines Steuersignals mit.
• Widersprüche innerhalb einzelner Datenblätter. Ein Datenblatt nennt auf Seite 1 „322 Pin“ und auf Seite 2 „332 Contacts“ — ein Zahlendreher, der in einer Stückliste teuer wird.

Praktische Konsequenz: OSM senkt die Qualifizierungskosten für standardisierte Formfaktoren spürbar (NXP, abgerufen am 26.07.2026), ersetzt aber keinen Pin-für-Pin-Abgleich. Wer Second Sourcing als Risikominderung einplant, muss die konkreten Kandidaten paarweise vergleichen — nicht nur ihre Konformitätsaussage lesen.

Einen solchen Abgleich und die Qualifizierung einer Zweitquelle begleiten wir im Rahmen der Hardwareentwicklung.

Dokumentationsqualität: die unterschätzte Auswahlachse

Die Spreizung in der Dokumentationstiefe ist größer als jeder technische Unterschied zwischen diesen Modulen — und sie sagt mehr über den Projektverlauf voraus.

An einem Ende steht F&S Elektronik: CAD-Bibliotheken für Cadence und Altium, 3D-STEP-Modelle, ein Carrier-Implementierungsleitfaden und eine Kühllösung. Aus diesem Material allein lässt sich ein Carrier-Design beginnen. Der AN-OSM01-Implementierungsleitfaden ist dabei weitgehend herstellerneutral und für jedes Size-S-Design brauchbar. Das gilt für die Designunterlagen — das Moduldatenblatt zum i.MX 93 lässt umgekehrt mehrere Kernangaben offen. Tiefe der Unterstützung und Vollständigkeit des Datenblatts sind hier zwei verschiedene Dinge.

Geniatech ist der am vollständigsten dokumentierte Anbieter im Vergleich, ohne der detaillierteste zu sein: Modul, Carrier-Board und ein echtes Yocto-BSP-Handbuch auf einer benannten NXP-Basis. Advantech liefert Datenblatt, User Guide, Entwicklungskit-Handbuch, Schaltplan, IO-MUX-Tabelle und CE-Zertifikat.

Am anderen Ende steht ein Anbieter, dessen Modulunterlagen aus Marketing-Broschüren mit Versionsnummern unter 1.0 bestehen — dort lesen sich die meisten Spezifikationszeilen als „nicht angegeben“, inklusive des Temperaturbereichs.

Eine zweite, oft übersehene Achse ist der Dokumentenstatus. Drei der inhaltlich reichsten Datenblätter im Vergleich sind als PRELIMINARY oder DRAFT gekennzeichnet — und alle drei halten die Leistungsaufnahme zurück. Bei einem dieser Datenblätter gab es innerhalb von fünf Monaten vier Revisionen, zwei davon zur Korrektur inhaltlicher Fehler. Für Bauteile auf einer neuen SoC-Familie ist das normal; es heißt aber, dass Zahlen sich noch bewegen.

Tiefe der Dokumentation ist nicht dasselbe wie Reife der Dokumentation. Beides sollte man getrennt bewerten.

Leistungsaufnahme: wer misst, wer schätzt, wer schweigt

Nur ein Anbieter veröffentlicht gemessene Leistungswerte. Geniatech nennt 1,24 W im Idle und 2,41 W unter Last, jeweils mit der zugrunde liegenden Spannung und Stromaufnahme. Alle anderen liefern eine Spanne, einen Maximalwert, einen widersprüchlichen Satz von Zahlen — oder nichts.

Zwei Muster verdienen Beachtung. Erstens: Bei einem Modul stehen in drei Dokumenten desselben Herstellers drei unterschiedliche Leistungswerte — 2,1 W, 2,14 W und 4,82 W. Zwischen dem niedrigsten und dem höchsten liegt ein Faktor von rund 2,3 — und damit die Frage, ob ein passives Kühlkonzept trägt. Zweitens: Die Angabe „TBA“ in einem PRELIMINARY-Datenblatt ist zwar ehrlich, hilft aber bei der Thermik-Auslegung nicht weiter.

Für ein batteriebetriebenes oder lüfterloses Design ist die gemessene Angabe eines Anbieters mehr wert als die längere Merkmalsliste eines anderen. Wo keine Zahl vorliegt, sollte man sie vor der Designfreigabe schriftlich anfordern — mit Angabe des Lastszenarios.

Software und BSP: Yocto ist der gemeinsame Nenner

Yocto Linux können alle; unterscheiden lässt sich nur, wer es dokumentiert. Von neun Anbietern liefert genau einer ein vollständiges BSP-Handbuch. Bei allen anderen ist der Software-Support eine Merkmalsliste, die sich aus den vorliegenden Unterlagen nicht bewerten lässt.

Ein Strich in der Spalte Benannte Versionen heißt: Der Anbieter nennt ein Betriebssystem, aber weder Kernel-Version noch Yocto-Release, Layer-Namen, Release-Kadenz oder Support-Dauer.

Drei Positionierungen heben sich ab:

Toradex verkauft den Lebenszyklus mit. Torizon OS bringt OTA-Updates, Flottenüberwachung und Fernzugriff über Torizon Cloud mit und wird ausdrücklich mit erleichterter CRA-Konformität beworben; das i.MX-93-Modul ist für Torizon OS vorbereitet, Yocto wird vollständig unterstützt, FreeRTOS, Zephyr, QNX und Android auf Anfrage (Toradex; unabhängig bestätigt bei CNX Software, beide abgerufen am 26.07.2026).

Ezurio verkauft Sicherheit als Softwareprodukt. Als einziger Anbieter im Vergleich bietet er bezahlte Lifecycle-Dienste statt nur ein BSP: Secure-Boot-Provisionierung, Schlüssel- und Zertifikatserzeugung, einen Signierdienst, Schwachstellen-Monitoring gegen die SBOM des Kunden mit planbaren Benachrichtigungen und eine Remediation mit aktualisierten BSP-Releases. Ein FIPS-140-3-Level-1-Kryptomodul ist angekündigt. Für regulierte Produkte kann das schwerer wiegen als die Spezifikationsunterschiede.

F&S verkauft Schulung statt Dokumentation. Qt-, LVGL- und Secure-Boot-Workshops sind ein reales Angebot für ein Team, das sein erstes Linux-Produkt baut — ersetzen aber kein veröffentlichtes BSP.

Die größte offene Frage: NPU-Software

Sieben Module im Vergleich können mit einer NPU bestückt werden — bei fünf davon hängt das an der konkreten Teilenummer, und Geniatech nennt den Beschleuniger nicht einmal namentlich (nur „256 MAC/Takt“). Genau ein Anbieter nennt NXP eIQ, und kein einziger dokumentiert den Ethos-Treiberstack oder einen Workflow zur Modellkonvertierung. Wer On-Device-Inferenz ins Zentrum des Produkts stellt, hat hier die größte Lücke im gesamten Vergleich — und sollte sie vor der Modulauswahl schließen, nicht danach.

Die Integration eines solchen Stacks — von der BSP-Anpassung bis zur Modellkonvertierung — gehört in die Firmwareentwicklung.

Langzeitverfügbarkeit und CRA: die eigentliche Risikofrage

Zwei der neun Anbieter nennen ein datiertes Verfügbarkeitsende. F&S sichert die Verfügbarkeit bis 2039 zu. Toradex nennt für OSM und Lino eine Verfügbarkeit bis 2038 und einen garantierten Lebenszyklus von mehr als 15 Jahren (Toradex; unabhängig bestätigt bei CNX Software, beide abgerufen am 26.07.2026). Die übrigen sieben veröffentlichen in den ausgewerteten Unterlagen kein Longevity-Programm, keine EOL-Richtlinie und kein Verfügbarkeitsdatum.

Für ein Industrieprodukt mit zehn Jahren Feldlaufzeit ist das eine direkte Frage an jeden Anbieter — und zwar schriftlich.

Noch schärfer wird es beim Thema Sicherheitsupdates. Kein Anbieter im Vergleich nennt eine Support-Dauer für Software. Wo Longevity-Aussagen existieren, betreffen sie die Hardware-Verfügbarkeit, nicht die Versorgung mit Sicherheitsupdates. Das kollidiert mit dem Fahrplan des Cyber Resilience Act:

Quellen: Verordnung (EU) 2024/2847 — die beiden Hauptfristen bestätigt die Europäische Kommission („die wichtigsten … Verpflichtungen gelten ab dem 11. Dezember 2027, wobei die Berichtspflichten ab dem 11. September 2026 gelten“); die Frist für Konformitätsbewertungsstellen sowie die Einordnung der Übergangsregeln nach White & Case. Beide abgerufen am 26.07.2026. Produkte, die vor dem 11.12.2027 rechtmäßig in Verkehr gebracht wurden, sind grundsätzlich ausgenommen — solange sie danach keine „wesentliche Änderung“ erfahren.

Praktisch heißt das: Die Pflicht, Schwachstellen zu behandeln, liegt beim Hersteller des Endgeräts, aber die Fähigkeit dazu hängt am BSP des Modulanbieters. Genau hier ist die EdgeLock Secure Enclave beider SoCs relevant — sie liefert Root of Trust, Schlüsselverwaltung und Secure Boot als Hardwarebasis. Sie ersetzt aber keinen Anbieter, der über Jahre Patches liefert.

Deshalb gehört in jede Anfrage: Wie lange liefern Sie Sicherheitsupdates für dieses BSP, und in welcher Kadenz?

Wie sich Secure Boot, SBOM und Schwachstellenmanagement in ein Produkt einziehen lassen, behandeln wir unter Produkt-Security.

Carrier-Design und Thermik

Weil das Modul gelötet und nicht entnehmbar ist, verschiebt OSM Risiko nach vorn — ins Carrier-Design und in die Fertigung. Ein Footprint-Fehler, ein unzureichender Wärmepfad oder ein falsches Reflow-Profil fällt spät auf und ist dann teuer.

Das beste Material dafür stammt von F&S: Carrier-Footprint und Pad-Design, Schablone und Paste, Abstandshalter, Routing und Impedanzen, Signalgruppierung und Leistungsverteilung — zusammen mit Cadence- und Altium-Symbolen, PCB-Footprints und 3D-STEP-Modellen. Die Leitlinien sind größtenteils herstellerneutral.

Zwei Details aus der Auswertung, die in der Planung stören können:

• Das Designdatenpaket enthält 3D-Modelle für die i.MX-8M-Mini-, 8M-Plus-, 8ULP- und i.MX-93-Varianten — aber kein Modell für den i.MX 91, obwohl der Anbieter ein i.MX-91-Modul verkauft.
• Ein Reflow-Profil-Dokument liegt als reines Bild-PDF ohne Textebene vor. Es ist damit nicht durchsuchbar, nicht maschinell prüfbar und in einem Fertigungsfreigabe-Prozess unangenehm zu handhaben.

Wer ein eigenes Carrier-Board plant, sollte das Designdatenpaket und das Reflow-Profil vor der Modulentscheidung anfordern und prüfen, ob die benötigte Variante enthalten ist.

Footprint, Lagenaufbau, Impedanzen und Reflow-Prozess für ein solches Carrier-Board fallen in das Leiterplattendesign.

Empfehlung nach Anwendungsfall

Kurzregel: Wählen Sie nach dem, was Ihr Projekt am wahrscheinlichsten aufhält — nicht nach Taktfrequenz.

• Eigenes Carrier-Board von Null → F&S Elektronik. Kein anderer Anbieter liefert CAD-Bibliotheken, 3D-Modelle, einen Implementierungsleitfaden und eine Kühllösung zusammen. Dazu die längste datierte Verfügbarkeit (2039).
• Schnellster Weg zum lauffähigen Prototyp → Geniatech. Modul, Carrier und ein dokumentiertes Yocto-BSP auf einer benannten NXP-Basis, plus real gemessene Leistungswerte.
• Reguliertes oder sicherheitskritisches Produkt → Ezurio. Schwachstellen-Monitoring gegen die eigene SBOM, Remediation, Signierdienst, geplantes FIPS 140-3. Im Vergleich einzigartig.
• OTA-Updates und CRA-Nachweis im Zentrum → Toradex. Torizon OS mit Cloud-Anbindung, Verfügbarkeit bis 2038, ausdrücklich auf CRA-Konformität ausgerichtet.
• Maximale I/O-Reserve → die beiden Size-L-Module (45 × 45 mm, bis zu 662 Kontakte laut Größenklasse) von Advantech und iWave.
• Größte SoC-Variantenauswahl auf einem Footprint → TRIA, mit sechs dokumentierten i.MX-93- und zwei i.MX-91-Varianten.

Zwei Warnhinweise zur Bestellbarkeit: Bei einem Modul enthält die Bestelltabelle ausschließlich Vorserien-Teilenummern und kein einziges bestellbares i.MX-91-Teil, obwohl die Familie so vermarktet wird. Bei einem weiteren sind alle sieben Bestellmodelle als „TBD“ gelistet. Beide sind Design-in-Kandidaten, keine kaufbaren Teile — das ist vor der Stücklistenfreigabe zu klären.

Öffentliche Preise sind in diesem Marktsegment selten. Für die Toradex-Module sind sie dokumentiert: 25,55 US-Dollar für das OSM iMX91 und 28,20 US-Dollar für das OSM iMX93 im Mengenbezug (CNX Software, 31.03.2026). Sie geben eine Vorstellung von der Größenordnung; verbindliche Preise nennen die Anbieter projektbezogen.

Fragen, die Sie jedem Anbieter stellen sollten

Diese Liste ergibt sich unmittelbar aus den Lücken der ausgewerteten Unterlagen. Sie lässt sich als Anfrage-Vorlage verwenden:

1. Welche exakte i.MX-Teilenummer bestücken Sie? (Entscheidet über NPU, Kernzahl und Takt.)
2. Wie viele der 332 bzw. 662 Kontakte sind belegt, und weicht ein Signal von der OSM-Definition ab?
3. Auf welche OSM-Revision ist das Modul ausgelegt — 1.1 oder 1.2?
4. Wie hoch ist die Leistungsaufnahme bei Idle und Vollast, gemessen, mit Angabe des Lastszenarios?
5. Bis wann ist das Modul verfügbar, und existiert eine schriftliche EOL-Richtlinie?
6. Wie lange liefern Sie Sicherheitsupdates für das BSP, in welcher Kadenz, und wie werden sie bereitgestellt?
7. Welche Yocto- und Kernel-Version ist die aktuelle Basis, und welche NXP-Release-Distro liegt darunter?
8. Existiert ein BSP-Handbuch und ein dokumentiertes Carrier-Board?
9. Enthält das Designdatenpaket die von uns benötigte Variante — inklusive 3D-Modell und Reflow-Profil als prüfbares Dokument?
10. Bei NPU-Nutzung: Welcher Ethos-U-Treiberstack ist integriert, und existiert ein dokumentierter Workflow zur Modellkonvertierung?

Häufige Fragen

Sind OSM-Module verschiedener Hersteller austauschbar?

Auf Spezifikationsebene ist die Grundlage gegeben: OSM definiert ein einheitliches Pinout, und die SGET erklärt OSM 1.2 als voll kompatibel zu 1.1-Modulen. In der Praxis reicht das nicht. Die Hersteller belegen unterschiedlich viele Kontakte, mehrere nennen ihre Kontaktzahl nicht, und mindestens einer invertiert ein Steuersignal gegenüber dem Standard. Ein Pin-für-Pin-Abgleich der konkreten Kandidaten bleibt unverzichtbar.

Lohnt sich der i.MX 91 gegenüber dem i.MX 93?

Nur wenn Sie sicher kein Display über DSI oder LVDS, keine Kamera, keine NPU und keinen Cortex-M33 benötigen. Der i.MX 91 behält EdgeLock Secure Enclave und TSN-Ethernet — das ist der Grund, ihn einem echten Low-End-Baustein vorzuziehen. Wer bei einem der genannten Punkte unsicher ist, sollte den i.MX 93 nehmen: Vier Anbieter führen beide SoCs auf demselben Size-S-Footprint, was einen späteren Wechsel ohne Carrier-Respin erlaubt.

Kann ich auf diesen Modulen eine 3D-Oberfläche darstellen?

Nein. Weder der i.MX 91 noch der i.MX 93 besitzen eine 3D-GPU; der i.MX 93 hat lediglich eine 2D-PXP-Engine. Für OpenGL-ES-Lasten oder GPU-Compute ist eine andere i.MX-Familie erforderlich. Zweidimensionale Bedienoberflächen, etwa mit LVGL oder Qt über den Framebuffer, sind auf dem i.MX 93 dagegen üblich.

Wie viel Rechenleistung liefert die NPU wirklich?

Die Arm Ethos-U65 im i.MX 93 leistet 0,5 TOPS bei bis zu 1 GHz. Sie sitzt allerdings nur auf den -5x-Teilen (i.MX 9352, 9351). Ein i.MX 9332 oder 9331 hat keine NPU. Da mehrere Anbieter die bestückte Teilenummer nicht nennen, ist die NPU-Verfügbarkeit vor der Auswahl zu bestätigen.

Warum ist die Nicht-Entnehmbarkeit ein Kostenfaktor?

Ein reflow-gelötetes Modul lässt sich nicht wie ein gestecktes tauschen. Das betrifft drei Phasen: Prototypen-Iteration wird langsamer, Rework in der Fertigung erfordert Ausrüstung und Prozessfreigabe, und ein Feldtausch des Moduls allein ist praktisch ausgeschlossen — im Servicefall wird die Baugruppe getauscht. Dem gegenüber stehen entfallende Steckverbinderkosten, geringere Bauhöhe und höhere Schock- und Vibrationsfestigkeit.

Fazit

Der Markt für OSM-Module auf i.MX 91 und i.MX 93 ist technisch enger, als die Anbieterzahl vermuten lässt. Dreizehn Module, neun Anbieter — und im Kern dasselbe Silizium mit maximal 2 GB RAM, bei zehn von zwölf OSM-Modulen auf denselben 30 × 30 mm.

Was bleibt, sind drei Fragen, die kein Datenblatt vollständig beantwortet:

• Wer dokumentiert so, dass Sie das Modul vor dem Kauf bewerten können? Ein Anbieter liefert ein BSP-Handbuch, drei ein dokumentiertes Carrier-Board.
• Wer bindet sich an ein Datum? Zwei von neun nennen ein Verfügbarkeitsende — 2038 und 2039.
• Wer versorgt Sie mit Sicherheitsupdates, solange Ihr Produkt im Feld ist? Darauf antwortet in den ausgewerteten Unterlagen niemand mit einer Zahl. Angesichts der CRA-Fristen ab September 2026 ist das die teuerste offene Frage im gesamten Vergleich.

Standardisierte Formfaktoren senken die Qualifizierungskosten — aber nur für den, der die richtigen Fragen vor der Designfreigabe stellt.

Nutzen Sie den Fragenkatalog aus dem Abschnitt „Fragen, die Sie jedem Anbieter stellen sollten“ als Anfrage-Vorlage für Ihre Shortlist. Zehn Fragen, schriftlich gestellt, trennen die Anbieter schneller als jeder Datenblattvergleich. Wenn Sie die Auswahl oder das Carrier-Design nicht allein durchziehen möchten: sprechen Sie uns zur Modulauswahl an.

Weitere Fachbeiträge finden Sie im Teleconnect-Blog.

Methodik und Quellen

Dieser Vergleich beruht auf der vollständigen Auswertung von 32 Herstellerdokumenten zu 13 Modulen von neun Anbietern: Datenblätter, User Guides, Design- und Implementierungsleitfäden, Schaltpläne, IO-MUX-Tabellen, BSP-Handbücher und Zertifikate. Vier Regeln haben die Auswertung geleitet:

1. „Nicht angegeben“ ist ein Ergebnis. Wo ein Hersteller eine Zahl nicht veröffentlicht, steht das so — statt eines Schätzwerts oder einer Angabe aus anderer Quelle.
2. Widersprüche werden festgehalten, nicht geglättet. Wo zwei Dokumente desselben Herstellers sich widersprechen, sind beide Lesarten vermerkt.
3. Der Dokumentenstatus ist Teil des Befundes. PRELIMINARY-, DRAFT- und Broschürenstatus sind mit erfasst.
4. Bei kritisch bewerteten Punkten werden Anbieter nicht namentlich genannt. Positive Befunde sind namentlich zugeordnet, Lücken kategorisch beschrieben.

Die OSM-Spezifikation selbst liegt der Auswertung nicht zugrunde; Angaben zum Standard und zu den Revisionen 1.1 und 1.2 stammen aus den öffentlichen Veröffentlichungen der SGET. Externe Quellen sind im Text mit Abrufdatum verlinkt.

Stand: 26. Juli 2026. Datenblätter dieser Modulgeneration ändern sich häufig — prüfen Sie vor einer Designentscheidung die aktuelle Revision beim Hersteller.