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

Abstract

The OTA master (14), the relay device (6 to 8), and the ECUs (25 to 31) hold a diagnosis client for performing a diagnosis service. The OTA master, the relay device, and the ECUs assign a command for performing a diagnosis service to a user data area of a CAN communication frame or an Ethernet communication frame using a 29-bit CAN ID, transceive the CAN communication frame or the Ethernet communication frame to which the command is assigned between the communication partner devices, and perform a diagnosis service.

Description

[0001] Cross-reference of related applications

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

[0003] This disclosure relates to data communication devices, vehicle systems, data communication systems, data communication methods, and data communication programs. Background Technology

[0004] Vehicles are equipped with numerous electronic control units (hereinafter referred to as ECUs). As a diagnostic service for ECUs, OTA (Over-The-Air) reprogramming technology is provided to wirelessly update the software installed in the ECU. A structure is disclosed in which, when there are multiple target ECUs that are the devices to be updated with software, the software is installed in parallel from the OTA master to multiple target ECUs (see, for example, Patent Document 1).

[0005] Existing technical documents

[0006] Patent documents

[0007] Patent document 1: Japanese Patent Application Publication No. 2018-92577.

[0008] When installing software from the OTA master controller to multiple target ECUs in parallel, data communication using the standard 11-bit CAN ID will fail if a conflict occurs between identical CAN IDs. Therefore, to prevent CAN ID conflicts, there are technical problems such as having to configure only one installer as a diagnostic client for each vehicle, or requiring intervention to stop transmissions within the installer, thus increasing the software installation time. Furthermore, since only one installer is configured for each specific ECU, there are also technical problems where the target ECUs are limited to those capable of data communication with all ECUs in the vehicle, or those with high-performance specifications. To address these technical problems, a structure is envisioned where the installer is configured from the OTA master controller to one or more domain control ECUs acting as client devices, allowing parallel software installation from the domain control ECU with the installer configured to the target ECUs.

[0009] However, in an architecture where the diagnostic client is configured from the OTA master controller to the domain control ECU, the following technical problems arise. Firstly, in diagnostic communication based on fault diagnosis, there is no mechanism for multiple diagnostic clients to freely send and receive commands; the diagnostic clients cannot freely send and receive commands to each other. Secondly, the diagnostic client configured on the domain control ECU is assumed to be temporarily activated, and there are insufficient commands for conditions such as determining whether an ECU is a communication partner. Furthermore, in CAN communication using an 11-bit CAN ID, only the target address is defined. Additionally, since a frame is 8 bytes or 64 bytes, a flow control mechanism as defined in diagnostic communication is needed for complex processing. Therefore, in an architecture where the diagnostic client is configured from the OTA master controller to the domain control ECU, a mechanism for the diagnostic clients to send and receive commands to each other is required to solve the aforementioned technical problems. Summary of the Invention

[0010] This disclosure aims to enable diagnostic clients to appropriately send and receive commands to each other and to perform diagnostic services appropriately.

[0011] One aspect of this disclosure is a data communication apparatus that maintains a diagnostic client for performing diagnostic services. Commands for performing the diagnostic services are assigned to the user data area of ​​a CAN communication frame or an Ethernet communication frame using a 29-bit CAN ID. The apparatus then transmits and receives the assigned CAN communication frame or Ethernet communication frame with a communication counterpart and performs the diagnostic services.

[0012] One aspect of the vehicle system disclosed herein includes multiple data communication devices that maintain a diagnostic client for performing diagnostic services. Each data communication device assigns commands for performing the diagnostic services to the user data area of ​​a CAN communication frame or an Ethernet communication frame using a 29-bit CAN ID, transmits and receives the assigned commands in the CAN communication frame or the Ethernet communication frame with a communication peer device, and performs the diagnostic services.

[0013] One aspect of the data communication system disclosed herein includes a data communication device and a communication counterpart device. The data communication device maintains a diagnostic client for performing diagnostic services. The data communication device assigns commands for performing the diagnostic services to the user data area of ​​CAN communication frames or Ethernet communication frames using 29-bit CAN IDs, transmits and receives the assigned commands in the CAN communication frames or Ethernet communication frames with the communication counterpart device, and performs the diagnostic services.

[0014] One aspect of the data processing method disclosed herein involves, within a data communication device maintaining a diagnostic client for performing diagnostic services, the following data communication steps: assigning a command for performing the diagnostic service to the user data area of ​​a CAN communication frame or an Ethernet communication frame using a 29-bit CAN ID; transmitting and receiving the CAN communication frame or the Ethernet communication frame to which the command was assigned between the device and the communication counterpart; and performing the diagnostic service.

[0015] One aspect of the data processing procedure disclosed herein causes a data communication device maintaining a diagnostic client for performing diagnostic services to perform the following data communication steps: assigning a command for performing the diagnostic service to the user data area of ​​a CAN communication frame or an Ethernet communication frame using a 29-bit CAN ID, sending and receiving the CAN communication frame or the Ethernet communication frame to which the command was assigned between the device and the communication counterpart, and performing the diagnostic service.

[0016] According to one embodiment of this disclosure, a diagnostic client is maintained for performing diagnostic services. Commands for performing diagnostic services are assigned to the user data area of ​​a CAN communication frame or Ethernet communication frame using a 29-bit CAN ID. The client then sends and receives CAN communication frames or Ethernet communication frames with assigned commands between itself and a communication peer device, and performs diagnostic services accordingly. This enables diagnostic clients to appropriately send and receive commands and perform diagnostic services appropriately.

[0017] According to one aspect of this disclosure, in a vehicle system equipped with multiple data communication devices, each data communication device maintains a diagnostic client for performing diagnostic services. Commands for performing diagnostic services are assigned to the user data area of ​​CAN communication frames or Ethernet communication frames using a 29-bit CAN ID. The device then sends and receives CAN communication frames or Ethernet communication frames with assigned commands to other communication devices and performs diagnostic services. This enables the diagnostic clients to appropriately send and receive commands to each other and perform diagnostic services accordingly.

[0018] According to one aspect of this disclosure, in a data communication system comprising a data communication device and a communication counterpart device, the data communication device maintains a diagnostic client for performing diagnostic services, assigns commands for performing diagnostic services to the user data area of ​​a CAN communication frame or Ethernet communication frame using a 29-bit CAN ID, and transmits and receives CAN communication frames or Ethernet communication frames with assigned commands between the data communication counterpart device and performs diagnostic services. This enables the diagnostic clients to appropriately send and receive commands to each other and appropriately perform diagnostic services. Attached Figure Description

[0019] The foregoing objects, as well as other objects, features, or advantages of this disclosure, will become more apparent from the following detailed description with reference to the accompanying drawings. These drawings are as follows:

[0020] Figure 1 This is a diagram showing the overall structure of one implementation method.

[0021] Figure 2 This is a functional block diagram of the reprogrammed main controller.

[0022] Figure 3 It is a diagram showing the distribution of specification data and installers.

[0023] Figure 4 It is a diagram representing a series of processing stages.

[0024] Figure 5 This diagram illustrates the transfer of permissions to the installer.

[0025] Figure 6 It is a diagram representing specification data.

[0026] Figure 7 It is a diagram representing specification data.

[0027] Figure 8 This is a diagram illustrating the sending and receiving of commands.

[0028] Figure 9 This is a diagram representing CAN communication frames and Ethernet communication frames.

[0029] Figure 10 This is a diagram representing the types of commands.

[0030] Figure 11 This is a diagram illustrating how the command is implemented.

[0031] Figure 12 This is a diagram representing the allocation of SIDs.

[0032] Figure 13 This is a diagram representing request and response commands.

[0033] Figure 14 This is a diagram illustrating an example of request and response commands.

[0034] Figure 15 This is a diagram representing HTTP methods.

[0035] Figure 16 This is a diagram illustrating route transitions. Detailed Implementation

[0036] Hereinafter, one embodiment will be described with reference to the accompanying drawings. In this embodiment, the diagnostic service includes a whole service utilizing diagnostic communication, such as software updates, remote diagnostics, and vehicle information collection. The diagnostic client is equivalent to the write control function unit (installer) used for installation during the software update installation phase, the control function unit used for remote diagnostics, and the control function unit used for vehicle information collection, etc.

[0037] like Figure 1 As shown, the data communication system 1 (equivalent to a data communication system) is configured to enable data communication between an OTA (Over-The-Air) center 2 (equivalent to an external device) and the vehicle system 3 installed in the vehicle. A considerable number of vehicle systems 3 can communicate with the OTA center 2. The vehicle is, for example, an electric vehicle such as a battery-powered vehicle (BEV). Unlike non-electric vehicles such as gasoline vehicles that use gasoline as a power source, electric vehicles can freely control the power supply of all ECUs installed in the vehicle through software.

[0038] Vehicle system 3 includes an onboard communication unit (hereinafter referred to as DCM (Data Communication Module)) 4, a central gateway (hereinafter referred to as CGW (Central Gateway)) 5, a first relay 6 (equivalent to a data communication device or relay device), a second relay 7 (equivalent to a data communication device or relay device), and a third relay 8 (equivalent to a data communication device or relay device). CGW5, first relay 6, second relay 7, and third relay 8 are referred to as domain controllers. First relay 6, second relay 7, and third relay 8 are connected to CGW5, for example, via a CAN bus or Ethernet (registered trademark). In the configuration connected via a CAN bus, CAN communication between CGW5 and relays 6-8 is data communication using a 29-bit CAN ID.

[0039] OTA Center 2 generates and stores update packages containing the software and specification data of the target devices. Additionally, OTA Center 2 stores update packages obtained from external sources such as OEMs (Original Equipment Manufacturers). OTA Center 2 includes: a configuration management unit that manages the hardware and software structure of the vehicle side that can be distributed with update packages; and a distribution management unit that manages the distribution of update packages to the vehicle side. The software includes programs, data, libraries, etc., used to activate the ECU.

[0040] The specification data includes information that identifies the ECU corresponding to the OTA, information that identifies the target ECU to be updated with software, information that identifies the object to be installed in the installation phase (described later), information that determines the installation order, information that identifies the object to be activated in the activation phase (described later), and information that determines the activation order. The ECU corresponding to the OTA is the ECU capable of implementing the OTA. Furthermore, the OTA center 2 may distribute the specification data to the vehicle side including it in the update package, or it may distribute the specification data to the vehicle side separately from the update package.

[0041] DCM4 communicates with OTA Center 2 via a communication network. This communication network may include, for example, mobile communication networks based on 4G or 5G lines, the Internet, or WiFi (Wireless Fidelity) (registered trademark). Alternatively, DCM4 and CGW5 may be integrated, with DCM4's functionality incorporated into CGW5's structure. Alternatively, the functions of DCM4 and CGW5 may be integrated into a display device or similar structure. Upon receiving an update packet from OTA Center 2, DCM4 forwards the received update packet to CGW5. The software distributed from OTA Center 2 to DCM4 is, for example, OTA reprogramming software. For inter-center communication between OTA Center 2 and DCM4, the SOVD format conforming to the SOVD communication specification or the RestAPI format conforming to the Rest (REpresentational State Transfer) API communication specification is used. Software updates based on update packets distributed from OTA Center 2 are called wireless reprogramming. On the other hand, software updates based on update packets distributed from external tools described later are called wired reprogramming.

[0042] The CGW5 features a reprogrammable main controller (9), an in-vehicle HMI (Human Machine Interface) (10), remote diagnostics (11), and an in-vehicle client (hereinafter referred to as OBC) (12). Figure 2 As shown, the reprogramming master controller 9 has a downloader 13 and an OTA master controller 14 (equivalent to a data communication device and a master controller).

[0043] When a download execution request is input from the OTA master controller 14, the downloader 13 instructs the DCM4 to execute the download process. The downloader 13 downloads the update package from the OTA center 2 via the DCM4 by receiving the update package distributed from the OTA center 2 and forwarding the received update package from the DCM4. The downloaded update package is temporarily stored in the reprogramming master controller 9 or an external memory, as described later.

[0044] The OTA master controller 14 includes an update control function unit 15, a status 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 an active target ECU list storage unit 21. These functions are implemented through software processing by the CPU executing computer programs stored in a non-transitory physical storage medium based on a microcomputer, or through hardware processing based on dedicated electronic circuits.

[0045] The update control function unit 15 has the function of controlling software updates. The status management function unit 16 has the function of managing the status of the software update object that accompanies the software update. The display control function unit 17 has the function of controlling the display in the vehicle HMI 10 that accompanies the software update. The write control function unit 18 has the function of controlling the installation of software to the software update object. Hereafter, the write control function unit 18 is sometimes referred to as the installer 18 (equivalent to a diagnostic client).

[0046] The OTA-compatible ECU list storage unit 20 stores information from the specification data that identifies the ECUs compatible with the OTA as an OTA-compatible ECU list. The target ECU list storage unit 21 stores information from the specification data that identifies the target ECU as a target ECU list. ECUs in the target ECU list that are compatible with the OTA are the target ECUs, while ECUs in the target ECU list that are compatible with the OTA but not stored in the target ECU list are ECUs not included in the target ECU list.

[0047] The power control function unit 19 refers to the OTA-compatible ECU list to determine the ECU corresponding to the OTA update. The power control function unit 19 also refers to the target ECU list to determine the target ECU. The power control function unit 19 collaborates with the power control application 22 configured in the second relay 7 to control the power supply to the ECU as the software update progresses. Furthermore, although this embodiment illustrates the case where the power control function unit 19 and the power control application 22 collaborate to control the power supply to the ECU, the configuration could also include a power control ECU that controls the power supply to the ECU. The objects to which the power supply is controlled by the power control function unit 19 include the DCM4, the vehicle HMI 10, the first relay 6, the second relay 7, and the third relay 8.

[0048] The OBC12 includes a mediation function unit 23 and a diagnostic communication function unit 24. The mediation function unit 23 focuses on the diagnostic communication between the reprogramming master controller 9 and the relay unit and ECU, and determines which diagnostic communication to prioritize. The diagnostic communication function unit 24 performs the diagnostic communication between the reprogramming master controller 9 and the relay unit and ECU based on the mediation result of the mediation function unit 23.

[0049] The OBC12 connects to multiple ECUs 25 and 26 (equivalent to data communication devices or electronic control devices) via a first relay 6. These ECUs 25 and 26 are connected to the first relay 6, for example, via a CAN bus. CAN communication between the first relay 6 and the multiple ECUs 25 and 26 uses a 29-bit CAN ID. The ECU among the multiple ECUs 25 and 26 connected to the first relay 6 that is the target of a software update can become the target ECU. Although the example illustrates two ECUs connected to the first relay 6, the number of ECUs connected to the first relay 6 is not limited to two.

[0050] Similarly, OBC12 is connected to multiple ECUs 27 and 28 (equivalent to data communication devices or electronic control devices) via a second relay 7. These multiple ECUs 27 and 28 are connected to the second relay 7, for example, via a CAN bus. CAN communication between the second relay 7 and the multiple ECUs 27 and 28 uses a 29-bit CAN ID. The ECU among the multiple ECUs 27 and 28 connected to the second relay 7 that is the target ECU for software updates can become the target ECU. Although the example illustrates two ECUs connected to the second relay 7, the number of ECUs connected to the second relay 7 is not limited to two.

[0051] Similarly, OBC12 is connected to multiple ECUs 29 and 30 (equivalent to data communication devices or electronic control devices) via a third relay 8. These multiple ECUs 29 and 30 are connected to the third relay 8, for example, via a CAN bus. CAN communication between the third relay 8 and the multiple ECUs 29 and 30 uses a 29-bit CAN ID. The ECU among the multiple ECUs 29 and 30 connected to the third relay 8 that is the target of a software update can become the target ECU. Although the example illustrates two ECUs connected to the third relay 8, the number of ECUs connected to the third relay 8 is not limited to two.

[0052] Additionally, the OBC12 is connected to the ECU31 (data communication device, electronic control device) without a relay connection. The ECU that is the target of a software update among the multiple ECUs connected to the OBC12 can become the target ECU. Although the case of a single ECU not connected to the OBC12 without a relay connection is illustrated, the number of ECUs not connected to the OBC12 without a relay connection is not limited to one.

[0053] As described above, the power control application 22 configured in the second relay 7 cooperates with the power control function unit 19 of the OTA master controller 14 to control the power supply to the DCM4, vehicle HMI10, relays 6-8, and ECUs 25-31 as software updates are performed. That is, the OTA master controller 14 enables the power control function unit 19 and the power control application 22 to cooperate in controlling the power supply to the relays 6-8 and ECUs 25-31, which are capable of diagnostic communication through the diagnostic communication function unit 24.

[0054] If a start request is input from the OTA master controller 14 when DCM4, vehicle HMI10, repeaters 6-8, and ECUs 25-31 are all in a stopped state, the system will transition to the start state and begin power supply from the vehicle battery. If a stop request is input from the OTA master controller 14 when DCM4, vehicle HMI10, repeaters 6-8, and ECUs 25-31 are all in a start state, the system will transition to the stop state and cease power supply from the vehicle battery.

[0055] External tool 32 distributes the update package to OTA master controller 14 while installed in the connector configured in the vehicle. External memory 33 functions as an external storage device for OTA master controller 14. As described above, it functions as a temporary storage target for update packages downloaded from OTA center 2, and also functions as a temporary fallback target for the software before the update when the software of relays 6-8 and ECUs 25-31 is updated.

[0056] The software update process involves a series of stages, including the synchronization stage, the download stage, the installation stage, the activation stage, and the update completion notification stage. The synchronization stage involves synchronizing the software and hardware configuration information of the ECU installed in the target vehicle with the OTA center 2.

[0057] The download phase occurs when the OTA controller 14 downloads the update package from the OTA center 2. Before proceeding with the download phase, the OTA controller 14 determines factors such as whether the software to be downloaded is legitimate, and compares the data size of the software with the remaining charge capacity of the vehicle battery to determine if the download can proceed. For example, if the OTA controller 14 determines that the software to be downloaded is legitimate and that the remaining charge capacity of the vehicle battery is sufficient relative to the data size of the software, then the download phase begins.

[0058] The installation phase, within the OTA controller 14, involves installing the software extracted from the update package onto the target ECU. Installation refers to writing the software into the target ECU's storage area. Before proceeding with the installation phase, the OTA controller 14 determines factors such as whether the software to be installed is legitimate, and compares the data volume of the software with the remaining charge capacity of the vehicle's battery to determine if the installation can proceed. For example, if the OTA controller 14 determines that the software to be installed is legitimate and that the remaining charge capacity of the vehicle's battery is sufficient relative to the data volume of the software, then the installation phase begins.

[0059] The activation phase is the phase in which the installed software is activated in the target ECU. Before proceeding with the activation phase, the OTA master controller 14 determines, for example, whether the software to be activated is legitimate, and compares the amount of data in the software with the remaining charge capacity of the vehicle battery to determine whether activation can be performed until the end. For example, if the OTA master controller 14 determines that the software to be activated is legitimate and that the remaining charge capacity of the vehicle battery is sufficient relative to the amount of data in the software to be activated, then the activation phase begins.

[0060] The update completion notification stage is in the OTA master controller 14. When the target ECU receives the update completion notification through activation, it sends the update completion notification to the OTA center 2.

[0061] like Figure 3 As shown, OTA Center 2 distributes specification data, including configuration target information, diagnostic service information, permission transfer information, and parallel execution information, along with the installer, to the vehicle side. OTA Center 2 performs the distribution steps through a data processing method, executing the distribution steps through a data processing program. The configuration target information is used by OTA Master 14 to determine the configuration target of the installer. Based on the configuration target information, OTA Master 14 determines the first relay 6, the second relay 7, and the third relay 8 as the configuration targets of the installer, and configures the installer on the first relay 6, the second relay 7, and the third relay 8 as described later.

[0062] The diagnostic service information is used by the OTA master controller 14 to install software onto the target ECU. Based on the diagnostic service information, the OTA master controller 14 determines the target ECU and the order in which the software will be installed onto that target ECU, including whether to use a storage method or a streaming method. As described later, when a transfer of authority from the OTA master controller 14 to the installer occurs, the installer, whose authority has been transferred from the OTA master controller 14, determines the target ECU based on the diagnostic service information, determines the order in which the software will be installed onto that target ECU, including whether to use a storage method or a streaming method, and then performs the installation onto the target ECU.

[0063] The OTA master controller 14 determines the target of the permission transfer to the installer and the order of permission transfer based on the permission transfer information. When installing software to target ECUs 25-28 serially, for example, first installing software to target ECUs 25 and 26 connected to the first relay 6 and then installing software to target ECUs 27 and 28 connected to the second relay 7, the OTA master controller 14 first performs the permission transfer to the installer configured on the first relay 6, and then performs the permission transfer to the installer configured on the second relay 7. When installing software to target ECUs 25-28 in parallel, for example, according to the parallel execution information described later, the OTA master controller 14 simultaneously performs the permission transfer to the installer configured on the first relay 6 and the permission transfer to the installer configured on the second relay 7.

[0064] Parallel execution information is information used by the installer to perform software installation to the target ECUs in parallel. That is, it is information used to perform software installation to target ECUs 25 and 26 by the installer configured in the first relay 6, software installation to target ECUs 27 and 28 by the installer configured in the second relay 7, and software installation to target ECUs 29 and 30 by the installer configured in the third relay 8.

[0065] The parallel execution information contains information that determines whether the installation of software to the target ECU should be performed in parallel, or in other words, simultaneously, by multiple installers. Based on the parallel execution information, the OTA master controller 14 instructs the installers to perform the installation after the transfer of authority. If the installation of software to the target ECU is to be performed in parallel by multiple installers, the OTA master controller 14 instructs the installation of software to the target ECU to be performed simultaneously by multiple installers. Therefore, the OTA master controller 14 may, for example, instruct multiple installers to perform the installation in parallel, or instruct the installation to perform the installation at the same timing.

[0066] The parallel execution information may also include information that determines whether the software installation to the target ECU should be performed serially, or in other words, sequentially, by multiple installers, and information that determines the order in which the installations are performed sequentially. When the OTA master controller 14 causes the software installation to the target ECU to be performed serially by multiple installers, it causes the software installation to be performed sequentially by the multiple installers. Therefore, the OTA master controller 14, for example, instructs one installer to perform the installation, waits for a completion notification from that installer, and after receiving the completion notification, instructs the next installer to perform the installation. Furthermore, when instructing multiple installers to perform the installation in parallel, this waiting for a completion notification is not necessary.

[0067] The parallel execution information may also include information for the installer after the transfer of authority to install software to multiple target ECUs in parallel. Based on the parallel execution information, the installer installs software to multiple target ECUs in parallel or sequentially. When installing software to multiple target ECUs in parallel, the installer installs the software to multiple ECUs simultaneously. When installing software to multiple target ECUs sequentially, the installer installs the software to one target ECU at a time, and after completing the installation of the software to one target ECU, it proceeds to install the software to the next ECU.

[0068] Based on the configuration target information received from the OTA center 2, the OTA master controller 14 configures the installer on relays 6 and 8. As an example of how the OTA master controller 14 configures the installer on the configuration target, it can be listed that the OTA master controller 14 installs the installer, such as the executable file of the installer received from the OTA center 2, into the file system of the configuration target. The OTA master controller 14 can also remove the configured installer from the configuration target. As an example of how the OTA master controller 14 removes the installer, it can be listed that the OTA master controller 14 uninstalls the installer, such as the executable file of the installer, which was appended to the file system of the configuration target. Furthermore, as another method for configuring or removing the installer, it can be listed that the installer is installed or uninstalled by writing or deleting the binary data containing the installer into the address area of ​​the non-volatile memory of the configuration target.

[0069] The OTA master controller 14 transfers authority to the installers configured in relay units 6-8 based on the authority transfer information received from the OTA center 2, and instructs the installers to execute the software installation to the target ECU. The OTA master controller 14 executes the software installation to the target ECU in parallel according to the parallel execution information received from the OTA center 2.

[0070] like Figure 4 As shown, the OTA controller 14, as part of a series of processes involved in software updates, performs the following stages: synchronization (S1), download (S2), installation (S3), activation (S4), and update completion notification (S5). Figure 5 As shown, during the installation phase, the OTA master controller 14 configures the installer 18, OBC 12, and specification data to the relay units 6-8, and transfers the authority to the configured installer 18, instructing the installer 18 to execute the software installation to the target ECU.

[0071] Specifically, when the installer 18 is configured from the OTA master controller 14, and the authority to be transferred to the installer 18 is transferred and the installation is instructed to be executed, the first relay 6 installs the software to the target ECUs 25 and 26. Similarly, when the installer 18 is configured from the OTA master controller 14, and the authority to be transferred to the installer 18 is transferred and the installation is instructed to be executed, the second relay 7 installs the software to the target ECUs 27 and 28. When the installer 18 is configured from the OTA master controller 14, and the authority to be transferred to the installer 18 is transferred and the installation is instructed to be executed, the third relay 8 installs the software to the target ECUs 29 and 30.

[0072] The specification data is explained. When the OTA master controller 14 configures the specification data for repeaters 6-8, there are two scenarios: one where the OTA master controller 14 and repeaters 6-8 are configured with common specification data, and another where each repeater 6-8 is configured with its own specific specification data. In the case where the OTA master controller 14 and repeaters 6-8 are configured with common specification data, such as... Figure 6 As shown, the configuration stores the specification data of each target ECU, including the OTA master controller 14 and relays 6-8. The reference data for relays 6-8 is included in "Sync Group Info A". Relays 6-8 install software to target ECUs 25-30 by referring to the data defined for their own reference objects.

[0073] With the OTA main controller 14 and repeaters 6-8 configured with their inherent specifications, such as Figure 7As shown, the configuration stores specification data containing information about each target ECU of each of the relay units 6-8. The reference data for the first relay unit 6 is contained in "Sync Group Info B", the reference data for the second relay unit 7 is contained in "Sync Group Info C", and the reference data for the third relay unit 8 is contained in "Sync Group Info D". Relay units 6-8, respectively, refer to the data defined for their reference units to install software onto the target ECUs 25-30.

[0074] Provide instructions on sending and receiving commands. For example... Figure 8 As shown, commands related to the transfer of authority between the OTA master controller 14 and repeaters 6-8 are transmitted and received, for example, with the diagnostic client. The relationship between the OTA master controller 14 and repeaters 6-8 is that of a data communication device and a communication counterpart. The OTA master controller 14 and repeaters 6-8 perform data communication steps through a data communication method, and execute data communication steps through a data communication program. When the OTA master controller 14 and repeaters 6-8 are connected via a CAN bus, commands are distributed to... Figure 9 The user data area (0-64) of the CAN communication frame using a 29-bit CAN ID is shown. When the OTA master controller 14 and repeaters 6-8 are connected via Ethernet, commands are distributed to... Figure 9 The Ethernet communication frame shown contains a User Data Area (Max 64kByte) UDS Message. When assigning commands to the User Data Area, commands conforming to the UDS (Unified Diagnostic Services) protocol are assigned. This is in addition to the information described later. Figure 13 and Figure 14 In addition to the UDS Service Identifier, Sub Function, and Parameter shown, commands in the form of Application Functions are also assigned.

[0075] Between the OTA master controller 14, relays 6-8, and ECUs 25-31, commands related to confirming the presence of the diagnostic client, confirming the corresponding service of the diagnostic service, and other special action instructions are sent and received. Furthermore, commands related to special action instructions are commands related to services not specified in the UDS standard, and commands related to the transfer of authority to the diagnostic client are also included in the commands related to special action instructions. The relationship between the OTA master controller 14, relays 6-8, and ECUs 25-31 becomes that of a data communication device and a communication counterpart. The OTA master controller 14, relays 6-8, and ECUs 25-31 perform data communication steps through a data communication method and execute data communication steps through a data communication program. In this case, commands are distributed to... Figure 9 The user data area (0-64) of a CAN communication frame using a 29-bit CAN ID is shown.

[0076] exist Figure 8 The example illustrates an OTA master controller 14 configuring the installer and vehicle information collection on the first relay 6 as a diagnostic client, and configuring the installer and remote diagnostics on the second relay 7 as a diagnostic client, with respective permission transfers. When the installer and vehicle information collection, configured from the OTA master controller 14, are configured as diagnostic clients and permission is transferred to the installer and the installation is instructed to proceed, the first relay 6 installs software to target ECUs 25 and 26. When permission is transferred to the vehicle information collection and the vehicle information collection is instructed to proceed, the first relay 6 collects vehicle information from target ECUs 25 and 26. When the installer and remote diagnostics, configured from the OTA master controller 14, are configured as diagnostic clients and permission is transferred to the installer and the installation is instructed to proceed, the second relay 7 installs software to target ECUs 27 and 28. When permission is transferred to the remote diagnostics and the remote diagnostics is instructed to proceed, the second relay 7 performs remote diagnostics on target ECUs 25 and 26. Similarly, the OTA master controller 14 configures the diagnostic client on the third relay unit 8. After the diagnostic client is configured from the OTA master controller 14, and the authority to the diagnostic client is transferred and the execution of the diagnostic client is instructed, the third relay unit 8 performs diagnostic services to the target ECUs 29 and 30.

[0077] As a type of command assigned to user data areas, such as Figure 10 As shown, there are commands with regular behavior characteristics, commands with request-acceptance behavior (event) characteristics, commands with triggering (timer) characteristics, and commands with special behavior characteristics.

[0078] Commands exhibiting regular behavior characteristics include commands related to the synchronization of states between applications, and commands related to periodic communication of scene information, time information, etc. Commands exhibiting request-receiving behavior characteristics include commands related to permission transfer, commands related to confirming the existence (existence / non-existence) of diagnostic clients, and commands related to confirming the corresponding service (correspondence / non-correspondence) of diagnostic services. Commands exhibiting request-receiving behavior characteristics are classified as "reliable" commands sent after confirming a response from the communicating party's device, while commands classified as "unreliable" commands are sent without confirming a response from the communicating party's device.

[0079] Commands with triggering characteristics include those related to a certain time elapsed, those related to a condition being met, etc. Among these triggering commands, those classified as "reliable" are sent after confirming a response from the communicating party's device, while those classified as "unreliable" are sent without confirming a response from the communicating party's device. Commands with special behavioral characteristics include those related to a condition being met, etc.

[0080] like Figure 11 As shown, commands are implemented in two ways: internally affecting commands and externally affecting commands. Internally affecting commands do not impact other devices and are expressed as "○○ control will...(verb)." Externally affecting commands impact other devices and are expressed as "○○ mechanism performs (verb)" or "to ○○ mechanism (verb)." Commands with regular behavior characteristics, commands with request-receiving behavior characteristics, and commands with triggering characteristics are implemented as internally affecting commands and externally affecting commands, respectively. Commands with special behavior characteristics are implemented as externally affecting commands.

[0081] OTA controller 14 Figure 12 The UDS (Unified Diagnostic Services) protocol, as shown, allocates the SID (Service Identifier) ​​in the regions open to system vendors, namely "0xBA-0xBE" and "0xFA-0xFE," to assign the aforementioned commands. For example... Figure 13As shown, the OTA controller 14, for example, uses "0xBA" as a request command and "0xFA" as a response command, defines 128 modes using "Sub Function" and 256 modes using "Application Function," thereby enabling the definition of 32,768 modes. By using areas open to system vendors, resources prepared in the ISO standard can be utilized, and content can be freely changed for each OEM, for example.

[0082] As a specific example, such as Figure 14 As shown, for example, the 0th segment (00-0F) of "Sub Function" is used as the OTA service area, "Application Function" is used to define the necessary processing, and "Sub Function" and "Application Function" are combined to define the necessary data. For example, "00" of "Application Function" is used to define the data associated with synchronization, "01" is used to define the data associated with download, "02" is used to define the data associated with installation, "03" is used to define the data associated with activation, "04" is used to define the data associated with permission transfer, and "05" is used to define the data associated with special operation instructions.

[0083] For example, use segment 1 (10-1F) of "Sub Function" as the SOVD transformation area, use "Application Function" to define the necessary processing, and combine "Sub Function" and "Application Function" to define the necessary data. Figure 15 As shown, for example, use "00" of "Application Function" to define the HTTP method "GET", use "01" of "Application Function" to define the HTTP method "PUT", use "02" to define the HTTP method "POST", and use "03" to define the HTTP method "DELETE".

[0084] For example, use segment 2 (20-2F) and segment 3 (20-2F) of "Sub Function" as inter-application communication areas, use "Application Function" to define the necessary processing, and combine "Sub Function" and "Application Function" to define the necessary data.

[0085] As an example of transforming messages obtained from external sources, the example uses segment 1 (10-1F) of "Sub Function" as the SOVD transformation region, but it can also be used as a RestAPI transformation region. That is, as... Figure 16 As shown, the OTA master controller 14 is not limited to the OTA center 2. The message conversion described above can also be applied to the dedicated language used in data communication with communication devices such as DCMs, CAN-BT (Controller Area Network-Bluetooth) and charging devices, instrument devices, navigation devices, and IVI (In-Vehicle Infotainment) devices, as well as display devices, iOS devices, Android devices, and IVI devices. When a dedicated language is received, the OTA master controller 14, as a route converter, performs an authentication request and interprets the message based on language conversion, decryption, and data tampering detection. The OTA master controller 14 performs message conversion, CAN ID allocation, and SID BA-based allocation conversion, and sends commands. When a command is received, the OTA master controller 14, as a route converter, performs message conversion, CAN ID allocation, and SID FA-based allocation conversion. The OTA master controller 14 performs language conversion, interprets the encrypted message, and provides an authentication response.

[0086] As explained above, the following effects can be achieved according to the implementation method.

[0087] In the OTA master controller 14, commands for diagnostic services are assigned to the user data area of ​​CAN communication frames and Ethernet communication frames using 29-bit CAN IDs. The master controller then transmits and receives these assigned CAN and Ethernet communication frames with repeaters 6-8 and ECU 31, and performs diagnostic services. Diagnostic clients can appropriately send and receive commands and perform diagnostic services accordingly.

[0088] In repeaters 6-8, commands for diagnostic services are assigned to the user data areas of CAN and Ethernet communication frames using 29-bit CAN IDs. These assigned CAN and Ethernet communication frames are then sent and received between the repeater and OTA master controller 14 and ECUs 25-30, and diagnostic services are performed accordingly. Diagnostic clients can appropriately send and receive commands and perform diagnostic services as needed.

[0089] In ECUs 25-30, commands for diagnostic services are assigned to the user data areas of CAN and Ethernet communication frames using 29-bit CAN IDs. These command-assigned CAN and Ethernet communication frames are sent and received between the OTA master controller 14 and repeaters 6-8, and diagnostic services are performed accordingly. Diagnostic clients can appropriately send and receive commands and perform diagnostic services as needed.

[0090] In addition to the description of the scope of the patent claims, this disclosure includes the following disclosures. [1]

[0092] A data communication device (6-8, 14, 25-31) maintains a diagnostic client for performing diagnostic services.

[0093] The command for performing the diagnostic service is assigned to the user data area of ​​a CAN communication frame or an Ethernet communication frame using a 29-bit CAN ID. The CAN communication frame or the Ethernet communication frame to which the command is assigned is sent and received between the communication counterpart and the communication counterpart device, and the diagnostic service is performed. [2]

[0095] According to the data communication device described in [1], as the command, at least one of the following is assigned: a command related to the transfer of permissions of the diagnostic client, a command related to the confirmation of the existence of the diagnostic client, a command related to the confirmation of the corresponding service of the diagnostic service, and a command related to the special action instruction of the diagnostic client. [3]

[0097] According to the data communication device described in [1] or [2], in the absence of a diagnostic client corresponding to the diagnostic service, the diagnostic client is downloaded from an external device. [4]

[0099] The diagnostic client is configured on multiple communication counterpart devices according to any one of [1] to [3] data communication devices. [5]

[0101] According to the data communication device described in [4], the same type of diagnostic client is configured on the plurality of communication counterpart devices. [6]

[0103] According to the data communication device described in [4], different types of diagnostic clients are configured on the plurality of client devices. [7]

[0105] The software is updated as a diagnostic service using a data communication device described in any one of [1] to [6]. [8]

[0107] According to any one of [1] to [6], the data communication device performs the conversion of messages obtained from the outside as the diagnostic service. [9]

[0109] The data communication device described in any of [1] to [8] is a master control device (14) that configures the diagnostic client in the relay device.

[0110] The relay device is used as the communication counterpart device.

[10]

[0112] According to any one of [1] to [8], the data communication device is a relay device (6 to 8) that has configured the diagnostic client from the main control device.

[0113] The main control device is used as the communication counterpart device.

[11]

[0115] The data communication device described in any one of [1] to [8] is an electronic control device (25-31) that is the object of the diagnostic service from a master control device or a relay device, wherein the master control device configures the diagnostic client to the relay device, and the relay device configures the diagnostic client from the master control device.

[0116] The main control device or the relay device is used as the communication counterpart device.

[0117] This disclosure is described with reference to embodiments, but it should be understood that this disclosure is not limited to those embodiments or constructions. This disclosure includes various modifications and equivalent variations. Furthermore, various combinations and methods, including only one of these elements, or other combinations and methods including more than one element or the following, are all within the scope and spirit of this disclosure.

[0118] The example of OTA Center 2 as an external device illustrates the case of wireless reprogramming, but it can also be applied to the case of wired reprogramming based on external tool 32 connected to CGW5 via a wired connection. Furthermore, the external device is not limited to OTA Center 2 or external tool 32; it can also be a portable information terminal such as a smartphone or tablet.

[0119] The control unit and method described in this disclosure can also be implemented by a dedicated computer, which is provided by comprising a processor and memory programmed to perform one or more functions embodied in a computer program. Alternatively, the control unit and method described in this disclosure can also be implemented by a dedicated computer provided by comprising a processor composed of one or more dedicated hardware logic circuits. Alternatively, the control unit and method described in this disclosure can also be implemented by one or more dedicated computers, which are composed of a combination of a processor and memory programmed to perform one or more functions and a processor composed of one or more hardware logic circuits. Furthermore, the computer program can also be stored as instructions to be executed by the computer in a computer-readable non-volatile storage medium.

Claims

1. A data communication device (6-8, 14, 25-31) for maintaining a diagnostic client for performing diagnostic services, characterized in that, The command for performing the diagnostic service is assigned to the user data area of ​​a CAN communication frame or an Ethernet communication frame using a 29-bit CAN ID. The CAN communication frame or the Ethernet communication frame to which the command is assigned is sent and received between the communication counterpart and the communication counterpart device, and the diagnostic service is performed.

2. The data communication device according to claim 1, characterized in that, The command may be any one of the following: a command related to the transfer of permissions for the diagnostic client; a command related to the confirmation of the existence of the diagnostic client; a command related to the confirmation of the corresponding service of the diagnostic service; and a command related to the special action instruction of the diagnostic client.

3. The data communication device according to claim 1, characterized in that, If no diagnostic client corresponding to the diagnostic service exists, the diagnostic client is downloaded from an external device.

4. The data communication device according to claim 1, characterized in that, The diagnostic client is configured on multiple communication counterpart devices.

5. The data communication device according to claim 4, characterized in that, Configure the same diagnostic client on the multiple communication counterpart devices.

6. The data communication device according to claim 4, characterized in that, Different types of diagnostic clients are configured on the plurality of client devices.

7. The data communication device according to claim 1, characterized in that, As part of the diagnostic service, software updates are performed.

8. The data communication device according to claim 1, characterized in that, As part of the diagnostic service, the messages obtained from external sources are converted.

9. The data communication device according to claim 1, characterized in that, The data communication device is the main control device (14) that configures the diagnostic client in the relay device. The relay device is used as the communication counterpart device.

10. The data communication device according to claim 1, characterized in that, The data communication device is a relay device (6-8) configured from the main control device with the diagnostic client. The main control device is used as the communication counterpart device.

11. The data communication device according to claim 1, characterized in that, The data communication device is an electronic control device (25-31) that receives the diagnostic service from a master control device or a relay device, wherein the master control device configures the diagnostic client to the relay device, and the relay device configures the diagnostic client from the master control device. The main control device or the relay device is used as the communication counterpart device.

12. A vehicle system (3) comprising multiple data communication devices (6-8, 14, 25-31), wherein the data communication devices maintain a diagnostic client for performing diagnostic services, characterized in that, Each data communication device assigns commands for performing the diagnostic service to the user data area of ​​a CAN communication frame or an Ethernet communication frame using a 29-bit CAN ID, and sends and receives the assigned CAN communication frame or Ethernet communication frame with the communication counterpart device, and performs the diagnostic service.

13. A data communication system (1) comprising data communication devices (6-8, 14, 25-31) and a communication counterparty device, wherein the data communication devices maintain a diagnostic client for performing diagnostic services, characterized in that, The data communication device assigns commands for performing the diagnostic service to the user data area of ​​a CAN communication frame or an Ethernet communication frame using a 29-bit CAN ID, and sends and receives the CAN communication frame or the Ethernet communication frame to which the command is assigned between the communication counterpart and the device, and performs the diagnostic service.

14. A data communication method, characterized in that, In the data communication device (6-8, 14, 25-31) used for diagnostic services, the following data communication steps are performed: The command for performing the diagnostic service is assigned to the user data area of ​​a CAN communication frame or an Ethernet communication frame using a 29-bit CAN ID. The CAN communication frame or the Ethernet communication frame to which the command is assigned is sent and received between the communication counterpart and the communication counterpart device, and the diagnostic service is performed.

15. A data communication program, characterized in that, The data communication devices (6-8, 14, 25-31) used for diagnostic services by the diagnostic client shall perform the following data communication steps: The command for performing the diagnostic service is assigned to the user data area of ​​a CAN communication frame or an Ethernet communication frame using a 29-bit CAN ID. The CAN communication frame or the Ethernet communication frame to which the command is assigned is sent and received between the communication counterpart and the communication counterpart device, and the diagnostic service is performed.

Images