LED- und Sensoranbindung im Fahrzeug OSP verbindet Licht, Sensorik und Aktuatoren

Ein Gastbeitrag von Florian M. Kolb* 7 min Lesedauer

Anbieter zum Thema

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)
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)
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)
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)
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.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

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)
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)
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)
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.

(ID:50947429)