Viele Lichtpunkte, verteilte Sensoren und zentrale Fahrzeugcomputer stellen neue Anforderungen an die sogenannte letzte Meile im Fahrzeugnetzwerk. Das Open System Protocol soll LEDs, I²C-Komponenten und weitere Aktuatoren über eine gemeinsame, kostengünstige Schnittstelle anbinden.
Open System Protocol: Das Konzept eines Fahrzeuginnenraums mit verteilter, dynamischer RGB-Beleuchtung.
(Bild: AMS Osram)
Im Gegensatz zu konventionellen Fahrzeugarchitekturen mit einer großen Zahl verteilter Steuergeräte (Electronic Control Units) setzen moderne Architekturen zunehmend auf zentralisierte Steuergeräte. Dadurch lassen sich softwaredefinierte Funktionen und Softwareupdates einfacher realisieren; zugleich kann die Komplexität der Softwarelandschaft im Fahrzeug reduziert werden.
Die zentralisierten Steuergeräte sind über ein Netzwerk-Backbone verbunden, meist über Ethernet-Netzwerke mit hoher Datenrate. Einzelne Sensoren oder Aktuatoren, beispielsweise ein Drehratensensor, ein Elektromotor oder Leuchtdioden mit zugehörigem Treiber, können aus Kostengründen jedoch nicht jeweils mit einer Ethernet-Schnittstelle ausgestattet werden. Dafür wären unter anderem ein Ethernet-Transceiver, ein Mikrocontroller und ein Netzwerk-Stack erforderlich. Daher müssen die über Ethernet verfügbaren Fahrzeugdaten in den jeweiligen Steuergeräten oder Netzwerkverteilern, den sogenannten Zone Controllern, auf angepasste und kostengünstige Schnittstellen für die sogenannte letzte Meile umgesetzt werden. Gemeint ist damit die Verbindung vom Fahrzeugnetzwerk zu einer einzelnen Komponente oder zu einer kleinen Gruppe von Komponenten.
Bisherige Automotive-Schnittstellen wie LIN oder CAN werden häufig für diese „letzte Meile“ eingesetzt. Für neue und anspruchsvollere Anwendungen im Fahrzeug sind sie jedoch nur bedingt geeignet – etwa wegen der begrenzten Datenrate, der begrenzten Zahl adressierbarer Komponenten oder des erforderlichen lokalen Mikrocontrollers für die Kommunikationssteuerung
Eine dynamische Innenraumbeleuchtung und die Fahrzeugelektronik
Bild 1: OSP-Daisy-Chain-Topologie mit Single-ended-Kommunikation zwischen Mikrocontroller und erstem OSP-Gerät sowie LVDS-Kommunikation zwischen den weiteren OSP-Geräten. Bei der Initialisierung erfolgt eine automatische Adressierung: Ein INIT-Telegramm wird an das jeweils nächste OSP-Gerät weitergegeben, das die Geräteadresse erhöht.
(Bild: AMS Osram)
Ein Beispiel für eine weiterentwickelte Fahrzeuganwendung mit neuen Anforderungen an die Datenschnittstellen ist die Innenraum- oder Ambientebeleuchtung. In der Vergangenheit handelte es sich dabei meist um eine funktionale Anwendung mit wenigen Lichtpunkten.
Auch aufgrund der Möglichkeiten moderner LED-Technik ist die Innenraumbeleuchtung heute ein Faktor für Komfort und Markendifferenzierung. An die Anwendung werden unter anderem folgende Anforderungen gestellt:
eine hohe Zahl an Lichtpunkten,
die Abdeckung eines großen Bereichs des RGB-Spektrums, teilweise ergänzt um weiße Emitter,
eine hohe absolute und relative Farbtreue zwischen den einzelnen Lichtpunkten unter verschiedenen Umgebungs- und insbesondere Temperaturbedingungen,
die dynamische Variation der Beleuchtungsparameter in Echtzeit, beispielsweise von Helligkeit oder Farbton, synchronisiert über den gesamten Fahrzeuginnenraum.
Bisherige Datenschnittstellen wie LIN oder CAN können diese Anforderungen nur mit zusätzlichem Aufwand abdecken. So reicht die verfügbare Datenrate von LIN möglicherweise nicht aus, um eine größere Zahl von Lichtpunkten anzusteuern. Eine Aufteilung auf mehrere LIN-Busse erfordert dann zusätzliche Hardware- und Softwareebenen und erschwert die zeitliche Synchronisation.
CAN und Ethernet können bei Anwendungen mit teilweise mehreren hundert einzelnen Lichtpunkten aufgrund der erforderlichen Hardware und Software ebenfalls mit erhöhtem Aufwand verbunden sein. Daneben gibt es proprietäre Lösungen, die bestimmte Bauelemente und damit möglicherweise auch eine bestimmte Lieferkette voraussetzen.
Das Open System Protocol (OSP)
Bild 2: OSP-Topologie mit Loop-Back. Das letzte OSP-Gerät ist mit einem zweiten I/O des Mikrocontrollers verbunden. Dies kann die Ausfallsicherheit erhöhen und insbesondere bei langen Ketten die Antwortzeiten verkürzen.
(Bild: AMS Osram)
Eine Schnittstelle für diese Anwendung ist das von AMS Osram entwickelte Open System Protocol oder kurz OSP. Dabei handelt es sich um ein Interface-Standard, dessen Spezifikation offen verfügbar ist und der zur Standardisierung bei der ISO eingebracht wurde.
OSP arbeitet als Commander-Responder-Schnittstelle in einer Daisy-Chain-Topologie. Die Komponenten sind dabei über ein störunempfindliches, LVDS-basiertes Interface miteinander verbunden. Der zentrale Controller sendet Befehle in Form von Telegrammen an die erste Komponente der Kette. Stimmt die Zieladresse im Telegramm mit der Adresse dieser Komponente überein, führt sie den Befehl aus. Andernfalls leitet sie das Telegramm an die nachfolgende Komponente weiter. Eine Antwort der Zielkomponente wird über die Kette an den Controller zurückübertragen.
Die Daisy-Chain-Topologie ermöglicht auch eine automatische Adressierung bei der Initialisierung des OSP-Systems. Dazu wird die jeweilige OSP-Adresse von einer Komponente an die nächste weitergegeben und dort inkrementiert. Für die Anwendung als Lichtbus werden unter anderem RGB-LEDs mit integriertem OSP-kompatiblem Treiber eingesetzt.
Bild 3: Einsatz von CAN-FD-Transceivern zur Überbrückung größerer Distanzen, beispielsweise zwischen zwei separaten Leiterplatten.
(Bild: AMS Osram)
Neben einer Kette mit einem Terminator am letzten Element ist auch eine Loop-Back-Topologie möglich. Dabei wird das letzte Element über ein zweites Interface mit dem Controller verbunden. Dadurch kann die Ausfallsicherheit steigen, da jede Komponente prinzipiell aus beiden Richtungen erreichbar ist. Bei langen Ketten kann sich außerdem die Antwortzeit verkürzen, weil Antworttelegramme über den kürzeren Teil der Kette zum Controller zurückgesendet werden können. Nach Angaben des Herstellers lassen sich mit OSP bis zu 1.000 Komponenten in einer Kette adressieren. Beispielsweise können 100 LEDs mit einer Bildwiederholrate von mehr als 100 Hz angesteuert werden. Zur Überbrückung größerer Distanzen kann ein CAN-FD-Transceiver eingesetzt werden. Er dient dabei zur Umsetzung der standardmäßigen LVDS-Physical-Layer von OSP auf eine CAN-FD-Physical-Layer.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel Communications Group GmbH & Co. KG, Max-Planckstr. 7-9, 97082 Würzburg einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von redaktionellen Newslettern nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung, Abschnitt Redaktionelle Newsletter.
RGB-LED mit einem OSP-kompatiblen Treiber
Die CAN-FD-Physical-Layer ermöglicht außerdem den Aufbau einer Stern-Topologie. Dazu werden an einen CAN-FD-Strang mehrere Subnetze mit jeweils einem eigenen Transceiver angebunden. Über Stand-alone-Treiber wird am Beginn jedes Subnetzes eine Subnetzadresse definiert. Die nachfolgenden Komponenten erhalten bei der Initialisierung automatisch eine Adresse.
Eine mögliche Standardkomponente für OSP-Netzwerke ist eine RGB-LED mit integriertem OSP-kompatiblem Treiber, die ohne weitere externe Bauteile in eine Kette integriert werden kann. Da die Kalibrierdaten jeder einzelnen LED bereits im Treiber hinterlegt sind, kann eine nachträgliche Farbvermessung und Kalibrierung im Fertigungsprozess entfallen.
Um LEDs mit anderen Farben oder Bauformen über OSP anzusteuern, können Stand-alone-Treiber eingesetzt werden. Sie erlauben den Anschluss von bis zu neun einzelnen LEDs oder drei RGB-LEDs. Beispiele sind spezielle Bauformen wie RGB-Seitenemitter, LEDs mit besonderen Farben oder LEDs mit unterschiedlichen Weißtönen.
Beim Chipdesign und beim Pinout wurde nach Angaben des Herstellers darauf geachtet, dass keine mehrlagige Leiterplatte erforderlich ist. Dies kann gegenüber Lösungen mit mehrlagigen Leiterplatten den Leiterplattenaufwand reduzieren und die Integration in flexible Leiterplatten erleichtern.
Verteilte Sensoren und Aktuatoren mit OSP
Bild 4: Stand-alone-Treiber für OSP zur Ansteuerung beliebiger LEDs und zur Anbindung von I²C-Komponenten. Diese lassen sich über OSP steuern und auslesen.
(Bild: AMS Osram)
OSP lässt sich nicht nur als Lichtbus nutzen. Zusätzlich zur LED-Ansteuerung besitzen die Stand-alone-Treiber eine weitere Funktion, die die Einsatzmöglichkeiten des Interfaces erweitert: Pro Treiber lassen sich drei LED-Ansteuerleitungen gemeinsam als I²C-Schnittstelle mit Taktleitung (SCL), Datenleitung (SDA) und Interrupt-Leitung (INT) konfigurieren.
Damit können I²C-Komponenten ohne zwischengeschalteten Mikrocontroller in eine OSP-Kette integriert werden. Verteilte Sensoren oder Aktuatoren lassen sich so dort unterbringen, wo bereits ein OSP-Interface in der Nähe vorhanden ist. Zusätzliche Leitungen zu einem lokalen Mikrocontroller sind in diesem Fall nicht erforderlich.
Beispiele für die Integration von I²C-Komponenten in OSP finden sich im OSP Evaluation Kit, das bei verschiedenen Elektronik-Distributoren erhältlich ist. Neben I²C-EEPROMs zur Speicherung von Farb- und Animationsdaten sowie Temperatur- und Umgebungslichtsensoren enthält das Evaluation Kit Hall-Drehgeber als Positionssensoren. Über I²C-I/O-Expander sind außerdem konventionelle Drucktaster und Signalleuchten angebunden.
Eine mögliche Anwendung ist die Erfassung von Temperaturen an mehreren Stellen im Fahrzeuginnenraum, um die Klimaregelung zu unterstützen. Licht- und Farbsensoren können dazu dienen, Innenraumbeleuchtung und Displays an die Umgebungshelligkeit und die jeweilige Beleuchtungssituation anzupassen.
Die Komponenten lassen sich in der OSP-Kette mit RGB-LEDs kombinieren. Dank der automatischen Adressierung bei der Initialisierung werden sowohl den LEDs als auch den Stand-alone-Treibern mit ihrem I²C-Interface selbstständig OSP-Adressen zugewiesen. Softwarebeispiele für die allgemeine Nutzung von OSP und für die Integration von I²C-Komponenten mit OSP stellt AMS Osram auf GitHub bereit.
Anbindung an das Fahrzeugnetzwerk
Bild 5: Anbindung von OSP an das Ethernet-Fahrzeugnetzwerk über einen Ethernet-Endpoint.
(Bild: AMS Osram)
OSP bietet nicht nur auf der Komponentenseite Möglichkeiten zur Ansteuerung. Da moderne Fahrzeugarchitekturen häufig auf einem Ethernet-Backbone basieren, ist auch eine Schnittstelle zwischen Ethernet und OSP von praktischer Bedeutung. Zudem kann OSP über ein lokales Steuergerät oder einen Zone Controller mit Automotive-Mikrocontroller angebunden werden. Eine weitere Möglichkeit ist der Einsatz sogenannter Ethernet-Endpoints. Dabei handelt es sich um kleine, fest programmierte Bausteine, die auf der einen Seite eine Ethernet-Schnittstelle für die Verbindung mit dem Fahrzeugnetzwerk und auf der anderen Seite ein oder mehrere lokale Last-Mile-Interfaces bereitstellen.
Über ein Remote-Control-Protokoll, beispielsweise IEEE 1722, lassen sich Daten von und zu den lokalen Interfaces in Ethernet-Pakete kapseln. Die lokalen Interfaces können so über das Fahrzeugnetzwerk mit einer zentralisierten Recheneinheit verbunden werden.
Das ist insbesondere im Zusammenhang mit dem Ethernet-Standard 10BASE-T1S von Interesse. Der Standard ermöglicht Ethernet-Verbindungen über eine Zweidrahtleitung und kann damit den Einsatz von Ethernet innerhalb des Fahrzeugs unterstützen. Mehrere Hersteller von Mikrocontrollern und Ethernet-Endpoints haben nach Angaben von AMS Osram bereits Produkte für die Verbindung mit OSP vorbereitet. Eine Liste dieser Produkte ist auf den OSP-Webseiten des Herstellers verfügbar.
Anwendungen für die Fahrzeugaußenbeleuchtung
Bild 6: Dynamische Fahrzeugaußenbeleuchtung mit OSP.
(Bild: AMS Osram)
Künftige Ergänzungen und Weiterentwicklungen von OSP könnten auch Anwendungen in der Fahrzeugaußenbeleuchtung erschließen. Dazu zählen beispielsweise spezielle, für ASIL-Anforderungen ausgelegte Treiber, die über UART an einen Mikrocontroller oder Endpoint angebunden werden. Neben der konventionellen Signalbeleuchtung sind insbesondere Karosserie- und Grillbeleuchtungen mögliche Anwendungsbereiche. Dazu zählen dynamische Beleuchtungseffekte für die Markenidentität sowie Komfortfunktionen wie Welcome-Animationen.
Eine weitere Anwendung sind sogenannte Intelligent Signal Displays. Sie können zur Kommunikation mit anderen Verkehrsteilnehmern dienen oder dem Fahrer bereits vor dem Einsteigen Informationen wie den Ladezustand der Fahrzeugbatterie anzeigen.
Ausblick
Insbesondere im Automobilumfeld ist die Zuverlässigkeit der Lieferkette entscheidend. Ein offenes und standardisiertes Protokoll kann die Auswahl von Komponenten und Lieferanten erleichtern. OSP wurde nach Angaben von AMS Osram als offenes und herstellerunabhängiges Protokoll entwickelt. Darüber hinaus wird OSP seit Februar 2026 im Rahmen der ISO Working Group ISO/TC 22/SC 31/WG 3 standardisiert, was dabei hilft, das Protokoll im Automobil- und Industrieumfeld zu unterstützen.
OSP ist als offenes Interface für die letzte Meile zwischen zentraler Recheneinheit und verteilten Komponenten ausgelegt. Neben der Beleuchtung lassen sich damit auch Sensoren und Aktuatoren in verteilten Anwendungen anbinden. Die Kombination aus Daisy-Chain-Topologie, automatischer Adressierung und der Möglichkeit, I²C-Komponenten ohne lokalen Mikrocontroller einzubinden, adressiert Anwendungen mit einer größeren Zahl verteilter Komponenten. (heh)
* Florian M. Kolb ist für das Application Business Development bei AMS Osram verantwortlich.