Vehicle-mounted devices

Abstract

The present invention provides an in-vehicle device capable of executing multiple diagnostic communications in parallel without causing communication errors. [Solution] An in-vehicle device for controlling diagnostic communication, comprising: a determination unit that determines whether or not there is a second processing unit that is already communicating with the ECU when there is an access request for diagnostic communication from a first processing unit to the ECU; and an execution unit that, if the determination unit determines that there is no second processing unit, causes the first processing unit to access the ECU.

Description

Technical Field

[0001] The present disclosure relates to an in-vehicle device that enables parallel execution of diagnostic communications.

Background Art

[0002] Patent Document 1 discloses a system that performs single (serial communication) diagnostic communication between a main ECU and a plurality of sub-ECUs.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] When considering implementing so-called parallel communication, in which a plurality of diagnostic communications are simultaneously performed on the same path (bus), there is a risk of problems such as other diagnostic communications already being executed by the destination ECU becoming errors, or the diagnostic communication that is newly desired to be started becoming an error. Therefore, there is room for further consideration in order to execute a plurality of diagnostic communications in parallel.

[0005] The present disclosure has been made in view of the above problems, and an object thereof is to provide an in-vehicle device capable of executing a plurality of diagnostic communications in parallel without causing communication errors.

Means for Solving the Problems

[0006] To solve the above problems, one aspect of the disclosed technology is an in-vehicle device for controlling diagnostic communication, comprising: a determination unit that determines whether or not there is a second processing unit that is already communicating with the ECU when there is an access request for diagnostic communication from a first processing unit to the ECU; and an execution unit that, if the determination unit determines that there is no second processing unit, causes the first processing unit to access the ECU. [Effects of the Invention]

[0007] According to the in-vehicle device of the present disclosure, if the ECU of the communication partner is not performing other diagnostic communication (by the second processing unit), a new diagnostic communication (by the first processing unit) is initiated. This makes it possible to execute multiple diagnostic communications requested by multiple different ECUs in parallel without causing communication errors. [Brief explanation of the drawing]

[0008] [Figure 1] Schematic diagram for realizing an in-vehicle device according to one embodiment of the present disclosure. [Figure 2] Flowchart of the diagnostic communication control process performed by the in-vehicle device. [Modes for carrying out the invention]

[0009] The in-vehicle device described in this disclosure allows an application or task to initiate diagnostic communication with a specific ECU, provided that no other application or task is already performing diagnostic communication with that ECU. This prevents other diagnostic communications already being performed by the specific ECU from failing, and also prevents the newly initiated diagnostic communication from failing, while enabling the execution of multiple diagnostic communications in parallel. Hereinafter, one embodiment of this disclosure will be described in detail with reference to the drawings.

[0010] <Embodiment> [composition] Figure 1 is a schematic configuration diagram for realizing an in-vehicle device according to one embodiment of the present disclosure. In Figure 1, ECU-S100 and ECU-T200 are configured to output access requests for diagnostic communication, and ECU-V310, ECU-W320, ECU-X410, ECU-Y420, and ECU-Z430 are configured to perform diagnostic communication with ECU-S100 and / or ECU-T200 in response to access requests.

[0011] ECU-S100 implements applications A (App A) 110 and B (App B) 120. This ECU-S100 is equipped with arbitration function 150. ECU-T200 implements application C (App C) 210. In addition, application B 120 has tasks E121 and F122 as tasks to be processed.

[0012] The arbitration function 150 is configured to receive access requests for diagnostic communication from application A110, task E121, task F122, and / or application C210, and to perform the necessary functions (execution, determination, etc.) for arbitrating and managing conflicting communications. Priorities pre-assigned to each diagnostic communication are used for communication arbitration. This arbitration function 150 can accept all-exclusive access requests from application A110, task E121, task F122, and application C210. ​​In the case of all-exclusive access requests, all pre-processing can be interrupted after the completion of high-priority pre-processing (even if the addresses are different). The arbitration function 150 can also accept interrupt disable settings from application A110, task E121, task F122, and application C210. ​​In the case of interrupt disable settings, even if a high-priority request occurs after the start of post-processing, that high-priority request can be made to wait. Note that both all-exclusive access requests and interrupt disable settings can be specified.

[0013] ECU-V310 and ECU-W320, which can be communication partners for diagnostic communication, are connected to the arbitration function 150 via the same route J, enabling communication. Similarly, ECU-X410, ECU-Y420, and ECU-Z430, which can also be communication partners for diagnostic communication, are connected to the arbitration function 150 via the same route K, enabling communication. Examples of routes J and K include CAN and Ethernet (registered trademark).

[0014] [control] Next, with further reference to Figure 2, control performed by an in-vehicle device according to one embodiment of the present disclosure will be described. Figure 2 is a flowchart showing the processing procedure of diagnostic communication control performed by the in-vehicle device.

[0015] The diagnostic communication control illustrated in Figure 2 is initiated when a new access request for diagnostic communication is received from any application or task (hereinafter referred to as the "first processing unit") to any ECU (hereinafter referred to as the "communication target ECU"). This access request specifies the priority of the requested diagnostic communication.

[0016] (Step S201) The first processing unit determines whether there is only one (single) ECU to which it is requesting new diagnostic communication. If there is only one ECU to communicate with, it corresponds to unicast communication; if there is more than one ECU to communicate with, it corresponds to broadcast communication (or multicast communication).

[0017] If there is only one ECU to communicate with (step S201, yes), the process proceeds to step S202. On the other hand, if there is more than one ECU to communicate with (step S201, no), the process proceeds to step S205.

[0018] (Step S202) It is determined whether the communication target ECU for unicast communication is executing a diagnostic communication different from the diagnostic communication newly required this time (hereinafter referred to as "new diagnostic communication") (hereinafter referred to as "other diagnostic communication"). In other words, it is determined whether there is another application or task (hereinafter referred to as "second processing unit") that is executing other diagnostic communication with the communication target ECU. Whether this communication target ECU is executing other diagnostic communication, that is, whether there is a second processing unit, can be determined, for example, by whether there is a diagnostic communication with the same address as the address of the communication target ECU required this time among the diagnostic communications already executed by other applications or tasks.

[0019] If the communication target ECU is not executing other diagnostic communication, that is, if there is no second processing unit (step S202, no), the process proceeds to step S203. On the other hand, if the communication target ECU is executing other diagnostic communication, that is, if there is a second processing unit (step S202, yes), the process proceeds to step S204.

[0020] (Step S203) In accordance with the current access request, new diagnostic communication is performed between the first processing unit and the communication target ECU. When the new diagnostic communication is performed, this diagnostic communication control ends.

[0021] (Step S204) When there is a second processing unit that is executing other diagnostic communication with the communication target ECU, the priority of the new diagnostic communication to be executed between the first processing unit and the communication target ECU newly required this time is compared with the priority of the other diagnostic communication being executed between the second processing unit already in execution and the communication target ECU.

[0022] If the communication priority is higher for other diagnostic communication than for the new diagnostic communication (step S204, yes), the process proceeds to step S206. On the other hand, if the communication priority is not higher for other diagnostic communication than for the new diagnostic communication (step S204, no), the process proceeds to step S207.

[0023] (Step S205) For ECUs that will be using broadcast (or multicast) communication, it is determined whether or not another diagnostic communication with a higher priority than the new diagnostic communication that the newly requested first processing unit and the ECU are currently performing. In other words, it is determined whether or not there is a second processing unit that is performing another diagnostic communication with the ECU that has a higher priority than the new diagnostic communication. This determination is made for each ECU and for each path (in units of path J or path K).

[0024] If the ECU being communicated is currently performing another diagnostic communication with the second processing unit that has a higher priority than the new diagnostic communication (step S205, yes), the process proceeds to step S206. On the other hand, if the ECU being communicated is not performing another diagnostic communication that has a higher priority than the new diagnostic communication, or if the ECU is performing another diagnostic communication but it does not have a higher priority than the new diagnostic communication (step S205, no), the process proceeds to step S207.

[0025] (Step S206) Other diagnostic communications currently running between the second processing unit and the target ECU are allowed to continue. After these other diagnostic communications are completed, the new diagnostic communication requested by the first processing unit and the target ECU is executed. In other words, the new diagnostic communication is delayed until the other diagnostic communications are completed. After this arbitration process is performed, the diagnostic communication control based on the access request is terminated.

[0026] (Step S207) The second processing unit temporarily suspends any other diagnostic communications currently running between it and the target ECU, and then initiates a new diagnostic communication between the first processing unit and the target ECU as requested. After this new diagnostic communication is completed, the other diagnostic communications that were suspended are resumed. This arbitration process concludes the diagnostic communication control based on the current access request.

[0027] <Effects and Actions> As described above, according to the in-vehicle device according to one embodiment of the present disclosure, when an access request for diagnostic communication to the ECU is made from a certain application or task (first processing unit), it is determined whether there is another application or task (second processing unit) that is already communicating with the ECU for diagnostic purposes, and if there is no other application or task (second processing unit), the application or task (first processing unit) that made the access request is made to access the ECU.

[0028] This control prevents other diagnostic communications already being performed by the ECU receiving the diagnostic communication from failing, or prevents new diagnostic communications that the ECU wants to start from failing.

[0029] Furthermore, in the in-vehicle device according to one embodiment of this disclosure, when multiple applications or tasks simultaneously perform diagnostic communication with each ECU in the vehicle, the communication content can be arbitrated while considering the priority and characteristics of each diagnostic communication, so that diagnostic communication can be operated in parallel with multiple ECUs on the same path (bus).

[0030] Furthermore, in the in-vehicle device according to one embodiment of this disclosure, even when high-priority applications or tasks are running, there is an increased opportunity for lower-priority applications and tasks to also run. Therefore, for example, in situations where multiple services are competing, it is possible to avoid phenomena such as high-priority diagnostic communication (such as communication for OTA reprogramming) occupying the route (bus), preventing lower-priority diagnostic communication from running for a long time.

[0031] Furthermore, diagnostic communication is performed in three steps: the first step in which the client ECU requests a diagnostic from the server ECU; the second step in which the server ECU performs processing internally; and the third step in which the server ECU responds to the client ECU. In conventional processing, the processing time of the second step was entirely idle time for communication. However, in this disclosure, the processing time of the second step can be effectively used by having another application or task perform the first or third step. In addition, since the processing of the third step may be slow for some ECUs, this time can be processed in parallel with other ECUs, improving processing efficiency.

[0032] Although one embodiment of the disclosed technology has been described above, the disclosure can be understood not only as an in-vehicle device, but also as a method executed by an in-vehicle device equipped with a processor and memory, a program for executing that method, a computer-readable non-temporary storage medium storing that program, and a vehicle equipped with the in-vehicle device. [Industrial applicability]

[0033] The in-vehicle device described herein can be used in situations where it is desired to perform multiple diagnostic communications in parallel between an application or task and an ECU. [Explanation of Symbols]

[0034] 100, 200, 310, 320, 410, 420, 430 ECU 110, 120, 210 applications Tasks 121 and 122 150 Mediation function Routes 300 and 400

Claims

1. An in-vehicle device that controls diagnostic communication, When a request for access for diagnostic communication is made from the first processing unit to the ECU, a determination unit determines whether or not there is a second processing unit that is already communicating with the ECU for diagnostic purposes. If the determination unit determines that the second processing unit does not exist, the execution unit includes an execution unit that causes the first processing unit to access the ECU. In-vehicle device.

2. If the determination unit determines that the second processing unit exists, the execution unit will... If the priority of the diagnostic communication of the second processing unit is higher than that of the diagnostic communication of the first processing unit, the diagnostic communication of the first processing unit is performed after the diagnostic communication of the second processing unit is completed. If the communication priority of the diagnostic communication of the second processing unit is not higher than that of the diagnostic communication of the first processing unit, the diagnostic communication of the second processing unit is interrupted, the diagnostic communication of the first processing unit is performed, and then the diagnostic communication of the second processing unit is resumed. The in-vehicle device according to claim 1.

Images