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 2.10.1 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

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

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

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

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 21448 SOTIF UN Regulation No. xxx Amdenment of Complex Electronic System Annex ISO 26262 Functional Safety New Software Annex ISO/SAE 21434 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

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