In-vehicle device, program, and information processing method

Abstract

An in-vehicle device that is communicatively connected to multiple in-vehicle ECUs mounted on a vehicle, comprising a control unit that processes frames transmitted and received between the in-vehicle ECUs, the control unit acquires information about the software executed in each of the multiple in-vehicle ECUs, identifies the frames to be transmitted and received when the software is executed based on the acquired software information, identifies a transmitting ECU to transmit the identified frames and a receiving ECU to receive them, acquires frame definition information in the transmitting ECU and frame definition information in the receiving ECU, generates a frame conversion rule based on the frame definition information in the transmitting ECU and the frame definition information in the receiving ECU, converts the frames from the transmitting ECU using the generated frame conversion rule, and outputs the converted frames to the receiving ECU. [Effect] This device can provide an in-vehicle device that generates frame conversion rules.

Description

Technical Field

[0001] The present invention relates to an in-vehicle device, a program, and an information processing method.

Background Art

[0002] Vehicles are equipped with an ECU (Electronic Control Unit) for controlling in-vehicle devices such as a drive control system for engine control and a body system for air conditioner control. The ECU includes an arithmetic processing unit such as an MPU, a rewritable non-volatile storage unit such as an EEPROM, and a communication unit for communicating with other ECUs, and controls the in-vehicle devices by reading and executing a control program stored in the storage unit. Further, a communication device having a wireless communication function is mounted on the vehicle, and communicates with a program providing device connected to an external network via the communication device, downloads (receives) the control program of the ECU from the program providing device, and can update the control program of the ECU (see, for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, the communication device (relay device) of Patent Document 1 does not consider at all the generation of frame conversion rules based on the frame definition information in the transmitting ECU and the frame definition information in the receiving ECU in the frame transmitted and received when software is executed by the in-vehicle ECU.

[0005] The purpose of this disclosure is to provide an in-vehicle device, etc., that can generate frame conversion rules based on frame definition information in the transmitting ECU and frame definition information in the receiving ECU when software is executed in an in-vehicle ECU. [Means for solving the problem]

[0006] An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device that is communicably connected to a plurality of in-vehicle ECUs mounted on a vehicle, and includes a control unit that processes frames transmitted and received between the in-vehicle ECUs, the control unit acquires information about software executed in each of the plurality of in-vehicle ECUs, identifies the frames transmitted and received when the software is executed based on the acquired information about the software, identifies a transmitting ECU that transmits the identified frames and a receiving ECU that receives them, acquires definition information about the frames in the transmitting ECU and acquires definition information about the frames in the receiving ECU, generates a frame conversion rule based on the frame definition information in the transmitting ECU and the frame definition information in the receiving ECU, converts the frames from the transmitting ECU using the generated frame conversion rule, and outputs the converted frames to the receiving ECU. [Effects of the Invention]

[0007] According to one aspect of this disclosure, an in-vehicle device can be provided that generates frame conversion rules based on frame definition information in a transmitting ECU and frame definition information in a receiving ECU when software is executed in an in-vehicle ECU. [Brief explanation of the drawing]

[0008] [Figure 1] This is a schematic diagram illustrating the configuration of an in-vehicle system including an in-vehicle device according to Embodiment 1. [Figure 2] This is a block diagram illustrating the physical configuration of an in-vehicle device. [Figure 3] This flowchart illustrates the processing (main) of the control unit of an in-vehicle device. [Figure 4] This flowchart illustrates the processing performed by the control unit of an in-vehicle device (identifying the updated ECU). [Figure 5] This is an explanatory diagram illustrating information about the software implemented in an in-vehicle ECU (ECU software version list). [Figure 6] This flowchart illustrates the processing performed by the control unit of an in-vehicle device (identifying differences in the frame definition version). [Figure 7] This is an explanatory diagram illustrating the information (ECU communication definition information) related to frames transmitted and received when software is executed in an updated ECU. [Figure 8] This is an explanatory diagram illustrating the combinations of in-vehicle ECUs that send and receive frames (Vehicle Communication Definition List). [Figure 9] This is an explanatory diagram illustrating information about frames transmitted and received when software is executed on the other ECU (ECU communication definition information). [Figure 10] This is an explanatory diagram illustrating the differences in frame definition versions (frame transmission / reception comparison table). [Figure 11] This flowchart illustrates the processing (generation of conversion rules) by the control unit of an in-vehicle device. [Figure 12] This is an explanatory diagram illustrating matters related to frames with different definition versions (frame version difference table). [Figure 13] This is an explanatory diagram illustrating the definition information (frame definition information) that defines the communication specification items of a frame. [Figure 14] This flowchart illustrates the processing performed by the control unit of an in-vehicle device (determining whether an identifier can be converted). [Figure 15] This is an explanatory diagram illustrating the matters related to determining whether an identifier can be converted (conversion rule creation work table). [Figure 16] This flowchart illustrates the processing (determination of whether period conversion is possible) of the control unit of an in-vehicle device. [Figure 17] It is an explanatory diagram illustrating matters related to determination of whether cycle conversion is possible (conversion rule creation work sheet). [Figure 18] It is a flowchart illustrating the processing of the control unit of the in-vehicle device (determination of whether data length conversion is possible). [Figure 19] It is an explanatory diagram illustrating matters related to determination of whether data length conversion is possible (conversion rule creation work sheet). [Figure 20] It is a flowchart illustrating the processing of the control unit of the in-vehicle device (determination of whether signal conversion is possible). [Figure 21] It is an explanatory diagram illustrating matters related to determination of whether signal conversion is possible (conversion rule creation work sheet). [Figure 22] It is an explanatory diagram illustrating matters related to the generated conversion rule (conversion rule table). [Figure 23] It is a flowchart illustrating the processing of the control unit of the in-vehicle device (relay processing).

Embodiments for Carrying Out the Invention

[0009] [Description of Embodiments of the Present Disclosure] First, embodiments of the present disclosure will be listed and described. Also, at least a part of the embodiments described below may be arbitrarily combined.

[0010] (1) An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device that is communicably connected to a plurality of in-vehicle ECUs mounted on a vehicle, and includes a control unit that processes frames transmitted and received between the in-vehicle ECUs, the control unit acquires information about software executed in each of the plurality of in-vehicle ECUs, identifies the frames transmitted and received when the software is executed based on the acquired information about the software, identifies a transmitting ECU that transmits the identified frames and a receiving ECU that receives them, acquires definition information about the frames in the transmitting ECU, acquires definition information about the frames in the receiving ECU, generates a frame conversion rule based on the frame definition information in the transmitting ECU and the frame definition information in the receiving ECU, converts the frames from the transmitting ECU using the generated frame conversion rule, and outputs the converted frames to the receiving ECU.

[0011] In this embodiment, the in-vehicle device may be communicatively connected to a plurality of in-vehicle ECUs mounted in the vehicle and function as a relay device that relays frames (communication data) transmitted and received between these in-vehicle ECUs. Furthermore, the in-vehicle device may be communicatively connected to an external server such as an OTA (Over The Air) server located outside the vehicle and function as a reprogramming master that updates the software implemented in an in-vehicle ECU by applying an update program (software) obtained from the external server to one of the multiple in-vehicle ECUs mounted in the vehicle. The control unit of the in-vehicle device acquires and aggregates information about the software implemented in each individual in-vehicle ECU from all in-vehicle ECUs mounted in the vehicle at predetermined timings, such as when the IG switch is turned off or on. The control unit of the in-vehicle device further identifies one or more frames transmitted and received by the in-vehicle ECU when the software is executed in the in-vehicle ECU. For each identified frame, the control unit of the in-vehicle device identifies the in-vehicle ECU (transmitting ECU, receiving ECU) that transmits or receives the frame. The control unit of the in-vehicle device may, for example, identify the vehicle ECU that sends and receives a frame with a frame name, according to the frame name that uniquely identifies the type of each frame, by referring to a list of vehicle communication definitions stored in the memory unit. The control unit of the in-vehicle device obtains definition information, which defines the communication specification items of the frame, from each of the in-vehicle ECUs that transmit or receive the frame (transmitting ECU, receiving ECU). The control unit of the in-vehicle device generates frame conversion rules based on the definition information obtained from the transmitting ECU and the definition information obtained from the receiving ECU, so that the generation of said conversion rules can be performed efficiently and the processing required for the generation of said conversion rules can be automated. In other words, the control unit of the in-vehicle device can perform the processing related to the generation of conversion rules based on communication with the in-vehicle ECU within the vehicle, and the processing or control can be completed within the vehicle.Furthermore, the control unit of the in-vehicle device can generate conversion rules in a timely manner when the software of any of the in-vehicle ECUs is updated (version upgraded), and can flexibly respond to such software updates. The control unit of the in-vehicle device uses these automatically generated conversion rules to convert frames from the transmitting ECU and output (relay) them to the receiving ECU. Therefore, even if compatibility is lost due to differences in the software versions implemented in the transmitting ECU and the receiving ECU, communication between the transmitting ECU and the receiving ECU can be established.

[0012] (2) An in-vehicle device according to one aspect of the present disclosure wherein the information relating to the software includes the version of the software, and the control unit identifies an updated ECU in which the software has been updated based on the version of the software, and identifies the frame that is transmitted and received when the software implemented in the identified updated ECU is executed.

[0013] In this embodiment, the control unit of the in-vehicle device acquires and aggregates software information, such as the software model (software part number) or version, from all in-vehicle ECUs installed in the vehicle, for example, when the IG switch is turned off. The control unit of the in-vehicle device may store the software information aggregated from each of these in-vehicle ECUs in the storage unit of the in-vehicle device, for example, in a table format (ECU software version list). Then, for example, when the IG switch is turned on, the control unit of the in-vehicle device communicates with each of the in-vehicle ECUs listed (registered) in the ECU software version list and acquires and aggregates software information from each of these in-vehicle ECUs. By comparing the software information aggregated previously with the software information aggregated this time, the control unit of the in-vehicle device can identify the in-vehicle ECU whose software version has been updated. In other words, if the in-vehicle ECU is replaced, or the software implemented in the in-vehicle ECU is rewritten or updated, between the time the IG switch was last turned off and the time it is now turned on, the in-vehicle ECU with the updated software version can be identified by extracting the difference between the software information collected last time and the software information collected this time. Based on this, the control unit of the in-vehicle device can identify the frames that are transmitted and received when the software implemented in the identified updated ECU is executed, thereby efficiently identifying the frames affected by the software version update, and efficiently generating conversion rules that correspond only to those frames (frames affected by the software version update).

[0014] (3) An in-vehicle device according to one aspect of the present disclosure includes information relating to the software, which includes the version of the frame transmitted and received when the software is executed, and the control unit generates a frame conversion rule if the version of the frame in the transmitting ECU and the version of the frame in the receiving ECU are different.

[0015] In this embodiment, the software information obtained from each in-vehicle ECU includes the versions of one or more frames transmitted and received when the software is executed in the in-vehicle ECU. That is, by executing the software implemented in the in-vehicle ECU, the in-vehicle ECU generates and transmits a frame of one type (frame name) and receives a frame of another type (frame name). In this case, these transmitted and received frames are defined by the frame name, version (defined version), and transmit / receive flag (1: transmit, 0: receive), and in the case of reception, a conversion tolerance may also be assigned. The control unit of the in-vehicle device determines that frame conversion processing is necessary if the frame versions are different in each in-vehicle ECU (transmitting ECU, receiving ECU) that transmit and receive frames with the same frame name, and generates a frame conversion rule. The control unit of the in-vehicle device determines that frame conversion processing is unnecessary if the frame versions are the same in each in-vehicle ECU (transmitting ECU, receiving ECU) that transmit and receive frames with the same frame name, and does not generate a frame conversion rule. When the software implemented in the in-vehicle ECU is updated in this way, it is expected that there will be multiple types of frames (frame names) that the software will process. By generating conversion rules for each individual frame type (frame name), the availability of the conversion rules can be ensured or improved.

[0016] (4) An in-vehicle device according to one aspect of the present disclosure includes a plurality of communication specification items in the frame definition information, and the control unit determines whether there are differences in each of the communication specification items included in the frame definition information of the transmitting ECU and the receiving ECU, and generates the conversion rule according to the communication specification items that have differences.

[0017] In this embodiment, the frame definition information transmitted and received when software is executed in the in-vehicle ECU includes multiple communication specification items. The frame definition information will differ depending on the frame version, and it is assumed that differences will occur in only some of the multiple communication specification items included in the definition information. The control unit of the in-vehicle device determines whether there are differences in each of the communication specification items included in the frame definition information of the transmitting ECU and the receiving ECU when the version number of the frame (frame name) in the transmitting ECU and the version number of the frame (frame name) in the receiving ECU are different for each of the in-vehicle ECUs (transmitting ECU and receiving ECU) that transmit and receive the same type of frame (frame with the same frame name). Then, the control unit of the in-vehicle device extracts the communication specification items that have differences and generates a conversion rule for each of the one or more extracted communication specification items. Therefore, the control unit of the in-vehicle device may either not include communication specification items that do not have differences in the conversion rule, or generate a conversion rule that explicitly states that conversion is unnecessary. In this way, by including only the communication specification items in the frame definition information that have differing due to differences in frame versions in the conversion rule, the conversion rule can be generated efficiently.

[0018] (5) An in-vehicle device according to one aspect of the present disclosure, wherein the communication specification item includes the frame identifier, and the control unit generates the conversion rule including a provision to convert the frame identifier of the transmitting ECU to the frame identifier of the receiving ECU if the frame identifiers of the transmitting ECU and the receiving ECU are different.

[0019] In this embodiment, the communication specification items included in the frame definition information include, for example, a frame identifier such as CANID (message ID) in CAN (Controller Area Network) or CANFD. The frame identifier is not limited to CANID (message ID) in CAN, etc., and may be, for example, a TCP port number or a UDP port number if the communication protocol is Ethernet®. The control unit of the in-vehicle device generates a conversion rule that includes a provision to convert the frame identifier (CANID, etc.) of the transmitting ECU to the frame identifier (CANID, etc.) of the receiving ECU if the frame identifiers (CANID, etc.) differ between the transmitting ECU and the receiving ECU when the same type of frame (frame with the same frame name) is transmitted and received by the in-vehicle ECUs (transmitting ECU, receiving ECU). By generating a conversion rule in this way, even if the identifiers of frames (frames with the same frame name) transmitted and received when the software is executed become different between the transmitting ECU and the receiving ECU due to the influence of updated software, communication between the transmitting ECU and the receiving ECU can be established.

[0020] (6) An in-vehicle device according to one aspect of the present disclosure includes a communication specification item that includes the period of the frame, and the control unit generates the conversion rule, which includes converting the period of the frame of the transmitting ECU to the period of the frame of the receiving ECU if the period of the frame of the transmitting ECU is shorter than the period of the frame of the receiving ECU, or if the receiving ECU allows a difference in period.

[0021] In this embodiment, the communication specification items included in the frame definition information include the frame period (transmission / reception period). That is, the frame period corresponds to the frame transmission period in the transmitting ECU and to the frame reception period in the receiving ECU. The control unit of the in-vehicle device generates a conversion rule that includes a provision to convert the frame period (transmission period) of the transmitting ECU to the frame period (reception period) of the receiving ECU if the frame periods (transmission / reception periods) differ between the in-vehicle ECUs (transmitting ECU and receiving ECU) that transmit and receive the same type of frame (frames with the same frame name). In this case, if the frame period (transmission period) of the transmitting ECU is shorter than the frame period (reception period) of the receiving ECU (tolerance for change: acceptable as long as there is no loss of information), the control unit of the in-vehicle device may output (relay) the frame from the transmitting ECU to the receiving ECU in accordance with the receiving ECU's period (reception period). Thus, if the frame period (transmission period) of the transmitting ECU is shorter than the frame period (reception period) of the receiving ECU, the amount of information processed per unit time will be greater for the transmitting ECU (sender) than for the receiving ECU (receiver). Therefore, even if the amount of information for the transmitting ECU (sender) is reduced to match the amount of information for the receiving ECU (receiver), the information will be updated (transmitted from the transmitting ECU) more frequently than the information update cycle expected by the receiving ECU (receiver), so no information loss will occur in the amount of information acquired by the receiving ECU (receiver). Alternatively, the control unit of the in-vehicle device may output (relay) the frame from the transmitting ECU to the receiving ECU in accordance with the receiving ECU's period (reception period), even if the frame period (transmission period) of the transmitting ECU is not shorter than the frame period (reception period) of the receiving ECU, i.e., longer, as long as the receiving ECU can tolerate the difference in period (tolerance for change: always acceptable). By generating conversion rules in this way, even if the period (transmission / reception period) of frames (frames with the same frame name) transmitted and received when the software is executed differs between the transmitting ECU and the receiving ECU due to the effects of the updated software, communication between the transmitting ECU and the receiving ECU can still be established.

[0022] (7) An in-vehicle device according to one aspect of the present disclosure includes a communication specification item which includes the data length of the frame which the control unit generates the conversion rule which includes a provision which converts the data length of the frame of the transmitting ECU to the data length of the frame of the receiving ECU if the data length of the frame of the transmitting ECU is longer than the data length of the frame of the receiving ECU, or if the receiving ECU allows a difference in data length.

[0023] In this embodiment, the communication specification items included in the frame definition information include the data length of the frame. The control unit of the in-vehicle device generates a conversion rule that includes a provision to convert the data length of the frame of the transmitting ECU to the data length of the frame of the receiving ECU if the data length of the frame, i.e., the data length of the payload contained in the frame, differs between the transmitting ECU and the receiving ECU, which transmit and receive frames of the same type (frames with the same frame name). In this case, if the data length of the transmitting ECU is longer than the data length of the frame of the receiving ECU (tolerance for change: acceptable as long as there is no loss of information), the control unit of the in-vehicle device may output (relay) the data length of the frame from the transmitting ECU to the receiving ECU, matching it to the data length of the receiving ECU. In this way, if the data length of the frame of the transmitting ECU is longer than the data length of the frame of the receiving ECU, the amount of information processed per unit time will be greater for the transmitting ECU (transmitter) than for the receiving ECU (receiver). Therefore, even if the amount of information from the transmitting ECU (transmitter) is reduced to the amount of information from the receiving ECU (receiver), it will still be larger than the data length expected by the receiving ECU (receiver), so no data loss will occur in the amount of information acquired by the receiving ECU (receiver). Alternatively, the control unit of the in-vehicle device may output (relay) the frame from the transmitting ECU to the receiving ECU, adjusting it to the data length of the receiving ECU, even if the data length of the transmitting ECU is not larger than that of the receiving ECU, i.e., smaller, provided that the receiving ECU allows for a difference in data length (tolerance for change: always allowed). By generating conversion rules in this way, even if the data length of frames transmitted and received (frames with the same frame name) differs between the transmitting ECU and the receiving ECU due to the influence of updated software, communication between the transmitting ECU and the receiving ECU can be established.

[0024] (8) An in-vehicle device according to one aspect of the present disclosure includes, in which the communication specification item includes the resolution of the data contained in the frame, and the control unit generates the conversion rule including a provision to convert the resolution of the frame of the transmitting ECU to the resolution of the frame of the receiving ECU if the resolution of the frame of the transmitting ECU is finer than the resolution of the frame of the receiving ECU, or if the receiving ECU allows for a difference in resolution.

[0025] In this embodiment, the communication specification items included in the frame definition information include the resolution of the data (measured value) contained in the frame. The data is, for example, a measured value or signal value measured, detected, or output by various sensors connected to the transmitting ECU, and the resolution is a value according to the characteristics or specifications of the sensor. The resolution is composed of, for example, a physical unit such as mm or cm, and a resolution value expressed in numerical values ​​corresponding to the physical unit, and an offset value may also be considered. In this case, the value of the signal output from the sensor may be calculated by subtracting the offset value from the value obtained by dividing the physical value by the resolution value, so "signal value = (physical value / resolution) - offset value". The control unit of the in-vehicle device generates a conversion rule that includes converting the resolution of the frame of the transmitting ECU to the resolution of the frame of the receiving ECU when the resolution of the data stored in the payload of the frame differs in each of the in-vehicle ECUs (transmitting ECU, receiving ECU) that transmit and receive the same type of frame (frame with the same frame name). In this case, if the resolution of the transmitting ECU is finer than the frame resolution of the receiving ECU (tolerance for change: acceptable as long as there is no loss of information), the control unit of the in-vehicle device may adjust the resolution of the frame from the transmitting ECU to match the resolution of the receiving ECU and output (relay) it to the receiving ECU. In this way, if the frame resolution of the transmitting ECU is finer than the frame resolution of the receiving ECU, the amount of information processed per unit time will be greater for the transmitting ECU (transmitter) than for the receiving ECU (receiver). Therefore, even if the amount of information from the transmitting ECU (transmitter) is reduced to match the amount of information from the receiving ECU (receiver), it will still be finer than the resolution expected by the receiving ECU (receiver), and no loss of information will occur in the amount of information acquired by the receiving ECU (receiver). Alternatively, the control unit of the in-vehicle device may output (relay) frames from the transmitting ECU to the receiving ECU, adjusted to the receiving ECU's resolution, even if the receiving ECU tolerates the difference in resolution (tolerance for change: always acceptable), provided that the receiving ECU does not have a finer resolution than the receiving ECU.By generating conversion rules in this way, even if the resolution of frames transmitted and received (frames with the same frame name) differs between the transmitting ECU and the receiving ECU due to the effects of updated software, communication between the transmitting ECU and the receiving ECU can still be established.

[0026] (9) In an in-vehicle device according to one aspect of the present disclosure, the control unit extracts communication specification items in a plurality of communication specification items included in the frame definition information that differ between the transmitting ECU and the receiving ECU, determines whether conversion is possible in the communication specification items that differ, and interrupts the process of generating the conversion rule if there are any communication specification items that cannot be converted.

[0027] In this embodiment, the control unit of the in-vehicle device extracts differences in the communication specification items of a frame in each of the in-vehicle ECUs (transmitting ECU, receiving ECU) that transmit and receive frames of the same type (frames with the same frame name). The communication specification items include, for example, the frame identifier, period, data length, resolution, and the start position (start bit number) and end position (end bit number) when the data (values ​​of individual signals) is stored. The control unit of the in-vehicle device determines whether conversion is possible for each of the one or more extracted communication specification items. If the control unit of the in-vehicle device determines that conversion is possible for all differing communication specification items, it generates a conversion rule. If the control unit of the in-vehicle device determines that conversion is not possible for any of the differing communication specification items, it interrupts the process of generating the conversion rule. If the process is interrupted in this way without generating a conversion rule, the control unit of the in-vehicle device outputs to an HMI (Human Machine Interface) device, such as a display, that the in-vehicle ECU with updated software (updated ECU) is invalid. In this case, the control unit of the in-vehicle device may, along with the notification indicating that the updated ECU is invalid, also notify the user of matters related to the version change, such as reverting the software version of the updated ECU to its previous version. It is expected that differences may occur in one or more communication specification items due to differences in the version (definition version) of the frame in each in-vehicle ECU (transmitting ECU, receiving ECU) that sends and receives the same type of frame (frame with the same frame name). In this case, if it is determined that conversion is not possible for any one of the differing communication specification items, the control unit of the in-vehicle device will interrupt the process of generating the conversion rule and output a notification indicating that the updated ECU is invalid. Therefore, if a conversion rule is generated, it can be ensured that the generated conversion rule corresponds to all differing communication specification items, and if no conversion rule is generated, it can efficiently notify the vehicle operator that the in-vehicle ECU with updated software (updated ECU) is invalid.

[0028] (10) A program according to one aspect of the present disclosure is communicated with a plurality of in-vehicle ECUs mounted in a vehicle and causes a computer that processes frames transmitted and received between the in-vehicle ECUs to obtain information about software executed in each of the plurality of in-vehicle ECUs, identify the frames transmitted and received when the software is executed based on the obtained information about the software, identify a transmitting ECU that transmits the identified frames and a receiving ECU that receives them, obtain definition information of the frames in the transmitting ECU and definition information of the frames in the receiving ECU, generate a frame conversion rule based on the frame definition information in the transmitting ECU and the frame definition information in the receiving ECU, convert the frames from the transmitting ECU using the generated frame conversion rule, and output the converted frames to the receiving ECU.

[0029] In this embodiment, a program is provided that causes a computer to be executed as an in-vehicle device that efficiently identifies an ECU when applying an additional program obtained from an external server to one of the ECUs installed in the vehicle.

[0030] (11) An information processing method according to one aspect of the present disclosure involves a computer that is communicatively connected to a plurality of in-vehicle ECUs mounted in a vehicle and performs processing relating to frames transmitted and received between the in-vehicle ECUs, which then performs processing relating to software executed in each of the plurality of in-vehicle ECUs, identifies the frames transmitted and received when the software is executed based on the acquired information relating to the software, identifies a transmitting ECU that transmits the identified frames and a receiving ECU that receives them, acquires definition information of the frames in the transmitting ECU and acquires definition information of the frames in the receiving ECU, generates a frame conversion rule based on the frame definition information in the transmitting ECU and the frame definition information in the receiving ECU, converts the frames from the transmitting ECU using the generated frame conversion rule, and outputs the converted frames to the receiving ECU.

[0031] In this embodiment, an information processing method is provided that causes a computer to be executed as an in-vehicle device that efficiently identifies an ECU when applying an additional program obtained from an external server to one of the ECUs installed in the vehicle.

[0032] [Details of the Embodiments of the Invention] The present invention will be specifically described based on the drawings illustrating its embodiments. An in-vehicle device 2 according to an embodiment of this disclosure will be described below with reference to the drawings. However, the present invention is not limited to these examples and is intended to include all modifications within the meaning and scope equivalent to the claims as indicated by the claims.

[0033] (Embodiment 1) The embodiments will be described below with reference to the drawings. Figure 1 is a schematic diagram illustrating the configuration of an in-vehicle system including an in-vehicle device according to Embodiment 1. Figure 2 is a block diagram illustrating the physical configuration of the in-vehicle device. The in-vehicle system S includes an external communication device 1 and an in-vehicle device 2 mounted on the vehicle C, and transmits additional programs (OTA modules) obtained from an external server SV1 (program provider, OTA server) connected via an external network N to the in-vehicle ECU 3 (Electronic Control Unit) mounted on the vehicle C.

[0034] The external server SV1 is a computer, such as a server, connected to an external network N, such as the Internet or a public telephone network. It is equipped with storage such as RAM (Random Access Memory), ROM (Read Only Memory), or a hard disk, and corresponds to an external program delivery device. The external server SV1 stores programs or data for controlling the in-vehicle ECU 3, created by the manufacturer of the in-vehicle ECU 3, in its storage. These programs or data are transmitted to the vehicle C as additional programs or update programs and are used to add or update the programs or data of the in-vehicle ECU 3 installed in the vehicle C, thereby adding software functionality to the vehicle C. The external server SV1 (program delivery device) configured in this way is also called an OTA (Over The Air) server.

[0035] The in-vehicle device 2 functions as a relay device that relays communication data (such as CAN frames) transmitted and received between in-vehicle ECUs 3 connected to the in-vehicle network 4. The in-vehicle device 2 is connected to an external server SV1 via an external communication device 1 and an external network N. The in-vehicle device 2 may also function as an OTA master that transmits additional programs obtained from the external server SV1 to the applicable in-vehicle ECU 3, and transmits an activation instruction to apply the transmitted additional programs to the in-vehicle ECU 3.

[0036] Vehicle C is equipped with an external communication device 1, an in-vehicle device 2, and multiple in-vehicle ECUs 3 for controlling various in-vehicle devices. The external communication device 1 and the in-vehicle device 2 are connected via a harness such as a serial cable. The in-vehicle device 2 and the in-vehicle ECUs 3 are connected via an in-vehicle network 4 that supports communication protocols such as CAN (Control Area Network) or Ethernet (registered trademark).

[0037] The external communication device 1 includes an external communication unit (not shown) and an input / output interface (I / F) for communicating with the in-vehicle device 2. The external communication unit is a communication device for wireless communication using mobile communication protocols such as LTE®, 4G, 5G, and WiFi®, and transmits and receives data with the external server SV1 via an antenna 11 connected to the external communication unit. Communication between the external communication device 1 and the external server SV1 is performed via an external network N, such as a public telephone network or the Internet.

[0038] The input / output interface (I / F) of the external communication device 1 is a communication interface for, for example, serial communication with the in-vehicle device 2. The external communication device 1 and the in-vehicle device 2 communicate with each other via a harness such as a serial cable connected between the input / output interfaces. In this embodiment, the external communication device 1 is a separate device from the in-vehicle device 2, and these devices are connected to enable communication via the input / output interface, etc., but this is not limited to this. The external communication device 1 may be built into the in-vehicle device 2 as a component of the in-vehicle device 2. Alternatively, the external communication device 1 and the in-vehicle device 2 may be connected by an in-vehicle network 4 such as CAN.

[0039] The in-vehicle device 2 includes a control unit 20, a storage unit 23, an input / output interface 21, and an in-vehicle communication unit 22. The in-vehicle device 2 is a gateway (in-vehicle relay device) that manages multiple bus (segment) systems, such as an in-vehicle ECU 3 for the control system, an in-vehicle ECU 3 for the safety system, and an in-vehicle ECU 3 for the body system, and relays communication between these buses (segments) and the in-vehicle ECUs 3. That is, each of the communication lines 41 constituting these multiple buses (segments) is connected to the in-vehicle device 2, and the in-vehicle network 4 is formed by the multiple communication lines 41 (segments) aggregated by the in-vehicle device 2. The in-vehicle device 2 functions as a CAN gateway in the relay of the CAN protocol, and functions as a Layer 2 switch or Layer 3 switch in the relay of the TCP / IP protocol. In addition to relaying communications, the in-vehicle device 2 may also function as a PLB (Power LAN Box) that distributes and relays power output from a power supply device such as a secondary battery and supplies power to in-vehicle devices such as actuators connected to the device. Alternatively, the on-board device 2 may be configured as a functional unit of the body ECU that controls the entire vehicle C. Alternatively, the on-board device 2 may be configured as an integrated ECU that performs overall control of the vehicle C, for example, as a central control unit such as a vehicle computer.

[0040] The control unit 20 is composed of a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), and performs various control and calculation processes by reading and executing a control program P (program product) and data that have been pre-stored in the storage unit 23.

[0041] The storage unit 23 is composed of volatile memory elements such as RAM (Random Access Memory) or non-volatile memory elements such as ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable ROM), or flash memory. The storage unit 23 pre-stores the control program P and data that is referenced during processing, such as vehicle information, which will be described later. Furthermore, the storage unit 23 stores various data acquired by the control unit 20 from the external server SV1. In addition, the storage unit 23 stores various intermediate data and result data generated when the control unit 20 performs various calculation processes. These various intermediate data and result data include, for example, an ECU software version list, ECU communication definition information, a vehicle communication definition list, a frame transmission / reception comparison table, a frame version difference table, frame definition information, a conversion rule creation work table, and a conversion rule table. Details of these will be described later. The control program P (program product) stored in the storage unit 23 may be a control program P (program product) read from a recording medium M that the in-vehicle device 2 can read. Alternatively, the control program P may be downloaded from an external computer (not shown) connected to a communication network (not shown) and stored in the memory unit.

[0042] The input / output interface 21 is a communication interface for serial communication, similar to the input / output interface of the external communication device 1. Through the input / output interface, the in-vehicle device 2 is connected to communicate with the external communication device 1, a display device such as a display, or an IG switch that controls the operation or shutdown of the vehicle C.

[0043] The in-vehicle communication unit 22 is an input / output interface using a communication protocol such as CAN or Ethernet (registered trademark), and the control unit 20 communicates with in-vehicle equipment such as the in-vehicle ECU 3 or other relay devices connected to the in-vehicle network 4 via the in-vehicle communication unit 22. Multiple in-vehicle communication units 22 are provided (three in this embodiment), and each in-vehicle communication unit 22 is connected to a communication line 41 (segment, CAN bus) that constitutes the in-vehicle network 4.

[0044] The in-vehicle ECU 3, like the in-vehicle device 2, includes a control unit (CPU), a memory unit, and an in-vehicle communication unit. The memory unit is composed of volatile memory elements such as RAM (Random Access Memory) or non-volatile memory elements such as ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable ROM), or flash memory, and stores the program or data of the in-vehicle ECU 3. This program or data is the target of additions by a program transmitted from a program provider and relayed by the in-vehicle device 2. The in-vehicle communication unit of the in-vehicle ECU 3, like the in-vehicle device 2, is composed of, for example, a CAN transceiver or an Ethernet PHY unit, and communicates with the in-vehicle device 2 via this in-vehicle communication unit.

[0045] Figure 3 is a flowchart illustrating the processing (main) of the control unit 20 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 performs the following processing when, for example, vehicle C goes from a stopped state (e.g., IG switch is off) to a running state (e.g., IG switch is on). In other words, the control unit 20 of the in-vehicle device 2 may perform the following processing triggered by the starting of vehicle C (IG switch is turned on).

[0046] The control unit 20 of the in-vehicle device 2 acquires information about the software (S1). The control unit 20 of the in-vehicle device 2 communicates with each of the in-vehicle ECUs 3 connected to the in-vehicle network 4 via a communication line 41 such as a CAN bus, acquires the software version information (ECU version information) of the software implemented in these in-vehicle ECUs 3, and stores it in the storage unit 23. The software version information (ECU version information) transmitted from the in-vehicle ECU 3 includes the version of the software implemented in that in-vehicle ECU 3.

[0047] The control unit 20 of the in-vehicle device 2 identifies the updated ECU whose software has been updated (S2). The control unit 20 of the in-vehicle device 2 identifies the updated ECU based on the list of ECU software versions currently stored in the memory unit 23 and the software version information (ECU version information) obtained and aggregated from all in-vehicle ECUs 3 connected to the in-vehicle network 4. Then, the control unit 20 of the in-vehicle device 2 updates the list of ECU software versions to reflect the identified updated ECU.

[0048] Figure 4 is a flowchart illustrating the processing (identification of the update ECU) of the control unit 20 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 performs the following processing to identify the update ECU.

[0049] The control unit 20 of the in-vehicle device 2 reads the ECU software version list (S201). The control unit 20 of the in-vehicle device 2 reads the ECU software version list currently stored in the storage unit 23 by referring to the storage unit 23. The current ECU software version list is an ECU software version list that was generated or updated based on the software version information (ECU version information) acquired and aggregated from all in-vehicle ECUs 3 before this process, that is, when the IG switch was last turned on or off.

[0050] The control unit 20 of the in-vehicle device 2 identifies the updated ECU by matching the information (S202). The control unit 20 of the in-vehicle device 2 compares or contrasts the read ECU software version list with the software version information (ECU version information) that has been aggregated, extracts differences or discrepancies, and identifies the in-vehicle ECU 3 with differences as the updated ECU whose software version has been updated.

[0051] The control unit 20 of the in-vehicle device 2 updates the ECU software version list (S203). The control unit 20 of the in-vehicle device 2 updates the software version list stored in the storage unit 23 to reflect the identified updated ECU.

[0052] Figure 5 is an explanatory diagram illustrating the software information (ECU software version list) implemented in the in-vehicle ECU3. The ECU software version list includes the ECUID, connection bus, software version, and update flag as management items.

[0053] The ECUID management item stores an ID (identification number) that uniquely identifies the in-vehicle ECU3. The connection bus management item stores the number of the communication line 41, such as a CAN bus, to which the in-vehicle ECU3 is connected. The software version management item stores the version number of the software implemented in the in-vehicle ECU3. The update flag management item stores a flag indicating whether the in-vehicle ECU3 is an update ECU or not (False: not an update ECU, True: is an update ECU). In this embodiment, it indicates that the software of the in-vehicle ECU3 with ECUID 006 has been upgraded from version 1.0 to 2.0 and is identified as an update ECU.

[0054] The control unit 20 of the in-vehicle device 2 identifies the difference in the definition versions of frames transmitted and received by the updated software (S3). The control unit 20 of the in-vehicle device 2 identifies one or more frames transmitted and received by the updated software and identifies the difference in the definition versions of the frames between the in-vehicle ECU 3 that transmits the frame (transmitting ECU) and the in-vehicle ECU 3 that receives the frame (detects a communication definition version mismatch). If the updated ECU is the transmitting ECU, the receiving ECU corresponds to the other ECU. If the updated ECU is the receiving ECU, the transmitting ECU corresponds to the other ECU.

[0055] Figure 6 is a flowchart illustrating the processing performed by the control unit 20 of the in-vehicle device 2 (identifying differences in frame definition versions). The control unit 20 of the in-vehicle device 2 performs the following processing to identify differences in frame definition versions.

[0056] The control unit 20 of the in-vehicle device 2 acquires the ECU communication definition information of the updated ECU (S301). The control unit 20 of the in-vehicle device 2 obtains the ECU communication definition information from the updated ECU by querying it and stores it in the storage unit 23.

[0057] Figure 7 is an explanatory diagram illustrating the frame information (ECU communication definition information) that is transmitted and received when the software is executed in the updated ECU. The ECU communication definition information includes the frame name, definition version, transmission / reception (transmission / reception flag), and conversion tolerance as management items.

[0058] The frame name management field stores a name or type that uniquely identifies the frame transmitted and received between the in-vehicle ECUs 3 via the in-vehicle network 4. The definition version management field stores the definition version number of the frame. When this definition version changes, the data length, transmission period, signal definition, etc., may change. This version number (definition version number) may also be stored within the frame. The transmit / receive (transmit / receive flag) field stores a transmit / receive flag (1: transmit, 0: receive) indicating whether the frame is being transmitted or received.

[0059] The conversion tolerance management item stores a level indicating the conversion tolerance when receiving a frame (0: not allowed, 1: allowed if no information is lost, 2: always allowed). The conversion tolerance level is determined by whether the receiving ECU can handle information that has been converted and relayed from the transmitting ECU's transmitted frame without causing any control problems. In receiving ECUs where even slight differences in accuracy can cause significant problems, such as in safety-related functions, a stricter value (0: not allowed) may be set. If the conversion tolerance is not allowed (0), conversion of the frame is not allowed at all. If the conversion tolerance is always allowed (2), conversion of the frame is always allowed.

[0060] If the conversion tolerance is (1) acceptable as long as there is no loss of information, then the conversion of the frame is acceptable if there is no loss of information after the conversion. In other words, if the amount of information processed per unit time by the transmitting ECU (transmitter) is greater than the amount of information processed by the receiving ECU (receiver), then even if the in-vehicle device 2 reduces the amount of information processed by the transmitting ECU (transmitter) to the amount of information processed by the receiving ECU (receiver), no loss of information will occur for the receiving ECU (receiver). To increase the amount of information processed per unit time in this way, it is effective to shorten the transmission period, lengthen the data length of the payload in a single frame, or increase the resolution of the data included in the payload (measurements from sensors, etc.).

[0061] The control unit 20 of the in-vehicle device 2 identifies the other ECU based on the vehicle communication definition list (S302). The vehicle communication definition list stores information about the in-vehicle ECUs 3 (transmitting ECU, receiving ECU) that send and receive each frame, and is pre-stored in the storage unit 23 of the in-vehicle device 2. By referring to the vehicle communication definition list, the control unit 20 of the in-vehicle device 2 identifies the other ECU (ECUID 001) that will communicate with the updated ECU (ECUID 006) for each frame (frame name).

[0062] Figure 8 is an explanatory diagram illustrating the details of the combination of in-vehicle ECU3s that transmit and receive frames (vehicle communication definition list). The vehicle communication definition list includes the frame name, transmit bus ID, transmit ECU ID, receive bus ID, and receive ECU ID as management items. There may be multiple combinations consisting of the receive bus ID and receive ECU ID.

[0063] The frame name management field stores a name that uniquely identifies the frame. The transmit bus ID management field stores the number of the communication line 41, such as the CAN bus, to which the transmit ECU that transmits the frame is connected. The transmit ECU ID management field stores the ECUID of the transmit ECU that transmits the frame. The receive bus ID management field stores the number of the communication line 41, such as the CAN bus, to which the receive ECU that receives the frame is connected. The receive ECU ID management field stores the ECUID of the receive ECU that receives the frame.

[0064] The control unit 20 of the in-vehicle device 2 acquires the ECU communication definition information of the other ECU (S303). The control unit 20 of the in-vehicle device 2 obtains the ECU communication definition information from the other ECU by querying it and stores it in the storage unit 23.

[0065] Figure 9 is an explanatory diagram illustrating the frame information (ECU communication definition information) transmitted and received when the software on the other ECU is executed. The management items of the ECU communication definition information are common or standardized across all in-vehicle ECUs 3, and the management items of the ECU communication definition information of the other ECU are the same as those of the updated ECU.

[0066] The control unit 20 of the in-vehicle device 2 generates a frame transmission / reception comparison table (S304). The control unit 20 of the in-vehicle device 2 combines the three pieces of information obtained up to this point—namely, the ECU communication definition information of the updated ECU, the vehicle communication definition list, and the ECU communication definition information of the other ECU—to create a frame transmission / reception comparison table.

[0067] Figure 10 is an explanatory diagram illustrating matters related to the similarity or difference of frame definition versions (frame transmission / reception comparison table). The frame transmission / reception comparison table includes the frame name, the sender's bus ID and version, the receiver's bus ID and version, the conversion tolerance, and version differences as management items.

[0068] The frame name management item stores a name that uniquely identifies the frame. The transmitting bus ID management item stores the number of the communication line 41, such as the CAN bus to which the transmitting ECU is connected. The transmitting Ver management item stores the frame definition version number of the transmitting ECU. The receiving bus ID management item stores the number of the communication line 41, such as the CAN bus to which the receiving ECU is connected. The receiving Ver management item stores the frame definition version number of the receiving ECU. The conversion tolerance management item stores a level indicating the conversion tolerance when receiving a frame. The Ver difference management item stores a flag indicating the result of the control unit 20 of the in-vehicle device 2's determination of whether there is a difference between the transmitting Ver and the receiving Ver (difference: yes / no).

[0069] The control unit 20 of the in-vehicle device 2 identifies differences in the definition versions of frames in the frame transmission / reception comparison table (S305). The control unit 20 of the in-vehicle device 2 compares the transmitting version and the receiving version for each frame in the frame transmission / reception comparison table, and sets a "Version difference" flag for each frame if there is a difference. Based on the frame transmission / reception comparison table with the flags set in this way, the control unit 20 of the in-vehicle device 2 identifies frames with differences in the definition versions.

[0070] The control unit 20 of the in-vehicle device 2 generates conversion rules for frames with different definition versions (S4). Figure 11 is a flowchart illustrating the processing (generation of conversion rules) of the control unit 20 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 performs the following processing when generating conversion rules.

[0071] The control unit 20 of the in-vehicle device 2 generates a frame version difference table (S401). The control unit 20 of the in-vehicle device 2 extracts only the rows in the frame transmission / reception comparison table where the Ver difference flag is "present" and creates the frame version difference table.

[0072] Figure 12 is an explanatory diagram illustrating matters related to frames with different definition versions (frame version difference table). The frame version difference table includes the frame name, the sender's bus ID and version, the receiver's bus ID and version, and the conversion tolerance as management items.

[0073] The frame name management field stores a name that uniquely identifies the frame. The transmitting bus ID management field stores the number of the communication line 41, such as the CAN bus, to which the transmitting ECU is connected. The transmitting Ver management field stores the frame definition version number of the transmitting ECU. The receiving bus ID management field stores the number of the communication line 41, such as the CAN bus, to which the receiving ECU is connected. The receiving Ver management field stores the frame definition version number of the receiving ECU. The conversion tolerance management field stores a level indicating the conversion tolerance when receiving a frame.

[0074] The control unit 20 of the in-vehicle device 2 obtains the conversion tolerance in the frame version difference table (S402). The control unit 20 of the in-vehicle device 2 checks or extracts the conversion tolerance value (level) for the transmitting and receiving sides of each row in the frame version difference table.

[0075] The control unit 20 of the in-vehicle device 2 determines whether or not there is a frame in any of the frames for which the conversion tolerance is not allowed (S403). The control unit 20 of the in-vehicle device 2 determines whether or not there is at least one frame with a conversion tolerance of "Conversion Tolerance == 0 (Not Allowed)" among the one or more frame names listed in the frame version difference table.

[0076] If there are frames for which conversion is not permitted (S403: YES), the control unit 20 of the on-board device 2 interrupts the conversion rule generation process (S4031). If there is at least one frame for which conversion is not permitted among the frame names listed in the frame version difference table, the control unit 20 of the on-board device 2 interrupts the conversion rule generation process. In other words, the control unit 20 of the on-board device 2 determines that conversion relay is not possible, displays a message indicating that the updated ECU is invalid, and outputs information to the user (operator of vehicle C) prompting them to change the version, etc.

[0077] If there are no frames for which conversion is not permitted (S403: NO), the control unit 20 of the on-board device 2 acquires frame definition information (S404). If there are no frames for which conversion is not permitted among one or more frame names listed in the frame version difference table, the control unit 20 of the on-board device 2 retrieves the frame definition information corresponding to each of the one or more frame names listed in the frame version difference table. The frame definition information is pre-stored in the storage unit 23 of the on-board device 2. Alternatively, the control unit 20 of the on-board device 2 may acquire the latest frame definition information from the updated ECU.

[0078] Figure 13 is an explanatory diagram illustrating the definition information (frame definition information) in which the communication specification items of a frame are defined. In this embodiment, the communication specification items (frame definition information) for a frame named SonarSense are illustrated. The management items in the frame definition information include a horizontal item called the version (frame definition version) and a vertical item containing multiple communication specification items, and are composed of a matrix structure of horizontal and vertical items. The management item of the horizontal item called the version (frame definition version) stores the value of the frame definition version (1.0, 2.0, 3.0, etc.). For each of these frame definition versions, the values ​​or contents of the multiple communication specification items, which are vertical items, are stored.

[0079] Multiple communication specification items, which are vertical columns, include the transmitting ECUID, CAN-ID, transmission period, data length, and resolution, specifically the following: Signal 1: Start position, Signal 1: End position, Signal 1: Physical unit, and Signal 1: Resolution. These resolution-related items may also include those for other signals (Signal 2, Signal 3, etc.). Furthermore, the communication specification items may include offset values.

[0080] The Transmitting ECUID field stores the ID of the vehicle-mounted ECU3 (transmitting ECU) that transmits the frame. The CAN-ID field stores the message ID if the frame is a CAN message. The transmission cycle field stores the transmission cycle for the frame. The data length field stores the data length of the payload contained in the frame.

[0081] Signal 1: Start Position stores the start bit number when Signal 1 is stored. Signal 1: End Position stores the end bit number when Signal 1 is stored. Signal 1: Physical Units stores the physical unit (cm, mm, etc.) of the signal value. Signal 1: Resolution stores the resolution of the signal value.

[0082] The control unit 20 of the in-vehicle device 2 generates a conversion rule creation work table (S405). Based on the frame definition information, the control unit 20 of the in-vehicle device 2 generates conversion rules for each communication specification item in the frame definition version of the updated ECU and the frame definition version of the other ECU, and generates the conversion rule creation work table by integrating each of the generated conversion rules. In this embodiment, as an example of a communication specification item, the process for generating conversion rules for identifier (CAN-ID), period, data length, and signal (resolution) will be described.

[0083] Figure 14 is a flowchart illustrating the processing (determination of whether identifiers can be converted) of the control unit 20 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 performs the following processing when generating identifier conversion rules.

[0084] The control unit 20 of the in-vehicle device 2 obtains the frame identifiers in the transmitting ECU and the receiving ECU (A101). The control unit 20 of the in-vehicle device 2 extracts the CAN-ID (frame identifier) ​​for the transmitting and receiving sides from the conversion rule generation work table.

[0085] Figure 15 is an explanatory diagram illustrating the matters related to determining whether an identifier can be converted (conversion rule creation work table). The control unit 20 of the in-vehicle device 2 generates a conversion rule creation work table using the ECU communication definition information of the updated ECU, the ECU communication definition information of the other ECU, frame definition information, and the vehicle communication definition list. The management items of the conversion rule creation work table include horizontal items such as transmitting side, receiving side, and conversion feasibility determination, and vertical items such as bus ID, version, transmitting ECU ID, CAN-ID, transmission cycle, data length, signal1: start position, signal1: end position, signal1: physical unit, signal1: resolution, and signal1: offset value, and are arranged in a matrix.

[0086] The Bus ID management field stores the number of the communication line 41, such as the CAN bus to which the transmitting ECU is connected, and the number of the communication line 41, such as the CAN bus to which the receiving ECU is connected, for both the transmitting and receiving fields. The Version management field stores the frame definition version of the transmitting ECU and the frame definition version of the receiving ECU, for both the transmitting and receiving fields. The Transmitting ECU ID management field stores the ID of the transmitting ECU and the ID of the receiving ECU, for both the transmitting and receiving fields. The CAN-ID management field stores the identifier (message ID) of the frame transmitted by the transmitting ECU and the identifier (message ID) of the frame received by the receiving ECU, for both the transmitting and receiving fields. The Transmission Cycle management field stores the transmission cycle of the transmitting ECU and the reception cycle of the receiving ECU, for both the transmitting and receiving fields. The Data Length management field stores the data length of the frame of the transmitting ECU and the data length of the frame of the receiving ECU, for both the transmitting and receiving fields.

[0087] Signal 1: The management item for the start position stores the start bit number of the frame of the transmitting ECU and the receiving ECU for the horizontal items of the transmitting and receiving sides. Signal 1: The management item for the end position stores the end bit number of the frame of the transmitting ECU and the receiving ECU for the horizontal items of the transmitting and receiving sides. Signal 1: The management item for the physical unit stores the physical unit of the signal stored in the frame of the transmitting ECU and the physical unit of the signal stored in the frame of the receiving ECU for the horizontal items of the transmitting and receiving sides. Signal 1: The management item for the resolution stores the resolution of the signal stored in the frame of the transmitting ECU and the resolution of the signal stored in the frame of the receiving ECU for the horizontal items of the transmitting and receiving sides. Signal 1: The management item for the offset value stores the offset value stored in the frame of the transmitting ECU and the offset value stored in the frame of the receiving ECU for the horizontal items of the transmitting and receiving sides.

[0088] The control unit 20 of the in-vehicle device 2 determines whether the identifiers of the transmitting ECU and the receiving ECU are not the same (A102). The control unit 20 of the in-vehicle device 2 determines whether the identifiers of the transmitting ECU and the receiving ECU are not the same (transmitting CAN-ID ≠ receiving CAN-ID).

[0089] If they are not identical (A102: YES), the control unit 20 of the in-vehicle device 2 sets the identifier item in the conversion rule creation work table to convertible (A103). If the identifiers are not identical, the control unit 20 of the in-vehicle device 2 sets the identifier item in the conversion rule creation work table to convertible (conversion OK). The reason why the control unit 20 of the in-vehicle device 2 can unconditionally set convertible (conversion OK) is that no information loss occurs in CAN-ID conversion, and the case where conversion tolerance is not possible for both transmission and reception has already been excluded.

[0090] If they are the same (A102: NO), the control unit 20 of the in-vehicle device 2 sets the identifier item in the conversion rule creation work sheet to "No conversion required" (A1021). If the identifiers are the same, the control unit 20 of the in-vehicle device 2 sets the identifier item in the conversion rule creation work sheet to "No conversion required".

[0091] Figure 16 is a flowchart illustrating the processing (determination of whether period conversion is possible) of the control unit 20 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 performs the following processing when generating the period conversion rule.

[0092] The control unit 20 of the in-vehicle device 2 acquires the frame period in the transmitting ECU and the receiving ECU (B101). The control unit 20 of the in-vehicle device 2 extracts the transmission period (transmitting side: transmission period, receiving side: reception period) for the transmitting side (transmitting ECU) and the receiving side (receiving ECU) from the conversion rule generation work table.

[0093] The control unit 20 of the in-vehicle device 2 determines whether the periods of the transmitting ECU and the receiving ECU are the same (B102). The control unit 20 of the in-vehicle device 2 determines whether the periods of the transmitting ECU and the receiving ECU are the same (transmitting side: transmission period == receiving side: reception period (the transmission period that the receiving side expects from the transmitting side)).

[0094] If they are the same (B102: YES), the control unit 20 of the in-vehicle device 2 sets the period item in the conversion rule creation work sheet to "No conversion required" (B103). If the transmission and reception periods on the transmitting side (transmitting ECU) and the receiving side (receiving ECU) are the same, the control unit 20 of the in-vehicle device 2 sets the period item in the conversion rule creation work sheet to "No conversion required".

[0095] If they are not the same (B102: NO), the control unit 20 of the in-vehicle device 2 determines whether the period of the receiving ECU is greater than the period of the transmitting ECU (B104). If the transmission and reception periods on the transmitting side (transmitting ECU) and the receiving side (receiving ECU) are not the same, the control unit 20 of the in-vehicle device 2 determines whether the period of the receiving ECU is greater than the period of the transmitting ECU (receiving side: receiving period > transmitting side: transmitting period).

[0096] If the period is larger (B104: YES), the control unit 20 of the in-vehicle device 2 sets the period item in the conversion rule creation work table to convertible (B105). If the period of the receiving ECU is larger than the period of the transmitting ECU, the control unit 20 of the in-vehicle device 2 sets the period item in the conversion rule creation work table to convertible. Since the information is updated more frequently than the information update period expected by the receiving side, there is no loss of information, and therefore the control unit 20 of the in-vehicle device 2 can set it to convertible.

[0097] If it is not large (B104: NO), the control unit 20 of the in-vehicle device 2 determines whether the tolerance for change is always acceptable (B1041). If the period of the receiving ECU is not larger than the period of the transmitting ECU, i.e., smaller, the control unit 20 of the in-vehicle device 2 determines whether the tolerance for change is always acceptable. Because the update period is longer than the information update period expected by the receiving side, there is a loss of information, so the control unit 20 of the in-vehicle device 2 determines whether the tolerance for change is always acceptable.

[0098] If it is always possible (B1041: YES), the control unit 20 of the in-vehicle device 2 sets the period item in the conversion rule creation work table to convertible (B1042). If the tolerance for change is always possible, it sets the period item in the conversion rule creation work table to convertible. After processing B103, B105, or B1042, the control unit 20 of the in-vehicle device 2 may return to the main routine (S4).

[0099] Figure 17 is an explanatory diagram illustrating the matters related to determining whether the period can be converted (conversion rule creation work table). The control unit 20 of the in-vehicle device 2 sets the conversion by storing "conversion possible" (conversion OK) in the management item for determining whether the transmission period can be converted in the conversion rule creation work table.

[0100] If it is not always possible (B1041: NO), the control unit 20 of the in-vehicle device 2 sets the period item in the conversion rule creation work table to "Not convertible" (B1043). The control unit 20 of the in-vehicle device 2 interrupts the conversion rule generation process (B1044). If the change tolerance is not always possible, it is set by storing "Not convertible" in the management item for the conversion feasibility determination for the transmission period in the conversion rule creation work table. Then, the control unit 20 of the in-vehicle device 2 interrupts the conversion rule generation process. In other words, the control unit 20 of the in-vehicle device 2 determines that conversion relay is not possible, displays a message indicating that the update ECU is invalid, and outputs information to the user (operator of vehicle C) prompting them to change the version, etc.

[0101] Figure 18 is a flowchart illustrating the processing (determination of whether data length conversion is possible) of the control unit 20 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 performs the following processing when generating data length conversion rules.

[0102] The control unit 20 of the in-vehicle device 2 obtains the data length of the frame in the transmitting ECU and the receiving ECU (C101). The control unit 20 of the in-vehicle device 2 extracts the data lengths of the transmitting side (transmitting ECU) and the receiving side (receiving ECU) from the conversion rule generation work table.

[0103] The control unit 20 of the in-vehicle device 2 determines whether the data lengths of the transmitting ECU and the receiving ECU are the same (C102). The control unit 20 of the in-vehicle device 2 determines whether the data lengths of the transmitting ECU and the receiving ECU are the same (transmitting side: data length == receiving side: data length).

[0104] If they are the same (C102: YES), the control unit 20 of the in-vehicle device 2 sets the data length item in the conversion rule creation work sheet to "No conversion required" (C103). If the data lengths on the transmitting side (transmitting ECU) and the receiving side (receiving ECU) are the same, the control unit 20 of the in-vehicle device 2 sets the data length item in the conversion rule creation work sheet to "No conversion required".

[0105] Figure 19 is an explanatory diagram illustrating the items related to determining whether or not data length can be converted (conversion rule creation work table). As an example, the control unit 20 of the in-vehicle device 2 sets the conversion rule creation work table by storing "no conversion required" in the management item for determining whether or not data length can be converted.

[0106] If they are not the same (C102: NO), the control unit 20 of the in-vehicle device 2 determines whether the data length of the receiving ECU is smaller than the data length of the transmitting ECU (C104). If the data lengths on the transmitting side (transmitting ECU) and the receiving side (receiving ECU) are not the same, the control unit 20 of the in-vehicle device 2 determines whether the data length of the receiving ECU is smaller than the data length of the transmitting ECU (receiving side data length < transmitting side data length).

[0107] If it is smaller (C104: YES), the control unit 20 of the in-vehicle device 2 sets the data length item in the conversion rule creation work table to convertible (C105). If the data length of the receiving ECU is smaller than the data length of the transmitting ECU, the control unit 20 of the in-vehicle device 2 sets the data length item in the conversion rule creation work table to convertible. Since it is larger than the data length expected by the receiving side, there is no loss of information, so the control unit 20 of the in-vehicle device 2 can set it to convertible.

[0108] If it is not small (C104: NO), the control unit 20 of the in-vehicle device 2 determines whether the tolerance for modification is always acceptable (C1041). If the data length of the receiving ECU is not smaller than the data length of the transmitting ECU, i.e., it is larger, the control unit 20 of the in-vehicle device 2 determines whether the tolerance for modification is always acceptable. Because it is smaller than the data length expected by the receiving side, there is a loss of information, so the control unit 20 of the in-vehicle device 2 determines whether the tolerance for modification is always acceptable.

[0109] If it is always possible (C1041: YES), the control unit 20 of the in-vehicle device 2 sets the data length item in the conversion rule creation work table to convertible (C1042). If the degree of change tolerance is always possible, the data length item in the conversion rule creation work table is set to convertible. After processing C103, C105, or C1042, the control unit 20 of the in-vehicle device 2 may return to the main routine (S4).

[0110] If it is not always possible (C1041: NO), the control unit 20 of the in-vehicle device 2 sets the data length item in the conversion rule creation work table to "Not convertible" (C1043). The control unit 20 of the in-vehicle device 2 interrupts the conversion rule generation process (C1044). If the change tolerance is not always possible, it is set by storing "Not convertible" in the management item for the conversion feasibility determination for data length in the conversion rule creation work table. Then, the control unit 20 of the in-vehicle device 2 interrupts the conversion rule generation process. In other words, the control unit 20 of the in-vehicle device 2 determines that conversion relay is not possible, displays a message indicating that the update ECU is invalid, and outputs information to the user (operator of vehicle C) prompting them to change the version, etc.

[0111] Figure 20 is a flowchart illustrating the processing (signal conversion feasibility determination) of the control unit 20 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 performs the following processing when generating signal (resolution) conversion rules. If there are multiple signals (signal 1, signal 2, ...), the control unit 20 of the in-vehicle device 2 performs the processing for signal 1 and then repeatedly performs the processing for subsequent signals (signal 2, ...).

[0112] The control unit 20 of the in-vehicle device 2 acquires the resolution of the frame in the transmitting ECU and the receiving ECU (D101). The control unit 20 of the in-vehicle device 2 extracts the resolution of the transmitting side (transmitting ECU) and the receiving side (receiving ECU), i.e., signal definition information related to the signal (signal 1: start position, signal 1: end position, signal 1: physical unit, signal 1: resolution, signal 1: offset value) from the conversion rule generation work table. In this case, the offset value may be defined by the formula "signal value = (physical value / resolution) - offset value". The physical unit may include conversions between unit systems such as Celsius and Fahrenheit, and metric and inch systems.

[0113] The control unit 20 of the in-vehicle device 2 performs processing to standardize the units of resolution, etc. (D102). The control unit 20 of the in-vehicle device 2 performs processing to standardize the units of the signal definition so that the resolution can be compared. This processing includes, for example, calculating the physical resolution of the signal and calculating the physical maximum and minimum values ​​of the signal.

[0114] The control unit 20 of the in-vehicle device 2 determines whether the resolution, etc., of the transmitting ECU and the receiving ECU are the same (D103). The control unit 20 of the in-vehicle device 2 determines whether the resolution, etc., of the transmitting ECU and the receiving ECU are the same (transmitting side: resolution, etc. == receiving side: resolution, etc.).

[0115] If they are the same (D103:YES), the control unit 20 of the in-vehicle device 2 sets the resolution and other items in the conversion rule creation work table to "No conversion required" (D104). If the resolution and other items on the transmitting side (transmitting ECU) and the receiving side (receiving ECU) are the same, the control unit 20 of the in-vehicle device 2 sets the resolution and other items (signal definition information) in the conversion rule creation work table to "No conversion required".

[0116] If they are not the same (D103: NO), the control unit 20 of the in-vehicle device 2 determines whether the resolution of the receiving ECU is coarser than the resolution of the transmitting ECU (D105). If the resolution etc. on the transmitting side (transmitting ECU) and the receiving side (receiving ECU) are not the same, the control unit 20 of the in-vehicle device 2 determines whether the resolution of the receiving ECU is coarser than the resolution of the transmitting ECU. In this case, the control unit 20 of the in-vehicle device 2 may also determine whether the resolution of the receiving ECU is greater than or equal to the resolution of the transmitting ECU, the maximum value of the receiving ECU is less than or equal to the maximum value of the transmitting ECU, and the minimum value of the receiving ECU is greater than or equal to the minimum value of the transmitting ECU (receiving side resolution ≥ transmitting side resolution) & (receiving side maximum value ≤ transmitting side maximum value) & (receiving side minimum value ≥ transmitting side minimum value).

[0117] Figure 21 is an explanatory diagram illustrating the matters related to determining whether a signal can be converted (conversion rule creation work table). In the values ​​shown in this embodiment, in this case, "transmitter resolution: 5 mm < receiver resolution: 10 mm", "transmitter minimum value: 0 mm == receiver minimum value: 0 mm", and "transmitter maximum value: 327,675 (65,535 * 5) > receiver maximum value: 2,550 mm".

[0118] If the resolution is coarse (D105: YES), the control unit 20 of the in-vehicle device 2 sets the resolution item in the conversion rule creation work sheet to convertible (D106). If the resolution of the receiving ECU is greater than the resolution of the transmitting ECU, the control unit 20 of the in-vehicle device 2 sets the resolution item in the conversion rule creation work sheet to convertible. In this case, if the resolution of the receiving ECU is greater than or equal to the resolution of the transmitting ECU, the maximum value of the receiving ECU is less than or equal to the maximum value of the transmitting ECU, and the minimum value of the receiving ECU is greater than or equal to the minimum value of the transmitting ECU, the control unit 20 of the in-vehicle device 2 may set the resolution item in the conversion rule creation work sheet to convertible. Since the transmitting side resolution is finer than the resolution expected by the receiving side, there is no loss of information, so the control unit 20 of the in-vehicle device 2 can set it to convertible.

[0119] If the resolution is not coarse (D105: NO), the control unit 20 of the in-vehicle device 2 determines whether the tolerance for change is always permissible (D1051). If the resolution of the receiving ECU is not coarser than the resolution of the transmitting ECU, that is, if the resolution of the receiving ECU is finer than the resolution of the transmitting ECU, the control unit 20 of the in-vehicle device 2 determines whether the tolerance for change is always permissible. In this case, the control unit 20 of the in-vehicle device 2 may also determine whether the tolerance for change is always permissible if the resolution of the receiving ECU is finer than the resolution of the transmitting ECU, or if the maximum value of the receiving ECU is greater than the maximum value of the transmitting ECU, or if the minimum value of the receiving ECU is smaller than the minimum value of the transmitting ECU. Because there is a loss of information in either the resolution or the value range for the signal expected by the receiving side, the control unit 20 of the in-vehicle device 2 determines whether the tolerance for change is always permissible.

[0120] If it is always possible (D1051: YES), the control unit 20 of the in-vehicle device 2 sets the resolution item in the conversion rule creation work table to convertible (D1052). If the tolerance for change is always possible, it sets the resolution (signal definition information) item in the conversion rule creation work table to convertible (conversion OK). After processing D104, D106, or D1052, the control unit 20 of the in-vehicle device 2 may return to the main routine (S4).

[0121] If it is not always possible (D1051: NO), the control unit 20 of the in-vehicle device 2 sets the resolution item in the conversion rule creation work table to "Not convertible" (D1053). The control unit 20 of the in-vehicle device 2 interrupts the conversion rule generation process (D1054). If the change tolerance is not always possible, it is set by storing "Not convertible" in the management item for the conversion feasibility determination for resolution (signal definition information) in the conversion rule creation work table. Then, the control unit 20 of the in-vehicle device 2 interrupts the conversion rule generation process. In other words, the control unit 20 of the in-vehicle device 2 determines that conversion relay is not possible, displays a message indicating that the update ECU is invalid, and outputs information to the user (operator of vehicle C) prompting them to change the version, etc.

[0122] The control unit 20 of the in-vehicle device 2 generates (completes) a conversion rule table by extracting the necessary items from the conversion rule creation work table, which includes the conversion rules generated for each communication specification item, and configuring it in the conversion rule generation work table. In other words, the control unit 20 of the in-vehicle device 2 determines, as described above, whether a conversion is necessary for each communication specification item, and if a conversion is necessary, whether the conversion is permissible, for each frame with a different definition version in the updated ECU and the partner ECU, and generates a conversion rule creation work table based on these determination results. Then, the control unit 20 of the in-vehicle device 2 generates a conversion rule table based on the generated conversion rule generation work table.

[0123] Figure 22 is an explanatory diagram illustrating the generated conversion rules (conversion rule table). A conversion rule table is generated for each frame (for each frame name). The management items in the conversion rule table include horizontal items such as sender, receiver, and conversion requirement, and vertical items such as bus ID, version, CAN-ID, transmission cycle, data length, signal 1, signal 1: start position, signal 1: end position, signal 1: conversion formula: coefficient, signal 1: conversion formula: intercept, signal 1: conversion formula: minimum value, and signal 1: conversion formula: maximum value, and are arranged in a matrix. Furthermore, in addition to signal 1, other signals such as signal 2 and signal 3 may also be included.

[0124] The Bus ID management field stores the number of the communication line 41, such as the CAN bus to which the transmitting ECU is connected, and the number of the communication line 41, such as the CAN bus to which the receiving ECU is connected, for both the transmitting and receiving fields. The Version management field stores the frame definition version of the transmitting ECU and the frame definition version of the receiving ECU, for both the transmitting and receiving fields. The CAN-ID management field stores the identifier (message ID) of the frame transmitted by the transmitting ECU and the identifier (message ID) of the frame received by the receiving ECU, for both the transmitting and receiving fields. The Transmission Cycle management field stores the transmission cycle of the transmitting ECU and the reception cycle of the receiving ECU, for both the transmitting and receiving fields. The Data Length management field stores the data length of the frame of the transmitting ECU and the data length of the frame of the receiving ECU, for both the transmitting and receiving fields. The Signal 1 management field stores a null value for both the transmitting and receiving fields. In each of these vertical items (communication specification items) for CAN-ID, transmission cycle, data length, and signal 1, the horizontal item "Conversion Required" stores whether or not conversion is required (required or not).

[0125] The control unit 20 of the in-vehicle device 2 may, when generating conversion rules for each communication specification item related to signal 1, standardize the units of the signal definitions and enable comparison of resolution. The Signal 1: Start Position management item stores the start bit number when signal 1 of the frame of the transmitting ECU is stored and the start bit number when signal 1 of the frame of the receiving ECU is stored for the horizontal items of the transmitting and receiving sides. The Signal 1: End Position management item stores the end bit number when signal 1 of the frame of the transmitting ECU is stored and the end bit number when signal 1 of the frame of the receiving ECU is stored for the horizontal items of the transmitting and receiving sides. The Signal 1: Conversion Formula: Coefficient management item stores the coefficient of signal 1 of the frame of the transmitting ECU and the coefficient of signal 1 of the frame of the receiving ECU for the horizontal items of the transmitting and receiving sides. The Signal 1: Conversion Formula: Intercept management item stores the intercept of signal 1 of the frame of the transmitting ECU and the intercept of signal 1 of the frame of the receiving ECU for the horizontal items of the transmitting and receiving sides. The Signal 1: Conversion Formula: Minimum Value management item stores the minimum value of Signal 1 in the transmitting ECU frame and the minimum value of Signal 1 in the receiving ECU frame for the horizontal items of the transmitting and receiving sides. The Signal 1: Conversion Formula: Maximum Value management item stores the maximum value of Signal 1 in the transmitting ECU frame and the maximum value of Signal 1 in the receiving ECU frame for the horizontal items of the transmitting and receiving sides.

[0126] The control unit 20 of the in-vehicle device 2 may, when generating conversion rules for each communication specification item related to signal 1, standardize the units of the signal definitions so that the resolution can be compared. That is, the control unit 20 of the in-vehicle device 2 may extract the smaller unit from the transmitting and receiving units (for example, if the units are "cm" and "mm", it may extract "mm"), and convert the resolution values ​​of both sides to the smaller unit for unification. The control unit 20 of the in-vehicle device 2 may calculate the coefficient by dividing the transmitting physical resolution by the receiving physical resolution ("Coefficient = Transmitting Physical Resolution / Receiving Physical Resolution"). The control unit 20 of the in-vehicle device 2 may calculate the intercept by subtracting the receiving offset value from the value obtained by multiplying the transmitting offset value by the coefficient ("Intercept = Transmitting Offset Value × Coefficient - Receiving Offset Value"). The control unit 20 of the in-vehicle device 2 may calculate the maximum and minimum values ​​of the signal (receiving side) from the number of bits defined for the signal (for example, if it is 8 bits, the minimum value is 0 and the maximum value is 255 (=2^8-1)). In this case, the receiving signal and the transmitting signal are represented by the formula "receiving signal = transmitting signal × coefficient + intercept", and if the minimum value of the receiving side is greater than the transmitting signal "if minimum value of the receiving side > transmitting signal", the receiving signal corresponds to the minimum value of the receiving side "receiving signal = minimum value of the receiving side", and if the maximum value of the receiving side is less than the transmitting signal "if maximum value of the receiving side < transmitting signal", the receiving signal corresponds to the maximum value of the receiving side "receiving signal = maximum value of the receiving side".

[0127] At both the transmitting and receiving ends, the physical value is expressed by the formula "physical value = (signal value + offset value) × resolution," and the physical value remains constant at both the transmitting and receiving ends. Therefore, at both the transmitting ECU (send) and the receiving ECU (receive), the signal value is expressed by the formula "(signal value (send) + offset value (send)) × resolution (send) = (signal value (receive) + offset value (receive)) × resolution (receive)." The formula is expressed as follows: "(Signal value (transmitted) + Offset value (transmitted)) × (Resolution (transmitted) / Resolution (received)) = (Signal value (received) + Offset value (received))", "(Signal value (transmitted) + Offset value (transmitted)) × Coefficient = (Signal value (received) + Offset value (received))", "Signal value (received) = (Signal value (transmitted) + Offset value (transmitted)) × Coefficient - Offset value (received)", and "Signal value (received) = Signal value (transmitted) × Coefficient + {Offset value (transmitted) × Coefficient - Offset value (received)}". By defining the conversion rules in this way, the control unit 20 of the in-vehicle device 2 can perform conversions while taking into account the physical unit system of the signal.

[0128] The control unit 20 of the in-vehicle device 2 stores the generated conversion rules in the storage unit 23. In this embodiment, the in-vehicle device 2 acquires various types of information from the in-vehicle ECU 3, but is not limited to this. The in-vehicle device 2 may acquire all or some of the information necessary for this process from the external server SV1 via the external communication device 1 and the external network N.

[0129] The control unit 20 of the in-vehicle device 2 starts relay processing using the generated conversion rule (S5). The storage unit 23 of the in-vehicle device 2 stores the conversion rule for each frame (for each frame name). The control unit 20 of the in-vehicle device 2 performs relay processing for frames where the definition version differs between the transmitting ECU and the receiving ECU by referring to the conversion rule stored in the storage unit 23. The control unit 20 of the in-vehicle device 2 extracts the identifier (CAN-ID) or frame name contained in the received frame and performs conversion processing for that frame by referring to the conversion rule corresponding to the extracted frame name.

[0130] FIG. 23 is a flowchart illustrating the processing (relay processing) of the control unit 20 of the in-vehicle device 2. When starting the relay processing using the conversion rule, the control unit 20 of the in-vehicle device 2 performs the following processing.

[0131] The control unit 20 of the in-vehicle device 2 acquires the number of received frames (S501). For example, when using the CAN communication protocol, the control unit 20 of the in-vehicle device 2 refers to the register of the CAN reception port of the in-vehicle communication unit 22 and acquires the CAN reception frame number (the number of received CAN frames).

[0132] The control unit 20 of the in-vehicle device 2 sets the number of relayed frames to 0 (S502). By setting (storing in the storage unit 23) the number of relayed frames to 0, the control unit 20 of the in-vehicle device 2 initializes the number of relayed frames.

[0133] The control unit 20 of the in-vehicle device 2 determines whether the number of relayed frames is smaller than the number of received frames (S503). The control unit 20 of the in-vehicle device 2 determines whether the number of relayed frames is smaller than the number of received frames, i.e., "the number of relayed frames < CAN reception frame number".

[0134] If the number of relayed frames is smaller than the number of received frames (S503: YES), the control unit 20 of the in-vehicle device 2 extracts the received frame (S504). When the number of relayed frames is smaller than the number of received frames, the control unit 20 of the in-vehicle device 2 extracts the received frame by extracting the CAN reception frame from the CAN reception port.

[0135] The control unit 20 of the in-vehicle device 2 acquires the number of relay destination buses (S505). In the storage unit 23 of the in-vehicle device 2 that functions as a relay device, a routing map used when performing relay processing is stored. The routing map includes information regarding the relay destination bus (communication line 41) for each frame (for each frame name). The control unit 20 of the in-vehicle device 2 refers to the routing map stored in the storage unit 23 and acquires the number of relay destination buses and the relay destination bus ID list.

[0136] The control unit 20 of the in-vehicle device 2 sets the number of relayed buses to 0 (S506). The control unit 20 of the in-vehicle device 2 initializes the number of relayed buses by setting it to 0 (storing it in the storage unit 23).

[0137] The control unit 20 of the on-board device 2 determines whether the number of relayed buses is less than the number of destination buses (S507). The control unit 20 of the on-board device 2 determines whether the number of relayed buses is less than the number of destination buses, i.e., "number of relayed buses" < "number of destination buses".

[0138] If the number of relayed buses is less than the number of destination buses (S507: YES), the control unit 20 of the on-board device 2 executes a conversion process using the conversion rules (S508). If the number of relayed buses is less than the number of destination buses, the control unit 20 of the on-board device 2 refers to the conversion rule table using the CAN-ID (frame identifier) ​​as the key and, if necessary (for communication specification items in the conversion rule table that require conversion), executes a conversion process such as CAN-ID conversion, data length conversion, or signal conversion.

[0139] In other words, the control unit 20 of the in-vehicle device 2 sets the CAN-ID of the receiving side in CAN-ID conversion. The control unit 20 of the in-vehicle device 2 sets the data length of the receiving side in data length conversion. In signal conversion, the control unit 20 of the in-vehicle device 2 sets the receiving side signal to a value shown by the formula "receiving side signal = transmitting side signal × coefficient + intercept". In this case, if the minimum receiving side value is greater than the transmitting side signal ("if minimum receiving side value > transmitting side signal"), the receiving side signal is set to the minimum receiving side value ("receiving side signal = minimum receiving side value"), and if the maximum receiving side value is less than the transmitting side signal ("if maximum receiving side value < transmitting side signal"), the receiving side signal is set to the maximum receiving side value ("receiving side signal = maximum receiving side value").

[0140] The control unit 20 of the on-board device 2 determines whether the conversion content does not include "periodic conversion," or whether the conversion content includes "periodic conversion" and it is the first time a "converted frame" is transmitted to the bus (S509). If the conversion content does not include "periodic conversion," or if the conversion content includes "periodic conversion" and it is the first time a "converted frame" is transmitted to the bus (S509: YES), the control unit 20 of the on-board device 2 transmits the converted frame (S510). The number of relayed frames is increased by one each time a frame relay is performed by an increment process described later (+1). The control unit 20 of the on-board device 2 may, for example, determine whether the relay of the converted frame is the first based on the number of relayed frames.

[0141] The control unit 20 of the on-board device 2 starts the transmit timer (S511). The control unit 20 of the on-board device 2 may also perform processing related to the transmit timer if the transmit cycle in the communication specification item requires conversion (conversion is required). In this case, the control unit 20 of the on-board device 2 may send the converted frame to the transmit bus as a receiver-side cycle timer expiration interrupt and start the transmit timer (receiver-side cycle).

[0142] After processing in S511, or if the conversion content does not include "periodic conversion," or if the conversion content includes "periodic conversion" and it is not the first transmission of "converted frames" to the bus (S509: NO), the control unit 20 of the on-board device 2 performs an increment process for the number of relayed buses (S512). The control unit 20 of the on-board device 2 performs an increment process ("number of relayed buses" ← "number of relayed buses" + 1) by increasing the value of the number of relayed buses by 1 (+1), and then performs a loop process to execute the processing from S507 again.

[0143] If the number of relayed buses is not less than the number of destination buses (S507: NO), the control unit 20 of the on-board device 2 performs an increment process for the number of relayed frames (S513). The control unit 20 of the on-board device 2 performs an increment process ("number of relayed frames" ← "number of relayed frames" + 1) by increasing the value of the number of relayed frames by 1 (+1), and then performs a loop process to execute the process from S503 again.

[0144] If the number of relayed frames is not less than the number of received frames (S503: NO), the control unit 20 of the in-vehicle device 2 terminates this process. If the number of relayed frames is not less than the number of received frames, i.e., if it is greater than or equal to the number of received frames (when the number of relayed frames reaches the number of received frames), the control unit 20 of the in-vehicle device 2 terminates this process.

[0145] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of this disclosure is indicated by the claims, not in the sense described above, and all modifications within the sense and scope equivalent to the claims are intended.

[0146] With respect to the multiple claims described in the claims, they can be combined with each other regardless of the form of reference. Multiple dependent claims that depend on multiple claims may be described in the claims. Multiple dependent claims that depend on multiple dependent claims may also be described. Even if multiple dependent claims that depend on multiple dependent claims are not described, this does not limit the description of multiple dependent claims that depend on multiple dependent claims. [Explanation of Symbols]

[0147] C Vehicle S In-vehicle system SV1 External Server (OTA Server) N External Network 1. External communication device 11 Antennas 2. On-board equipment (relay device) 20 Control Unit 21 Input / Output Interfaces 22 In-vehicle communication unit 23 Memory section M recording medium P Control Program (Program Product) 3. On-board ECUs (update ECU, partner ECU, transmitting ECU, receiving ECU) 4. In-vehicle network 41 Communication lines

Claims

1. An in-vehicle device that is capable of communicating with multiple in-vehicle ECUs installed in a vehicle, The system includes a control unit that performs processing on frames transmitted and received between the in-vehicle ECUs, The control unit, Information regarding the software executed in each of the multiple in-vehicle ECUs is obtained, Based on the acquired information about the software, the frames transmitted and received when the software is executed are identified, Identify the transmitting ECU that transmits the identified frame and the receiving ECU that receives it. The definition information of the frame in the transmitting ECU is obtained, The definition information of the frame in the receiving ECU is obtained, Based on the frame definition information in the transmitting ECU and the frame definition information in the receiving ECU, a frame conversion rule is generated. Using the conversion rules for the generated frame, the frame from the transmitting ECU is converted. The converted frame is output to the receiving ECU. In-vehicle device.

2. The information relating to the software includes the version of the software, The control unit, In multiple in-vehicle ECUs, the updated ECU that has undergone the software update is identified based on the software version. Identify the frames that are transmitted and received when the software implemented in the identified updated ECU is executed. The in-vehicle device according to claim 1.

3. The information relating to the software includes the version of the frame transmitted and received when the software is executed, The control unit, If the version of the frame in the transmitting ECU and the version of the frame in the receiving ECU are different, a frame conversion rule is generated. The in-vehicle device according to claim 2.

4. The definition information of the frame includes multiple communication specification items, The control unit, Determine whether there are any differences in each of the communication specification items included in the frame definition information between the transmitting ECU and the receiving ECU. The conversion rule is generated according to the differences in the aforementioned communication specification items. The in-vehicle device according to claim 3.

5. The aforementioned communication specification item includes the identifier of the frame, The control unit generates the conversion rule, which includes a provision to convert the frame identifier of the transmitting ECU to the frame identifier of the receiving ECU if the frame identifiers of the transmitting ECU and the receiving ECU are different. The in-vehicle device according to claim 4.

6. The aforementioned communication specification item includes the period of the frame, The control unit generates the conversion rule, which includes a provision to convert the frame period of the transmitting ECU to the frame period of the receiving ECU if the frame period of the transmitting ECU is shorter than the frame period of the receiving ECU, or if the receiving ECU allows for a difference in period. The in-vehicle device according to claim 4.

7. The aforementioned communication specification item includes the data length of the frame, The control unit generates the conversion rule, which includes a provision to convert the data length of the frame of the transmitting ECU to the data length of the frame of the receiving ECU if the data length of the frame of the transmitting ECU is longer than the data length of the frame of the receiving ECU, or if the receiving ECU allows a difference in data length. The in-vehicle device according to claim 4.

8. The aforementioned communication specification item includes the resolution of the data contained in the frame, The control unit generates the conversion rule, which includes a provision to convert the resolution of the frame of the transmitting ECU to the resolution of the frame of the receiving ECU if the resolution of the frame of the transmitting ECU is finer than the resolution of the frame of the receiving ECU, or if the receiving ECU allows for differences in resolution. The in-vehicle device according to claim 4.

9. The control unit, Among the multiple communication specification items included in the definition information of the frame, the communication specification items that differ between the transmitting ECU and the receiving ECU are extracted. Determine whether conversion is possible in the aforementioned communication specification items where there are differences. If there are any communication specification items that cannot be converted, the process of generating the conversion rule is interrupted. The in-vehicle device according to claim 4.

10. A computer that is communicatively connected to multiple in-vehicle ECUs installed in a vehicle and processes frames transmitted and received between the in-vehicle ECUs, Information regarding the software executed in each of the multiple in-vehicle ECUs is obtained, Based on the acquired information about the software, the frames transmitted and received when the software is executed are identified, Identify the transmitting ECU that transmits the identified frame and the receiving ECU that receives it. The definition information of the frame in the transmitting ECU is obtained, The definition information of the frame in the receiving ECU is obtained, Based on the frame definition information in the transmitting ECU and the frame definition information in the receiving ECU, a frame conversion rule is generated. Using the conversion rules for the generated frame, the frame from the transmitting ECU is converted. The converted frame is output to the receiving ECU. A program that executes a process.

11. A computer that is communicatively connected to multiple in-vehicle ECUs installed in a vehicle and processes frames transmitted and received between the in-vehicle ECUs, Information regarding the software executed in each of the multiple in-vehicle ECUs is obtained, Based on the acquired information about the software, the frames transmitted and received when the software is executed are identified, Identify the transmitting ECU that transmits the identified frame and the receiving ECU that receives it. The definition information of the frame in the transmitting ECU is obtained, The definition information of the frame in the receiving ECU is obtained, Based on the frame definition information in the transmitting ECU and the frame definition information in the receiving ECU, a frame conversion rule is generated. Using the conversion rules for the generated frame, the frame from the transmitting ECU is converted. The converted frame is output to the receiving ECU. An information processing method that executes a process.

Images