On-vehicle software management device, on-vehicle software management method and on-vehicle software management program

Abstract

To appropriately manage software mounted in a vehicle.SOLUTION: An on-vehicle software management device is used in an on-vehicle network in a vehicle. The on-vehicle network comprises: an acquisition unit which includes a relay device which performs relay processing of data, and acquires software management information for managing software used in the on-vehicle network; and a determination unit which performs determination processing related to the relay processing of update data which are the data for updating the software, and performs the determination processing, on the basis of the software management information acquired by the acquisition unit.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates to an in-vehicle software management device, an in-vehicle software management method, and an in-vehicle software management program. [Background technology]

[0002] Conventionally, technologies for managing updates to software built into devices have been developed. For example, Patent Document 1 (Japanese Patent Laid-Open Publication No. 2001-265888) discloses the following technology. That is, an information processing device that exchanges information signals with an electronic device includes: control information acquisition means for acquiring, from the electronic device, control information for writing or reading product history information including purchase information or repair information related to the electronic device; control information identification storage means for identifying and storing the control information acquired by the control information acquisition means; and product history update means for updating the product history information stored in the electronic device based on the control information stored by the control information identification storage means. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2001-265888 [Patent Document 2] Japanese Patent Application Laid-Open No. 2009-245169 Summary of the Invention [Problem to be solved by the invention]

[0004] In recent years, development of vehicles known as SDVs (Software Defined Vehicles) has been progressing. SDVs are vehicles that use SDN (Software Defined Network) technology to enable the addition and updating of software used in the in-vehicle network after purchase.

[0005] For example, it is expected that a vehicle with the above-mentioned software added will be sold, and a technique that can appropriately manage the software of such a vehicle is desired.

[0006] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to provide an in-vehicle software management device, an in-vehicle software management method, and an in-vehicle software management program that are capable of properly managing software installed in a vehicle. [Means for solving the problem]

[0007] The in-vehicle software management device disclosed herein is an in-vehicle software management device used in an in-vehicle network in a vehicle, wherein the in-vehicle network includes a relay device that performs data relay processing, and is equipped with an acquisition unit that acquires software management information for managing software used in the in-vehicle network, and a judgment unit that performs judgment processing regarding the relay processing of update data, which is the data for updating the software, and performs the judgment processing based on the software management information acquired by the acquisition unit.

[0008] One aspect of the present disclosure can be realized not only as an in-vehicle software management device equipped with such a characteristic processing unit, but also as a semiconductor integrated circuit that realizes part or all of the in-vehicle software management device, or as a system that includes the in-vehicle software management device. [Effects of the Invention]

[0009] According to the present disclosure, software installed in a vehicle can be appropriately managed. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration of a communication system according to an embodiment of the present disclosure. [Figure 2]FIG. 2 is a diagram illustrating an example of the configuration of an in-vehicle system according to an embodiment of the present disclosure. [Figure 3] FIG. 3 is a diagram illustrating an example of a configuration of a server according to an embodiment of the present disclosure. [Figure 4] FIG. 4 is a diagram illustrating an example of a configuration of a relay device according to an embodiment of the present disclosure. [Figure 5] FIG. 5 is a diagram illustrating an example of SM information stored in a relay device according to an embodiment of the present disclosure. [Figure 6] FIG. 6 is a diagram illustrating an example of an authentication table stored in the server according to the embodiment of the present disclosure. [Figure 7] FIG. 7 is a flowchart illustrating an example of an operation procedure when a relay device according to an embodiment of the present disclosure performs a determination process. [Figure 8] FIG. 8 is a flowchart showing an example of a detailed operation procedure of the determination process shown in FIG. [Figure 9] FIG. 9 is a flowchart illustrating an example of an operation procedure when a relay device according to an embodiment of the present disclosure performs a determination process using authentication result information received from a server. [Figure 10] FIG. 10 is a flowchart illustrating an example of an operation procedure when the server according to the embodiment of the present disclosure performs authentication processing. [Figure 11] FIG. 11 is a diagram illustrating an example of a sequence that defines the operation procedures of each device when a software license is transferred to another vehicle in the communication system according to the embodiment of the present disclosure. [Figure 12] FIG. 12 is a diagram illustrating an example of a sequence that defines the operation procedures of each device when a software license is transferred to another vehicle in the communication system according to the embodiment of the present disclosure. [Figure 13] FIG. 13 is a diagram illustrating an example of a sequence that defines the operation procedures of each device when a software license is transferred to another vehicle in the communication system according to the embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0011] First, the contents of the embodiments of the present disclosure will be listed and described. (1) An in-vehicle software management device according to an embodiment of the present disclosure is an in-vehicle software management device used in an in-vehicle network in a vehicle, the in-vehicle network including a relay device that performs data relay processing, and the device is equipped with an acquisition unit that acquires software management information for managing software used in the in-vehicle network, and a judgment unit that performs judgment processing regarding the relay processing of update data, which is the data for updating the software, and that performs the judgment processing based on the software management information acquired by the acquisition unit.

[0012] In this way, by acquiring SM information and using the acquired SM information to perform a determination process regarding relaying of update data, software used in the in-vehicle network can be managed on a vehicle-by-vehicle basis, allowing for accurate determination of whether the software to be updated is installed in the vehicle. This allows for accurate determination of relaying of update data. Therefore, software installed in the vehicle can be appropriately managed.

[0013] (2) In (1) above, the SM information may include the purchase date and time of the software.

[0014] In this way, by performing the judgment process using software management information including the purchase date and time of the software, it is possible to determine whether the software to be updated is installed in the vehicle based on whether the purchase date and time is registered in the software management information, making it easy to make a judgment regarding the relay of update data.

[0015] (3) In (2) above, the in-vehicle software management device may further include a communication unit that transmits vehicle information, including vehicle identification information for identifying the vehicle and the purchase date and time, to an external device outside the vehicle, and the communication unit may receive authentication result information from the external device indicating the result of the authentication process of the vehicle information by the external device, and the judgment unit may perform the judgment process further based on the authentication result information received by the communication unit.

[0016] With this configuration, it is possible to determine whether the software to be updated is legitimately purchased software based on the results of the authentication process performed by the external device, thereby making it possible to make more accurate decisions regarding the relaying of update data.

[0017] (4) In any of (1) to (3) above, the in-vehicle software management device may further include a transmission unit that, when the software license is transferred from the vehicle to another vehicle, transmits the software management information acquired by the acquisition unit to an external device outside the vehicle and outside the other vehicle.

[0018] With this configuration, software management information obtained in the vehicle from which the license is being transferred can be transferred to the vehicle to which the license is being transferred via an external device, allowing the software that was installed in the vehicle from which the license was being transferred to be managed in the vehicle to which the license is being transferred.

[0019] (5) In any of (1) to (4) above, an external device outside the vehicle may hold the software management information, and the in-vehicle software management device may further include a receiving unit that receives the software management information from the external device and a recording unit that stores the software management information received by the receiving unit in a memory unit.

[0020] With this configuration, SM information held in an external device can be obtained from the external device, making it easy to transfer SM information between vehicles.

[0021] (6) In any one of (1) to (5) above, the in-vehicle software management device may include the relay device.

[0022] This configuration simplifies the configuration of the in-vehicle system because it allows SM information acquisition, decision processing, and update data relay processing to be performed in a single device.

[0023] (7) An in-vehicle software management method according to an embodiment of the present disclosure is an in-vehicle software management method in an in-vehicle software management device used in an in-vehicle network in a vehicle, wherein the in-vehicle network includes a relay device that performs data relay processing, and the in-vehicle software management method includes a step of acquiring software management information for managing software used in the in-vehicle network, and a step of performing a judgment process regarding the relay processing of update data, which is the data for updating the software, and performing the judgment process based on the acquired software management information.

[0024] In this way, by acquiring SM information and using the acquired SM information to perform a decision process regarding relaying of update data, software used in the in-vehicle network can be managed on a vehicle-by-vehicle basis, allowing for accurate determination of whether the software to be updated is installed in the vehicle. This allows for accurate decisions regarding relaying of update data. Therefore, software installed in the vehicle can be appropriately managed.

[0025] (8) An in-vehicle software management program according to an embodiment of the present disclosure is an in-vehicle software management program used in an in-vehicle software management device used in an in-vehicle network in a vehicle, the in-vehicle network including a relay device that performs data relay processing, and the program causes a computer to function as an acquisition unit that acquires software management information for managing software used in the in-vehicle network, and a judgment unit that performs judgment processing regarding the relay processing of update data, which is the data for updating the software, and the judgment unit that performs the judgment processing based on the software management information acquired by the acquisition unit.

[0026] In this way, by acquiring SM information and using the acquired SM information to perform a determination process regarding relaying of update data, software used in the in-vehicle network can be managed on a vehicle-by-vehicle basis, allowing for accurate determination of whether the software to be updated is installed in the vehicle. This allows for accurate determination of relaying of update data. Therefore, software installed in the vehicle can be appropriately managed.

[0027] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In the drawings, identical or corresponding parts are designated by the same reference numerals, and their description will not be repeated. Furthermore, at least some of the embodiments described below may be combined in any manner.

[0028] [Communication Systems] Fig. 1 is a diagram illustrating an example of a configuration of a communication system according to an embodiment of the present disclosure. Referring to Fig. 1, a communication system 501 includes a server 180 and one or more in-vehicle systems 301. The in-vehicle system 301 is mounted on a vehicle 1. The vehicle 1 is, for example, an SDV. The server 180 is provided outside the vehicle 1. The server 180 is an example of an external device.

[0029] 2 is a diagram illustrating an example of a configuration of an in-vehicle system according to an embodiment of the present disclosure. Referring to FIG. 2, the in-vehicle system 301 includes a relay device 101 and a plurality of in-vehicle devices 202. The relay device 101 is an example of an in-vehicle software management device.

[0030] The in-vehicle device 202 is an in-vehicle ECU (Electronic Control Unit), an OTA (Over The Air) master, a sensor, a navigation device, a human-machine interface, a camera, etc. The in-vehicle ECU is a TCU (Telematics Communication Unit), an engine ECU, an automatic driving ECU, a brake control ECU, a steering control ECU, etc.

[0031] The relay device 101 and the multiple on-board devices 202 configure an on-board network 401. The multiple on-board devices 202 are connected to the relay device 101 via a CAN bus 51 that conforms to the CAN (Controller Area Network) standard, for example.

[0032] 2, the in-vehicle system 301 includes in-vehicle devices 202A, 202B, 202C, and 202D that are the in-vehicle device 202. In addition, in the example shown in FIG. 2, CAN buses 51A and 51B are provided as the CAN bus 51.

[0033] The in-vehicle devices 202A and 202B are connected to the relay device 101 via a CAN bus 51A. The in-vehicle devices 202C and 202D are connected to the relay device 101 via a CAN bus 51B.

[0034] The relay device 101 is, for example, a gateway device, and performs a relay process of relaying data transmitted and received between the in-vehicle devices 202.

[0035] For example, each in-vehicle device 202 transmits a CAN frame including various information (described later) such as information for assisting the autonomous driving performed by the vehicle 1 and information used for entertainment, and a CAN-ID (Identifier) ​​indicating the type of data, to another in-vehicle device 202 or the relay device 101. The relay device 101 relays a CAN frame received from one in-vehicle device 202 to another in-vehicle device 202. The relay device 101 also creates a CAN frame including the various information and the CAN-ID, and transmits the created CAN frame to the destination in-vehicle device 202.

[0036] The in-vehicle system 301 is not limited to a configuration in which two CAN buses 51 are provided, and may be a configuration in which one CAN bus 51 or three or more CAN buses 51 are provided.

[0037] In addition, the relay device 101 and the in-vehicle device 202 may be configured to communicate in accordance with a communication protocol such as CAN FD (CAN with Flexible Data Rate), Ethernet (registered trademark), FlexRay (registered trademark), MOST (Media Oriented System Transport) (registered trademark), LIN (Local Interconnect Network), and CXPI (Clock Extension Peripheral Interface) (registered trademark), instead of or in addition to communication in accordance with the CAN standard.

[0038] 2, the in-vehicle device 202A and the in-vehicle device 202B are a TCU and a navigation device, respectively. Hereinafter, the in-vehicle device 202A and the in-vehicle device 202B are also referred to as the TCU 202A and the navigation device 202B, respectively.

[0039] 1 and 2, the TCU 202A communicates with the server 180 via the wireless base station device 161, for example.

[0040] More specifically, the TCU 202A performs wireless communication with the wireless base station device 161 in accordance with a communication standard such as LTE (Long Term Evolution) (registered trademark) or 5G.

[0041] Specifically, when the TCU 202A receives a CAN frame from the relay device 101 or another in-vehicle device 202, the TCU 202A transmits to the wireless base station device 161 a wireless signal including various information included in the received CAN frame.

[0042] When the wireless base station device 161 receives a wireless signal from the TCU 202A, it transmits various information included in the received wireless signal to the server 180 via the external network 151 such as the Internet.

[0043] Furthermore, when the wireless base station device 161 receives an IP packet from the server 180 via the external network 151, the wireless base station device 161 transmits the received IP packet to the TCU 202A in a wireless signal.

[0044] When TCU 202A receives a wireless signal including an IP packet from server 180 from wireless base station device 161, it acquires the IP packet from the received wireless signal, stores the acquired IP packet in a CAN frame, and transmits it to relay device 101.

[0045] The server 180 is, for example, an OTA server. The server 180 holds update data Da for updating software SW used in the in-vehicle network 401. In the in-vehicle network 401, for example, various software SW are installed in the relay device 101 and each in-vehicle device 202. Here, the update data Da is assumed to be a program for updating the software SW installed in the in-vehicle device 202. Specifically, for example, the update data Da is a program for updating software components (hereinafter also simply referred to as "components") that make up the software SW.

[0046] [Problem description] For example, in the in-vehicle network 401 of the vehicle 1, which is an SDV, software SW can be added after the vehicle 1 is purchased.

[0047] In some cases, software is added to a communication terminal device such as a smartphone. In this case, for example, by associating information that identifies the user of the communication terminal device with the ID of the added software, even if the user replaces the communication terminal device, the same software can be used on both the new and old communication terminal devices.

[0048] For example, in the case of a vehicle, if information that can identify the vehicle user is associated with the ID of the added software SW, when the vehicle is sold, the software SW must be uninstalled in advance.

[0049] On the other hand, there are cases where software SW is not transferred between vehicles. Specifically, a user of a vehicle to which software SW has been added may wish to sell the vehicle with the added software SW still installed, i.e., a vehicle with added value. In cases such as when selling a vehicle, a technology that can appropriately manage the vehicle's software SW is desired.

[0050] Therefore, the communication system 501 according to the embodiment of the present disclosure solves the above problem by the following configuration and operation.

[0051] [server] 3 is a diagram illustrating an example of a configuration of a server according to an embodiment of the present disclosure. Referring to FIG. 3, server 180 includes a communication unit 31, an update processing unit 32, an authentication unit 33, a software management unit 34, and a storage unit 35. Some or all of communication unit 31, update processing unit 32, authentication unit 33, and software management unit 34 are implemented by, for example, a processing circuit including one or more processors. Storage unit 35 is, for example, a non-volatile memory included in the processing circuit.

[0052] 1 and 3, communication unit 31 communicates with TCU 202A by transmitting and receiving various information via external network 151 and wireless base station device 161, for example.

[0053] The update processing unit 32 performs an update process of transmitting the update data Da to the in-vehicle device 202 via the communication unit 31 .

[0054] More specifically, for example, when the processing timing T of the update processing arrives, the update processing unit 32 checks whether the update data Da is stored in the storage unit 35 or not.

[0055] Then, when the update data Da is stored in the storage unit 35, the update processing unit 32 outputs the update data Da and component information indicating the name N of the component corresponding to the update data Da to the communication unit 31.

[0056] When the communication unit 31 receives the update data Da and the component information from the update processing unit 32, it divides the update data Da. In the following description, each of the divided pieces of update data Da will also be referred to as divided update data Db.

[0057] For example, the storage unit 35 stores a correspondence table showing the correspondence between vehicle identification information (hereinafter also referred to as "vehicle ID") for identifying a vehicle and the name N of a component.

[0058] After dividing the update data Da into a plurality of divided update data Db, the communication unit 31 refers to the correspondence table in the storage unit 35 to identify the vehicle ID corresponding to the component name N indicated by the component information.

[0059] Then, the communication unit 31 sequentially transmits the plurality of divided update data Db to the TCU 202A. More specifically, for example, the communication unit 31 transmits an IP packet (hereinafter also referred to as a packet P) including the divided update data Db to the TCU 202A.

[0060] Specifically, for example, the communication unit 31 creates packets P that include one piece of divided update data Db and component information received from the update processing unit 32, and that include, as a source IP address and a destination IP address, the IP address of the server 180 and the IP address of the vehicle 1 that corresponds to the identified vehicle ID, respectively. Then, the communication unit 31 transmits each of the created packets P to the TCU 202A.

[0061] The TCU 202A transmits to the relay device 101 a frame including the divided update data Db (hereinafter also referred to as an “update frame”).

[0062] Specifically, for example, every time the TCU 202A receives a packet P from the server 180, the TCU 202A transmits a CAN frame that stores the divided update data Db and component information included in the packet P as an update frame to the relay device 101. In the following description, this CAN frame is also referred to as an update frame F1.

[0063] For example, the divided update data Db included in the packet P is stored in the data field of the update frame F1. Also, the component information included in the packet P is stored in the header portion of the update frame F1, for example, in the control field.

[0064] [Repeater] FIG. 4 is a diagram illustrating an example of a configuration of a relay device according to an embodiment of the present disclosure. Referring to FIG. 4, relay device 101 includes communication ports 60 and 70, a relay unit 11, a processing unit 12, and a storage unit 13. Relay unit 11 includes a buffer 20. Processing unit 12 includes an acquisition unit 21, a determination unit 22, an update management unit 23, a recording unit 24, and a migration unit 25. One or both of relay unit 11 and processing unit 12 are realized, for example, by a processing circuit including one or more processors. Storage unit 13 is, for example, a non-volatile memory included in the processing circuit. Update management unit 23 is an example of a communication unit. Migration unit 25 is an example of a transmission unit and an example of a reception unit.

[0065] The communication port 60 is a connector to which the CAN bus 51 can be connected. In the example shown in Fig. 4, the relay device 101 includes communication ports 60A and 60B, which are the communication ports 60. The communication port 60A is connected to a plurality of in-vehicle devices 202, such as in-vehicle devices 202A and 202B, via the CAN bus 51A. The communication port 60B is connected to a plurality of in-vehicle devices 202, such as in-vehicle devices 202C and 202D, via the CAN bus 51B.

[0066] (Relay section) The relay unit 11 receives a CAN frame transmitted from a certain in-vehicle device 202. Then, the relay unit 11 checks whether the received CAN frame is a CAN frame that the relay unit 101 itself should receive.

[0067] The storage unit 13 stores, for example, a reception list indicating CAN-IDs included in CAN frames that should be received by the own relay device 101. The reception list is registered in the storage unit 13 by the manufacturer of the vehicle 1, for example, when the vehicle 1 is shipped.

[0068] When the relay unit 11 receives a CAN frame, it refers to the reception list in the storage unit 13 to check whether the CAN-ID included in the CAN frame is registered in the reception list.

[0069] For example, if the CAN-ID included in the received CAN frame is not registered in the reception list, the relay unit 11 discards the CAN frame.

[0070] For example, the storage unit 13 stores a routing table indicating the correspondence between the CAN-ID, the device to which the CAN frame is to be transmitted, and the CAN bus 51 to which the device to which the CAN frame is to be transmitted (hereinafter also referred to as the "destination bus"). The routing table is registered in the storage unit 13 by the manufacturer of the vehicle 1, for example, when the vehicle 1 is shipped.

[0071] For example, if the CAN-ID contained in the CAN frame received from the in-vehicle device 202 is registered in the reception list, the relay unit 11 checks the destination device corresponding to the CAN-ID by referring to the routing table in the memory unit 13.

[0072] When the destination device of the received CAN frame is its own relay device 101, the relay unit 11 outputs the CAN frame to the processing unit 12.

[0073] Furthermore, when the destination of the received CAN frame is the in-vehicle device 202, the relay unit 11 determines whether or not the CAN frame is an update frame F1.

[0074] More specifically, for example, if component information is stored in the header of a received CAN frame, the relay unit 11 determines that the CAN frame is an update frame F1. Then, the relay unit 11 stores the CAN frame in the buffer 20 and outputs a reception notification P1 indicating that the update frame F1 has been received to the acquisition unit 21.

[0075] On the other hand, if the component information is not stored in the header portion of the received CAN frame, the relay unit 11 determines that the CAN frame is not an update frame F1. Then, the relay unit 11 relays the CAN frame.

[0076] Specifically, for example, if the received CAN frame is not an update frame F1, the relay unit 11 identifies a destination bus corresponding to the CAN-ID included in the CAN frame by referring to the routing table in the storage unit 13. Then, the relay unit 11 outputs the CAN frame to the identified destination bus.

[0077] (Software Management Information) FIG. 5 is a diagram illustrating an example of SM information stored in a relay device according to an embodiment of the present disclosure.

[0078] 5, storage unit 13 stores software management information M for managing software SW used in in-vehicle network 401. More specifically, software management information M is metadata of software SW, and is, for example, information that can determine whether software SW is to be updated. Software management information M is registered in storage unit 13 by the manufacturer of vehicle 1, for example, when vehicle 1 is shipped.

[0079] 5, the software management information M is a software bill of materials (SBOM) that includes the purchase dates and times when components were purchased by the user of vehicle 1. More specifically, the software management information M indicates the correspondence between the supplier, the component name N, the creation date and time when the component was created, and the purchase date and time.

[0080] In the software management information M shown in FIG. 5, the creation date and time and purchase date and time of the component "Application" supplied by supplier "AAA" are "May 9, 2022, 1:00 PM" and "May 7, 2023, 2:00 PM," respectively. The creation date and time and purchase date and time of the component "Browser" supplied by supplier "BBB" are "April 18, 2022, 3:00 PM" and "April 17, 2023, 1:00 PM," respectively. The creation date and time and purchase date and time of the component "Compression Engine" supplied by supplier "CCC" are "May 9, 2022, 1:10 PM" and "November 12, 2023, 3:00 PM," respectively. The creation date and purchase date of the component "Protocol" supplied by the supplier "DDD" are "2022-05-09 13:30" and "2023-12-05 10:00", respectively.

[0081] (Acquisition Department) 4, acquisition unit 21 acquires SM information M. More specifically, upon receiving reception notification P1 from relay unit 11, acquisition unit 21 reads SM information M from storage unit 13.

[0082] Acquiring unit 21 then checks whether component name N indicated by component information included in update frame F1 held in buffer 20 is registered in SM information M or not.

[0083] If the name N of a component indicated by the component information contained in the update frame F1 stored in the buffer 20 is registered in the software management information M, the acquisition unit 21 outputs confirmation result information K1 indicating the name N and the purchase date and time corresponding to the name N to the judgment unit 22 and the update management unit 23.

[0084] On the other hand, if the name N of the component indicated by the component information contained in the update frame F1 stored in the buffer 20 is not registered in the software management information M, the acquisition unit 21 outputs confirmation result information K2 indicating that the name N is not registered in the software management information M to the judgment unit 22.

[0085] (Update Management Department) For example, the update management unit 23 transmits to the server 180 vehicle information E1 including vehicle identification information (hereinafter also referred to as "vehicle ID") for identifying the vehicle 1 and the purchase date and time of the component.

[0086] For example, the storage unit 13 stores a vehicle ID. The vehicle ID is an ID unique to each vehicle 1.

[0087] For example, when the update management unit 23 receives confirmation result information K1 from the acquisition unit 21, it transmits vehicle information E1, which includes the vehicle ID stored in the memory unit 13, as well as the name N of the component and the purchase date and time of the component indicated in the confirmation result information K1, to the server 180 via the relay unit 11 and TCU202A.

[0088] Referring back to FIG. 3, in server 180, communication unit 31 receives vehicle information E1 from relay device 101 via TCU 202A, and outputs the received vehicle information E1 to authentication unit 33.

[0089] (Authentication Table) FIG. 6 is a diagram illustrating an example of an authentication table stored in the server according to the embodiment of the present disclosure.

[0090] 3 and 6, in server 180, storage unit 35 stores authentication table Tb indicating correspondence relationships between vehicle IDs, component names N, and purchase dates and times of the components. Authentication table Tb is registered in storage unit 35 by, for example, a user of server 180.

[0091] In the authentication table Tb shown in FIG. 6, the components used in the in-vehicle network 401 of the vehicle 1 with the vehicle ID "001" are the component "Application" purchased at 14:00 on May 7, 2023, and the component "Browser" purchased at 13:00 on April 17, 2023. The components used in the in-vehicle network 401 of the vehicle 1 with the vehicle ID "002" are the component "Application" purchased at 11:00 on July 7, 2023, and the component "Compression Engine" purchased at 15:00 on August 11, 2023.

[0092] (Authentication process for vehicle information E1) The authentication unit 33 performs authentication processing of the vehicle information E1. More specifically, for example, when the authentication unit 33 receives the vehicle information E1 from the communication unit 31, the authentication unit 33 reads out an authentication table Tb in the storage unit .

[0093] Then, the authentication unit 33 checks whether a set C of the vehicle ID, the component name N, and the purchase date and time of the component, which is included in the vehicle information E1 received from the communication unit 31, is registered in the authentication table Tb.

[0094] The authentication unit 33 transmits authentication result information indicating the result of the authentication process to the relay device 101. Specifically, when the group C is registered in the authentication table Tb, the authentication unit 33 transmits authentication success information indicating that the authentication of the vehicle information E1 has been successful as authentication result information to the relay device 101 via the communication unit 31 and the TCU 202A.

[0095] On the other hand, if group C is not registered in the authentication table Tb, the authentication unit 33 transmits authentication failure information indicating that authentication of the vehicle information E1 has failed as authentication result information to the relay device 101 via the communication unit 31 and TCU 202A.

[0096] Referring back to FIG. 4, in relay device 101, when update management unit 23 receives authentication result information from server 180 via TCU 202A and relay unit 11, it outputs the received authentication result information to determination unit 22.

[0097] (Decision-making process) For example, determination unit 22 performs a determination process regarding relay processing of divided update data Db based on SM information M acquired by acquisition unit 21 and authentication result information received by update management unit 23.

[0098] More specifically, for example, when the judgment unit 22 receives confirmation result information K1 from the acquisition unit 21 and also receives authentication success information from the update management unit 23 as authentication result information, it determines to relay the update frame F1 including the divided update data Db.

[0099] Then, the determining unit 22 outputs relay request information B1 to the relay unit 11, which indicates a request to relay the update frame F1 held in the buffer 20.

[0100] For example, the storage unit 13 stores a device table indicating the correspondence between device identification information (hereinafter also referred to as "device ID") for identifying the in-vehicle device 202 and the component name N. The device table is registered in the storage unit 13 by the manufacturer of the vehicle 1, for example, when the vehicle 1 is shipped.

[0101] When the relay unit 11 receives the relay request information B1 from the determination unit 22, it performs relay processing of the update frame F1 held in the buffer 20.

[0102] More specifically, for example, when the relay unit 11 receives relay request information B1 from the determination unit 22, it refers to the device table in the storage unit 13 to identify a device ID corresponding to the component name N included in the update frame F1 stored in the buffer 20. Then, the relay unit 11 transmits the update frame F1 to the in-vehicle device 202 with the identified device ID.

[0103] Furthermore, the relay unit 11 determines that other update frames F1 that include the same name N as the name N of a component included in the relayed update frame F1 are frames to be relayed, and performs relay processing on them.

[0104] On the other hand, when the decision unit 22 receives the confirmation result information K2 from the acquisition unit 21 or receives the authentication failure information from the update management unit 23 as the authentication result information, it decides not to relay the update frame F1.

[0105] Then, the decision unit 22 outputs to the relay unit 11 relay disable information W1 indicating that the update frame F1 held in the buffer 20 will not be relayed.

[0106] When the relay unit 11 receives the relay disable information W1 from the determination unit 22, it discards the update frame F1 held in the buffer 20.

[0107] Furthermore, the relay unit 11 determines that other update frames F1 that include the same name N as the name N of a component included in the discarded update frame F1 are not frames to be relayed, and discards them.

[0108] [Updating components using the diagnostic tool] 2 and 4, the communication port 70 in the relay device 101 is a connector to which the Ethernet cable 52 can be connected. The communication port 70 is connected to the diagnostic tool 250 via the Ethernet cable 52.

[0109] The diagnostic tool 250 is a device used to update components that make up the software SW and to diagnose the in-vehicle device 202. The diagnostic tool 250 is provided outside the in-vehicle network 401 and is used, for example, at a dealer of the vehicle 1.

[0110] Information is exchanged using Ethernet frames between the relay device 101 and the diagnostic tool 250. For example, the diagnostic tool 250 transmits to the relay device 101 an Ethernet frame that includes various types of information, which will be described later.

[0111] The diagnostic tool 250 holds the update data Da. For example, a dealer's worker operates the diagnostic tool 250 to transmit the update data Da to the relay device 101.

[0112] Specifically, for example, when updating a component, an operator at a dealer inputs update request information into the diagnostic tool 250, which indicates a request to transmit update data Da.

[0113] When the diagnostic tool 250 receives update request information input by a user, it divides the update data Da it holds into a plurality of divided update data Db, and then transmits the plurality of divided update data Db to the relay device 101 in sequence.

[0114] More specifically, for example, the diagnostic tool 250 transmits to the relay device 101 an update frame including the divided update data Db.

[0115] Specifically, for example, the diagnostic tool 250 transmits, as an update frame, an Ethernet frame that stores one piece of divided update data Db and component information indicating the name N of the component that corresponds to that divided update data Db, to the relay device 101. In the following description, this Ethernet frame is also referred to as an update frame F2.

[0116] For example, the divided update data Db is stored in the payload of the update frame F2, and the component information is stored in the header portion of the update frame F2.

[0117] In the relay device 101, the relay unit 11 receives an Ethernet frame transmitted from the diagnostic tool 250. When the relay unit 11 receives the Ethernet frame from the diagnostic tool 250, it determines whether the received Ethernet frame is an update frame F2.

[0118] More specifically, for example, if component information is stored in the header portion of a received Ethernet frame, the relay unit 11 determines that the Ethernet frame is an update frame F2. Then, the relay unit 11 stores the Ethernet frame in the buffer 20 and outputs a reception notification P2 indicating that the update frame F2 has been received to the acquisition unit 21.

[0119] On the other hand, if the component information is not stored in the header portion of the received Ethernet frame, the relay unit 11 determines that the Ethernet frame is not an update frame F2. Then, the relay unit 11 relays the Ethernet frame.

[0120] More specifically, for example, the relay unit 11 performs relay processing involving conversion of a communication protocol. Specifically, for example, when the relay unit 11 receives a frame from the diagnostic tool 250 in accordance with the Ethernet communication standard, the relay unit 11 changes the format of the received frame to a format in accordance with the CAN communication standard, and transmits the format-changed frame to the destination in-vehicle device 202 in accordance with the CAN communication standard.

[0121] Upon receiving reception notification P2 from relay unit 11, acquirer 21 reads SM information M from storage unit 13.

[0122] Acquiring unit 21 then checks whether component name N indicated by component information contained in update frame F2 held in buffer 20 is registered in SM information M.

[0123] If the name N of a component indicated by the component information contained in the update frame F2 stored in the buffer 20 is registered in the software management information M, the acquisition unit 21 outputs to the judgment unit 22 confirmation result information K3 indicating the name N and the purchase date and time corresponding to the name N.

[0124] On the other hand, if the name N of the component indicated by the component information contained in the update frame F2 stored in the buffer 20 is not registered in the software management information M, the acquisition unit 21 outputs confirmation result information K4 to the judgment unit 22 indicating that the name N is not registered in the software management information M.

[0125] When the determination unit 22 receives the confirmation result information K3 from the acquisition unit 21, it determines that the update frame F2 held in the buffer 20 should be relayed.

[0126] Then, the decision unit 22 outputs to the relay unit 11 relay request information B2 requesting that the update frame F2 be relayed.

[0127] When the relay unit 11 receives the relay request information B2 from the determination unit 22, it refers to the device table in the storage unit 13 to identify the device ID corresponding to the component name N included in the update frame F2 stored in the buffer 20. Then, the relay unit 11 changes the format of the update frame F2 to a format that complies with the CAN communication standard, and transmits the updated update frame F2 after the change in format to the in-vehicle device 202 with the identified device ID.

[0128] Furthermore, the relay unit 11 determines that other update frames F2 that include the same name N as the name N of a component included in the relayed update frame F2 are frames to be relayed, and performs relay processing on them.

[0129] On the other hand, when the determination unit 22 receives the confirmation result information K4 from the acquisition unit 21, it determines not to relay the update frame F2.

[0130] Then, the decision unit 22 outputs to the relay unit 11 relay disable information W2 indicating that the update frame F2 held in the buffer 20 will not be relayed.

[0131] When the relay unit 11 receives the relay disable information W2 from the determination unit 22, it discards the update frame F2 held in the buffer 20.

[0132] Furthermore, the relay unit 11 determines that other update frames F2 that include the same name N as the name N of the component included in the discarded update frame F2 are not frames to be relayed, and discards them.

[0133] [Operation flow] Next, the flow of operations of each device in the communication system 501 according to the embodiment of the present disclosure will be described with reference to the drawings.

[0134] FIG. 7 is a flowchart illustrating an example of an operation procedure when a relay device according to an embodiment of the present disclosure performs a determination process.

[0135] 7, first, relay device 101 waits for reception of a frame from in-vehicle device 202 or diagnostic tool 250 (NO in step ST101).

[0136] Next, when the relay device 101 receives a frame from the in-vehicle device 202 or the diagnostic tool 250 (YES in step ST101), the relay device 101 determines whether the received frame is an update frame (step ST102).

[0137] If the received frame is not an update frame (NO in step ST102), relay device 101 processes the frame. For example, as described above, relay device 101 performs relay processing of the frame (step ST103) and waits for reception of a new frame from in-vehicle device 202 or diagnostic tool 250 (NO in step ST101).

[0138] On the other hand, if the received frame is an update frame (YES in step ST102), the relay device 101 checks whether or not relaying of the update frame has been permitted (step ST104).

[0139] Next, if the relay device 101 does not allow the received update frame to be relayed (NO in step ST104), it checks whether the received update frame contains a name N that is the same as the name N of a component contained in the update frame that has been determined not to be relayed (step ST105).

[0140] If the received update frame contains a name N that is the same as the name N of a component contained in an update frame that has been determined to be unrelayable (YES in step ST105), the relay device 101 discards the received update frame (step ST106) and waits to receive a new frame from the in-vehicle device 202 or the diagnostic tool 250 (NO in step ST101).

[0141] On the other hand, if the received update frame contains a name N different from the name N of the component contained in the update frame that has been determined not to be relayable (NO in step ST105), the relay device 101 holds the received update frame. For example, as described above, the relay device 101 saves the received update frame in the buffer 20 (step ST107).

[0142] Next, the relay device 101 performs a determination process regarding relaying of the update frame (step ST108), and waits for reception of a new frame from the in-vehicle device 202 or the diagnostic tool 250 (NO in step ST101).

[0143] Furthermore, if the relay device 101 has already been permitted to relay the received update frame (YES in step ST104), it relays the update frame (step ST109) and waits to receive a new frame from the in-vehicle device 202 or the diagnostic tool 250 (NO in step ST101).

[0144] FIG. 8 is a flowchart showing an example of a detailed operation procedure of the determination process shown in FIG.

[0145] Referring to FIG. 8, first, relay device 101 reads SM information M from storage unit 13 (step ST201).

[0146] Next, relay device 101 refers to SM information M to check whether name N of a component included in the update frame held in buffer 20 is registered in SM information M (step ST202).

[0147] Then, if the name N of the component contained in the update frame stored in the buffer 20 is not registered in the software management information M (NO in step ST202), the relay device 101 decides not to relay the update frame (step ST203).

[0148] Next, relay device 101 discards the update frame held in buffer 20 (step ST204), and receives a new frame from in-vehicle device 202 or diagnostic tool 250 (step ST101 shown in FIG. 7).

[0149] On the other hand, if the name N of the component contained in the update frame stored in the buffer 20 is registered in the software management information M (YES in step ST202), the relay device 101 determines whether the device that sent the update frame is the diagnostic tool 250 (step ST205).

[0150] If the device that is the transmission source of the update frame held in the buffer 20 is the diagnostic tool 250 (YES in step ST205), the relay device 101 determines to relay the update frame (step ST206).

[0151] Next, the relay device 101 relays the update frame held in the buffer 20 (step ST207), and receives a new frame from the in-vehicle device 202 or the diagnostic tool 250 (step ST101 shown in FIG. 7).

[0152] On the other hand, if the device that sent the update frame stored in the buffer 20 is not the diagnostic tool 250 but the server 180 (NO in step ST205), the relay device 101 checks whether vehicle information E1, which includes the vehicle ID, the name N of the component to be updated, and the purchase date and time of the component, has already been sent to the server 180 (step ST208).

[0153] If the relay device 101 has already transmitted the vehicle information E1 to the server 180 (YES in step ST208), the relay device 101 receives a new frame from the in-vehicle device 202 or the diagnostic tool 250 (step ST101 shown in FIG. 7).

[0154] On the other hand, if the relay device 101 has not transmitted the vehicle information E1 to the server 180 (NO in step ST208), it transmits the vehicle information E1 to the server 180 (step ST209) and receives a new frame from the in-vehicle device 202 or the diagnostic tool 250 (step ST101 shown in FIG. 7).

[0155] FIG. 9 is a flowchart illustrating an example of an operation procedure when a relay device according to an embodiment of the present disclosure performs a determination process using authentication result information received from a server.

[0156] 9, first, relay device 101 transmits vehicle information E1 to server 180 (step ST301), similarly to the contents described in step ST209 shown in FIG.

[0157] Next, relay device 101 waits for reception of authentication result information from server 180 (NO in step ST302).

[0158] Next, when relay device 101 receives authentication result information from server 180 (YES in step ST302), relay device 101 checks whether the received authentication result information indicates that the authentication process of vehicle information E1 has been successful (step ST303).

[0159] Then, if the authentication result information received from server 180 indicates that the authentication process of vehicle information E1 has been successful (YES in step ST303), relay device 101 determines to relay the update frame held in buffer 20 (step ST304).

[0160] Next, relay device 101 relays the update frame held in buffer 20 (step ST305).

[0161] On the other hand, if the authentication result information received from server 180 indicates a failure in the authentication process of vehicle information E1 (NO in step ST303), relay device 101 decides not to relay the update frame held in buffer 20 (step ST306).

[0162] Then, relay device 101 discards the update frame held in buffer 20 (step ST307).

[0163] FIG. 10 is a flowchart illustrating an example of an operation procedure when the server according to the embodiment of the present disclosure performs authentication processing.

[0164] Referring to FIG. 10, first, server 180 waits for the arrival of processing timing T for the update processing (NO in step ST401).

[0165] Next, when the processing timing T arrives (YES in step ST401), the server 180 checks whether the update data Da for the components that make up the software SW is stored in the storage unit 35 (step ST402).

[0166] Then, if the update data Da is stored in the storage unit 35 (YES in step ST402), the server 180 transmits the update data Da to the vehicle 1 equipped with the component corresponding to the update data Da. For example, as described above, the server 180 divides the update data Da stored in the storage unit 35 into a plurality of divided update data Db, and sequentially transmits the plurality of divided update data Db to the vehicle 1 (step ST403).

[0167] Next, the server 180 waits for reception of the vehicle information E1 from the vehicle 1 (NO in step ST404).

[0168] Next, when the server 180 receives the vehicle information E1 from the vehicle 1 (YES in step ST404), the server 180 performs authentication processing of the vehicle information E1. For example, as described above, the server 180 checks whether the set C of the vehicle ID, the component name N, and the purchase date and time of the component, which is included in the received vehicle information E1, is registered in the authentication table Tb in the storage unit 35 (step ST405).

[0169] If the group C is registered in the authentication table Tb (YES in step ST405), the server 180 transmits authentication success information indicating that the authentication of the vehicle information E1 has been successful to the vehicle 1 (step ST406).

[0170] On the other hand, if the group C is not registered in the authentication table Tb (NO in step ST406), the server 180 transmits authentication failure information indicating that the authentication of the vehicle information E1 has failed to the vehicle 1 (step ST407).

[0171] Furthermore, if the update data Da is not stored in the storage unit 35 (NO in step ST402), the server 180 waits for the next processing timing T to arrive (NO in step ST401).

[0172] 11 to 13 are diagrams illustrating an example of a sequence that defines the operation procedures of each device when a software license is transferred to another vehicle in a communication system according to an embodiment of the present disclosure. FIG. 12 illustrates a continuation of the operation flow illustrated in FIG. 11, and FIG. 13 illustrates a continuation of the operation flow illustrated in FIG. 12. In the following description, the vehicle 1 from which the software SW license is transferred will also be referred to as vehicle 1A, and the vehicle 1 to which the license is transferred will also be referred to as vehicle 1B. Furthermore, the relay device 101 mounted on vehicle 1A and the relay device 101 mounted on vehicle 1B will also be referred to as relay device 101A and relay device 101B, respectively. Furthermore, it is assumed that multiple software SWs are used in the in-vehicle networks 401 in each of vehicles 1A and 1B.

[0173] 3, 4, and 11 to 13, first, the navigation device 202B in the vehicle 1A accepts license transfer information input by the user and transmits the input license transfer information to the relay device 101A. The license transfer information is information indicating that the license of the software SW is to be transferred from the vehicle 1A to the vehicle 1B (step ST501).

[0174] Next, in the relay device 101A, when the transfer unit 25 receives the license transfer information from the navigation device 202B via the relay unit 11, it transmits the vehicle information E11 including the vehicle ID stored in the memory unit 35 and the received license transfer information to the server 180 via the relay unit 11 and the TCU 202 (step ST502).

[0175] Next, in server 180, when software management unit 34 receives vehicle information E11 from relay device 101A via TCU 202A and communication unit 31, it transmits a request notification R11 to relay device 101A via communication unit 31 and TCU 202A indicating a request to transmit software management information M (step ST503).

[0176] Next, in relay device 101A, when the license of software SW is transferred from vehicle 1A to vehicle 1B, transfer unit 25 transmits SM information M acquired by acquisition unit 21 to server 180. More specifically, for example, when transfer unit 25 receives request notification R11 from server 180 via TCU 202A and relay unit 11, transfer unit 25 transmits vehicle information E12 including the vehicle ID and SM information M stored in memory unit 35 to server 180 via relay unit 11 and TCU 202 (step ST504).

[0177] Next, in server 180, upon receiving vehicle information E12 from relay device 101A via TCU 202A and communication unit 31, software management unit 34 performs a registration process to store SM information M included in the received vehicle information E12 in storage unit 35. For example, storage unit 35 stores a user table indicating the correspondence between vehicle IDs and identification information for identifying users of vehicle 1 (hereinafter also referred to as "user IDs"). Upon receiving vehicle information E12 from relay device 101A, software management unit 34 identifies the user ID corresponding to the vehicle ID included in the vehicle information E12 by referring to the user table in storage unit 35. Then, the identified user ID is associated with the SM information M included in the vehicle information E12 and stored in storage unit 35 (step ST505).

[0178] Next, SM unit 34 transmits request notification R12 requesting deletion of SM information M to relay device 101A via communication unit 31 and TCU 202A (step ST506).

[0179] Next, in the relay device 101A, when the transition unit 25 receives a request notification R12 from the server 180 via the TCU 202A and the relay unit 11, it transmits uninstallation request information requesting the uninstallation of the software SW to the in-vehicle device 202 (hereinafter also referred to as "in-vehicle device A11") in which the software SW is incorporated via the relay unit 11 (step ST507).

[0180] Next, when the in-vehicle apparatus A11 receives the uninstallation request information from the relay apparatus 101A, the in-vehicle apparatus A11 uninstalls the software SW installed in the in-vehicle apparatus A11 (step ST508).

[0181] Next, the in-vehicle apparatus A11 transmits uninstallation completion information indicating that the uninstallation of the software SW has been completed to the relay apparatus 101 (step ST509).

[0182] Next, in the relay device 101, when the transition unit 25 receives uninstallation completion information from all vehicle-mounted devices A11 to which the uninstallation request information was sent via the relay unit 11, it performs a deletion process to delete the software management information M stored in the memory unit 13 (step ST510).

[0183] Next, the transition unit 25 transmits vehicle information E13, which includes the vehicle ID stored in the memory unit 13 and deletion completion information indicating that the software management information M has been deleted, to the server 180 via the relay unit 11 and the TCU 202 (step ST511).

[0184] Next, in server 180, upon receiving vehicle information E13 from relay device 101A via TCU 202A and communication unit 31, software management unit 34 transmits authentication information for authenticating a user to relay device 101A via communication unit 31 and TCU 202A. For example, the authentication information includes a user ID and a password (step ST512).

[0185] Next, in the relay device 101A, when the relay unit 11 receives the authentication information from the server 180 via the TCU 202A, it transmits the received authentication information to the navigation device 202B (step ST513).

[0186] Next, upon receiving the authentication information from the relay device 101A, the navigation device 202B performs notification processing based on the received authentication information. Specifically, for example, the navigation device 202B displays on its display unit a screen G1 indicating the user ID and password included in the authentication information received from the relay device 101A. This allows the user of the vehicle 1A to understand the authentication information (step ST514).

[0187] Next, the navigation device 202B in the vehicle 1B accepts the input of license transfer information by the user of the vehicle 1B and transmits the input license transfer information to the relay device 101B (step ST515). Here, it is assumed that the user of the vehicle 1B is the same as the user of the vehicle 1A.

[0188] Next, in the relay device 101B, when the transfer unit 25 receives the license transfer information from the navigation device 202B via the relay unit 11, it transmits the vehicle information E21 including the vehicle ID stored in the memory unit 35 and the received license transfer information to the server 180 via the relay unit 11 and the TCU 202 (step ST516).

[0189] Next, in the server 180, when the software management unit 34 receives the vehicle information E21 from the relay device 101B via the TCU 202A and the communication unit 31, it transmits a request notification R21 to the relay device 101B via the communication unit 31 and the TCU 202A, indicating a request to send authentication information (step ST517).

[0190] Next, in the relay device 101B, when the relay unit 11 receives the request notification R21 from the server 180 via the TCU 202A, it transmits the received request notification R21 to the navigation device 202B (step ST518).

[0191] Next, when the navigation device 202B receives the request notification R21 from the relay device 101B, it displays on its own display unit a screen G2 for requesting input of authentication information in accordance with the received request notification R21 (step ST519).

[0192] Next, the navigation device 202B accepts the input of authentication information by the user, and transmits the input authentication information to the relay device 101B (step ST520).

[0193] Next, in the relay device 101B, when the transition unit 25 receives authentication information from the navigation device 202B via the relay unit 11, it transmits vehicle information E22 including the vehicle ID stored in the memory unit 13 and the received authentication information to the server 180 via the relay unit 11 and the TCU 202A (step ST521).

[0194] Next, in server 180, when software management unit 34 receives vehicle information E22 from relay device 101B via TCU 202A and communication unit 31, software management unit 34 authenticates the user using the authentication information included in the received vehicle information E22. Here, it is assumed that software management unit 34 has successfully authenticated the user (step ST522).

[0195] Next, if software management unit 34 succeeds in authenticating the user, it transmits download request information indicating names N of multiple components registered in software management information M in storage unit 35 and multiple URLs (Uniform Resource Locators) corresponding to the multiple components to relay device 101B via communication unit 31 and TCU 202A. The URLs indicate the download sources of the components (step ST523).

[0196] Next, in the relay device 101B, when the relay unit 11 receives download request information from the server 180 via the TCU 202A, it refers to the device table in the memory unit 13 to identify the device ID corresponding to each name N of the component indicated in the received download request information (step ST524).

[0197] Next, the relay unit 11 transmits URL information U1 including a URL corresponding to each name N of a component indicated in the received download request information to the in-vehicle unit 202 (hereinafter also referred to as "in-vehicle unit A21") with the identified device ID (step ST525).

[0198] Next, when the in-vehicle device A21 receives the URL information U1 from the relay device 101B, the in-vehicle device A21 accesses the URL included in the received URL information U1 via the TCU 202A and the external network 151, and downloads the component (step ST526).

[0199] Next, the in-vehicle apparatus A21 transmits download completion information indicating the name N of the downloaded component to the relay apparatus 101B (step ST527).

[0200] Next, in the relay device 101B, when the relay unit 11 receives download completion information from one or more in-vehicle devices A21 during a period Q from when the URL information U1 is transmitted to the plurality of in-vehicle devices A21 until a predetermined time has elapsed, the relay unit 11 outputs the received download completion information to the transition unit 25. The transition unit 25 transmits vehicle information E23, which includes the vehicle ID stored in the storage unit 13 and the name N of the component indicated by each piece of download completion information received from the relay unit 11 during the period Q, to the server 180 via the relay unit 11 and the TCU 202A (step ST528).

[0201] Next, in server 180, upon receiving vehicle information E23 from relay device 101B via TCU 202A and communication unit 31, software management unit 34 reads software management information M from storage unit 35. Software management unit 34 then performs a comparison process to compare component names N registered in software management information M with component names N included in vehicle information E23 received from relay device 101B. Here, it is assumed that some of the component names N registered in software management information M are not included in vehicle information E23 received from relay device 101B (step ST529).

[0202] Next, software management unit 34 updates software management information M. For example, software management unit 34 deletes from software management information M any entry that includes the name N of a component that is not included in vehicle information E23 (step ST530).

[0203] Next, SMI 34 transmits the updated SMI information M to relay device 101B via communication unit 31 and TCU 202A (step ST531). If all of the component names N registered in SMI M are included in vehicle information E23 received from relay device 101B, SMI 34 does not update SMI information M, but transmits the updated SMI information M to relay device 101B via communication unit 31 and TCU 202A.

[0204] Next, in relay device 101B, migration unit 25 receives SM information M from server 180 via TCU 202A and relay unit 11. Migration unit 25 then outputs the received SM information M to recording unit 24. For example, recording unit 24 stores SM information M received by migration unit 25 in memory unit 13 (step ST532).

[0205] Next, recording unit 24 transmits a storage completion notice indicating that SM information M has been stored to server 180 via relay unit 11 and TCU 202A (step ST533).

[0206] Next, in server 180, software management unit 34 transmits update information indicating that software management information M has been updated and the name N of a component not included in vehicle information E23 to relay device 101A via communication unit 31 and TCU 202A (step ST534).

[0207] Next, in the relay device 101A, when the relay unit 11 receives the update information from the server 180 via the TCU 202A, it transmits the received update information to the navigation device 202B (step ST535).

[0208] Next, when the navigation device 202B receives the update information from the relay device 101A, the navigation device 202B displays a screen G3 based on the received update information on its display unit. For example, the navigation device 202B displays the name N of the component indicated by the update information on the screen G3 (step ST536).

[0209] Next, the navigation device 202B accepts an input of restoration request information by the user and transmits the input restoration request information to the relay device 101A. The restoration request information is information indicating a request to reinstall the component with the name N displayed on the navigation device 202B (step ST537).

[0210] Next, in the relay device 101A, when the transition unit 25 receives the restoration request information from the navigation device 202B via the relay unit 11, it transmits vehicle information E31 including the vehicle ID stored in the memory unit 13 and the received restoration request information to the server 180 via the relay unit 11 and the TCU 202A (step ST538).

[0211] Next, in the server 180, when the software management unit 34 receives the vehicle information E31 from the relay device 101A via the TCU 202A and the communication unit 31, it transmits a request notification R31 to the relay device 101A via the communication unit 31 and the TCU 202A, requesting the transmission of authentication information (step ST539).

[0212] Next, in the relay device 101A, when the relay unit 11 receives the request notification R31 from the server 180 via the TCU 202A, it transmits the received request notification R31 to the navigation device 202B (step ST540).

[0213] Next, when the navigation device 202B receives the request notification R31 from the relay device 101A, it displays a screen G4 for requesting input of authentication information on its own display unit in accordance with the received request notification R31 (step ST541).

[0214] Next, the navigation device 202B accepts the input of authentication information by the user, and transmits the input authentication information to the relay device 101A (step ST542).

[0215] Next, in the relay device 101A, when the transition unit 25 receives authentication information from the navigation device 202B via the relay unit 11, it transmits vehicle information E32 including the vehicle ID stored in the memory unit 13 and the received authentication information to the server 180 via the relay unit 11 and the TCU 202A (step ST543).

[0216] Next, in server 180, when software management unit 34 receives vehicle information E32 from relay device 101A via TCU 202A and communication unit 31, software management unit 34 authenticates the user using the authentication information included in the received vehicle information E32. Here, it is assumed that software management unit 34 has successfully authenticated the user (step ST544).

[0217] Next, if the software management unit 34 successfully authenticates the user, it sends re-download information indicating the name N of the component not included in the vehicle information E23 received from the relay device 101B and the URL indicating the download source of the component to the relay device 101A via the communication unit 31 and TCU202A (step ST545).

[0218] Next, in the relay device 101A, when the transition unit 25 receives the re-download information from the server 180 via the TCU 202A and the relay unit 11, it identifies the device ID corresponding to the component name N indicated in the received re-download information by referring to the device table in the memory unit 13 (step ST546).

[0219] Next, the transition unit 25 transmits URL information U2 indicating the URL indicated by the received re-download information to the vehicle-mounted device 202 (hereinafter also referred to as "vehicle-mounted device A12") with the identified device ID via the relay unit 11 (step ST547).

[0220] Next, upon receiving the URL information U2 from the relay device 101A, the in-vehicle device A12 accesses the URL indicated by the received URL information U2 via the TCU 202A and the external network 151, and downloads the component (step ST548).

[0221] In in-vehicle system 301 according to the embodiment of the present disclosure, SM information M stored in relay device 101 includes the purchase date and time of the component, but this is not limited to this. SM information M may include other information other than the purchase date and time that can be used to determine whether software SW is subject to update.

[0222] In addition, in-vehicle system 301 according to the embodiment of the present disclosure, storage unit 35 in relay device 101 is configured to store SM information M, but this is not limited to this. A device other than relay device 101 may also store SM information M. In this case, relay device 101 obtains SM information M from the other device.

[0223] Furthermore, in in-vehicle system 301 according to the embodiment of the present disclosure, relay device 101 is configured to make a decision regarding relaying update frame F1 based on SM information M stored in memory unit 13 and authentication result information received from server 180, but this is not limited to this. Relay device 101 may also be configured to make a decision using SM information M without using authentication result information.

[0224] Furthermore, in communication system 501 according to the embodiment of the present disclosure, relay device 101 is configured to transmit SM information M to server 180 when a license for software SW is transferred from vehicle 1 to another vehicle 1, but this is not limited to this. Relay device 101 may be configured not to transmit SM information M to server 180 when the license is transferred from vehicle 1 to another vehicle 1.

[0225] Furthermore, in communication system 501 according to the embodiment of the present disclosure, when a license for software SW is transferred from vehicle 1 to another vehicle 1, relay device 101 in the other vehicle 1 receives SM information M from server 180 and stores the received SM information M in storage 13. However, this is not limited to this. Relay device 101 may also be configured not to receive SM information M from server 180. In this case, for example, relay device 101 acquires various information related to software SW, such as component name N, through user input operations, and creates SM information M based on the acquired information. Relay device 101 then stores the created SM information M in storage 13.

[0226] In addition, in the in-vehicle system 301 according to the embodiment of the present disclosure, the relay device 101 is configured to include the acquisition unit 21, the determination unit 22, the update management unit 23, the recording unit 24, and the migration unit 25, but this is not limited to this. A device other than the relay device 101 in the in-vehicle network 401 may be configured to include some or all of the acquisition unit 21, the determination unit 22, the update management unit 23, the recording unit 24, and the migration unit 25.

[0227] The above-described embodiments should be considered to be illustrative in all respects and not restrictive. The scope of the present invention is defined by the claims, not by the above description, and is intended to include all modifications within the meaning and scope of the claims.

[0228] Each process (each function) in the above-described embodiments is realized by a processing circuit including one or more processors. The processing circuit may be configured as an integrated circuit or the like that combines one or more memories, various analog circuits, and various digital circuits in addition to the one or more processors. The one or more memories store programs (instructions) that cause the one or more processors to execute each of the processes. The one or more processors may execute each of the processes according to the programs read from the one or more memories, or according to logic circuits pre-designed to execute each of the processes. The processor may be various processors suitable for computer control, such as a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), a DSP (Digital Signal Processor), an FPGA (Field Programmable Gate Array), and an ASIC (Application Specific Integrated Circuit). Note that the physically separate processors may execute each of the processes in cooperation with each other. For example, the processors mounted on a plurality of physically separated computers may cooperate with each other to execute the above processes via a network such as a LAN (Local Area Network), a WAN (Wide Area Network), the Internet, etc. The program may be installed into the memory from an external server device or the like via the network, or may be distributed in a state stored on a recording medium such as a CD-ROM (Compact Disc Read Only Memory), a DVD-ROM (Digital Versatile Disc Read Only Memory), or a semiconductor memory, and installed into the memory from the recording medium.

[0229] The above description includes the following additional features. [Appendix 1] An in-vehicle software management device used in an in-vehicle network in a vehicle, the in-vehicle network includes a relay device that performs a data relay process; processing circuitry; The processing circuitry acquiring software management information for managing software used in the in-vehicle network; an in-vehicle software management device that performs a determination process regarding the relay process of update data, which is the data for updating the software, and performs the determination process based on the acquired SM information; [Explanation of symbols]

[0230] Vehicles 1, 1A, 1B 11 Relay Section 12 Processing section 13,35 Storage section 20 buffers 21 Acquisition Department 22 Judgment Department 23 Update Management Department 24 Recording section 25 Transition 31 Communications Department 32 Update processing section 33 Authentication Section 34 Software Management Department 51, 51A, 51B CAN bus 52 LAN cable 60, 60A, 60B, 70 communication ports 101 Relay device 151 External Network 161 Wireless base station equipment 180 servers 202,202A,202B,202C,202D Vehicle equipment 250 Diagnostic Tool 301 In-Vehicle Systems 401 In-Vehicle Network 501 Communication Systems

Claims

1. An in-vehicle software management device used in an in-vehicle network in a vehicle, the in-vehicle network includes a relay device that performs a data relay process; an acquisition unit that acquires software management information for managing software used in the in-vehicle network; An in-vehicle software management device comprising: a judgment unit that performs judgment processing regarding the relay processing of update data, which is the data for updating the software, and the judgment unit performs the judgment processing based on the software management information acquired by the acquisition unit.

2. The in-vehicle software management device according to claim 1 , wherein the software management information includes a purchase date and time of the software.

3. The in-vehicle software management device further a communication unit that transmits vehicle information including vehicle identification information for identifying the vehicle and the purchase date and time to an external device outside the vehicle; the communication unit receives, from the external device, authentication result information indicating a result of an authentication process of the vehicle information performed by the external device; The in-vehicle software management device according to claim 2 , wherein the determination unit performs the determination process further based on the authentication result information received by the communication unit.

4. The in-vehicle software management device further 3. The in-vehicle software management device of claim 1, further comprising a transmission unit that transmits the software management information acquired by the acquisition unit to an external device outside the vehicle and outside the other vehicle when the software license is transferred from the vehicle to another vehicle.

5. an external device outside the vehicle holds the SM information; The in-vehicle software management device further a receiving unit for receiving the SM information from the external device; 3. The in-vehicle software management device according to claim 1, further comprising: a recording unit that stores the SM information received by the receiving unit in a memory unit.

6. The in-vehicle software management device according to claim 1 , further comprising the relay device.

7. 1. An in-vehicle software management method in an in-vehicle software management device used in an in-vehicle network in a vehicle, comprising: the in-vehicle network includes a relay device that performs a data relay process; The in-vehicle software management method includes: acquiring software management information for managing software used in the in-vehicle network; an in-vehicle software management method including a step of performing a judgment process regarding the relay process of update data, which is the data for updating the software, and performing the judgment process based on the acquired software management information.

8. An in-vehicle software management program used in an in-vehicle software management device used in an in-vehicle network in a vehicle, the in-vehicle network includes a relay device that performs a data relay process; Computer, an acquisition unit that acquires software management information for managing software used in the in-vehicle network; a determination unit that performs a determination process regarding the relay process of update data, which is the data for updating the software, based on the SM information acquired by the acquisition unit; An in-vehicle software management program that functions as a

Images