Noticed that the operation of SUMS is not easy -What is RXSWIN-
- Introduction
- Section 7.1 Requirements for SU Management System (SUMS)
- Section 7.2 Vehicle model requirements including SU function
- Manage software updates using BOM?
Both of the top 2 most accessed articles on this blog are about RX SWIN. Therefore, this time, I would like to translate this RX SWIN article, which has few English sites, into English so that overseas readers can access it and connect it to two-way communication.
The original Japanese article is here.
Introduction
Just as we have looked at the WP29 CS Regulations (UN-R155) under consideration for cybersecurity, this time we would like to take a look at the contents of the WP29 SU Regulations (UN-R156) for software updates. As I mentioned at the end of the last time, I recommend this time as well, referring to the MONOist article.
It seems that it is a requirement for Section 7.1 SU Management System (SUMS) and a requirement for vehicle type including Section 7.2 SU function.
Section 7.1 Requirements for SU Management System (SUMS)
Let's start with section 7.1.
Before we get inside, there's one more difficult term to come up with. It is called RXSWIN (Software Identification Number for Regulation x). It was devised as a concept to aggregate and manage version information of software installed in in-vehicle systems that have received type approval. It may seem like something, but since a concrete example was written on pwc's HP, I will try to interpret it while looking at it.
In this example, imagine an in-vehicle ECU (Electronic Control Unit) that corresponds to a certain Regulation No. X, for example, an inter-vehicle distance control system that requires the approval of UN 89 (speed limiting device) under UN regulations. (This is just an example of the idea, and I'm sorry, but I'm not sure if UN 89 actually applies. For reference.) *1
It is assumed that such an inter-vehicle distance control system consists of two ECUs, and each ECU contains two microcomputers (MCUs). Since UN 89 has been approved as an inter-vehicle distance control system, even if a software update is required for one microcomputer, it is necessary to obtain approval for the entire system again. For that purpose, I understand that the identifier of the previous version and the identifier of the latest version after the update are required, and they can be numbered and managed as SWIN (Software Identification Number). (In the figure, SWIN is newly numbered because the version of MCU 2 of ECU 2 has been updated.)
By managing the versions before and after the software update using this RXSWIN, it is possible to check what version of the software is actually installed for each vehicle, and the requirement required in sections 7.1.1.2 to 7.1.1.4 will be met.
Sections 7.1.1.5 to 7.1.1.7 require a process to check the dependency between the system to be updated and other systems, identify the vehicle to be updated, and check the compatibility before and after the update.
Sections 7.1.1.8 and 7.1.1.10 require a process to check for features, performance, and parameters that change with software updates, and to evaluate the impact on vehicle model and safety. Section 7.1.1.11 requires a process for vehicle users to be notified about software updates.
I think that is enough for the overview, but I will describe the details for reference.
-
Section 7.1.1 Process verified by a certification body / technical service
Section 7.1.1.1 A process in which information related to this rule is documented, securely managed by the OEM, and available upon request from a certification body or technical service.
Section 7.1.1.2 A process that can uniquely identify information about the version of the initial and update SW, including integrity verification data and the HW component of the type-approved system.
Section 7.1.1.3 The process that enables you to view and update information about RXSWIN. Includes the ability to update information about all SWs, SW versions, and their integrity verification data associated with each RX SWIN.
Section 7.1.1.4 A process that can confirm that the SW version installed in the system matches the information registered as RXSWIN.
Section 7.1.1.5 A process that can identify dependencies between the updated system and other systems.
Section 7.1.1.6 The process by which an OEM can identify a vehicle subject to SU.
Section 7.1.1.7 The process of verifying the compatibility of the HW / SW configuration before and after updating the target vehicle.
Section 7.1.1.8 The process of assessing, identifying, and recording the impact on an authenticated system. This will take into account the identification of systems that may affect the SU and whether it involves changes in parameters related to regulations.
Section 7.1.1.9 The process of evaluating, identifying, and recording features added, modified, or enabled by SU, or changes or invalidations of parameters or features specified by law. The evaluation should consider the following items. (A) Update of relevant information (b) Does the test result no longer cover the updated vehicle? (C) Does the change in vehicle function affect vehicle type approval?
Section 7.1.1.10 The process of assessing, identifying, and recording whether SU affects other systems related to vehicle safety, or whether there are additions or changes to the vehicle.
Section 7.1.1.11 The process by which vehicle users can be notified about SU.
Section 7.1.1.12 The process of making the information contained in Sections 7.1.2.3 and 7.1.2.4 available to the certification body or technical service.
The details of the rest of Section 7.1 are a priori and a little complicated, so I will only give an overview when referring to the MONOist article.
Section 7.1.2 requires a record of information about software updates. Sections 7.1.2.1 to 7.1.2.4 require that you document the information generated through the process activities in Section 7.1.1. It is mainly a description of the software update process, a description of the system configuration that receives type certification, documents related to RXSWIN before and after the software update, software update version and integrity verification data, vehicle configuration information and compatibility verification results. Section 7.1.2.5 sets out the requirements for software update documentation to obtain vehicle type approval. Especially in (h), a document that can confirm that the software update is being performed securely is required.
Section 7.1.3 calls for security measures in performing a software update, such as preventing tampering with the software update, preventing the software update process from being compromised, and verifying the functionality and effectiveness of the updated software.
Section 7.1.4 asks for a description of the safety of performing an OTA software update while in operation and a process that ensures that the mechanic in charge is involved until the OTA software update is complete. I am.
Section 7.2 Vehicle model requirements including SU function
Next, let's take a brief look at section 7.2. Since there are many parts that can be understood a priori, we will proceed by referring to the MONOist article for details of each section.
See section 7.2.1. Section 7.2.1.1 calls for ensuring the reliability and integrity of software updates. Section 7.2.1.2 uses RXSWIN for the type approval and requires that the condition of the vehicle can be reliably grasped by reading the RXSWIN or software version from the vehicle. It's natural content, isn't it?
Section 7.2.2 describes additional requirements for OTA. Section 7.2.2.1 is a requirement for the vehicle for a software update and will only be executed if it has sufficient power to complete the software update, even if the software update fails or is interrupted. We want to be able to restore it to its previous state or keep the vehicle safe. We also want an explanation that software updates can be safely performed and a process that can be verified by vehicle users. It feels like that is the case around here as well. Of course, it is a very important part.
It seems that further requirements have been added, Section 7.2.2.2 is a notification item to the vehicle user, Section 7.2.2.3 is a countermeasure when the update while driving is not safe, and it will not be possible to drive during the update or it will be affected The vehicle function is disabled, and section 7.2.2.4 requires the user of the vehicle to be notified of the success or failure of the update and any changes after the update. Yes, I don't want it to be updated without permission, so I have to notify you.
Manage software updates using BOM?
The WP29 SU Regulations in the MONOist article, which had a lot of a priori concepts, need to raise the concept of phases and processes that were considered in CSMS as an important point not mentioned here. pwc seems to be aware of that and shows it in the figure below.
In the previous article, I happened to mention the seminar by Professor Takahiro Fujimoto of the University of Tokyo, but as a person who has learned from Professor Fujimoto's book, the BOM is always in the corner of my head, so the entire product life cycle such as design, production, and sales. I was thinking while writing an article that I had to think about software updates as well as design changes.
Especially, how to manage after mass production is a thought. In the figure, there is configuration management for each unit in the manufacturing department, but if you have that much data, there will be a disadvantage that the data volume will become enormous. In order to identify the version of the software installed on the actual vehicle that was actually lined off, it is necessary to make a reliable link with the manufacturing BOM, including software management.
Also, moving the viewpoint to software development itself, in a word, software updates include major updates such as specification changes and small updates that make the process a little faster. I feel that it is difficult to formulate this standard as to how to determine when to reflect these various updates in the manufacturing BOM. Aside from the same serious software anomalies as component recalls, if you make a mistake in the policy of applying updates that are slightly comfortable for the user, the loyalty of the user will also increase. It's a delicate area that you can lose. I wonder if it will be updated on a daily basis like a smartphone app without noticing it, and if the software installed in the new model can be used with the hardware of the old model, existing users Of course I ask for an update. However, in reality, I think that something like that that is incompatible with another system of the old model and cannot be applied will occur in the depths, and that will have to be explained in the field. And on the net, it will be rigorously pursued by users.
I think that hiding information is the most hated thing, but how to disclose it, how it is appropriate for users to accept it, and because it entrusts the life of a car, a car I think it is necessary to have wide-ranging discussions involving not only the industry but also users.
*1:For the body shape of UN rules, refer to the JASIC website https://www.jasic. .org/j/08_publication/hh/un.htm
