JP2013233904A - Electronic control system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an electronic control system which prevents the hindering of an original control process of an in-vehicle ECU even if data acquisition requests are issued frequently from the outside.SOLUTION: An ECU-A10 specified as a data-sender ECU measures its processing load, and when the measured processing load exceeds a first level, asks the other ECU-B20 which possesses the same data to transmit a response signal as a proxy. This allows the ECU-A10 to avoid the case of an increased processing load. When transmitting a response signal as the proxy, the ECU-B20 makes the response signal to which an ID of the ECU-A10 specified as the data-sender ECU is attached. Therefore, even if an ECU different from the data-sender ECU specified by an OBD2 user device 60 transmits a response signal, the OBD2 user device 60 can recognize the transmitted response signal as the response signal from the specified data-sender ECU.

Description

  The present invention includes a plurality of ECUs connected to a network, and when at least one of the plurality of ECUs receives a request signal for requesting data transmission from an external device, the ECU responds to the request signal. The present invention also relates to an electronic control system that transmits a response signal including data held by the ECU to an external device.

  For example, in Patent Document 1, a plurality of electronic control devices mounted on a vehicle and connected to the plurality of electronic control devices via an external connection connector are used to diagnose input / output data of the plurality of electronic control devices. A vehicle diagnostic system including a vehicle diagnostic device is disclosed.

JP-A-1-247774

  2. Description of the Related Art In recent years, a technique for connecting a portable information terminal such as a smartphone to an OBD2 connector, which is a failure diagnosis connector installed in a vehicle, and acquiring and displaying various data related to the vehicle from an in-vehicle ECU is becoming widespread. .

  When a data acquisition request is made to the in-vehicle ECU by using such a portable information terminal (hereinafter referred to as an OBD2 user device) that acquires data relating to the vehicle, the in-vehicle ECU makes a request for the data acquisition. It is necessary to respond to this. For this reason, if a data acquisition request is frequently issued by the OBD2 user device, the processing load of the in-vehicle ECU increases due to the reception and response processing, and there is a possibility that the control processing that the in-vehicle ECU should originally perform may be hindered. Arise.

  The present invention has been made in view of the above points, and prevents the occurrence of problems in the original control processing of the in-vehicle ECU as much as possible even when external data acquisition requests are frequently made. It is an object of the present invention to provide an electronic control system capable of performing the above.

In order to achieve the above-described object, the electronic control system according to claim 1 has a plurality of ECUs (10, 20, 30) each having a unique ID and network-connected, and the plurality of ECUs. When at least one of the ECUs receives from the external device (60) connected to the network a request signal for requesting data transmission, designated by the data transmission source ECU using the ID, In response to a request signal, a response signal including data held by the ECU is transmitted to the external device,
The ECU designated as the data transmission source ECU is:
Measuring means (S130) for measuring its own processing load;
Request means for requesting another ECU having the same data to transmit a response signal as a proxy when the processing load measured by the measurement means exceeds a predetermined first level. S140, S170, S200), and
When the other ECU transmits the response signal to the external device as a substitute, the other ECU creates a response signal to which the ID of the ECU designated as the data transmission source ECU is added and transmits the response signal to the external device Transmission control means (S380, S390) to be provided.

  As described above, the ECU designated as the data transmission source ECU measures its own processing load, and when the measured processing load exceeds the first level, other ECUs holding the same data The ECU is requested to perform proxy transmission of a response signal. Therefore, in the ECU designated as the data transmission source ECU, it is possible to avoid a situation in which the processing load increases in order to respond to the data transmission request from the external device. When another ECU transmits a response signal by proxy, a response signal to which the ID of the ECU designated as the data transmission source ECU is added is created. Therefore, even if another ECU different from the data transmission source ECU designated by the external device transmits the response signal, the external device can recognize the response signal from the designated data transmission source ECU.

  Note that the reference numerals in the parentheses merely show an example of a correspondence relationship with a specific configuration in an embodiment described later in order to facilitate understanding of the present invention, and limit the scope of the present invention. It is not intended.

  Further, the features of the present invention other than the features described above will be apparent from the description of embodiments and the accompanying drawings described later.

It is a block diagram which shows the structure of the electronic control system which concerns on embodiment. It is a figure which shows the format of the CAN frame used for communication between each ECU and OBD2 user device. It is a figure which shows the list of defined CAN-ID. When ECU-A is designated as data transmission origin ECU by an OBD2 user device, it is a figure which shows an example of the CAN flame | frame which ECU-A transmits toward other ECU. When ECU-B receives a request for proxy transmission from ECU-A, it is a diagram illustrating an example of a CAN frame that ECU-B transmits to another ECU. It is a figure which shows an example of the CAN frame transmitted when an OBD2 user device makes a data transmission request (data monitor request) to ECU-A. It is a figure which shows an example of a CAN frame when ECU-A receives a data transmission request from an OBD2 user device and returns a response signal to the OBD2 user device. It is the table which summarized the information regarding the data which each ECU holds. It is a flowchart which shows the process performed by interruption, when ECU-A receives the signal (CAN frame) which requests | requires transmission of data from an OBD2 user device. It is a flowchart which shows the process periodically repeated in ECU-A in order to transmit a sensor detection value and a calculated value between ECUs. It is a flowchart which shows the process performed by interruption in ECU-A, when the regular transmission signal from other ECU which requested proxy transmission is received. It is a flowchart which shows the process performed by interruption in ECU-B, when the regular transmission signal from ECU-A is received. It is a flowchart which shows the process periodically and repeatedly performed in ECU-B in order to transmit a sensor detection value and a calculated value between ECUs. It is a flowchart which shows the process performed by interruption when ECU-B receives the signal (CAN frame) which requests | requires transmission of data from an OBD2 user device. It is explanatory drawing which shows the process which ECU-A performs when the data transmission request signal is first output from an OBD2 user device. It is explanatory drawing which shows the process which ECU-B performs when the data transmission request signal after the 2nd time is output from the OBD2 user device. It is explanatory drawing which shows notionally a mode that a processing load is equalized.

  Hereinafter, an electronic control system according to an embodiment of the present invention will be described with reference to the drawings.

  As shown in FIG. 1, the electronic control system according to the present embodiment includes a plurality of ECUs (ECU-A10, ECU-B20, ECU-C30,...) Connected to a network. For example, the electronic control system can be applied to control the driving force of the vehicle, and in this case, each ECU (ECU-A10, ECU-B20, ECU-C30) is an engine fuel injection amount, It controls ignition timing, valve timing, throttle opening, transmission gear position, and so on.

  Each ECU (ECU-A10, ECU-B20, ECU-C30) is communicably connected to each other via a local area network (in-vehicle LAN) 40 provided in the vehicle for data sharing and cooperative control. Has been. In this mutual communication, for example, a CAN protocol is used as a communication protocol.

  The in-vehicle LAN 40 is provided with an OBD2 connector 50 that is a failure diagnosis connector. The OBD2 connector is provided for connecting a diagnostic device at a dealer or the like, for example, when the vehicle is malfunctioning. Using this diagnostic device, internal data such as diagnostic codes are read from each ECU (ECU-A10, ECU-B20, ECU-C30), making it easy to determine whether the vehicle is normal or abnormal and to identify abnormal parts. It can be carried out.

  However, in recent years, as an application for portable information terminals such as smartphones and tablet PCs, various vehicle data (engine speed, air flow rate, accelerator opening, fuel injection amount, etc.) are acquired via the OBD2 connector 50. Some of them are displayed as they are or after being processed. When a portable information terminal (hereinafter referred to as an OBD2 user device) 60 in which such an application is installed is connected to the OBD2 connector 50 by wire or wirelessly and frequently sends data requests to a specific ECU, the ECU However, there is a risk that the control process that should be originally performed may be hindered.

  Therefore, in the present embodiment, the processing load in the ECU (the ECU designated as the data transmission source ECU) that is the data transmission request target is measured, and if the processing load exceeds a predetermined first level, the transmission is performed. Other ECUs having the same data to be allowed can respond on behalf of them. This point will be described in detail later.

  2 is a diagram illustrating an example of a format of a CAN frame used for communication between each ECU ((ECU-A10, ECU-B20, ECU-C30)) and the OBD2 user device 60. In this CAN frame, At the beginning, a CAN-ID section for recording a CAN-ID for identifying a transmission source and specifying a transmission destination is provided.

  This CAN-ID will be described in detail below. In the present embodiment, for example, CAN-ID is defined as shown in FIG. For example, when the CAN-ID is “7E0”, the transmission source is the OBD2 user device 60 and the transmission destination is the ECU-A10. When the CAN-ID is “7E1”, the transmission source is the OBD2 user device 60. Means that the transmission destination is ECU-B20. In the case of “7E2,” it means that the transmission source is the OBD2 user device 60 and the transmission destination is ECU-C30. When the CAN-ID is “7E8”, the transmission source is the ECU-A10, and the transmission destination is the OBD2 user device 60. When the CAN-ID is “7E9”, the transmission source is the ECU-B20. This means that the transmission destination is the OBD2 user device 60. In the case of “7EA”, the transmission source is the ECU-C30, and the transmission destination is the OBD2 user device 60.

  In communication between each ECU (ECU-A10, ECU-B20, ECU-C30), a CAN-ID is determined so that an ECU other than itself can be collectively designated as a transmission destination ECU. It has been. For example, when the electronic control system is composed of ECU-A10, ECU-B20, and ECU-C30, when “120” is used as the CAN-ID, the transmission source is ECU-A10, and the transmission destination is other ECU-B20. And ECU-C30. Similarly, in the case where “121” is used as the CAN-ID, the transmission source is ECU-B20 and the transmission destinations are ECU-A10 and ECU-C30. In the case where “122” is used, the transmission source is ECU-C30. The destination is ECU-A10 and ECU-B20.

  Referring to FIG. 2 again, in the CAN frame, a DATA part is defined following the first CAN-ID part. This DATA section stores detection values detected by various sensors (not shown) and calculation values in each ECU for sharing with other ECUs, etc., and requests for proxy transmission to other ECUs In addition, an answer of acceptance / rejection to the request is stored. Further, in the case of a CAN frame communicated between the OBD2 user device 60 and the ECU, the requested service content, the requested data name, and the like are stored in the DATA section, and data in response to the request is stored.

  4 to 7 show examples of various types of information stored in the DATA part of the CAN frame. First, FIG. 4 shows an example of a CAN frame that the ECU-A 10 transmits to another ECU when the ECU-A 10 is designated by the OBD2 user device 60 as the data transmission source ECU. In addition, between each ECU, a CAN frame is created and communicated with each other every predetermined time.

  As shown in FIG. 4, the CAN frame transmitted from the ECU-A 10 to another ECU stores sensor detection values such as the rotation speed, air flow rate, accelerator opening, and the like. Furthermore, the ECU-A 10 designated as the data transmission source ECU may request other ECUs to perform proxy transmission of response signals to the OBD2 user device 60 according to its processing load. Information necessary for requesting transmission is also stored. Specifically, a proxy request information flag B indicating whether there is a request for proxy transmission, a request data name C, CAN-ID information D indicating the ECU to which proxy transmission is requested, and the like are stored. Note that the CAN-ID information D uses an ID indicating the transmission source. For example, when the proxy transmission is requested to the ECU-B 20, “121” is stored as the CAN-ID information D.

  FIG. 5 shows an example of a CAN frame that the ECU-B 20 transmits to another ECU when the ECU-B 20 receives a request for proxy transmission from the ECU-A 10. As shown in FIG. 5, the ECU-B 20 indicates a proxy acceptance flag X indicating whether to accept or reject a request for proxy transmission, a request data name C, and an ECU (ECU-A10) requesting proxy transmission. CAN-ID information Y and the like are stored.

  Such a CAN frame shown in FIG. 4 and FIG. 5 is exchanged between the ECU-A 10 and the ECU-B 20 to determine whether a request for proxy transmission and whether or not the request is accepted. Can be recognized.

  FIG. 6 shows an example of a CAN frame transmitted when the OBD2 user device 60 makes a data transmission request (data monitor request) to the ECU-A 10. In this case, as illustrated in FIG. 6, “7E0” indicating that the transmission source is the OBD2 user device 60 and the transmission destination is the ECU-A10 is stored in the CAN-ID portion. In the DATA section, a service number indicating the requested service content and a request data name are stored. The service number “01” shown in the figure means a data monitor (data transmission request). Further, the number of request data names is not limited to one, and a plurality of request data names may be stored.

  FIG. 7 shows an example of a CAN frame when the ECU-A 10 receives a data transmission request from the OBD 2 user device 60 and returns a response signal to the OBD 2 user device 60. In addition, also when ECU-B20 performs proxy transmission, the CAN frame including each information shown in FIG. 7 is transmitted.

  As illustrated in FIG. 7, “7E8” indicating that the transmission source is the ECU-A 10 and the transmission destination is the OBD2 user device 60 is stored in the CAN-ID portion. In the DATA section, a service number (“41” in the illustrated example) indicating transmission of the requested data, a requested data name, and a value of the data are stored.

  Here, in the electronic control system according to the present embodiment, the data held by each ECU (ECU-A10, ECU-B20, ECU-C30) is predetermined as shown in FIG. Each of the ECU and OBD2 user device 60 is known. Therefore, when there is a desire to acquire desired data, the OBD2 user device 60 can transmit the above-described CAN frame by designating the ECU holding the data by the CAN-ID.

In addition, the ECU that has received the data transmission request from the OBD2 user device 60 can search for another ECU having the same data with reference to the table shown in FIG. 8 when the processing load of the ECU is large. It is possible to make a request for proxy transmission to the retrieved ECU. In the present embodiment, when there are a plurality of ECUs that have the same data, the ECU that requests proxy transmission is randomly selected from the table shown in FIG. Also, possessing the same data means that if there is a plurality of requested data, it means that all of the plurality of data are retained. Next, the ECU-A 10 performs data transmission using the OBD2 user device 60. Specific processing executed in the ECU-A 10 when designated as the transmission source ECU will be described with reference to the flowcharts of FIGS. 9 to 11.

  The flowchart of FIG. 9 shows processing executed by an interrupt when the ECU-A 10 receives a signal (CAN frame) requesting transmission of data from the OBD2 user device 60. In this case, first, in step S100, the ECU-A 10 refers to the proxy response flag A that is turned ON when another ECU is executing proxy transmission. At this time, if the proxy response flag A is ON, it is not necessary for the ECU-A 10 to respond to the data transmission request signal, so the processing is terminated as it is. On the other hand, if the proxy response flag A is OFF, the process proceeds to step S110, where a response signal including the requested data is created and transmitted. Accordingly, when a data transmission request signal is first received from the OBD2 user device 60, a response signal can be transmitted without delay.

  Since the processing shown in the flowchart of FIG. 9 is executed by receiving the data transmission request from the OBD2 user device 60, the OBD2 user device 60 is connected to the OBD2 connector 50, and the data transmission request is repeated in the future. There is a possibility of receiving a signal. Therefore, in step S120, the state of the proxy request information flag B is set to “REQ” indicating that proxy transmission is necessary.

  Next, the flowchart of FIG. 10 will be described. The flowchart of FIG. 10 is periodically and repeatedly executed by the ECU-A 10 in order to transmit sensor detection values and calculation values between ECUs.

  First, in step S130, for example, the increment counter value by the idle task is regarded as the processing load value, and the processing load is calculated from the increment counter value. However, the calculation of the processing load is not limited to such an example. For example, the processing load may be calculated from the CPU usage rate in the ECU-A 10.

  In subsequent step S140, it is determined whether or not the processing load is large depending on whether or not the processing load calculated in step S130 exceeds a predetermined first level. If it is determined that the processing load is large, the process proceeds to step S150. If it is determined that the processing load is not large, the process proceeds to step S160.

  In step S150, it is determined whether or not the state of the proxy request information flag B is set to “REQ” indicating that proxy transmission is necessary. If “YES” is determined in this determination processing, the processing load on the ECU-A 10 is large and there is a possibility that the data transmission request signal will be repeatedly received in the future. Therefore, the process proceeds to step S170, and the table shown in FIG. Referring to and determining the ECU that requests proxy transmission. On the other hand, if “NO” is determined in the determination process of step S150, the processing load on the ECU-A10 is heavy, but there is currently no possibility of receiving a data transmission request signal, so the process proceeds to step S180. The proxy request information flag B is set to “NONE” indicating that there is no need for proxy transmission.

  In step S160, it is determined whether the proxy response flag A is OFF. If the proxy response flag A is not OFF, that is, if it is determined that the proxy response flag A is ON, the process proceeds to step S190. In this case, the other ECU is executing proxy transmission, but the processing load of the ECU-A10 that requested the proxy transmission is reduced, and the ECU-A10 can create and transmit a response signal. It can be said that it became. Therefore, in step S190, the state of the proxy request information flag B is set to “CANCEL” indicating cancellation of the request for proxy transmission. Further, since the CAN frame including the proxy request information flag B set to “CANCEL” is transmitted to the proxy transmission request destination ECU in step S200 described later, the proxy transmission is completed. Is set to OFF.

  On the other hand, if it is determined in step S160 that the proxy response flag A is OFF, the process proceeds to step S180. Accordingly, even if the state of the proxy request information flag B is set to “REQ” indicating that proxy transmission is necessary by the processing of step S120 in the flowchart of FIG. 9, the processing load of the ECU-A10 Therefore, it can be reset to “NONE” indicating that there is no need for proxy transmission.

  In step S200, the ECU-A 10 transmits a CAN frame storing various pieces of information as shown in FIG. 4 to other ECUs as a periodic transmission signal. In step S210, since the transmission to the other ECU is completed, the state of the proxy request information flag B is set to “NONE” which is the initial state.

  In step S140 described above, when determining the processing load level of the ECU-A 10, the processing load level (first level) for determining that proxy transmission is necessary, and the proxy transmission being executed are determined. The processing load level (second level) for determining cancellation may be the same level, but the second level may be lower than the first level. In this way, by making the first level different from the second level, it is possible to prevent the request for proxy transmission and cancellation from being repeated frequently.

  Next, the flowchart of FIG. 11 will be described. The flowchart of FIG. 11 shows a process executed by interruption when a periodic transmission signal is received from another ECU that has requested proxy transmission.

  First, in step S220, the proxy acceptance flag X included in the periodic transmission signal (CAN frame) received from another ECU is referred to. If this proxy acceptance flag X is ON, it means that the proxy transmission request has been accepted, and if it is OFF, it means that the proxy transmission request has been rejected. If it is determined in step S220 that the proxy acceptance flag X is ON, the process proceeds to step S230, and the proxy response flag A is set to ON. While this proxy response flag A is ON, not the ECU-A 10 but another ECU transmits a response signal in response to a data transmission request from the OBD 2 user device 60.

  On the other hand, if it is determined in step S220 that the proxy acceptance flag X is OFF, the process proceeds to step S240, and the proxy response flag A is set to OFF. While the proxy response flag A is OFF, the ECU-A 10 generates a response signal when it receives a data transmission request signal from the OBD2 user device 60 even if its processing load level is high. And return it.

  When a request for proxy transmission is rejected by another ECU, the state of the proxy request information flag B is set again to “REQ” indicating that proxy transmission is necessary, and the next periodic transmission is performed. In the processing, a request for proxy transmission may be made to an ECU other than the ECU that refuses proxy transmission.

  Next, processing executed in another ECU (for example, ECU-B20) that has received a request for proxy transmission from the ECU-A10 or has already accepted the request is used with reference to the flowcharts of FIGS. I will explain.

  First, the flowchart of FIG. 12 shows processing executed by interruption when a periodic transmission signal from the ECU-A 10 is received. In this case, the ECU-B 20 refers to the proxy request information flag B included in the received periodic transmission signal in step S300. Then, when the state of the proxy request information flag B is “REQ”, the process proceeds to step S310, and the proxy acceptance flag X is once set to ON. If the state of the proxy request information flag B is “CANCEL”, the process proceeds to step S320, and the proxy acceptance flag X is set to OFF. When the state of the proxy request information flag B is “NONE”, the processing shown in the flowchart of FIG. 12 is terminated without setting the proxy acceptance flag X.

  Next, the flowchart of FIG. 13 will be described. The flowchart of FIG. 13 is periodically and repeatedly executed by the ECU-B 20 in order to transmit sensor detection values and calculation values between ECUs.

  First, in step S330, the processing load on the ECU-B 20 is calculated. The calculation of the processing load is performed in the same manner as the processing in step S130 in the flowchart of FIG. In subsequent step S340, it is determined whether or not the processing load is large depending on whether or not the processing load calculated in step S330 exceeds a predetermined level. If it is determined that the processing load is large, the process proceeds to step S350, and the proxy acceptance flag X is set to OFF. Thereby, even if the proxy acceptance flag X is set to ON in step S310 of the flowchart of FIG. 12, the proxy acceptance flag X is reset to OFF when the processing load of the ECU-B 20 is large. Furthermore, even after accepting a request for proxy transmission from ECU-A once, if the processing load on ECU-B 20 is large during periodic transmission processing, proxy acceptance flag X is set to OFF, Acceptance of proxy transmission is cancelled.

  In step S360, the ECU-B 20 uses the CAN frame that includes the proxy acceptance flag X set as described above and stores various types of information as shown in FIG. Transmit to the ECU. The ECU-A 10 receives this periodic transmission signal and refers to the proxy acceptance flag X, so that the ECU-B 20 has accepted or rejected the request for proxy transmission, or cancels the accepted proxy transmission. Can recognize.

  Next, the flowchart of FIG. 14 will be described. The flowchart of FIG. 14 illustrates processing executed by an interrupt when the ECU-B 20 receives a signal (CAN frame) requesting data transmission from the OBD2 user device 60. Note that since the ECU-B 20 is connected to the in-vehicle LAN 40, even a signal directed from the OBD2 user device 60 to the ECU-A 10 can be received.

  First, in step S370, it is determined whether the proxy acceptance flag X is set to ON. At this time, if it is determined that the proxy acceptance flag X is set to ON, the ECU-B 20 needs to respond to the data request signal from the OBD2 user device 60, and thus the process proceeds to step S380. In step S380, the CAN-ID is rewritten in the CAN frame as a response signal to the OBD2 user device 60. That is, when the ECU-B 20 transmits a signal to the OBD2 user device 60, “7E9” is normally used as the CAN-ID. However, when the ECU-B 20 transmits a response signal instead of the ECU-A 10, the CAN-ID is rewritten to “7E8” indicating the ECU-A 10. As a result, when the OBD2 user device 60 receives the response signal, the OBD2 user device 60 recognizes that the response is a valid response signal to the data transmission request signal, and performs reception processing. In other words, if “7E9” indicating that it is ECU-B20 is used as it is as the CAN-ID, the OBD2 user device 60 determines that it does not respond to its own data transmission request signal. . As a result, for example, since it has not yet responded to its own data transmission request, the ECU-A 10 is repeatedly requested to transmit data.

  In step S390, the CAN frame including the rewritten CAN-ID is transmitted as a response signal by proxy.

  When the ECU-A 10 and the ECU-B 20 perform the above-described processing, when the data transmission request signal is first output from the OBD2 user device 60, the ECU-A 10 sends a response signal as shown in FIG. Create and return. However, at that time, if its own processing load is large, it requests other ECUs to substitute the response signal. When the request is accepted, as shown in FIG. 16, a response signal for the second and subsequent data transmission request signals is created and returned by another ECU (ECU-B20). Accordingly, as shown in FIG. 17, the response processing for the data transmission request signal, that is, the reception processing of the data transmission request signal and the generation and transmission of the response signal are transferred to another ECU having a lower processing load than the ECU-A10. By doing so, it is possible to avoid as much as possible the trouble in the control process that the ECU-A 10 should originally process.

  The preferred embodiments of the present invention have been described above. However, the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the spirit of the present invention. .

  For example, in the above-described embodiment, when a data transmission request signal is received from the OBD2 user device, proxy transmission is requested to another ECU, but for each type of data requested in advance, Depending on the processing load, an ECU for proxy transmission of the response signal may be determined. Since the processing load of each ECU is not always constant, it is preferable to periodically update the ECU that performs proxy transmission.

  Further, in the above-described embodiment, the ECU designated as the data transmission source ECU randomly determines the ECU that requests the proxy transmission from among the ECUs having the same data. However, the processing load information of each ECU is included in the periodically transmitted data, and when the ECU designated as the data transmission source ECU requests proxy transmission, the processing load is reduced among the ECUs having the same data. The lowest ECU may be selected. Alternatively, for each of a plurality of ECUs that have the same data, the ECU designated as the data transmission source ECU records the acceptance and rejection results when requesting proxy transmission, and in order of decreasing acceptance probability, A request for proxy transmission may be made.

  Furthermore, in the above-described embodiment, when the request for proxy transmission is rejected, the ECU that requested the proxy transmission has explained that another ECU requests the proxy transmission. It is also possible for an ECU that refuses to make a request for proxy transmission to another ECU.

10 ECU-A
20 ECU-B
30 ECU-C
40 in-car LAN
50 OBD2 connector 60 OBD2 user device

Claims (7)

Each of the plurality of ECUs (10, 20, 30) is assigned a unique ID and is connected to the network. At least one of the ECUs is an external device (60) connected to the network. When a request signal for requesting data transmission is received, designated by the data transmission source ECU using the ID, a response signal including data held by the ECU is sent in response to the request signal. An electronic control system for transmitting to an external device,
The ECU designated as the data transmission source ECU is:
Measuring means (S130) for measuring its own processing load;
Request means for requesting another ECU having the same data to transmit a response signal as a proxy when the processing load measured by the measurement means exceeds a predetermined first level. S140, S170, S200), and
When the other ECU transmits the response signal to the external device as a substitute, the other ECU creates a response signal to which the ID of the ECU designated as the data transmission source ECU is added and transmits the response signal to the external device An electronic control system comprising transmission control means (S380, S390) for performing When the ECU designated as the data transmission source ECU first receives a request signal from the external device, it transmits a response signal by itself, and when the processing load exceeds a predetermined first level, The requesting unit requests proxy transmission of a response signal to the other ECU,
2. The electronic control system according to claim 1, wherein the other ECU transmits a response signal as a proxy in response to a request signal from the external device on and after the next time. The other ECU also includes measuring means (S330) for measuring its own processing load,
The other ECU accepts the request when the processing load measured by the measuring unit is equal to or lower than a predetermined level when the request unit receives a request to transmit a response signal on behalf of the request unit. 3. The electronic control system according to claim 1, wherein the request is rejected when the predetermined level is exceeded.   In addition to the ECU designated as the data transmission source ECU, there are a plurality of ECUs that hold the same data as the data to be transmitted to the external device, and the other ECU that requested the proxy transmission requests that The ECU designated as the data transmission source ECU or the ECU that rejected the request for proxy transmission further requests another ECU holding the same data for proxy transmission. The electronic control system according to claim 3.   The ECU designated as the data transmission source ECU records the acceptance and rejection results when requesting proxy transmission for each of the plurality of ECUs having the same data, in order of decreasing acceptance probability, 5. The electronic control system according to claim 3, wherein a request for proxy transmission is made. When there are a plurality of ECUs that have the same data as the data to be transmitted to the external device, a plurality of ECUs that have the same data measure processing load measuring means (S330) for measuring their own processing loads. Have
The ECU designated as the data transmission source ECU acquires the respective processing loads from the plurality of ECUs having the same data, and requests proxy transmission to the ECU with the lowest processing load. The electronic control system according to claim 3.   After the other ECU receives a request for proxy transmission, when the processing load of the ECU designated as the data transmission source ECU falls below a predetermined second level, or the processing load of the other ECU 7. The proxy transmission by the other ECU is canceled when it increases to a predetermined level or more, and an ECU designated as the data transmission source ECU transmits a response signal. Electronic control system.

Images