TFCS-06-xx
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?
1
Software update process matrix
moment of update
no impact
limited impact
severe impact
Initial type approval (TA)
not applicable
not applicable
not applicable
Existing TA, before
Certificate of Conformity
(CoC)
no action
extension TA
new TA
Existing TA, after CoC,
before registration
no action
extension TA and new CoC new TA and new CoC
Existing TA, after
registration, by OEM
no action
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
(multi stage) new National
approval. Registration
according to national rules
(multi stage) new National
approval. Registration
according to national rules
2
TFCS-06-xx
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.
3
TFCS-06-xx
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.
4
TFCS-06-xx
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
5
TFCS-06-xx
Requirements for Type Approval Numbers
1.
2.
3.
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
6
TFCS-06-xx
Next steps
1.
2.
3.
4.
5.
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:
a. Software update processes pre and post registration
b. Dependencies on electronic sharing of information
c. The use of Type Approval numbers
Development of a paper if these are are sufficient
7
Schedule(TBD)
2017
Feb.
(2)
2018
Mar.
(3)
Apr.
(4)
May
(5)
★2/16-17
TF#3@Paris
★3/13-14
TF#4@Geneva
Identify
update
cases
8
Jun.
(6)
★5/10-11
TF#5@Paris
Jul.
(7)
Aug. Sep.
(8) (9)
Nov.
(11)
Building
Update
process
Dec.
(12)
Jan.
(1)
★12/x
TF#x @xx
★8/30-31(?)
TF#7@Europe?
★6/13-14
TF#6@Washington
Identify
functions
Oct.
(10)
★10/11-12
TF#8@Tokyo
Drafting
recommendations
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.
9
Link between SW versions of different
ECUs and ACSF TAN
Example: 4 ECUs have an impact on the type approval of ACSF
Update with
TA impact
ECU SW version
ECU
SW version
ECU
SW version
Update w/o
TA impact
ECU SW version
1
V3.6
1
V3.9
1
V4.1
1
V5.0
2
V1.3
2
V1.4
2
V1.8
2
V1.8
3
V1.6
3
V1.6
3
V2.3
3
V2.7
4
V8.9
4
V9.1
4
V9.3
4
V9.8
Type approval test
R79 00322 Ext 00
ACSF TAN 0023
1.
2.
First registration
R79 00322 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.
10
Need to type approve SW update for new
vehicles before update of registered vehicles
New SW version
available with
impact on TA
System type
approval
information
document
ACSF TAN 0023
System type approval
certificate R79
00322 Ext 00
Extension of
type
approval
New system type
approval
information
document
ACSF TAN 0024
New system type
approval certificate R79
00322 Ext 01
Information to Type
Approval Authority
Legend:
Blue: UNECE process
Green: national process
Vehicle owner gets
information that type
approved SW update is
available
Vehicle owner wants to
update the vehicle
Vehicle manufacturer
informs authorities that
TAN 0024 is authorized
for after-market update
Vehicle is updated with
secured process
Authorities can check
during PTI whether the
TAN on the vehicle is
authorized
11
Current situation of software updates
Example for 1 vehicle (VIN)
Type approval test
First registration
After registration
ECU
SW version
ECU
SW version
ECU
SW version
1
V3.6
1
V3.9
1
V4.1
2
V1.3
2
V1.4
2
V1.8
3
V1.6
3
V1.6
3
V2.3
4
V8.9
4
V9.1
4
V9.3
Etc.
Etc.
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.
12
Possible needs
• Software configuration control may be necessary
1. For vehicle type approval and registration
• To update information on vehicle registration if a software
update has an impact on vehicle type approval
2. 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
13
Vehicle type approval and registration
Possible mid-term solution
1.
2.
3.
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.
Type approvals
of the modified
or new systems
WVTA
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.29-171-11)
14
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
15
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.
16
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.
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)
18