In January 2021, UN Regulations № 155 (Cybersecurity) and № 156 (Software management system) came into force. In July 2022, these new requirements were mandatory for all new vehicle type-approvals, and in July 2024 for all new vehicles, even those types homologated before July 2022.
The requirements in these regulations apply to lamp activation software, whether it’s in a main ECU like the BCM (body controller module) or HPC (high power computer), or embedded with a LIN or CAN interface. The new requirements are many, and they require unprecedented attention and thought by OEMs, especially their lighting teams, as well as by lamp and ECU suppliers.
Specifically: the new requirements call for deep discussion inside each company, with participation by the legal department, certification department, electrical architecture team, software team, and commodity team (e.g., lighting team) to define how to meet these new rules, both for vehicle type approval and for software update management after approval.
GRVA, the UNECE group handling this new regulation, have published an interpretive document with examples to be clearer – the first time such a guide has been put out, if I am correct.
So, how can OEM lighting teams be aware of a change in camera perception software which could affect automatic high beam activation performance, for example, which is legally defined in UN R48? Or the suspension compensation software which can affect load testing and low beam aiming as also prescribed in R48? Does a software change necessitate a vehicle certificate update?
During vehicle certification, the vehicle software description must be presented to test-house with a detailed and clear software traceability (first step). When vehicle certification is done, a clear process has been described to enable software updates after registration.
UN R156 ¶7.1.2.5. defines the steps in case of a software update with:
• the purpose of the update
• what systems or functions of the vehicle the update may affect
• Which of these (if any) are type-approved
• whether the update affects fulfilment of any relevant requirements of a type-approved system
• whether the software update affects any system type-approval parameter
• whether an approval for the update was sought from an approval body
• how the update may be executed and under what conditions
• confirmation that the update will be conducted safely and securely
• confirmation that the update has passed verification and validation procedures
When everything is done, the OEM contacts their UN R48 test house to check if a certification update must be done. This requires close software traceability across all stakeholders, which is a totally new way of working.
DVN organized a workshop last year in Munich to introduce and discuss these two new regulations.
We are pleased this week to publish a detailed report, written by Bylogix (with whom I have collaborated for software development) to introduce the topic to non-experts, with a complete background explanation to understand the impetus and intent of the new rules.
As always, we are listening; please feel free to write me and share your questions, comments, and thoughts.
Sincerely yours,
