Electronics

The changing role of lighting shows in the industry's new technologies. Today's lamps do more than run low beam, high beam, position, and turn-signal functions. ADB, matrix lighting, pixel lighting, dynamic lighting, welcome and goodbye animations, and digital rear lighting have widened what a lamp does towards programmable, multi-purpose systems.

In this structure, software directly affects how the light behaves. Beam patterns can change, the number of controllable points can grow, new lighting scenarios can be defined, and lighting can link more closely with other vehicle functions. The value of a lighting system can no longer be described only by light intensity, LED efficiency, or styling. Processing capability, resolution, control architecture, communication, and software extensibility are becoming part of the product's definition.

One clear sign of this change is how lighting control is organised. In distributed architectures, each function or group of functions can be controlled by its own ECU. As functions multiply, that approach needs more controllers, more communication, and often more wiring. The industry's move to domain, centralised, and zone-oriented architectures is changing the pattern.

In lighting, the light domain controller is an example of this direction: some lighting functions, instead of sitting in a set of fully independent controllers, can be managed within a more unified computing architecture. This does not mean every dedicated ECU disappears at once. The industry will live with hybrid architectures for some time, and the choice of architecture still depends on cost, performance, safety, networking, packaging, and project requirements. But the direction is clear: lighting is moving closer to the vehicle's main computing and communication architecture.

This has a direct effect on hardware design. When a lighting controller becomes part of a larger computing architecture, communication interfaces, processing resources, memory, timing, diagnostics, thermal design, and EMC are no longer separate from the system architecture.

In older architectures, software was developed mainly to control existing hardware. After production, a product's behaviour stayed largely fixed, and major changes came with a new generation of hardware. In a software-defined architecture that relationship is changing: software can change how a function behaves, add a new capability, offer a different user experience, or extend part of the system after production.

From this angle, the idea of Software as a Product (SaaP) becomes important. Software is no longer just a line in the technical BOM of an ECU; it is part of the product's value and of its development plan over its life cycle. Product development no longer ends at SOP.

Software-defined lighting is part of the larger shift to the software-defined vehicle (SDV). In traditional vehicles, most capabilities were fixed at design and production. In an SDV, the architecture moves towards a structure in which some capabilities can be developed over the vehicle's life, and lighting is on the same path. This matters most for functions such as dynamic lighting, animation, personalisation, digital lighting, and some communication features.

The idea of feature development is changing as a result: it no longer necessarily ends at SOP and can extend into the product's life cycle. ISO 24089:2023, Road vehicles: Software update engineering, was written for exactly this situation. It sets requirements and recommendations for software update engineering at organisation and project level, and for vehicles, systems, ECUs, and the deployment of update packages. It received Amendment 1 in 2024. Software updates are no longer a side feature of vehicle architecture; they are part of the engineering life cycle.

While architecture becomes software-defined, lighting technology itself is changing too. If multi-channel LEDs and matrix lighting were a step towards segmented control of light, MicroLED and high-resolution lighting are the next step.

More pixels allow more precise control of light distribution and enable functions such as ADB, projection, dynamic lighting, and more complex light patterns. But higher resolution is not just an optical advance. As the pixel count grows, so do data volume, control channels, processing needs, communication, timing management, and software requirements. High-resolution lighting naturally becomes tied to computing and software, and greater optical capability can lead to a considerable increase in engineering complexity.

Adaptive Driving Beam is one of the clearest examples of this change. In early generations, ADB was mainly an advanced lighting function. As segments and then pixels multiplied, deciding the beam pattern became a more complex computing problem. In high-resolution systems, lighting must control a finer light field and respond at the right moment to information about the surroundings and the state of the vehicle.

ADB development is moving from controlling a few light sources towards processing and managing a digital light field, and the same change blurs the lines between lighting, sensing, ADAS, and computing.

A notable industry trend is lighting moving closer to driver assistance systems. The headlamp is no longer necessarily a fully independent system for producing a beam pattern. Information about the surroundings, the road, oncoming vehicles, and driving conditions can play a part in deciding the light pattern. Vehicle architecture is also moving towards shared processing, network, and data resources. The future of lighting cannot be imagined entirely apart from sensing and ADAS.

This convergence carries an important engineering point. The more lighting functions depend on information from other systems, the more system dependencies, validation, and failure-mode management matter. A software change in the logic that decides the light pattern is no longer necessarily an internal change to the lamp ECU; it can affect system interfaces, function behaviour, and validation scenarios. This is one of the key differences between a traditional lighting ECU and a lighting function in a software-defined architecture.

The change is not limited to headlamps. Rear lighting is moving from the traditional stop, tail, and turn pattern towards digital light surfaces, animation, and visual communication. In this structure, the vehicle's lit surfaces can be part of its digital design and user experience as well as meeting regulatory and functional requirements.

Smaller pixels and more segmented control make more complex light patterns possible and push rear lighting towards something closer to a digital display. The lamp is no longer only a way of producing light; it can become a visual interface between the vehicle and its surroundings.

One of the most important consequences of software-defined lighting is a new idea of the product life cycle. If lighting functions can be developed through software, a software update is no longer just a repair or correction; it becomes part of product life-cycle management. Topics such as OTA, configuration management, version management, diagnostics, and cybersecurity move closer to the product architecture.

ISO 24089 treats software update engineering as an organised activity across the vehicle's life cycle, and UN Regulation No. 156 sets a framework for the software update management system and requirements for vehicles that can be updated. The message for lighting is clear: if a lamp can change after sale, the life cycle of its functions no longer ends when hardware production ends.

The closer lighting gets to the vehicle network, software updates, and central architecture, the more cybersecurity matters to it. Not every lighting function carries the same level of risk, but more connectivity and updatability bring the lamp into a chain of software and communication that has to be managed securely. Cybersecurity is no longer limited to infotainment or the gateway.

Depending on their connectivity, architecture, and update capability, lighting ECUs will become part of this engineering space. In a software-defined architecture, security has to be designed into the architecture and the software life cycle from the start, not added once the product is finished.

New architectures can aim for fewer ECUs, less wiring, more hardware reuse, and scalable platforms. At the same time, the complexity of software, integration, configuration, validation, cybersecurity, and version management grows. Some of the complexity that used to show up in the number of hardware parts and ECUs may move into software and architecture.

This matters especially in lighting, because more pixels, more functions, and updatability multiply the number of system states that need checking. Validation is no longer only about checking light output in a few defined states; a function's behaviour must be managed and assessed in combination with the software version, vehicle configuration, network conditions, and different scenarios. Less hardware should not be mistaken for less importance of reliability either: even if some capabilities move to software, the driver, power stage, PCB, thermal design, EMC, interconnects, and power supply still determine how reliable the product is.

Software-defined lighting does not necessarily mean less complexity. It means a change in where complexity sits, what kind it is, and how it is spread through the system.

As software and computing matter more in the lamp, it can seem that hardware's share will shrink. In practice that is not accurate. A software-defined lighting platform still needs hardware that performs reliably under temperature, vibration, humidity, voltage transients, EMC, ESD, and the long-term stresses of the vehicle environment. More processing can even add pressure: higher power consumption, greater heat density, more interconnects, more complex PCBs, and more sensitivity to thermal cycling.

Reliability in software-defined lighting is therefore not limited to software reliability. A product's real reliability comes from the interaction of hardware, software, thermal, electrical, mechanical, and architectural factors. This matters even more in high-resolution lamps, where the number of controllable parts and the dependencies between them grow. In such an architecture a component failure may not only lose one light source; it may affect part of a function, a pixel group, a communication path, or even the behaviour of the whole system. Reliability engineering has to develop together with the product architecture.

Put today's industry trends side by side and several of them clearly point the same way. None of them creates software-defined lighting on its own, but together they give a clear picture of where the industry is heading. The lamp of the future will not just be a set of LEDs and drivers with a separate ECU; it will be part of a computing, communication, and extensible system within the vehicle architecture.

This does not mean hardware goes away. On the contrary, the more software capability grows, the more the quality of hardware, power electronics, thermal design, EMC, manufacturing, and reliability matters. What changes is the role these parts play in the product architecture.

From an engineering point of view, the most important change in software-defined lighting is not simply that software has entered the lamp; it is that the definition of the product itself changes. In the past we could define a lamp mainly as an optical, electrical, and electronic assembly with defined functions. In the new architecture the product has to be seen in several layers at once: hardware, software, communication, computing, thermal, EMC, reliability, and validation.

Lighting design can no longer be done entirely apart from the vehicle's E/E architecture. When a lighting function depends on the network, a domain controller, ADAS, software updates, or other computing resources in the vehicle, the line between component design and system design gets thinner. At the same time, being software-defined must not push hardware engineering to the margins: excellent software on hardware that is not stable in real vehicle conditions does not make a dependable product.

In our view, the future of lighting is not software instead of hardware but software alongside hardware, within one integrated architecture in which design, validation, and reliability are considered together from the start. For the lighting industry this is not only a technological change but a change in how products are defined, developed, validated, and managed over their life. In the coming years, competition in lighting will not be only about LED efficiency, light intensity, or styling; software extensibility, resolution, architectural flexibility, processing power, interaction with other vehicle systems, updatability, cybersecurity, and reliability will be part of the product's real value.

Vehicle lighting is moving beyond a period focused mainly on electronic control of light sources and better optical performance. The industry is heading towards a structure in which light, software, computing, communication, and vehicle architecture come closer together. Light domain controllers, Software as a Product, MicroLED, high-resolution ADB, digital rear lighting, and software updates each show part of this change.

The trend creates new possibilities for safety, design, and interaction, and at the same time makes the architecture, development, validation, cybersecurity, and reliability of lighting products more complex. The future of lighting cannot be summed up as more LEDs and smarter controllers. The industry is moving from electronic lighting to software-defined lighting, and from a lighting module to a lighting platform in the vehicle architecture of the future. Perhaps the key point is this: the lamp of the future is not just something that produces light, but part of a system that can extend its capabilities over the life of the vehicle.