1. Summary of software update progress
Overview of progress to date
Developed a model for update processes
Defined scope
Identified requirements
How to decide what constitutes a change needing extension or renewal of type approval
Accessible information on system information and type approvals for vehicles
Configuration control
For registration of updates
To verify type approved systems on a vehicle (e.g. at PTI)
Suggested processes
How manufacturer provides information
What information is provided
How third parties may update type approved systems
Identification of future needs
Near future
DETA (Database for the Exchange of Type Approval)
Electronic CoC/DoC data
A secure process to update a CoC/DoC: like the extension of a type approval
Further future
Verification of software integrity?

2. Software update process matrix
moment of update
no impact
limited impact
severe impact
Initial type approval (TA)
not applicable
Existing TA, before Certificate of Conformity (CoC)
no action
extension TA
new TA
Existing TA, after CoC, before registration
extension TA and new CoC
new TA and new CoC
Existing TA, after registration, by OEM
extension TA or individual approval or approval with limited scope. Registration according to national rules
new TA or individual approval or approval with limited scope. Registration according to national rules
Existing TA, after registration, not by OEM
(multi stage) new National approval. Registration according to national rules

3. Summary of software update progress
Software updates remit
The group agreed that systems with „deep learning/self learning“ is currently out of scope
Many software updates do not impact type approved systems.
May need to consider if there is anything unique for OTA
National processes for registration would be out of scope
Benefits
Should improve consumer information if done correctly
Should aid repair and maintainance by providing additional information
Will help ensure vehicles have correct software on them.

4. Summary of software update progress
Solutions proposed in Paris for documentation
Pre-registration
Type approvals (extended or newly obtained) are linked to the Whole Vehicle Type Approval (WVTA).
Documented in the Certificate/Document of Conformity (CoC/DoC)
Requirement for both hardware and software information to be provided
Post registration
A transparent documentation of the modification is needed.
This can be achieved by an „extension“ of the CoC/DoC of the vehicle detailing the changes
With such documentation, changes of the registration can be performed according to national processes.
Interim solution for information:
A manufacturer provides documentation describing:
the software update and listing the new/modified type approvals for each impacted VIN.
whether and how the change affects registration- or tax- relevant parameters (CO2, engine power, etc.)
This documentation is provided via the type approval authority to the registration offices.
In case of relevant changes, the registration information is adjusted according to the national processes.

5. Summary of software update progress
Discussion on Type Approval Numbers
Type Approval Numbers are a unique identifier of a type approved system
They will be linked to information on the affected hardware/software of a system
TAN is updated when software affecting type approval is updated (extension or renewal?)
This can be used to:
Provide information on status of vehicles (e.g. At PTI)
Provide information to consumers on update status of their vehicles

6. Requirements for Type Approval Numbers
How would TAN‘s work?
Whole vehicle TAN vs TAN for each type approved system
(Matrix of ECU versus Type Approved systems)
What would be more burdensome/informative?
Would this work for heavy vehicles?
Administrative process requirements
Require ability to interogate vehicle to find its TAN(s)
Requirement to maintain integrity of information on vehicle and secure method to update information
Information requirements for CoC/DoC/Registration
Clear link is needed between CoC/DoC and the TAN(s),
how would this be maintained
What requirements would this place on the CoC/DoC
Other update requirements
Update process is secure
Update process can be conducted safety – requirements for this
Information to the vehicle operator
When an update may be performed
Consent of the operator

7. Next steps Confirm happy with approach so far
Identify missing requirements
Question on whether guidance for what might be an extension to type approval is needed
Confirm if happy with approaches for:
Software update processes pre and post registration
Dependencies on electronic sharing of information
The use of Type Approval numbers
Development of a paper if these are are sufficient

8. Schedule(TBD) 2017 2018 Feb. (2) Mar. (3) Apr. (4) May (5) Jun. (6)
Jul.
(7)
Aug.
(8)
Sep.
(9)
Oct.
(10)
Nov.
(11)
Dec.
(12)
Jan.
(1)
★2/16-17
★5/10-11
★8/30-31(?)
★12/x
★3/13-14
★6/13-14
★10/11-12
Identify
update
cases
Identify functions
Building
Update
process
Drafting
recommendations

9. ACSF proposal: Document ACSF-08-10
Requirement: It shall be possible to confirm the valid software identifier of the system by reading out the ACSFTAN via the use of an electronic communication interface or other fitted on-board system (e.g. display).
At the time of Type Approval the means implemented to protect against simple unauthorized modification to the operation of the verification means chosen by the manufacturer (e.g. warning signal) shall be confidentially outlined.
The manufacturer shall provide the ACSFTAN including the chosen strategy to determine the ACSFTAN in the information package.
The manufacturer shall provide information how to read out the ACSFTAN during periodic technical inspection.
In case the type approval relevant software parts of an ACSF are modified by the vehicle manufacturer, the ACSFTAN shall be updated according to the chosen strategy leading to a type approval extension. Modification of software parts are type approval relevant if they lead to a modification of the type regarding the Annex 6 of this Regulation or if functionalities are extended regarding the system information data.

10. Link between SW versions of different ECUs and ACSF TAN
Example: 4 ECUs have an impact on the type approval of ACSF
Update w/o TA impact
Update with
TA impact
Type approval test
First registration
ECU
SW version 1
V3.6 2
V1.3 3
V1.6 4
V8.9
ECU
SW version 1
V3.9 2
V1.4 3
V1.6 4
V9.1
ECU
SW version 1
V4.1 2
V1.8 3
V2.3 4
V9.3
ECU
SW version 1
V5.0 2
V1.8 3
V2.7 4
V9.8
R Ext 00
ACSF TAN 0023
R Ext 01
ACSF TAN 0024
The same principle than for some today Hardware Updates today (part number may change, but not type approval)
The system for vehicle recalls in case of safety problems is the same as today. No direct link with the TAN.

11. New SW version available with impact on TA
Need to type approve SW update for new vehicles before update of registered vehicles
Vehicle owner gets information that type approved SW update is available
New SW version available with impact on TA
Vehicle owner wants to update the vehicle
System type approval information document
ACSF TAN 0023
Extension of type approval
New system type approval information document
ACSF TAN 0024
Vehicle manufacturer informs authorities that TAN 0024 is authorized for after-market update
System type approval certificate R79
00322 Ext 00
New system type approval certificate R79
00322 Ext 01
Vehicle is updated with secured process
Information to Type Approval Authority
Authorities can check during PTI whether the TAN on the vehicle is authorized
Legend:
Blue: UNECE process
Green: national process

12. Current situation of software updates
Example for 1 vehicle (VIN)
Type approval test
First registration
After registration
ECU
SW version 1
V3.6 2
V1.3 3
V1.6 4
V8.9
Etc.
ECU
SW version 1
V3.9 2
V1.4 3
V1.6 4
V9.1
Etc.
ECU
SW version 1
V4.1 2
V1.8 3
V2.3 4
V9.3
Etc.
Note: Only some specific combinations of SW versions are compatible.
For example V4.1 of ECU 1 may not be compatible with V1.7 of ECU 2.
Software updates are performed during the whole vehicle life cycle.
The very big majority of updates does neither impact type approval nor PTI.

13. Possible needs Software configuration control may be necessary
For vehicle type approval and registration
To update information on vehicle registration if a software update has an impact on vehicle type approval
For Periodical Technical Inspection
To check whether type approval relevant software installed on the vehicle is compatible with vehicle type approval
Note:
PTI can check the software versions of type approval relevant systems but cannot check whether the software is corrupted
The case of cyberattacks (e.g. a hacker modifies a software without changing the official version) shall be covered by the Threat Analysis of UN TF Cybersecurity and OTA

14. Vehicle type approval and registration Possible mid-term solution
The necessary system type approvals are extended or newly obtained and linked into the Whole Vehicle Type Approval (WVTA). This step is also necessary for the ongoing production of vehicles (case 2).
For the already registered vehicles (case 1) a transparent documentation of the modification is needed. This can be achieved by allowing for an „extension“ of the CoC/DoC* of the vehicle.
With such documentation, changes of the registration can be performed according to national processes.
WVTA
Type approvals of the modified or new systems
Necessary for new production vehicles
Updated CoC/DoC
Documentation of changes for already registered vehicles
*CoC: Certificate of Conformity, see article 18 of Directive 2007/46/EC
*DoC: Declaration of Conformance, see Annex 6 of draft UN Regulation No. 0 (doc. WP )

15. Vehicle type approval and registration Mid-term target process
Background and necessary boundary conditions for the target process:
Europe: It is assumed that the CoC will be stored in electronic format in the next years. The EREG activity is ongoing, inclusion in the new EC framework regulation planned. It is an industry objective to replace the paper CoC by the electronic CoC after a transition time.
UNECE: With IWVTA and implementation of DETA, the DoC on VIN-basis will be implemented. This will include reference to the Regulations (and their versions) the individual vehicle complies with.
Today in Europe, this information is not directly included in the CoC where only reference to a WVTA is made. In the future, the information that figures in the DoC may need to be included in the CoC.
In Summary: for this target process we will need (application outside UN TF CS)
DETA
Electronic CoC/DoC data
A secure process to update a CoC/DoC: like the extension of a type approval

16. Vehicle type approval and registration Interim process
Since prerequisites for the target process are not yet available, an interim process is needed
The interim process will be relevant only for a limited period of time  it should not impose too much burden on all stakeholders.
The following way forward could be envisioned:
The manufacturer provides a documentation describing the software update and listing the new/modified type approvals for each impacted VIN. This will also identify whether and how the change affects registration- or tax- relevant parameters (CO2, engine power, etc.)
This documentation is provided via the type approval authority to the registration offices.
In case of relevant changes, the registration information is adjusted according to the national processes.

17. Vehicle type approval and registration Solution for 3rd party SW updates
For software updates that are not performed by the original manufacturer of the vehicle, a multistage type approval process may apply.
Here, the manufacturer’s responsibility is (partly) transferred which can be adequately covered in the multistage process.
The multistage process is not supported for updates performed under control of the vehicle manufacturer as the high volume of concerned vehicles creates too much administrative burden.

18. Periodical Technical Inspection
The need for PTI is to check whether the type approval relevant software installed on the vehicle is compatible with the vehicle type approval
This covers also the previously described update of type approval and registration data:
In the target process, the PTI needs an access to the electronic CoC/DoC
In the interim process, the PTI needs access to the documentation describing the update and listing the new/modified type approvals (e.g. via the type approval authority or the registration offices)