Center for controlling software updates

Abstract

To provide a center which can suitably perform explanation as to software update to a user, a manager, or the like of a vehicle.SOLUTION: A center which controls software update of an electronic control unit mounted on a vehicle includes: a communication unit which performs communication between the vehicle and an information terminal linked to the vehicle; an acquisition unit which acquires information on a user of the vehicle from the information terminal linked to the vehicle; a determination unit which determines a user type corresponding to the user of the vehicle on the basis of the information acquired by the acquisition unit; and a control unit which distributes explanation as to the software update to the vehicle on the basis of the user type determined by the determination unit for the vehicle as an object for which the software update is performed.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to a center for controlling software updates of electronic control units mounted on vehicles. [Background technology]

[0002] A vehicle is equipped with multiple electronic control units (ECUs) for controlling the operation of the vehicle. Each electronic control unit includes a processor, a temporary storage unit such as a RAM, and a non-volatile memory that is a non-volatile storage unit such as a flash ROM, and the processor executes software stored in the non-volatile memory to realize the control functions of the electronic control unit. The software stored in each electronic control unit is rewritable, and by updating the software to a newer version, it is possible to improve the functions of each electronic control unit or add new vehicle control functions.

[0003] As a technology for updating software in an electronic control unit, there is known an OTA (Over The Air) technology, in which an in-vehicle communication device connected to an in-vehicle network is wirelessly connected to a communication network such as the Internet, and a device responsible for updating the software in the vehicle downloads software from a server via wireless communication, writes and installs the downloaded software in the electronic control unit, and activates the installed software, thereby updating or adding software to the electronic control unit. For example, see Patent Document 1. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2017-149323 A Summary of the Invention [Problem to be solved by the invention]

[0005] In software updates using OTA, the center may need to provide advance explanations about the software update to vehicle users and administrators, etc., using a human-machine interface (HMI), etc. However, because the explanations about the software update use content (terminology, sizes, diagrams, etc.) that is uniformly set for all vehicle users and administrators, there is a risk that the explanations may not be appropriate for some users and administrators.

[0006] The present disclosure has been made in consideration of the above-mentioned problems, and aims to provide a center that can appropriately provide explanations regarding software updates to vehicle users, managers, and the like. [Means for solving the problem]

[0007] In order to solve the above problems, one aspect of the disclosed technology is a center that controls software updates of an electronic control unit installed in a vehicle, the center comprising: a communication unit that communicates between the vehicle and an information terminal linked to the vehicle; an acquisition unit that acquires information about the user of the vehicle from the information terminal linked to the vehicle; a determination unit that determines a user type corresponding to the user of the vehicle based on the information acquired by the acquisition unit; and a control unit that distributes instructions regarding the software update to the vehicle based on the user type determined by the determination unit for the vehicle that is the target of the software update. Effect of the Invention

[0008] According to the center of the present disclosure, it is possible to appropriately provide explanations regarding software updates to vehicle users, managers, and the like. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a block diagram showing an overall configuration of a network system according to an embodiment; [Diagram 2] Block diagram showing the general configuration of the center [Diagram 3] Center functional block diagram [Figure 4] Block diagram showing the schematic configuration of the OTA master [Diagram 5] OTA Master Functional Block Diagram [Figure 6] Flowchart of the process for setting user type performed by the center [Figure 7] Flowchart of distribution process of explanation regarding software update performed by the center [Figure 8] An example of user type information stored by the center DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] According to the present disclosure, the center that controls the software update of the electronic control unit mounted on the vehicle provides an explanation about the software update to the user, manager, etc. of the vehicle according to the user type set based on the information about the user. This allows the explanation about the software update to be appropriately provided to the user, manager, etc. of the vehicle. Hereinafter, an embodiment of the present disclosure will be described in detail with reference to the drawings.

[0011] <Embodiment> [System Configuration] Fig. 1 is a block diagram showing an overall configuration of a network system according to an embodiment of the present disclosure. The network system shown in Fig. 1 is a system for updating software of a plurality of electronic control units (ECUs) 50a to 50d mounted on a vehicle, and includes a center 10 located outside the vehicle, an in-vehicle network 90 built in the vehicle, and an information terminal 95 linked to the vehicle.

[0012] (1) Center The center 10 can communicate with an OTA master 30 (described later) provided in the in-vehicle network 90 via the network 100, and can control and manage software updates of the electronic control units 50a to 50d connected to the OTA master 30 by sending notifications of software updates to vehicle users, managers, etc., explaining software updates, sending update data for the software of the electronic control units 50a to 50d and information defining the procedure of the update process, and receiving notifications indicating the progress of the software update process. The center 10 has a function as a so-called server. The center 10 can also communicate with an information terminal 95 via the network 100, and can receive various information (hereinafter referred to as "information about the user") related to the user's preferences, lifestyle, habits, etc., including operations on the information terminal 95 performed by the vehicle user, manager, etc.

[0013] FIG. 2 is a block diagram showing a schematic configuration of the center 10 in FIG. 1. As shown in FIG. 2, the center 10 includes a central processing unit (CPU) 11, a random access memory (RAM) 12, a storage device 13, and a communication device 14. The storage device 13 is a device including a readable and writable storage medium such as a hard disk drive (HDD) or a solid state drive (SSD), and stores a program for performing software update management, information used for software update control and update management, and software update data for each electronic control unit. In the center 10, the CPU 11 executes a program read from the storage device 13 by using the RAM 12 as a working area, thereby performing a predetermined process related to software update. The communication device 14 is a device for communicating with the OTA master 30 and the information terminal 95 via the network 100.

[0014] Fig. 3 is a functional block diagram of the center 10 shown in Fig. 2. The center 10 shown in Fig. 3 includes a storage unit 16, a communication unit 17, a control unit 18, an acquisition unit 19, and a determination unit 20. The storage unit 16 is realized by the storage device 13 shown in Fig. 2. The communication unit 17, the control unit 18, the acquisition unit 19, and the determination unit 20 are realized by the CPU 11 shown in Fig. 2 executing a program stored in the storage device 13 using the RAM 12.

[0015] The storage unit 16 stores information on software update processing of one or more electronic control units mounted on the vehicle. As the information on the software update processing, the storage unit 16 stores at least update management information in which information indicating software available in the electronic control units 50a to 50d is associated with each vehicle identification information (vehicle ID) that identifies the vehicle, and update data on the software of the electronic control units 50a to 50d. As the information indicating the software available in the electronic control units 50a to 50d, for example, a combination of the latest version information of each software of the multiple electronic control units 50a to 50d is defined. As the information on the software update processing, the storage unit 16 can store an update status indicating an update state of the software being performed in the vehicle. Also, as the information on the software update processing, the storage unit 16 can store information on an update sequence indicating a procedure of the software update processing for issuing a control instruction to the OTA master 30. Also, the storage unit 16 can store user type information corresponding to a user type determined by a determination unit 20 described later.

[0016] FIG. 8 shows an overview of an example of user type information stored in the storage unit 16 of the center 10. This user type information is information that defines the manner of explanation regarding software update to be given to a vehicle user or administrator in advance when updating software using OTA. The manner of explanation regarding software update is determined to have different contents for each type classified according to the vehicle user or administrator who is assumed to be the subject of the explanation. In the example of FIG. 8, type "2" is a user type defined for an average user (standard person), and the manner of explanation regarding software update is defined to have contents that are generally considered to be standard (can be set arbitrarily, and the explanation is omitted). Type "1" is a user type defined for a person (e.g., elderly person) who has difficulty reading small characters compared to the standard person of type "2", and the manner of explanation regarding software update is set to simplify (summarize) the contents of the explanation, not use technical terms related to vehicles (or use them less frequently), use large font size, and use many visually easy-to-understand diagrams and charts, etc., compared to the contents of type "2". The type "3" is a user type defined for those who are knowledgeable about vehicles and IT (e.g., experts) and those who are accustomed to operating smartphones (e.g., young people) compared to the standard user of the type "2", and the manner of explanation regarding the software update is set to be more detailed (specialized) than the contents of the type "2", to use more vehicle technical terms, to use smaller font size, to use fewer diagrams that take up a display area, and the like. The user type information may be set to different contents for each update software. The storage unit 16 may store explanation data (e.g., HMI data) itself that is generated in advance by reflecting the definition of the user type information, instead of the format of the user type information that defines the manner of explanation regarding the software update as shown in FIG. 8.

[0017] The communication unit 17 functions as a transmitting unit and a receiving unit that transmits and receives data, information, notifications, requests, and the like between the OTA master 30 (vehicle) and the information terminal 95. The communication unit 17 receives a software update confirmation request from the OTA master 30 (receiving unit). The update confirmation request is information transmitted from the OTA master 30 to the center 10 when, for example, the power supply or ignition is turned on in the vehicle (hereinafter referred to as "power ON"), and is information for requesting the center 10 to confirm whether or not there is update data for the electronic control units 50a to 50d based on vehicle configuration information described later. In addition, in response to the update confirmation request received from the OTA master 30, the communication unit 17 transmits information indicating the presence or absence of update data to the OTA master 30 (transmitting unit). In addition, the communication unit 17 receives a transmission request (download request) for a distribution package from the OTA master 30 (receiving unit). Furthermore, when the communication unit 17 receives a download request for a distribution package (reception unit), it transmits a distribution package including software update data for the electronic control units 50a to 50d generated by the control unit 18 described later to the OTA master 30 (transmission unit). The communication unit 17 also receives information about the user of the information terminal 95 linked to the vehicle directly from the information terminal 95 or indirectly via the vehicle (reception unit). The communication unit 17 also transmits to the vehicle an explanation about the software update according to the user type determined by the determination unit 20 described later based on an instruction from the control unit 18 (transmission unit).

[0018] When the communication unit 17 receives an update check request from the OTA master 30, the control unit 18 determines whether or not there is software update data for the electronic control units 50a to 50d mounted on the vehicle identified by the vehicle ID included in the update check request, based on the update management information stored in the storage unit 16. The control unit 18 transmits the determination result of whether or not there is update data to the OTA master 30 by the communication unit 17. When the control unit 18 determines that there is software update data for the electronic control units 50a to 50d, and receives a download request for a distribution package from the OTA master 30, the control unit 18 generates one or more distribution packages including the corresponding update data stored in the storage unit 16. The control unit 18 also acquires or generates data for explaining the software update based on the user type determined by the determination unit 20. The data for explaining the software update may be included in the distribution package together with the update data.

[0019] The acquisition unit 19 acquires information about the user of the vehicle directly from the information terminal 95 via the communication unit 17 or indirectly via the vehicle (e.g., via WiFi-DCM). The acquisition unit 19 can determine which information terminal 95 the information about the user comes from, based on unique information (user identification information) such as the identification ID of the information terminal 95 transmitted together with the information about the user of the vehicle. The timing and cycle at which the acquisition unit 19 acquires the information about the user can be set arbitrarily, and the acquisition method may be either a push type or a pull type. This information about the user includes at least information about the content (moving images, music, emails, etc.) that the user is viewing or operating using the information terminal 95, and the user's spoken words (phone calls, messages, etc.).

[0020] The determination unit 20 determines a user type corresponding to a user of the vehicle, an administrator, or the like, based on information about the user of the vehicle acquired by the acquisition unit 19. Information about the user is accumulated for each information terminal 95 based on information unique to the information terminal 95, and is analyzed / analyzed to determine the user type. As a method of determining the user type, for example, when there is a lot (or high frequency) of information that the information terminal 95 is operated with large display characters, or when there is a lot of information that a homepage described in text is viewed, the user type of the user or administrator who has transmitted the information can be determined as "1". In addition, when there is a lot of information that the information terminal 95 is operated by frequently using scrolls, flicks, and swipes, or when there is a lot of information that a music distribution site or a video distribution site is viewed, the user type of the user or administrator who has transmitted the information can be determined as "3". Then, the user type of the user or administrator who does not correspond to either user type "1" or "3" can be determined as "2". The user type determined by the determination unit 20 is stored in the storage unit 16 in association with the vehicle and / or user identification information (information terminal 95).

[0021] (2) Information terminal The information terminal 95 is a device such as a smartphone, a personal computer, a network camera (surveillance camera), or a smart speaker owned by a user or manager of the vehicle. This information terminal 95 is connected to the center 10 so as to be able to communicate with the center 10 directly via the network 100 or indirectly via the vehicle. The information terminal 95 of this embodiment transmits information (raw data or processed data) about the user, which is information about the contents (moving images, music, e-mail, etc.) that the user or the like is viewing or operating using the information terminal 95, and the spoken words (phone calls, messages, etc.) of the user or the like, to the center 10. This information terminal 95 is linked to the vehicle by, for example, registering and managing unique information (terminal ID, etc.) in the vehicle. In addition, the unique information (terminal ID, etc.) of this information terminal 95 is linked to user identification information (user ID, etc.). Note that the user ID may be the same as the terminal ID. The number of information terminals 95 linked to the vehicle or user identification information is not limited to one, and may be multiple.

[0022] (3) In-vehicle network The in-vehicle network 90 includes an OTA master 30, a plurality of electronic control units 50a to 50d, a display device 70, and a communication module 80. The OTA master 30 and the communication module 80 are connected via a bus 60a. The OTA master 30 and the electronic control units 50a and 50b are connected via a bus 60b. The OTA master 30 and the electronic control units 50c and 50d are connected via a bus 60c. The OTA master 30 and the display device 70 are connected via a bus 60d.

[0023] The OTA master 30 can communicate wirelessly with the center 10 via the bus 60a and the communication module 80 and the network 100. The OTA master 30 can also communicate wired with the electronic control units 50a to 50d and the display device 70 via the buses 60b to 60d. The OTA master 30 is a device having a function of managing an OTA state, controlling an update sequence, which is a flow of a software update process, and performing software update of an electronic control unit to be updated (hereinafter referred to as a "target electronic control unit"). The OTA master 30 controls software update of the target electronic control unit among the electronic control units 50a to 50d based on update data acquired from the center 10. The OTA master 30 can also control an appropriate screen display on the display device 70 based on information and notifications related to software updates received from the center 10. The OTA master 30 may also be called a central gateway (CGW).

[0024] 4 is a block diagram showing a schematic configuration of the OTA master 30 in FIG. 1. As shown in FIG. 4, the OTA master 30 includes a CPU 31, a RAM 32, a ROM (Read-Only Memory) 33, a storage device 34, and a communication device 36. The CPU 31, the RAM 32, the ROM 33, and the storage device 34 constitute a microcomputer 35. In the OTA master 30, the CPU 31 executes a program read from the ROM 33 by using the RAM 32 as a working area, thereby executing a predetermined process related to software update. The communication device 36 is a device for communicating with the communication module 80, the electronic control units 50a to 50d, and the display device 70, respectively, via the buses 60a to 60d shown in FIG. 1.

[0025] Fig. 5 is a functional block diagram of the OTA master 30 shown in Fig. 4. The OTA master 30 shown in Fig. 5 includes a storage unit 37, a communication unit 38, and a control unit 39. The storage unit 37 is realized by the storage device 34 shown in Fig. 4. The communication unit 38 and the control unit 39 are realized by the CPU 31 shown in Fig. 4 executing a program stored in the ROM 33 using the RAM 32.

[0026] The storage unit 37 stores a program for executing software updates of the electronic control units 50a to 50d (a control program for the OTA master 30), various data used when executing software updates, and software update data downloaded from the center 10. The storage unit 37 can also store information on the type of non-volatile memory mounted in each of the electronic control units 50a to 50d. The storage unit 37 can also store information (such as a terminal ID) of an information terminal 95 linked to the vehicle.

[0027] The communication unit 38 functions as a transmitting unit and a receiving unit that transmits and receives data, information, notifications, requests, and the like to and from the center 10. The communication unit 38 transmits a software update check request to the center 10, for example, when the power of the vehicle is turned on (transmitting unit). The update check request includes, for example, a vehicle ID for identifying the vehicle and information on the current version of the software of the electronic control units 50a to 50d connected to the in-vehicle network 90. ​​The vehicle ID and the current version of the software of the electronic control units 50a to 50d are used to determine whether or not there is update data for the software of the electronic control units 50a to 50d by comparing them with the latest version of the software held by the center 10 for each vehicle ID. In addition, the communication unit 38 receives a notification indicating the presence or absence of update data from the center 10 as a response to the update check request (receiving unit). When there is update data for the software of the electronic control units 50a-50d, the communication unit 38 transmits a download request for a distribution package including the software update data and the like to the center 10 (transmission unit), and receives (downloads) the distribution package transmitted from the center 10 (reception unit). The communication unit 38 also transmits the update status of the software transmitted by the electronic control units 50a-50d to the center 10 (transmission unit). Based on an instruction from the control unit 39, the communication unit 38 can cause the display device 70 to display information related to the software update, a notification related to the transmission of the information, and the update status of the software.

[0028] The control unit 39 judges whether or not there is update data for the software of the electronic control units 50a to 50d, based on a response from the center 10 to the update confirmation request received by the communication unit 38. The control unit 39 also verifies the authenticity of the update data that the communication unit 38 receives (downloads) from the center 10 in a distribution package and stores in the storage unit 37. The control unit 39 also uses the update data downloaded from the center 10 to control the software update process (installation, activation, etc.) of the electronic control units 50a to 50d. Specifically, the control unit 39 transfers the downloaded update data to the target electronic control unit, and causes the target electronic control unit to install update software based on the update data. After the installation is completed, the control unit 39 instructs the target electronic control unit to activate the installed update software.

[0029] The electronic control units 50a to 50d are devices (ECUs) for controlling the operation of each part of the vehicle. Although an example in which the in-vehicle network 90 includes four electronic control units 50a to 50d is shown in Fig. 1, the number of electronic control units is not particularly limited. In addition, the number of buses connecting the electronic control units 50a to 50d to the OTA master 30 is not particularly limited.

[0030] The display device 70 is a device used to perform various displays, such as displaying that there is update data during software update processing of the electronic control units 50a to 50d, displaying an explanation of the software update based on the user type, displaying a consent request screen for requesting consent to the software update from the vehicle user or administrator, and displaying the result and status of the software update. A display device of a car navigation system can typically be used as the display device 70. In this embodiment, the display device 70 receives information and notifications transmitted from the center 10 via the OTA master 30, but the display device 70 may receive the information and notifications directly from the communication module 80 without the OTA master 30, or directly via another communication device (such as a WiFi-DCM) not shown in the figure instead of the communication module 80. In addition to the display device 70, an electronic control unit and the like may be further connected to the bus 60d shown in FIG. 1.

[0031] The communication module 80 is a unit having a function of controlling communication between the center 10 and the vehicle, and is a communication device for connecting the in-vehicle network 90 to the center 10. The communication module 80 is wirelessly connected to the center 10 via the network 100, and performs vehicle authentication by the OTA master 30, downloading update data, and the like. This communication module 80 may be configured as being included in the OTA master 30.

[0032] [Software update process overview] The OTA master 30 transmits a software update check request to the center 10, for example, when the power supply of the vehicle is turned on. The update check request includes a vehicle ID for identifying the vehicle, and vehicle configuration information, which is information on the state (system configuration) of the electronic control units 50a to 50d connected to the in-vehicle network 90, such as the current versions of the hardware and software of the electronic control units 50a to 50d. The vehicle configuration information can be created by acquiring the identification numbers (ECU_ID) of the electronic control units and the identification numbers (ECU_Software_ID) of the software versions of the electronic control units from the electronic control units 50a to 50d connected to the in-vehicle network 90. ​​The vehicle ID and the current versions of the software of the electronic control units 50a to 50d are used to determine whether or not there is update data for the software of the electronic control units 50a to 50d by comparing them with the latest version of the software held by the center 10 for each vehicle ID. In response to the update check request received from the OTA master 30, the center 10 transmits to the OTA master 30 a notification indicating the presence or absence of update data, information on software updates, and the like. When there is update data for the software of the electronic control units 50a to 50d, the OTA master 30 transmits a download request for a distribution package to the center 10. In response to the download request received from the OTA master 30, the center 10 transmits a distribution package including the update data and the like to the OTA master 30. In addition to the update data, the distribution package may include verification data for verifying the authenticity of the update data, the number and type information of update data, various control information used when updating the software, and the like.

[0033] The OTA master 30 determines whether or not there is update data for the software of the electronic control units 50a to 50d, based on the response to the update confirmation request received from the center 10. The OTA master 30 also verifies the authenticity of the distribution package received from the center 10 and stored in the storage device 13. The OTA master 30 also transfers the update data downloaded in the distribution package to the target electronic control unit, and causes the target electronic control unit to install the update data. After the installation is completed, the OTA master 30 instructs the target electronic control unit to activate the installed updated software to make it valid.

[0034] In addition, in the consent request process, the center 10 causes the output device to output information explaining the software update, a notification that consent is required for the software update, and a notification prompting input of consent to the software update. As the output device, a display device 70 or an information terminal 95 provided in the in-vehicle network 90 can be used. For example, in the consent request process, if information to be explained in advance to a vehicle user or administrator can be displayed on the screen of the display device 70, the display device 70 is used as the output device. When the display device 70 is used as the output device, the OTA master 30 can display information about the software update, a consent request screen for requesting consent to the software update from the user or administrator, and a notification prompting a specific input operation such as pressing an consent button if the user or administrator consents, on the display device 70. When the center 10 receives input of consent from the user or administrator via the OTA master 30, it instructs the OTA master 30 to execute the above-mentioned control process of installation and activation, and updates the software of the target electronic control unit.

[0035] Here, if the non-volatile memory of the target electronic control unit is a single bank memory having one storage area for storing data such as software, in principle, installation and activation are performed consecutively, so consent request processing for software update is performed before installation is performed. Note that even if the target electronic control unit is a single bank memory, depending on the information on the update sequence instructed by the center 10, it may be requested to temporarily stop the update processing in the state where installation is completed, that is, to suspend (standby) activation. Also, if the non-volatile memory of the target electronic control unit is a dual bank memory having two storage areas for storing data such as software, consent request processing for software update is performed at least after installation is performed and before activation is performed. Note that if the non-volatile memory of the target electronic control unit is a dual bank memory, consent request processing for software update before installation may be performed or may be omitted.

[0036] The software update process consists of a phase in which the OTA master 30 downloads update data from the center 10 (download phase), a phase in which the OTA master 30 transfers the downloaded update data to the target electronic control unit and installs update software based on the update data in the storage area of ​​the target electronic control unit (installation phase), and a phase in which the target electronic control unit activates the installed update software (activation phase).

[0037] Downloading is a process in which the OTA master 30 receives update data for updating the software of the electronic control unit, which is transmitted from the center 10 in a distribution package, and stores the data in the storage unit 37. When receiving update data by downloading, the download phase not only executes the download, but also includes control of a series of processes related to the download, such as determining whether the download can be executed and verifying the update data.

[0038] The update data transmitted from the center 10 to the OTA master 30 may include update software for the electronic control unit (all data or difference data), compressed data obtained by compressing the update software, or divided data obtained by dividing the update software or the compressed data. The update data may also include the ECU_ID (or serial number) of the target electronic control unit and the ECU_Software_ID of the target electronic control unit before the update. The update data is downloaded as the above-mentioned distribution package, and the distribution package includes update data for a single electronic control unit or multiple electronic control units.

[0039] The installation is a process in which the OTA master 30 writes update software (an updated program) into the non-volatile memory of the target electronic control unit based on the update data downloaded from the center 10. The installation phase not only executes the installation, but also includes control of a series of processes related to the installation, such as judging whether the installation can be executed, transferring the update data, and verifying the update software.

[0040] If the update data includes the update software itself (all data), the OTA master 30 transfers the update data (update software) to the target electronic control unit in the installation phase. If the update data includes compressed data, difference data, or divided data of the update software, the OTA master 30 may transfer the update data to the target electronic control unit and the target electronic control unit may generate the update software from the update data, or the OTA master 30 may generate the update software from the update data and then transfer the update software to the target electronic control unit. Here, the update software can be generated by decompressing the compressed data or assembling (integrating) the difference data or divided data.

[0041] The target electronic control unit can install the update software based on an installation request from the OTA master 30. Note that for a specific target electronic control unit that has received the update data, the installation may be performed autonomously without receiving an explicit instruction from the OTA master 30.

[0042] Activation is a process in which the target electronic control unit activates the update software installed in its own non-volatile memory. The activation phase includes not only the execution of activation, but also a series of controls related to activation, such as judging whether activation can be executed, requesting the vehicle user or administrator to consent to activation, and verifying the execution result.

[0043] The activation of the update software can be performed by the target electronic control unit based on an activation request from the OTA master 30. Note that, for a specific target electronic control unit that has received the update data, the activation may be performed autonomously after the installation is completed, without receiving an explicit instruction from the OTA master 30.

[0044] The software update process can be performed consecutively or in parallel for each of the multiple target electronic control units.

[0045] Furthermore, in this specification, the "software update process" includes not only a process in which download, installation, and activation are all performed consecutively, but also a process in which only some of the download, installation, and activation are performed.

[0046] [process] Next, with further reference to FIG. 6 and FIG. 7, a process relating to software update executed in the network system of this embodiment will be described.

[0047] 6 is a flowchart illustrating an example of a process in which the center 10 sets a user type to be linked to a vehicle or an information terminal 95 based on information about a user acquired from the information terminal 95. The process shown in FIG. 6 is started when the center 10 acquires information about a user from any information terminal 95.

[0048] (Step S601) The center 10 identifies the user or administrator (hereinafter referred to as the "user of the information terminal 95") who uses the information terminal 95 that has transmitted the information about the user. The user of the information terminal 95 can be identified based on unique information, such as the terminal ID of the information terminal 95, transmitted together with the information, and by vehicle and user identification information that are linked to the information terminal 95 and registered for management in advance. When the user of the information terminal 95 is identified, the process proceeds to step S602.

[0049] (Step S602) The center 10 judges whether or not sufficient user-related information has been acquired about the user of the information terminal 95 identified in step S601 above. "Sufficient information has been accumulated" means, for example, that enough information has been accumulated to predict how to explain the update software to the user of the information terminal 95 in a suitable manner by analyzing / parsing the accumulated pieces of information. If sufficient user-related information about the user of the information terminal 95 has been accumulated (step S602, Yes), the process proceeds to step S603. On the other hand, if sufficient user-related information about the user of the information terminal 95 has not yet been accumulated (step S602, No), this process ends.

[0050] (Step S603) The center 10 determines the user type corresponding to the user of the information terminal 95 based on the accumulated information on the user. As explained above in relation to the determination unit 20, the user type can be determined based on the user's preferences and lifestyle, such as what the user has seen and what he or she has spoken about. When the user type of the user of the information terminal 95 is determined, the process proceeds to step S604.

[0051] (Step S604) The center 10 sets the user type determined in the above step S603 as the user type of the user of the information terminal 95 identified in the above step S601 (or the user type of the vehicle linked to the user of the information terminal 95). When the user type is set, this process ends.

[0052] The center 10 repeatedly performs the processes in steps S601 to S604 described above, thereby setting a user type that defines a mode of explanation regarding the software update that is suitable for the user or manager of the vehicle.

[0053] Fig. 7 is a flowchart for explaining an example of a process for distributing an explanation regarding a software update based on a user type, which is performed by the center 10. The process shown in Fig. 7 is started when a request regarding a software update is generated from a vehicle, for example, when the center 10 receives a download request from the OTA master 30.

[0054] (Step S701) The center 10 identifies the vehicle requesting the software update. This identification of the vehicle is possible, for example, by vehicle identification information (vehicle ID) for identifying the vehicle that is transmitted together with the request. When the vehicle requesting the software update is identified, the process proceeds to step S702.

[0055] (Step S702) The center 10 determines the user type set (linked) to the vehicle identified in step S701 above. As a specific example, the center 10 determines whether the user type set to the vehicle is standard or non-standard. In the case of the user type information exemplified in FIG. 8, if the user type is "2", it is determined to be standard, and if the user type is "1" or "3", it is determined to be non-standard. If the user type set to the vehicle is standard (step S702, standard), the process proceeds to step S703. On the other hand, if the user type set to the vehicle is non-standard (step S702, non-standard), the process proceeds to step S704.

[0056] (Step S703) The center 10 selects a predetermined standard (default) software update explanation as a form of software update explanation suitable for the user or manager of the identified vehicle. In the case of the user type information exemplified in Fig. 8, an explanation in the form of user type "2" is selected. When the standard software update explanation is selected, the process proceeds to step S705.

[0057] (Step S704) The center 10 selects an explanation regarding the software update based on the determined user type as a form of explanation regarding the software update suitable for the user or manager of the identified vehicle. In the case of the user type information exemplified in Fig. 8, an explanation in the form of user type "1" or "3" is selected. When an explanation regarding the software update based on the determined user type is selected, the process proceeds to step S705.

[0058] (Step S705) The center 10 distributes the explanation regarding the software update selected in step S703 or S704 to the vehicle identified in step S601. When distributing to the vehicle, explanation data generated each time based on the mode of the explanation regarding the selected software update may be distributed, or explanation data prepared in advance for each mode may be obtained and distributed. When the explanation regarding the selected software update is distributed to the vehicle, this process ends.

[0059] By having center 10 carry out the above-mentioned processing of steps S701 to S705 prior to carrying out the software update, it is possible to provide an explanation regarding the software update using wording and illustrations that suit the individual preferences of the vehicle user or administrator, or content that is appropriate for their level of understanding.

[0060] <Actions and Effects> As described above, according to the center that controls software updates for an electronic control unit mounted on a vehicle according to an embodiment of the present disclosure, an explanation regarding the software update is given to the user, manager, etc. of the vehicle according to a user type that is preset based on information regarding the user related to the user's preferences, lifestyle, habits, etc. This process makes it possible to give an appropriate explanation regarding the software update to the user, manager, etc. of the vehicle.

[0061] Although one embodiment of the disclosed technology has been described above, the present disclosure can be understood not only as a center, but also as a method executed by a center equipped with a processor and memory, a program, a computer-readable non-transitory storage medium storing a program, an OTA master capable of communicating with a center, or a vehicle equipped with an OTA master, etc. [Industrial Applicability]

[0062] The disclosed technique can be used in a center that controls software updates for electronic control units mounted on vehicles. [Explanation of symbols]

[0063] 10 Center 11, 31 CPU 12,32 RAM 13, 34 Storage device 14, 36 Communication equipment 16, 37 Memory section 17, 38 Communications Department 18, 39 Control section 19 Acquisition Department 20 Judgment section 30 OTA Master 33 ROM 35 Microcomputer 50a~50d Electronic Control Unit (ECU) 60a~60d Bus 70 Display device 80 Communication Module 90 In-vehicle network 95 Information terminal 100 Network

Claims

[Claim 1] A center for controlling software updates of an electronic control unit mounted on a vehicle, comprising: A communication unit that communicates between the vehicle and an information terminal associated with the vehicle; an acquisition unit that acquires information about a user of the vehicle from an information terminal associated with the vehicle; a determination unit that determines a user type corresponding to a user of the vehicle based on the information acquired by the acquisition unit; a control unit that distributes an explanation regarding the software update to the vehicle based on the user type determined by the determination unit for the vehicle that is a target of the software update, The control unit is if the user type indicates a standard user, delivering instructions regarding the software update to the vehicle in a first text size and a first graphic; When the user type indicates a user who has difficulty seeing small characters compared to the standard user, an explanation regarding the software update is delivered to the vehicle using a second character size larger than the first character size and a second diagram that is visually easier to understand than the first diagram; If the user type indicates a user who is more familiar with operating the vehicle or smartphone than the standard user, the center delivers to the vehicle an explanation regarding the software update using a third character size smaller than the first character size and a third diagram having a smaller display area than the first diagram.

Images