1. Main problems of NL proposal for UN Software Regulation
Submitted by the experts of OICA/CLEPA
TFCS-ahSU2-02-Rev1
Main problems of NL proposal for UN Software Regulation
Scope: It goes beyond the scope and the deliverables of the UN TF (see pages 3 and 4)
Absence of type definition: Each UN Regulation needs a definition of the vehicle type with regard to the regulation. This definition is missing and will be difficult to find for software in general. A link to the different systems regulations seems necessary. In any case, the proposed administrative process is unclear (at first system approval, then SW approval?).
Feasibility of the approach: “The System” is defined in and includes all functions of the vehicle (regulated or not) that use sensors, electronic control units and actuators. The whole vehicle functional architecture is hence concerned. It is not realistic to deliver the documentation package required in chapter 1 and the system layout and schematics required in chapter 2 for all vehicle functions. It needs to be clarified to what “the system” relates to:
All software that is on a given vehicle?
The software for a specific vehicle system?
Functional safety of the vehicle
This aspect is out of the scope of the UN TF and is currently being discussed by the informal working group ACSF of GRRF on the evolution of the Complex Electronic Systems Annex.
State of the art to design a safe vehicle is currently being defined within ISO TC22/SC32
Safety aspects specific to software updates may have to be considered in addition to the general functional safety aspects.
Software as standalone regulation (see next page) 1

2. Software as standalone regulation
The safety and security impact of software depends on the functional architecture of the vehicle that links hardware and software. A system approach that defines requirements for each system is more appropriate to assure safety and security.
A software update that concerns more than one system will impact the type approval of each individual system.
System 1
Regulation 1
System 2
Regulation 2
System3
Regulation 3
Software
Regulation SW
NL proposal …
System approval approach
System 1 (HW + SW)
Regulation 1
System 2 (HW + SW)
Regulation 2
System 3 (HW + SW)
Regulation 3 2

3. Reminder of scope of UN TF-CS/OTA (status report ITS/AD-12-03)
Data protection
Cyber Security
Software updates
Legal aspects
Security aspects
Security aspects
Type approval aspects
Safety aspects
pre- registration
post- registration
out of scope
Threat analysis
Table of threats
Develop
recommendation for safe execution
Develop flow diagram
Define mitigation principles
Define approval method
Develop guidance/recommendation for ITS/AD

4. Issues addressed by NL proposal
Data protection
Cyber Security
Software updates
Safety
Environmental compliance
Safety Of The Intended Functionality
Safety in case of failures
Legal aspects
Security aspects
Security aspects
Type approval aspects
Safety aspects
The issues from the NL proposal in the light blue boxes are out of the scope of the TF.
As response to the NL concerns, the UN TF may wish to clarify how and in which form the addressed issues can be solved (see light blue zone above).
OICA/CLEPA proposal on the next slide
xxx

5. Environmental compliance of the Intended Functionality
Issues addressed by NL proposal
NL proposal
Data protection
Cyber Security
Software updates
Safety
Environmental compliance
Legal aspects
Security aspects
Security aspects
Type approval aspects
Safety aspects
of the Intended Functionality
in case of failures
out of scope
Generic requirements
Specific type approval requirements
UN ECE Consolidated Resolution R.E. 3
Generic amendment e.g. introducing RxSWIN
ISO SOTIF
UN Regulation No. xxx
Amdenment of Complex Electronic System Annex
ISO Functional Safety
New Software Annex
ISO/SAE Cyber Sec. Eng.
CoP Conformity of Producion
Implementation of S/W updates in a schedule of 1958 Agreement
RDE Real Driving Emissions
UN System Regulations (e.g. R79)
New documents
Amendments to existing documents
OICA/CLEPA proposal for deliverables to respond to Dutch concerns

6. Conclusions
OICA/CLEPA strongly suggest not to implement a generic Software Regulation (see arguments on page 1 and 2).
All issues of the NL proposal are addressed by the OICA/CLEPA proposal (partly referring to existing processes / parallel activities).
All issues addressed in the scope of the TF should have clear deliverables:
System specific requirements should be integrated in the UN regulation for the respective system (this will provide a lean type approval process in case of modifications of software).
Generic requirements should be integrated in RE3 and in a later stage be transformed into a schedule of the 1958 agreement.
It may be useful to identify which text components of the NL proposal could be used in the different deliverables. OICA/CLEPA is ready to engage in such an analysis. 6