Presentation is loading. Please wait.

Presentation is loading. Please wait.

Suggestion on software update

Similar presentations


Presentation on theme: "Suggestion on software update"— Presentation transcript:

1 Suggestion on software update
Japan (CSTF of ITS/AD 11-12, October 2017 Tokyo, Japan)

2 Outcome TFCS-07 // 30-31 August 2017 @ NH Den Haag, NL
Software updates: Results of the ad hoc meeting “Software TAN / Software updates” in Hamburg (2 August 2017) were presented: The possibility to introduce a Regulation-linked Software Identification Number (=> RxSWIN), formerly named S/W TAN, was confirmed. Different views on introducing the number: in each relevant Regulation (OICA/CLEPA approach) vs. introducing a standalone “Software Regulation” (NL) NL tabled a draft proposal for a new standalone Software Regulation (TFCS-07-05). Members were asked to provide comments on the paper by 15 September 2017 to

3 Outcome the ad-hoc meeting on software updates 27 Sep. 2017 @ web
The group agreed to discuss ways how the vehicle shall ensure the safety of the update process (to be attached to appropriate regulations) > annex a (Contents to be considered for meeting in Tokyo) ways specific regulatory requirements on software updates and help its implementation (to be attached to appropriate regulations) > annex b (Potentially based on OICA proposal)

4 Case studies on software update
Reports of cases which ECU program updates were conducted for non-regulatory recall or recall (2014~) were collected and reviewed for discussions on annex a (safety aspects of updates). The cases which updating process required physical inspections by technical experts were picked up. In some cases, the calibration of actuator which required physical movement of the mechanism were carried out after the software update. These cases should be clearly separated from the cases which enable OTA software updates.

5 Examples of software updates with physical inspections or calibrations
Description of malfunction Update and follow up Case A (Inspections are followed) The diagnosis for catalyst condition for pollutants in the exhaust gas did not function properly because of the fail of the original software. The system would not warn the degradation of catalyst . The program of engine control unit was updated. Then, the catalyst was inspected if the lifetime was over. The catalyst was replaced in case the lifetime ended. Case B (calibrations are followed) The fuel direct injection was not controlled properly because of the fail of the original software. Then, the engine would not function properly. The program of engine control unit was updated. Then, the leaning process of injection actuator was conducted. The relevant parts were inspected and replaced in case of getting damaged. These updating cases required the manual work of technical experts. Inspection or leaning process were carried out after the updates. Such processes should be completed by appropriate technical experts and then OTA is not applicable for these cases.

6 Suggestion for Software Update Issue
Security issues on software update have been addressed in the cyber-security session of CSTF. On the other hand, safe issues regarding updates including OTA have remained. The safe issues of updating should be discussed carefully based on case studies of actual software update. This approach may not be completed within the CSTF’s mandate. Japan suggests to build a dedicated group to discuss safe updates inviting experts of relevant systems for updates in 2018.

7 Possible issues on software update for the next stage
CSTF considered cases where safety, environmental protection, energy efficiency and anti-theft performance of wheeled vehicles, equipment and parts is changed through OTA into the one different from information submitted when the type approval was applied, and identified the exist of issues on procedures for safe updates as well as secure updates… Further discussion points to be considered which include the followings are remained. Possible issues to be considered: e.g. Identification of vehicle function areas where “OTA” can cover Identification of measures to assure the safe “OTA” : Whole process of OTA update should be clarified. Vehicle situations and stats to enable “OTA” should be clarified (e.g on public roads?, in a parking?, engine off?, ) etc. Such issues may exceed the area where CSTF has discussed and require other knowledges rather than these of cyber security.

8 Possible items to be reflected on Annex a
Annex a to the recommendation on software updates could include the following descriptions. “ CS/OTA TF identified the exist of issues on procedures for safe updates as well as secure updates. Possible discussion items on updates will be Cases to prohibit OTA, Confirmation of vehicle status before/after updates, Assurance of vehicle drive…. These common rules should be discussed carefully considering vehicle functions together with not only software but also whole relevant systems. In this perspective, CS/OTA TF proposes to set a dedicated group to discuss safe updates inviting experts of relevant systems for updates.


Download ppt "Suggestion on software update"

Similar presentations


Ads by Google