Data communication device, vehicle system, data communication system, data communication method, and data communication program

Abstract

An OTA master (14), repeaters (6-8), and ECUs (25-31) hold a diagnostic client for performing a diagnostic service. The OTA master, the repeaters, and the ECUs allocate a command for performing the diagnostic service to a user data area of a CAN communication frame using a 29-bit CAN ID or an Ethernet communication frame, and perform the diagnostic service by transmitting and receiving, to / from a communication partner device, the CAN communication frame or the Ethernet communication frame to which the command is allocated.

Description

Data communication device, vehicle system, data communication system, data communication method, and data communication program CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Japanese Application No. 2024-67498 filed on April 18, 2024, the contents of which are incorporated herein by reference.

[0002] The present disclosure relates to a data communication device, a vehicle system, a data communication system, a data communication method, and a data communication program.

[0003] A vehicle is equipped with a large number of electronic control units (hereinafter referred to as ECUs (Electronic Control Units)). Over-the-air (OTA) repro technology is available as a diagnostic service for the ECUs, which wirelessly updates the software installed in the ECUs. A configuration has been disclosed in which, when there are multiple target ECUs, which are devices subject to software updates, software is installed in parallel from an OTA master to the multiple target ECUs (see, for example, Patent Document 1).

[0004] Japanese Patent Application Laid-Open No. 2018-92577

[0005] When software is installed in parallel from an OTA master to multiple target ECUs, data communication using the standard 11-bit CAN ID prevents data communication if identical CAN IDs collide. Therefore, to prevent CAN ID collisions, only one installer serving as a diagnostic client must be installed per vehicle. This requires mediation to stop transmissions in the installer, which increases the time required for software installation. Furthermore, because one installer is installed on a specific ECU, the ECUs to which the installer is installed are limited to ECUs that can communicate with all ECUs in the vehicle or ECUs with high-performance specifications. To address these issues, a configuration is envisioned in which installers are installed on one or more domain control ECUs serving as client devices from the OTA master, and software is installed in parallel from the domain control ECUs where the installers are installed to the target ECUs.

[0006] However, a configuration in which a diagnostic client is located from the OTA master to the domain control ECU is expected to have the following problems. Specifically, diagnostic communication, which is intended for fault diagnosis, does not allow multiple diagnostic clients to freely send and receive commands; diagnostic clients cannot freely send and receive commands between each other. Furthermore, diagnostic clients located in the domain control ECU are intended for temporary activation and lack commands for determining execution conditions, such as whether an ECU exists as a communication partner. Furthermore, CAN communication using an 11-bit CAN ID defines only the target address, and each frame is 8 or 64 bytes. Therefore, a flow control mechanism, such as that defined in diagnostic communication, is required to perform complex processing. Thus, a configuration in which a diagnostic client is located from the OTA master to the domain control ECU requires a mechanism for diagnostic clients to send and receive commands between each other to solve the above-mentioned problems.

[0007] An object of the present disclosure is to enable diagnostic clients to appropriately send and receive commands to each other and to appropriately perform diagnostic services.

[0008] A data communication device according to one aspect of the present disclosure includes a diagnostic client for performing a diagnostic service, and assigns a command for performing the diagnostic service to a user data area of ​​a CAN communication frame or an Ethernet communication frame that uses a 29-bit CAN ID, and transmits and receives the CAN communication frame or the Ethernet communication frame to which the command is assigned, to and from a communication partner device, thereby performing the diagnostic service.

[0009] A vehicle system according to one aspect of the present disclosure includes a plurality of data communication devices each holding a diagnostic client for performing a diagnostic service, wherein each data communication device assigns a command for performing the diagnostic service to a user data area of ​​a CAN communication frame or an Ethernet communication frame using a 29-bit CAN ID, and transmits and receives the CAN communication frame or the Ethernet communication frame to which the command is assigned, to and from a communication partner device, thereby performing the diagnostic service.

[0010] A data communication system according to one aspect of the present disclosure includes a data communication device having a diagnostic client for performing a diagnostic service, and a communication partner device, wherein the data communication device assigns a command for performing the diagnostic service to a user data area of ​​a CAN communication frame or an Ethernet communication frame that uses a 29-bit CAN ID, and transmits and receives the CAN communication frame or the Ethernet communication frame to which the command is assigned, to and from the communication partner device, thereby performing the diagnostic service.

[0011] A data processing method according to one aspect of the present disclosure involves a data communication device that holds a diagnostic client for performing a diagnostic service, assigning a command for performing the diagnostic service to a user data area of ​​a CAN communication frame or an Ethernet communication frame that uses a 29-bit CAN ID, transmitting and receiving the CAN communication frame or the Ethernet communication frame to which the command is assigned between the data communication device and a communication partner device, and performing a data communication procedure for performing the diagnostic service.

[0012] A data processing program according to one embodiment of the present disclosure causes a data communication device that holds a diagnostic client for performing a diagnostic service to assign a command for performing the diagnostic service to a user data area of ​​a CAN communication frame or an Ethernet communication frame that uses a 29-bit CAN ID, transmit and receive the CAN communication frame or the Ethernet communication frame to which the command is assigned, to a communication partner device, and execute a data communication procedure for performing the diagnostic service.

[0013] According to one aspect of the present disclosure, a diagnostic client for performing diagnostic services is held, a command for performing the diagnostic services is assigned to a user data area of ​​a CAN communication frame or an Ethernet communication frame that uses a 29-bit CAN ID, and the CAN communication frame or the Ethernet communication frame to which the command is assigned is transmitted and received between a communication partner device, thereby performing the diagnostic services. The diagnostic clients can transmit and receive commands appropriately, and the diagnostic services can be performed appropriately.

[0014] According to one aspect of the present disclosure, in a vehicle system including a plurality of data communication devices, each data communication device holds a diagnostic client for performing diagnostic services, assigns commands for performing the diagnostic services to a user data area of ​​a CAN communication frame or an Ethernet communication frame that uses a 29-bit CAN ID, and transmits and receives the CAN communication frame or the Ethernet communication frame to which the command is assigned with a communication partner device to perform the diagnostic services. The diagnostic clients can properly transmit and receive commands, allowing the diagnostic services to be performed properly.

[0015] According to one aspect of the present disclosure, in a data communication system including a data communication device and a communication partner device, the data communication device holds a diagnostic client for performing diagnostic services, assigns commands for performing the diagnostic services to user data areas of CAN communication frames or Ethernet communication frames that use a 29-bit CAN ID, and transmits and receives the CAN communication frames or Ethernet communication frames to which the commands are assigned, with the communication partner device, thereby performing the diagnostic services. The diagnostic clients can properly transmit and receive commands, allowing the diagnostic services to be performed properly.

[0016] The above and other objects, features, and advantages of the present disclosure will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which Fig. 1 is a diagram showing the overall configuration of one embodiment, Fig. 2 is a functional block diagram of a ReproMaster, Fig. 3 is a diagram showing distribution of specification data and an installer, Fig. 4 is a diagram showing a series of processing phases, Fig. 5 is a diagram explaining transfer of authority to an installer, Fig. 6 is a diagram showing specification data, Fig. 7 is a diagram showing specification data, Fig. 8 is a diagram explaining transmission and reception of commands, Fig. 9 is a diagram showing CAN communication frames and Ethernet communication frames, Fig. 10 is a diagram showing types of commands, Fig. 11 is a diagram showing how to implement commands, Fig. 12 is a diagram showing SID assignment, Fig. 13 is a diagram showing request commands and response commands, Fig. 14 is a diagram showing examples of request commands and response commands, Fig. 15 is a diagram showing an HTTP method, and Fig. 16 is a diagram explaining routing conversion.

[0017] An embodiment will be described below with reference to the drawings. In this embodiment, a diagnostic service includes all services that utilize diagnostic communication, such as software updates, remote diagnostics, and vehicle information collection. A diagnostic client corresponds to an installer, which is a write control function unit for performing installation in the software update installation phase, a control function unit for performing remote diagnostics, a control function unit for performing vehicle information collection, and the like.

[0018] As shown in Fig. 1, a data communication system 1 (corresponding to a data communication system) is configured to enable data communication between an over-the-air (OTA) center 2 (corresponding to an external device) and a vehicle system 3 installed in a vehicle. An unspecified number of vehicle systems 3 can communicate data with the OTA center 2. The vehicle is, for example, an electric vehicle such as a BEV powered by electricity from an on-board battery. Unlike non-electric vehicles such as gasoline-powered vehicles, electric vehicles can freely control the power supply to all ECUs installed in the vehicle using software.

[0019] The vehicle system 3 includes an in-vehicle communication device (hereinafter referred to as a DCM (Data Communication Module)) 4, a central gateway (hereinafter referred to as a CGW (Central Gateway)) 5, a first repeater 6 (corresponding to a data communication device or a repeater), a second repeater 7 (corresponding to a data communication device or a repeater), and a third repeater 8 (corresponding to a data communication device or a repeater). The CGW 5, the first repeater 6, the second repeater 7, and the third repeater 8 are referred to as domain controllers. The first repeater 6, the second repeater 7, and the third repeater 8 are connected to the CGW 5 via, for example, a CAN bus or Ethernet (registered trademark). In a configuration connected via a CAN bus, CAN communication between the CGW 5 and the repeaters 6 to 8 is data communication using a 29-bit CAN ID.

[0020] The OTA center 2 generates and stores an update package including software and specification data to be updated. The OTA center 2 also stores update packages acquired from external sources, such as an OEM (Original Equipment Manufacturer). The OTA center 2 includes a configuration management function unit that manages the vehicle hardware and software configurations that may be targets for the update package distribution, and a distribution management function unit that manages the distribution of the update package to the vehicle. The software includes programs, data, libraries, etc. for operating the ECU.

[0021] The specification data includes information capable of identifying an ECU compatible with OTA, information capable of identifying a target ECU that is the target of the software update, information capable of identifying an installation target in the installation phase described below, information capable of identifying the order of installation, information capable of identifying an activation target in the activation phase described below, information capable of identifying the order of activation, etc. An ECU compatible with OTA is an ECU that can implement OTA. Note that the OTA center 2 may include the specification data in an update package and distribute it to the vehicle, or may not include the specification data in the update package and distribute the specification data to the vehicle separately from the update package.

[0022] The DCM 4 performs data communication with the OTA center 2 via a communication network. The communication network may include, for example, a mobile communication network using a 4G line or a 5G line, the Internet, Wi-Fi (Wireless Fidelity) (registered trademark), etc. The DCM 4 and the CGW 5 may be integrated, and the functions of the DCM 4 may be incorporated into the CGW 5. Alternatively, the functions of the DCM 4 and the CGW 5 may be incorporated into a display device or the like. When the DCM 4 receives an update package distributed from the OTA center 2, the DCM 4 forwards the received update package to the CGW 5. Software distributed from the OTA center 2 to the DCM 4 is, for example, OTA repro software. Inter-center communication, which is data communication between the OTA center 2 and the DCM 4, uses, for example, an SOVD format conforming to the SOVD communication specifications or a Rest (REpresentational State Transfer) API format conforming to the Rest API communication specifications. A software update using an update package distributed from the OTA center 2 is called wireless repro. On the other hand, a software update using an update package distributed from an external tool (described later) is called wired repro.

[0023] The CGW 5 includes a ReproMaster 9, an in-vehicle HMI (Human Machine Interface) 10, a remote diagnostics 11, and an onboard client (hereinafter referred to as OBC) 12. As shown in Fig. 2, the ReproMaster 9 includes a downloader 13 and an OTA master 14 (a data communication device, equivalent to a master device).

[0024] When a download execution request is input from the OTA master 14, the downloader 13 instructs the DCM 4 to execute the download process. The update package distributed from the OTA center 2 is received by the DCM 4, and the received update package is transferred from the DCM 4, whereby the downloader 13 downloads the update package from the OTA center 2 via the DCM 4. The downloaded update package is temporarily stored in the ReproMaster 9 or an external memory, which will be described later.

[0025] The OTA master 14 includes an update control function unit 15, a state management function unit 16, a display control function unit 17, a write control function unit (Flashing Adapter) 18, a power control function unit 19, an OTA-compatible ECU list storage unit 20, and a campaign target ECU list storage unit 21. These functions are realized by software processing in which a microcomputer executes a computer program stored in a non-transient physical storage medium using a CPU, or by hardware processing using a dedicated electronic circuit.

[0026] The update control function unit 15 has a function of controlling software updates. The status management function unit 16 has a function of managing the status of the software to be updated as the software is updated. The display control function unit 17 has a function of controlling the display on the in-vehicle HMI 10 as the software is updated. The write control function unit 18 has a function of controlling the installation of software into the software to be updated. Hereinafter, the write control function unit 18 may be referred to as an installer 18 (equivalent to a diagnostic client).

[0027] The OTA-compatible ECU list storage unit 20 stores information included in the specification data that can identify ECUs that are compatible with OTA as an OTA-compatible ECU list. The campaign target ECU list storage unit 21 stores information included in the specification data that can identify target ECUs as a campaign target ECU list. Among the ECUs that are compatible with OTA, an ECU that is recorded in the campaign target ECU list is the target ECU, and among the ECUs that are compatible with OTA, an ECU that is not recorded in the campaign target ECU list is an ECU that is not eligible for the campaign.

[0028] The power supply control function unit 19 refers to the OTA-compatible ECU list and identifies an ECU that supports OTA. The power supply control function unit 19 refers to the campaign target ECU list and identifies a target ECU. The power supply control function unit 19 cooperates with the power supply control app 22 located in the second relay 7 to control the power supply to the ECU as the software update progresses. Note that, although the present embodiment illustrates a case in which the power supply control function unit 19 cooperates with the power supply control app 22 to control the power supply to the ECU, a configuration in which a power control ECU that controls the power supply to the ECU is located may also be used. Targets for which the power supply control function unit 19 controls power supply include the DCM 4, the in-vehicle HMI 10, the first relay 6, the second relay 7, the third relay 8, etc.

[0029] The OBC 12 includes an arbitration function unit 23 and a diagnostic communication function unit 24. The arbitration function unit 23 is responsible for diagnostic communication between the ReproMaster 9 and the repeater or ECU, and arbitrates which diagnostic communication should be prioritized. The diagnostic communication function unit 24 performs diagnostic communication between the ReproMaster 9 and the repeater or ECU according to the arbitration result of the arbitration function unit 23.

[0030] The OBC 12 is connected to a plurality of ECUs 25, 26 (corresponding to data communication devices and electronic control devices) via a first repeater 6. The plurality of ECUs 25, 26 are connected to the first repeater 6 via, for example, a CAN bus. CAN communication between the first repeater 6 and the plurality of ECUs 25, 26 is data communication using a 29-bit CAN ID. Of the plurality of ECUs 25, 26 connected to the first repeater 6, an ECU whose software is to be updated can be the target ECU. Although the example shows a case where two ECUs are connected to the first repeater 6, the number of ECUs connected to the first repeater 6 is not limited to two.

[0031] Similarly, the OBC 12 is connected to a plurality of ECUs 27, 28 (corresponding to data communication devices and electronic control devices) via a second relay 7. The plurality of ECUs 27, 28 are connected to the second relay 7 via, for example, a CAN bus. CAN communication between the second relay 7 and the plurality of ECUs 27, 28 is data communication using a 29-bit CAN ID. Of the plurality of ECUs 27, 28 connected to the second relay 7, an ECU whose software is to be updated can be the target ECU. Although the example shows a case where two ECUs are connected to the second relay 7, the number of ECUs connected to the second relay 7 is not limited to two.

[0032] Similarly, the OBC 12 is connected to a plurality of ECUs 29, 30 (corresponding to data communication devices and electronic control devices) via a third relay 8. The plurality of ECUs 29, 30 are connected to the third relay 8 via, for example, a CAN bus. CAN communication between the third relay 8 and the plurality of ECUs 29, 30 is data communication using a 29-bit CAN ID. Of the plurality of ECUs 29, 30 connected to the third relay 8, an ECU whose software is to be updated can be the target ECU. Although the example shows a case where two ECUs are connected to the third relay 8, the number of ECUs connected to the third relay 8 is not limited to two.

[0033] Furthermore, the OBC 12 is connected to an ECU 31 (corresponding to a data communication device or electronic control device) without going through a repeater. Of the multiple ECUs connected to the OBC 12, an ECU whose software is to be updated can be the target ECU. Although the example shows a case where one ECU is connected to the OBC 12 without going through a repeater, the number of ECUs connected to the OBC 12 without going through a repeater is not limited to one.

[0034] The power control application 22 arranged in the second repeater 7 cooperates with the power control function unit 19 of the OTA master 14 as described above, and controls the power supply to the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 25 to 31 as the software update progresses. That is, the OTA master 14 cooperates the power control function unit 19 with the power control application 22, and controls the power supply to the repeaters 6 to 8 and the ECUs 25 to 31 that are capable of diagnostic communication via the diagnostic communication function unit 24.

[0035] When a start request is input from the OTA master 14 while the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 25 to 31 are in a stopped state, the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 25 to 31 transition to a started state, and the supply of power from the in-vehicle battery is stopped. When a stop request is input from the OTA master 14 while the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 25 to 31 are in a started state, the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 25 to 31 transition to a stopped state, and the supply of power from the in-vehicle battery is stopped.

[0036] The external tool 32, while attached to a connector arranged in the vehicle, delivers the update package to the OTA master 14. The external memory 33 functions as external storage for the OTA master 14, and as a temporary storage destination for the update package downloaded from the OTA center 2 as described above, and also as a temporary save destination for pre-update software when updating the software of the repeaters 6 to 8 and the ECUs 25 to 31.

[0037] A series of processing phases related to a software update includes a configuration synchronization phase, a download phase, an installation phase, an activation phase, and an update completion notification phase. The configuration synchronization phase is a phase in which the OTA center 2 synchronizes configuration information of the software and hardware of the ECU installed in the target vehicle with configuration information of the software and hardware of the ECU.

[0038] The download phase is a phase in which the OTA master 14 downloads an update package from the OTA center 2. Before performing the download phase, the OTA master 14 determines, for example, whether the software to be downloaded is legitimate, and whether the download can be completed by checking the data volume of the software to be downloaded against the remaining charge of the vehicle battery. If the OTA master 14 determines, for example, that the software to be downloaded is legitimate and that the remaining charge of the vehicle battery is sufficient for the data volume of the software to be downloaded, the OTA master 14 performs the download phase.

[0039] The installation phase is a phase in which the OTA master 14 installs software extracted from the update package into the target ECU. Installation means writing the software to a storage area of ​​the target ECU. Before performing the installation phase, the OTA master 14 determines, for example, whether the software to be installed is authentic, and whether the installation can be completed by comparing the data volume of the software to be installed with the remaining charge of the vehicle battery. If the OTA master 14 determines, for example, that the software to be installed is authentic and that the remaining charge of the vehicle battery is sufficient for the data volume of the software to be installed, the OTA master 14 performs the installation phase.

[0040] The activation phase is a phase in which the installed software is activated in the target ECU. Before performing the activation phase, the OTA master 14 determines, for example, whether the software to be activated is authentic, and whether the activation can be completed by comparing the data volume of the software to be activated with the remaining charge of the vehicle battery. If the OTA master 14 determines, for example, that the software to be activated is authentic and that the remaining charge of the vehicle battery is sufficient for the data volume of the software to be activated, the OTA master 14 performs the activation phase.

[0041] The update completion notification phase is a phase in which the OTA master 14 transmits an update completion notification to the OTA center 2 when the OTA master 14 receives an update completion notification from the target ECU upon completion of activation.

[0042] As shown in Fig. 3, the OTA center 2 distributes specification data including location information, diagnostic service information, authority transfer information, and parallel execution information, as well as an installer, to the vehicle. The OTA center 2 performs a distribution procedure using a data processing method and executes the distribution procedure using a data processing program. The location information is information that allows the OTA master 14 to identify the location of the installer. Based on the location information, the OTA master 14 identifies the first relay 6, the second relay 7, and the third relay 8 as the location of the installer, and distributes the installer to the first relay 6, the second relay 7, and the third relay 8, as described below.

[0043] The diagnostic service information is information used by the OTA master 14 to install software into target ECUs. The OTA master 14 identifies target ECUs based on the diagnostic service information, and determines the order in which software should be installed into the identified target ECUs, whether the software will be installed into the identified target ECUs using, for example, a storage method or a streaming method. As described below, when authority is transferred from the OTA master 14 to an installer, the installer to which authority is transferred from the OTA master 14 identifies target ECUs based on the diagnostic service information, and determines the order in which software should be installed into the identified target ECUs, whether the software will be installed into the identified target ECUs using, for example, a storage method or a streaming method, and installs the software into the target ECUs.

[0044] The OTA master 14 determines the destination of authority transfer to the installer, the order of authority transfer, etc., based on the authority transfer information. When software is installed serially into the target ECUs 25 to 28, for example, when software is installed first into the target ECUs 25 and 26 connected to the first repeater 6 and then into the target ECUs 27 and 28 connected to the second repeater 7, the OTA master 14 transfers authority to the installer arranged in the first repeater 6 first and then into the installer arranged in the second repeater 7. When software is installed in parallel into the target ECUs 25 to 28 according to parallel execution information described later, for example, the OTA master 14 transfers authority to the installer arranged in the first repeater 6 and the installer arranged in the second repeater 7 simultaneously.

[0045] The parallel execution information is information for the installers to install software in the target ECUs in parallel, i.e., the information for the installer located in the first relay device 6 to install software in the target ECUs 25 and 26, the installer located in the second relay device 7 to install software in the target ECUs 27 and 28, and the installer located in the third relay device 8 to install software in the target ECUs 29 and 30 in parallel.

[0046] The parallel execution information includes information that can identify whether multiple installers should install software in the target ECU in parallel, in other words, simultaneously. The OTA master 14 instructs the installer to which authority has been delegated to perform installation based on the parallel execution information. When the OTA master 14 causes multiple installers to install software in the target ECU in parallel, the OTA master 14 causes the multiple installers to install the software in the target ECU simultaneously. To achieve this, the OTA master 14 instructs the multiple installers to install the software in parallel, for example, or simultaneously.

[0047] The parallel execution information may include information that can identify whether multiple installers should install software on the target ECU serially, in other words, sequentially, and information that can identify the order in which the software should be installed sequentially. When the OTA master 14 causes multiple installers to install software on the target ECU serially, the OTA master 14 causes the multiple installers to install the software on the target ECU sequentially. To achieve this, the OTA master 14, for example, instructs one installer to install the software, waits for a notification of installation completion from that installer, and, after receiving the notification of installation completion, instructs the next installer in the order to install the software. Note that waiting for such a notification of installation completion is not necessary when instructing multiple installers to install the software in parallel.

[0048] The parallel execution information may include information for each of the authorized installers to install software in multiple target ECUs in parallel. The authorized installer installs software in multiple target ECUs in parallel or serially based on the parallel execution information. When installing software in multiple target ECUs in parallel, the installer installs software in multiple ECUs simultaneously in parallel. When installing software in multiple target ECUs in serial, the installer installs software in one target ECU, and after completing the installation of the software in the one target ECU, installs the software in the next ECU.

[0049] The OTA master 14 deploys the installer to the relay devices 6 to 8 based on the deployment destination information received from the OTA center 2. An example of a method by which the OTA master 14 deploys the installer to the deployment destination is a method in which the OTA master 14 installs the installer as an application by additionally deploying the executable file of the installer received from the OTA center 2 to the file system of the deployment destination. The OTA master 14 can delete the deployed installer from the deployment destination. An example of a method by which the OTA master 14 deletes an installer is a method in which the OTA master 14 uninstalls the installer as an application by deleting the executable file of the installer that was additionally deployed to the file system of the deployment destination. Another method by which the OTA master 14 deploys or deletes an installer is a method in which the OTA master 14 installs or uninstalls the installer by writing or deleting binary data including the installer to or from the address area of ​​the non-volatile memory of the deployment destination.

[0050] The OTA master 14 transfers authority to the installers located in the repeaters 6 to 8 based on the authority transfer information received from the OTA center 2, and instructs the installers to install the software into the target ECUs. The OTA master 14 installs the software into the target ECUs in parallel in accordance with the parallel execution information received from the OTA center 2.

[0051] As shown in Fig. 4, the OTA master 14 performs a series of processing phases related to a software update, including a configuration synchronization phase (S1), a download phase (S2), an installation phase (S3), an activation phase (S4), and an update completion notification phase (S5). As shown in Fig. 5, in the installation phase, the OTA master 14 places the installer 18, the OBC 12, and the specification data in the relays 6 to 8, transfers authority to the placed installer 18, and instructs the installer 18 to install the software in the target ECU.

[0052] That is, when the OTA master 14 places the installer 18, transfers authority to the installer 18, and instructs the first relay 6 to install software into the target ECUs 25 and 26. Similarly, when the OTA master 14 places the installer 18, transfers authority to the installer 18, and instructs the second relay 7 to install software into the target ECUs 27 and 28. When the OTA master 14 places the installer 18, transfers authority to the installer 18, and instructs the third relay 8 to install software into the target ECUs 29 and 30.

[0053] The specification data will now be described. When the OTA master 14 places specification data in the repeaters 6-8, it may place specification data common to the OTA master 14 and the repeaters 6-8, or it may place specification data specific to each repeater 6-8. When placing specification data common to the OTA master 14 and the repeaters 6-8, it places specification data that records information about each target ECU of the OTA master 14 and the repeaters 6-8, as shown in FIG. 6. The data referenced by the repeaters 6-8 is included in "Sync Group Info A." The repeaters 6-8 each refer to the data defined as their own reference target and install software into the target ECUs 25-30.

[0054] When specific data specific to the OTA master 14 and the repeaters 6 to 8 is allocated, specific data recording information on each target ECU for each repeater 6 to 8 is allocated, as shown in Figure 7. The data referenced by the first repeater 6 is included in "Sync Group Info B," the data referenced by the second repeater 7 is included in "Sync Group Info C," and the data referenced by the third repeater 8 is included in "Sync Group Info D." The repeaters 6 to 8 each refer to the data defined as their own reference target and install software into the target ECUs 25 to 30.

[0055] The following describes the transmission and reception of commands. As shown in FIG. 8, commands related to the transfer of authority of a diagnostic client are transmitted and received between the OTA master 14 and the repeaters 6-8. The relationship between the OTA master 14 and the repeaters 6-8 is that of a data communication device and a communication partner device. The OTA master 14 and the repeaters 6-8 perform data communication procedures using a data communication method and execute the data communication procedures using a data communication program. When the OTA master 14 and the repeaters 6-8 are connected via a CAN bus, commands are assigned to the user data field (0-64) of the CAN communication frame using the 29-bit CAN ID shown in FIG. 9. When the OTA master 14 and the repeaters 6-8 are connected via Ethernet, commands are assigned to the user data field (User data (Max 64 kBytes) UDS Message) of the Ethernet communication frame shown in FIG. 9. When assigning commands to the user data field, commands in a format conforming to the UDS (Unified Diagnostic Services) protocol are assigned. In addition to having a UDS Service Identifier, Sub Function, and Parameter as shown in FIGS. 13 and 14 (to be described later), a command in a format having an Application Function may be assigned.

[0056] Commands related to special operation instructions are transmitted and received between the OTA master 14, repeaters 6-8, and ECUs 25-31, including commands related to the presence of diagnostic clients, commands related to the availability of diagnostic services, and other special operation instructions. Commands related to special operation instructions are commands related to services not specified in the UDS standard, and include commands related to the transfer of authority to diagnostic clients. The relationship between the OTA master 14, repeaters 6-8, and ECUs 25-31 is that of a data communication device and a communication partner device. The OTA master 14, repeaters 6-8, and ECUs 25-31 perform data communication procedures using a data communication method and execute the data communication procedures using a data communication program. In this case, commands are assigned to the user data field (0-64) of the CAN communication frame using the 29-bit CAN ID shown in Figure 9.

[0057] 8 illustrates a case in which the OTA master 14 places the installer and vehicle information collection as diagnostic clients in the first repeater 6, and the installer and remote diagnosis as diagnostic clients in the second repeater 7, and transfers authority to each of them. The first repeater 6 places the installer and vehicle information collection as diagnostic clients from the OTA master 14. When authority is transferred to the installer and an instruction to execute installation is received, the first repeater 6 installs software to the target ECUs 25 and 26. When authority is transferred to the vehicle information collection and an instruction to execute vehicle information collection is received, the first repeater 6 collects vehicle information from the target ECUs 25 and 26. The second repeater 7 places the installer and remote diagnosis as diagnostic clients from the OTA master 14. When authority is transferred to the installer and an instruction to execute installation is received, the second repeater 7 installs software to the target ECUs 27 and 28. When authority is transferred to the remote diagnosis and an instruction to execute remote diagnosis is received, the second repeater 7 performs remote diagnosis on the target ECUs 25 and 26. Similarly, the OTA master 14 places a diagnostic client in the third repeater 8. The third relay device 8 provides a diagnostic service to the target ECUs 29 and 30 when a diagnostic client is placed therein by the OTA master 14, authority is transferred to the diagnostic client, and execution of the diagnostic client is instructed.

[0058] As shown in FIG. 10, the types of commands that can be assigned to the user data area include commands with characteristics of regular behavior, commands with characteristics of request-acceptance type behavior (event), commands with characteristics of firing type (timer), and commands with characteristics of special behavior.

[0059] Commands with characteristics of steady behavior include, for example, commands related to synchronization of states between applications, and commands related to periodic communication of scene information, time information, etc. Commands with characteristics of request reception type behavior include, for example, commands related to authority transfer, commands related to confirmation of the existence of a diagnostic client (existent / not existing), and commands related to confirmation of compatible services of a diagnostic service (compatible / not compatible). Of the commands with characteristics of request reception type behavior, commands classified as "reliable" are commands that are sent after confirming a response from the communication partner device, and commands classified as "unreliable" are commands that are sent without confirming a response from the communication partner device.

[0060] Commands with firing characteristics include, for example, commands related to the passage of a certain amount of time, commands related to the establishment of a condition, etc. Of the commands with firing characteristics, commands classified as "reliable" are commands that are sent after a response from the communication partner device is confirmed, and commands classified as "unreliable" are commands that are sent without confirming a response from the communication partner device. Commands with special behavior characteristics include, for example, commands related to the establishment of a condition, etc.

[0061] As shown in FIG. 11 , commands are classified into commands that affect the inside and commands that affect the outside in terms of how they are implemented. Commands that affect the inside are commands that do not affect other devices and are expressed in the format "XX control does (verb)." Commands that affect the outside are commands that affect other devices and are expressed in the format "XX mechanism does (verb)." or "XX mechanism does (verb)." Commands with normal behavior characteristics, commands with request-acceptance behavior characteristics, and commands with firing characteristics are implemented as commands that affect the inside and commands that affect the outside, respectively. Commands with special behavior characteristics are implemented as commands that affect the outside.

[0062] The OTA master 14 allocates the above-mentioned commands using the "0xBA-0xBE" and "0xFA-0xFE" areas, which are areas open to system suppliers in the SID (Service Identifier) ​​allocation division of the UDS (Unified Diagnostic Services) protocol shown in Figure 12. As shown in Figure 13, the OTA master 14 can define 32,768 patterns by using, for example, "0xBA" as a request command and "0xFA" as a response command, defining 128 patterns in the "Sub Function," and defining 256 patterns in the "Application Function." By using the areas open to system suppliers, resources provided by the ISO standard can be utilized and the content can be freely changed for each OEM, for example.

[0063] 14, for example, the zero-series (00-0F) "Sub Function" is used as the OTA service area, and the required processing is defined using the "Application Function," and the required data is defined by combining the "Sub Function" and the "Application Function." For example, "00" of the "Application Function" is used to define configuration synchronization-related data, "01" is used to define download-related data, "02" is used to define installation-related data, "03" is used to define activation-related data, "04" is used to define authority transfer-related data, and "05" is used to define special operation instruction-related data.

[0064] For example, the first "Sub Function" (10-1F) is used as the SOVD conversion area, the required processing is defined using the "Application Function," and the required data is defined by combining the "Sub Function" and the "Application Function." As shown in Figure 15, for example, "Application Function" "00" is used to define the HTTP method "GET," "Application Function" "01" is used to define the HTTP method "PUT," "02" is used to define the HTTP method "POST," and "03" is used to define the HTTP method "DELETE."

[0065] For example, "Sub Function" number 2 (20-2F) and "Sub Function" number 3 (20-2F) are used as inter-application communication areas, and "Application Function" is used to define the necessary processing, and "Sub Function" and "Application Function" are combined to define the necessary data.

[0066] For example, the first sub-function (10-1F) in the "Sub Function" is used as the SOVD conversion area for converting messages acquired from an external device. However, it may also be used as a RestAPI conversion area. That is, as shown in FIG. 16 , the OTA master 14 may apply the message conversion described above to dedicated languages ​​used in data communication with not only the OTA center 2 but also communication devices such as DCMs, CAN-BT (Controller Area Network-Bluetooth) and charging devices, meter devices, navigation devices, and IVI (In-Vehicle Infotainment) devices, and carry-on devices such as iOS devices, Android (registered trademark) devices, and IVI devices. When the OTA master 14 receives the dedicated language, it requests authentication as a routing conversion, and then performs language conversion, decryption, and interpretation based on data tampering determination. The OTA master 14 converts the message, assigns a CAN ID, and assigns a SID BA, and then transmits the command. When the OTA master 14 receives the command, it performs routing conversion by converting the message, assigning a CAN ID, and assigning a SID FA. The OTA master 14 then performs language conversion and interpretation by encryption, and sends an authentication response.

[0067] As described above, according to the embodiment, the following advantageous effects can be obtained. In the OTA master 14, commands for performing diagnostic services are assigned to the user data area of ​​CAN communication frames or Ethernet communication frames that use a 29-bit CAN ID, and the CAN communication frames or Ethernet communication frames to which the commands are assigned are transmitted and received between the repeaters 6 to 8 and the ECU 31 to perform diagnostic services. Diagnostic clients can transmit and receive commands appropriately, and diagnostic services can be performed appropriately.

[0068] In the repeaters 6 to 8, commands for performing diagnostic services are assigned to the user data areas of CAN communication frames or Ethernet communication frames that use a 29-bit CAN ID, and the diagnostic services are performed by transmitting and receiving the CAN communication frames or Ethernet communication frames to which the commands are assigned between the OTA master 14 and the ECUs 25 to 30. Diagnostic clients can properly transmit and receive commands, and the diagnostic services can be performed properly.

[0069] In the ECUs 25 to 30, commands for performing diagnostic services are assigned to the user data areas of CAN communication frames or Ethernet communication frames that use a 29-bit CAN ID, and the diagnostic services are performed by transmitting and receiving the CAN communication frames or Ethernet communication frames to which the commands are assigned between the OTA master 14 and the repeaters 6 to 8. Diagnostic clients can properly transmit and receive commands to each other, and the diagnostic services can be performed properly.

[0070] The present disclosure includes the following disclosures in addition to what is set forth in the claims: [1] A data communication device (6 to 8, 14, 25 to 31) that holds a diagnostic client for performing a diagnostic service, wherein the data communication device assigns a command for performing the diagnostic service to a user data area of ​​a CAN communication frame or an Ethernet communication frame that uses a 29-bit CAN ID, and transmits and receives the CAN communication frame or the Ethernet communication frame to which the command is assigned, to and from a communication partner device, thereby performing the diagnostic service.

[0071] [2] A data communication device as described in [1], in which at least one of a command related to the transfer of authority of the diagnostic client, a command related to confirming the existence of the diagnostic client, a command related to confirming the corresponding service of the diagnostic service, and a command related to a special operation instruction of the diagnostic client is assigned as the command.

[0072] [3] The data communication device according to [1] or [2], wherein if the diagnostic client corresponding to the diagnostic service does not exist, the diagnostic client is downloaded from an external device.

[0073] [4] The data communication device according to any one of [1] to [3], wherein the diagnostic client is arranged in a plurality of communication partner devices.

[0074] [5] The data communication device according to [4], wherein the same type of diagnostic client is arranged in the plurality of communication partner devices.

[0075] [6] The data communication device according to [4], wherein different types of diagnostic clients are arranged in the plurality of client devices.

[0076] [7] The data communication device according to any one of [1] to [6], wherein the diagnostic service includes updating software.

[0077] [8] The data communication device according to any one of [1] to [6], wherein the diagnostic service is to convert a message acquired from an external device.

[0078] [9] The data communication device according to any one of [1] to [8], wherein the data communication device is a master device (14) that places the diagnostic client in a relay device, and the relay device is the communication partner device.

[0079]

[10] The data communication device according to any one of [1] to [8], wherein the diagnostic client is arranged on a relay device (6 to 8) from a master device, and the master device is the communication partner device.

[0080]

[11] A data communication device according to any one of [1] to [8], which is an electronic control device (25 to 31) that is the target of the diagnostic service from a master device that places the diagnostic client in a relay device or the relay device in which the diagnostic client is placed from the master device, and which has the master device or the relay device as the communication partner device.

[0081] Although the present disclosure has been described with reference to the embodiments, it is understood that the present disclosure is not limited to the embodiments or structures. The present disclosure also encompasses various modifications and modifications within the scope of equivalents. In addition, various combinations and forms, as well as other combinations and forms including only one element, more than one element, or less than one element, are also within the scope and spirit of the present disclosure.

[0082] Although the OTA center 2 is used as an example of an external device and wireless reprogramming is described, the present invention can also be applied to wired reprogramming using an external tool 32 that is wired connected to the CGW 5. Furthermore, the external device is not limited to the OTA center 2 or the external tool 32, and may be, for example, a mobile information terminal such as a smartphone or a tablet terminal.

[0083] The control unit and the method described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to perform one or more functions embodied in a computer program. Alternatively, the control unit and the method described herein may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control unit and the method described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to perform one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible storage medium.

Claims

1. A data communication device (6-8, 14, 25-31) that holds a diagnostic client for performing diagnostic services, which assigns a command for performing the diagnostic services to a user data area of ​​a CAN communication frame or an Ethernet communication frame that uses a 29-bit CAN ID, and transmits and receives the CAN communication frame or the Ethernet communication frame to which the command is assigned between the data communication device and a communication partner device, thereby performing the diagnostic services.

2. A data communication device as described in claim 1, in which at least one of a command related to the transfer of authority of the diagnostic client, a command related to confirmation of the existence of the diagnostic client, a command related to confirmation of the corresponding service of the diagnostic service, and a command related to special operation instructions of the diagnostic client is assigned as the command.

3. The data communication device according to claim 1, wherein if the diagnostic client corresponding to the diagnostic service does not exist, the diagnostic client is downloaded from an external device.

4. A data communication device according to claim 1, wherein the diagnostic client is arranged in a plurality of communication partner devices.

5. A data communication device according to claim 4, wherein the same type of diagnostic client is arranged in the plurality of communication partner devices.

6. A data communication device according to claim 4, wherein different types of diagnostic clients are arranged in the plurality of client devices.

7. The data communication device according to claim 1, wherein the diagnostic service includes software updates.

8. The data communication device according to claim 1, wherein said diagnostic service includes converting a message acquired from an external device.

9. A data communication device according to claim 1, which is a master device (14) that places the diagnostic client in a relay device, and the relay device is the communication partner device.

10. A data communication device according to claim 1, which is a relay device (6-8) in which the diagnostic client is placed from a master device, and which uses the master device as the communication partner device.

11. A data communication device as described in claim 1, which is an electronic control device (25-31) that is the target of the diagnostic service from a master device that places the diagnostic client in a relay device or from the master device to the relay device in which the diagnostic client is placed, and which uses the master device or the relay device as the communication partner device.

12. A vehicle system (3) comprising a plurality of data communication devices (6-8, 14, 25-31) each holding a diagnostic client for performing diagnostic services, wherein each data communication device assigns a command for performing the diagnostic service to a user data area of ​​a CAN communication frame or an Ethernet communication frame using a 29-bit CAN ID, and transmits and receives the CAN communication frame or the Ethernet communication frame to which the command is assigned with a communication partner device, thereby performing the diagnostic service.

13. A data communication system (1) comprising a data communication device (6-8, 14, 25-31) that holds a diagnostic client for performing diagnostic services, and a communication partner device, wherein the data communication device assigns a command for performing the diagnostic service to a user data area of ​​a CAN communication frame or an Ethernet communication frame that uses a 29-bit CAN ID, and transmits and receives the CAN communication frame or the Ethernet communication frame to which the command is assigned, to and from the communication partner device, thereby performing the diagnostic service.

14. A data communication method in which a data communication device (6 to 8, 14, 25 to 31) that holds a diagnostic client for performing diagnostic services assigns a command for performing the diagnostic service to a user data area of ​​a CAN communication frame or an Ethernet communication frame that uses a 29-bit CAN ID, transmits and receives the CAN communication frame or the Ethernet communication frame to which the command is assigned, and performs a data communication procedure for performing the diagnostic service, in which the data communication device (6 to 8, 14, 25 to 31) holds a diagnostic client for performing diagnostic services, in which the command for performing the diagnostic service is transmitted and received to and from a communication partner device.

15. A data communication program that causes a data communication device (6-8, 14, 25-31) that has a diagnostic client for performing a diagnostic service to assign a command for performing the diagnostic service to the user data area of ​​a CAN communication frame or an Ethernet communication frame that uses a 29-bit CAN ID, transmit and receive the CAN communication frame or the Ethernet communication frame to which the command is assigned, to a communication partner device, and execute a data communication procedure for performing the diagnostic service.

Images