LED and Sensor Integration in Vehicles OSP Combines Lighting, Sensors, and Actuators

Numerous light sources, distributed sensors, and central vehicle computers place new demands on what is known as the “last mile” of the vehicle network. The Open System Protocol is designed to connect LEDs, I²C components, and other actuators via a common, cost-effective interface.

Unlike conventional vehicle architectures, which feature a large number of distributed electronic control units (ECUs), modern architectures are increasingly relying on centralized control units. This makes it easier to implement software-defined functions and software updates, while also reducing the complexity of the vehicle’s software landscape.

The centralized control units are connected via a network backbone, typically through high-speed Ethernet networks. However, for cost reasons, individual sensors or actuators—such as a rotational speed sensor, an electric motor, or light-emitting diodes with their associated drivers—cannot each be equipped with an Ethernet interface. This would require, among other things, an Ethernet transceiver, a microcontroller, and a network stack. Therefore, the vehicle data available via Ethernet must be converted in the respective control units or network distributors—known as zone controllers—into adapted and cost-effective interfaces for the so-called “last mile.” This refers to the connection from the vehicle network to a single component or a small group of components.

Existing automotive interfaces such as LIN or CAN are frequently used for this “last mile.” However, they are only partially suitable for new and more demanding in-vehicle applications—for example, due to their limited data rate, the limited number of addressable components, or the need for a local microcontroller to manage communication.

Dynamic Interior Lighting and the Vehicle's Electronics

One example of an advanced automotive application with new requirements for data interfaces is interior or ambient lighting. In the past, this was typically a functional application with only a few light sources.

Thanks in part to the capabilities of modern LED technology, interior lighting has become a key factor in comfort and brand differentiation. Among other things, the following requirements apply to its use:

• a large number of light sources,
• coverage of a wide range of the RGB spectrum, partially supplemented by white emitters,
• high absolute and relative color consistency among the individual light sources under various environmental conditions—and particularly under different temperature conditions,
• the dynamic, real-time adjustment of lighting parameters—such as brightness or color—synchronized throughout the entire vehicle interior.

Existing data interfaces such as LIN or CAN can only meet these requirements with additional effort. For example, the available data rate of LIN may not be sufficient to control a large number of light points. Distributing the load across multiple LIN buses then requires additional hardware and software layers and complicates temporal synchronization.

CAN and Ethernet can also involve significant effort in applications that sometimes include several hundred individual light points, due to the hardware and software required. In addition, there are proprietary solutions that require specific components and, as a result, may also depend on a specific supply chain.

The Open System Protocol (OSP)

One interface for this application is the Open System Protocol (OSP), developed by AMS Osram. This is an interface standard whose specifications are publicly available and which has been submitted to ISO for standardization.

OSP functions as a commander-responder interface in a daisy-chain topology. The components are connected to one another via an interference-resistant, LVDS-based interface. The central controller sends commands in the form of telegrams to the first component in the chain. If the destination address in the telegram matches the address of that component, it executes the command. Otherwise, it forwards the telegram to the next component in the chain. A response from the target component is transmitted back to the controller via the chain.

The daisy-chain topology also enables automatic addressing during initialization of the OSP system. To achieve this, the respective OSP address is passed from one component to the next, where it is incremented. For use as a light bus, RGB LEDs with integrated OSP-compatible drivers are used, among other components.

In addition to a chain with a terminator on the last element, a loopback topology is also possible. In this configuration, the last element is connected to the controller via a second interface. This can improve reliability, since each component is, in principle, accessible from both directions. In long chains, response time can also be reduced because response telegrams can be sent back to the controller via the shorter section of the chain. According to the manufacturer, OSP can address up to 1,000 components in a chain. For example, 100 LEDs can be driven at a refresh rate of more than 100 Hz. A CAN-FD transceiver can be used to bridge longer distances. It serves to convert the standard LVDS physical layer of OSP to a CAN-FD physical layer.

RGB LED with an OSP-Compatible Driver

The CAN-FD physical layer also allows for the creation of a star topology. To do this, multiple subnets—each with its own transceiver—are connected to a CAN-FD bus. A subnet address is defined at the beginning of each subnet using standalone drivers. The subsequent components are automatically assigned an address during initialization.

One possible standard component for OSP networks is an RGB LED with an integrated OSP-compatible driver that can be incorporated into a chain without any additional external components. Since the calibration data for each individual LED is already stored in the driver, there is no need for subsequent color measurement and calibration during the manufacturing process.

To control LEDs of other colors or types via OSP, standalone drivers can be used. They allow for the connection of up to nine individual LEDs or three RGB LEDs. Examples include special types such as RGB side-emitting LEDs, LEDs with specific colors, or LEDs with different shades of white.

According to the manufacturer, the chip design and pinout were engineered to eliminate the need for a multilayer printed circuit board. Compared to solutions using multilayer printed circuit boards, this can reduce PCB complexity and facilitate integration into flexible printed circuit boards.

Distributed Sensors and Actuators with OSP

OSP can be used for more than just a lighting bus. In addition to LED control, the stand-alone drivers have another feature that expands the interface’s range of applications: For each driver, three LED control lines can be configured together as an I²C interface with a clock line (SCL), a data line (SDA), and an interrupt line (INT).

This allows I²C components to be integrated into an OSP chain without an intermediate microcontroller. Distributed sensors or actuators can thus be placed wherever an OSP interface is already available nearby. In this case, no additional wires to a local microcontroller are required.

Examples of how to integrate I²C components into OSP can be found in the OSP Evaluation Kit, which is available from various electronics distributors. In addition to I²C EEPROMs for storing color and animation data, as well as temperature and ambient light sensors, the Evaluation Kit includes Hall-effect encoders as position sensors. Conventional pushbuttons and indicator lights are also connected via I²C I/O expanders.

One possible application is measuring temperatures at multiple locations inside the vehicle to assist with climate control. Light and color sensors can be used to adjust interior lighting and displays to the ambient brightness and the current lighting conditions.

The components can be combined with RGB LEDs in the OSP chain. Thanks to automatic addressing during initialization, OSP addresses are automatically assigned to both the LEDs and the standalone drivers via their I²C interface. AMS Osram provides software examples on GitHub for general use of OSP and for integrating I²C components with OSP.

Connection to the Vehicle Network

OSP offers control options beyond just the component level. Since modern vehicle architectures are often based on an Ethernet backbone, an interface between Ethernet and OSP is also of practical importance. In addition, OSP can be connected via a local control unit or a zone controller equipped with an automotive microcontroller. Another option is the use of so-called Ethernet endpoints. These are small, fixed-programmed modules that provide an Ethernet interface on one side for connection to the vehicle network and one or more local last-mile interfaces on the other.

Using a remote control protocol, such as IEEE 1722, data can be encapsulated in Ethernet packets to and from the local interfaces. This allows the local interfaces to be connected to a centralized processing unit via the vehicle network.

This is of particular interest in connection with the 10BASE-T1S Ethernet standard. The standard enables Ethernet connections over a two-wire line and can thus support the use of Ethernet within the vehicle. According to AMS Osram, several manufacturers of microcontrollers and Ethernet endpoints have already developed products designed to connect to OSP. A list of these products is available on the manufacturer’s OSP website.

Applications for Exterior Vehicle Lighting

Future additions and enhancements to OSP could also open up applications in exterior vehicle lighting. These include, for example, specialized drivers designed to meet ASIL requirements that are connected to a microcontroller or endpoint via UART. In addition to conventional signal lighting, potential applications include, in particular, body and grille lighting. These include dynamic lighting effects to enhance brand identity, as well as convenience features such as welcome animations.

Another application is what are known as intelligent signal displays. They can be used to communicate with other road users or to show the driver information—such as the vehicle battery’s charge level—even before getting in the car.

Outlook

Supply chain reliability is crucial, particularly in the automotive sector. An open and standardized protocol can simplify the selection of components and suppliers. According to AMS Osram, OSP was developed as an open and vendor-neutral protocol. Furthermore, OSP has been undergoing standardization since February 2026 as part of the ISO Working Group ISO/TC 22/SC 31/WG 3, which helps to promote support for the protocol in the automotive and industrial sectors.

OSP is designed as an open interface for the "last mile" between the central processing unit and distributed components. In addition to lighting, it can also be used to connect sensors and actuators in distributed applications. The combination of daisy-chain topology, automatic addressing, and the ability to integrate I²C components without a local microcontroller addresses applications with a large number of distributed components. 

*Florian M. Kolb is responsible for Application Business Development at AMS Osram