Many aspects of cars can be customised in line with customers’ wishes – and the functions of exterior lighting are no exception. However, while customers might enjoy ability to add a personal touch to their cars, this presents considerable challenges for development and validation. This is because, as the range of customisable functions continues to grow, so too does the amount of software required to facilitate this. Consequently, exterior lighting functions are becoming increasingly networked and complex. Ultimately, automotive exterior lighting has long since evolved past being a design element that improves visibility for drivers. Instead, the significance of exterior lighting systems has grown enormously, especially in the con-text of autonomous driving. It must also provide clear external communication and optimise safety for the driver and other road users. The ASAP Group therefore carries out validation of exterior lighting functions for its customers through scenario-based and keyword-driven testing.
New methods for functional validation of exterior lighting
Evolution of exterior light functions
Dipped headlights, full beam headlights, rear lights and indicators – up until the end of the last century, standard exterior lighting for cars only provided around five or six functions. In modern cars, however, exterior lights provide roughly sixteen top-level functions along with a whole host of sub-functions. These include adaptive front light systems, proximity detection, high-beam assistants and communication lights – to name but a few. This array of new functions was initially made possible through the use of LED technology, which has since completely replaced the xenon technology used in the past. Today, development is moving towards the digitalisation of LED lights, with digital matrix LED technology featuring micromirror systems set to become the new standard in the future. The primary advantage of this new technology is the ability to activate and deactivate LEDs individually, so that lighting can be used selectively. [2] This makes it possible, for example, to adjust high beam headlights very precisely to avoid blinding oncoming road users. [1] New functions – such as lane lights, which precisely illuminate the lane ahead and dynamically react to lane changes – improve safety on the road. [1] Furthermore, the rear lights can be used as a display area for communication with following vehicles, warning them of potential dangers such as a traffic jam coming up ahead. Customisation options also allow drivers to configure individual light signatures, giving their car a lighting design tailored to each driver’s wishes. There is considerable scope to make sensible use of exterior car lighting and develop numerous other functions in the future. This development will be further reinforced by autonomous driving levels 2 and 3, which will add further safety-related exterior lighting functions. A pedestrian crossing projected across the road by the car to indicate that pedestrians should cross is just one potential scenario.
Challenges for validation
New exterior light functions, and especially those relevant for autonomous driving levels 2 and 3, entail numerous challenges for validation. Different countries have a variety of mandatory regulations on exterior lighting. Another difficulty, however, is the fact that new functions are highly interconnected, because control units have to refer to data from numerous sources. This includes navigation data for information on routing, rain sensors, light sensors, radar, cameras and acceleration data. The vehicle’s lighting systems then need to adapt accordingly to all of this information. The numerous sources that influence exterior lighting generate input signals with extremely high information density, which makes the event chains examined in validation extremely complex. In addition to optical assessments (homogeneous light distribution, transitions when lights are activated/deactivated, etc.), ASAP also focuses on signal-based functional validation. It is not possible to provide an exhaustive specification for validation due to the infinite number of potential situations in which static and dynamic objects must be faultlessly identified, with multi-sensor data fusion creating a complete overall image for the light control unit. However, the variable parameters that could be used, for example, to accurately identify a vehicle ahead and trigger appropriate adjustments in exterior lighting functions, include: the size and speed of the vehicle, the angle between the two cars, light conditions, weather, road surface and other objects such as trees and road signs. Evaluating all of these parameters in all conceivable combinations is simply not possible. Conventional testing approaches alone are therefore not sufficient. Instead, it is important to create a virtual test environment for a test bench so that all variables can be examined and validated as fully as possible.
Validating dynamic processes through scenario-based testing
The ASAP Group has therefore adapted scenario-based testing, originally used in relation to ADAS functions, for use in the validation of exterior light functions. By referring to the PEGASUS project, ASAP can conduct effective and efficient testing while simultaneously taking heed of the risks involved. The PEGASUS research project, pursued by OEMs and numerous other partners from the worlds of business and science, aims to establish “generally accepted quality criteria, tools and methods as well as scenarios and situations for the release of highly automated driving functions” [3] and thus accelerate the realisation of autonomous driving. ASAP looked at the results of the PEGASUS research project while adapting scenario-based testing for the validation of exterior lighting functions – and thereby reduced the complexity inherent in validation due to the near-infinite number of possible test cases. Unlike requirements-based testing, which ASAP uses in parallel for static, selective testing, scenario-based testing also makes it possible to test dynamic processes – such as speed changes and various road situations (e.g. approaching motorway slip roads or junctions) with a variable environment (other road users) and many different environmental conditions (rain, snow, fog, etc.). The ASAP specialists responsible for test design specify both the required scenarios and the test cases. When specifying scenarios, they start by defining all static and dynamic objects in a given scenario, such as a nighttime drive with other vehicles travelling in the same and opposite directions. This description comprises detailed information of all environmental data, including the parameter spaces of the defined objects. This includes, for instance, all possible distances and speeds of a vehicle driving ahead. In sum, it describes in principle what should happen in a scenario. By contrast, when specifying test cases, the level of abstraction is far lower. Instead, test drives are set out with specific values for all objects involved in the test case so that, for example, an overtaking manoeuvre described as a scenario can be carried out correctly. Once the driving scenarios and test procedures have been defined, including the expected outcomes (test cases), ASAP then moves on to validate the transmission of data from the control unit to the light source and the communication between the two. This form of validation, an innovation in the context of exterior light validation, offers numerous advantages. For example, it makes it possible to validate a far wider range of test cases than conventional methods and also reduces the work involved in making the necessary changes. Furthermore, this method facilitates time-efficient, cost-effective validation. This is because the restbus simulations used in conventional testing methods require manual specification of all signals and values. Due to the countless parameters and all their potential combinations, a manually configured restbus simulation of exterior light functions simply cannot be completed in a reasonable time frame.
Keyword-driven testing for automated test case generation
Although scenario-based testing makes it considerably easier to carry out testing, the vast number of different scenarios adds to the complexity of test automation. The solution is to use test automation to depict thousands of test cases in such a way that the tests themselves can be fully automated. For this to be possible, the descriptions of test cases and driving scenarios must be implemented automatically in the corresponding tools. In addition, test automation also serves to link the entire tool chain – with around eight different tools used in the validation of exterior light functions, along with the light control unit and the high-performance control unit – and ensure that all tools engage automatically and without interruption. This ensures, for example, that all relevant tools are automatically started when a test drive commences, including a tool for automated comparison of target and actual values in pulse width modulation (PWM) signals to activate the lights at the right time. In order to implement test cases more swiftly and reduce the complexity of test automation, ASAP combines scenario-based testing with keyword-driven testing for use in the validation of exterior light functions. In this form of test case description, which is certified in accordance with ISO 29119-5, individual test steps are stored in a database in both human-readable and machine-readable formats. This means that ASAP starts by writing a corresponding script for each defined test step – the so-called keywords – so that it can be carried out automatically. A test step is an instruction to control a specific function, such as activating an indicator.
All finally defined keywords (test steps) are universally applicable and can be parametrised in the database – so if, for example, the PWM signals to control a light source are supposed to change, this can be input in the database. This creates reusable test steps that only need to be parametrised with different input values. The process of inputting test steps to create a test case is also automated. The result? Partial automation of test automation, which delivers immense time savings due to the enormous volume of test cases required to validate exterior light functions. Another advantage of keyword-driven testing is that changes only need to be manually input once – to the relevant keyword in the central database – for this change to be automatically implemented in all test cases. Further significant benefits also arise from the fact that test steps are stored in human-readable and machine-readable formats in the database. On the one hand, this means that real test drives can be reproduced using the documented data and repeated virtually any number of times until the desired validation outcome has been achieved or the scenario has been checked to ensure consistent quality. On the other hand, virtual test drives can also be verified with real test drives because the test cases are available not only as machine-readable script but also in a human-readable format for test drivers. So, with this new approach – a combination of scenario-based and keyword-driven testing – ASAP reduces the complexity and effort involved in test preparation and execution, ultimately ensuring time-saving, cost-effective and comprehensive validation of exterior light functions.