ECU control system and ECU control method

The system addresses data transmission challenges by managing communication load through pattern-based scheduling and priority, enabling efficient transfer of large data volumes in vehicle diagnostic systems.

WO2026069694A1PCT designated stage Publication Date: 2026-04-02NISSAN MOTOR CO LTD
View PDF 3 Cites 0 Cited by

Patent Information

Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-09-30
Publication Date
2026-04-02

AI Technical Summary

Technical Problem

Existing vehicle diagnostic systems face challenges in transmitting large volumes of vehicle data due to communication load restrictions during wireless communication between vehicles and servers.

Method used

The system determines communication load and schedules data transmission based on usage patterns and priority, transmitting critical data during high load and less critical data during low load, using a management ECU to manage data storage and transmission.

Benefits of technology

Ensures efficient transmission of large data volumes by prioritizing and timing data transfer according to communication load, reducing restrictions and ensuring timely data availability for diagnostics and updates.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure JP2024035017_02042026_PF_FP_ABST
    Figure JP2024035017_02042026_PF_FP_ABST
Patent Text Reader

Abstract

In an ECU control system 100, a management ECU 30: identifies a communication load in wireless communication between a server and a vehicle; transmits first vehicle data to the server 1 when the communication load is greater than a prescribed value; and transmits, to the server 1, vehicle data including at least second vehicle data, when the communication load is not greater than the prescribed value.
Need to check novelty before this filing date? Find Prior Art

Description

ECU Control System and ECU Control Method

[0001] The present invention relates to an ECU control system and an ECU control method.

[0002] Conventionally, a vehicle diagnostic system including a communication terminal that transmits vehicle information acquired from a vehicle to a server, and a server that analyzes the vehicle information received from the communication terminal and diagnoses the vehicle is known. For example, in the vehicle diagnostic system described in Patent Document 1, the server notifies the communication terminal of the items of vehicle information necessary for diagnosis to be acquired from the vehicle, and the communication terminal acquires vehicle information from the vehicle according to the items of vehicle information notified from the server, and transmits the acquired vehicle information to the server in real time.

[0003] Japanese Patent Application Laid-Open No. 2022-107913

[0004] However, when transmitting vehicle information from a vehicle to a server in real time, if the communication load is large, there is a problem that communication is restricted, so vehicle information with a large data volume cannot be transmitted to the server.

[0005] The problem to be solved by the present invention is to provide an ECU control system and an ECU control method capable of transmitting vehicle data with a large data volume to a server according to the communication load of wireless communication between the vehicle and the server.

[0006] The present invention solves the above problems by specifying the communication load of wireless communication between the server and the vehicle, transmitting first vehicle data to the server when the communication load is greater than a predetermined value, and transmitting vehicle data including at least second vehicle data to the server when the communication load is less than or equal to the predetermined value.

[0007] According to the present invention, vehicle data with a large data volume can be transmitted to the server according to the communication load of wireless communication between the vehicle and the server.

[0008] FIG. 1 is a schematic configuration diagram of an ECU control system according to the present embodiment.

[0009] Hereinafter, an embodiment of the ECU control system according to the present invention will be described based on the drawings.

[0010] Figure 1 is a schematic diagram of the configuration of the ECU control system 1000 according to this embodiment. The ECU control system 1000 according to this embodiment is a system that controls a server and an ECU in a vehicle, and includes a server 1 and a vehicle control system 100. The vehicle control system 100 is a system that controls an ECU and is installed in hybrid vehicles equipped with an engine and a motor, electric vehicles, vehicles that obtain power from an engine (ICE vehicles), etc. The vehicle control system 100 has a communication unit 10, an OBD terminal 20, a management ECU 30, a VCM 40, an IVI 41, a BMS 42, an ADCU 50, a camera 51, a LiDAR 52, a BCM 60, an ACU 61, a Meter 62, and buses 400-402, 500-502, and 600-602. The ECUs and loads (in-vehicle devices) included in the ECU control system 1000 are connected by an in-vehicle communication network such as CAN or LIN.

[0011] Server 1 communicates with vehicles remotely and sends and receives data between the server and the vehicles. Server 1 includes a server control unit 2 and a database 3. The server control unit 2 performs tasks such as remote diagnosis, software updates, and vehicle data collection, and stores the vehicle data collected from multiple vehicles in the database 3. Remote diagnosis involves connecting Server 1 and the vehicle wirelessly to access the vehicle remotely and diagnose its condition. Specifically, the server control unit 2 sends a diagnostic command to the vehicle to be diagnosed, specifying the data to be extracted from the vehicle. The server control unit 2 may also send a diagnostic command after specifying the ECU to be diagnosed from among the ECUs included in the vehicle. The server control unit 2 uses the vehicle data acquired from the vehicle to diagnose whether or not there is an abnormality in the vehicle. The vehicle data transmitted from the vehicle to Server 1 includes fault codes (DTCs), ECU logs, or data indicating the vehicle's driving status. In remote diagnosis, the diagnosis of whether or not there is an abnormality in the vehicle may be performed on the server side or on the vehicle side.

[0012] Software updates involve sending update data for updating the software contained in the vehicle's ECU from Server 1 to the vehicle via OTA (over-the-air) communication (wireless communication), and then performing the software update in the vehicle. Server 1 stores the update data for updating the ECU software in Database 3 and sends the update data to the vehicle in response to an update request. The update data is the latest software data. The update data may also include the time required for the software update. Server 1 manages campaigns in the database that include vehicle identification information (VIN) and ECU identification information (e.g., ECU name). For example, when the latest version of the ECU software is uploaded, Server Control Unit 2 sends an update request signal to obtain the information necessary for the software update from the vehicle. The update request signal may include the software to be updated or the identification information (ID) of the ECU. In response to a request from Server 1, Vehicle Control System 100 sends vehicle data including ECU update information (version information), etc., to Server 1. Server Control Unit 2 determines from the update information whether the ECU software is up to date. If the server control unit 2 determines that the current version of the ECU is outdated, it sends the latest software (update data, reprogramming data) to the vehicle. The management ECU 30 of the vehicle control system 100 downloads the update data sent from the server 1. The vehicle control system 100 then uses the update data to update the software of the ECU to be updated.

[0013] The server control unit 2 communicates with the vehicle and acquires vehicle data, including vehicle location information, images captured by the in-vehicle camera, vehicle speed information, and application operation history. The vehicle data acquired from multiple vehicles is stored in database 3 and used for business purposes by insurance companies, vehicle repair companies, application vendors, music and video distribution companies, etc. For example, when a vehicle accident occurs, insurance companies collect vehicle data to understand the accident scene from the vehicle's location information, vehicle speed, and captured images, and to calculate the compensation burden rate. Application vendors and music distribution companies also collect vehicle data to understand the usage history of applications and entertainment content such as music by vehicle users, and to provide users with recommended information on relevant applications, etc. Server 1 may not only collect vehicle data from multiple vehicles, but may also transmit application data to the vehicles. Server 1 is a general term for a data center that can communicate with multiple vehicles remotely, and it is not necessary to perform all remote diagnostics, software updates, and vehicle data collection on separate servers 1; these functions may be performed by different servers 1.

[0014] The server control unit 2 also identifies the vehicle usage pattern based on at least one of the following pieces of information included in the vehicle data: time information, information indicating the vehicle's driving status, and vehicle location information. The vehicle usage pattern indicates how the user uses the vehicle and varies from user to user. For example, if a user uses the vehicle frequently during specific times, such as during commuting hours, the user's usage of the vehicle will be reflected in the vehicle data. For example, commuting hours are indicated by the time information in the vehicle data, the vehicle's driving status is indicated by the information included in the commuting route driving data (e.g., vehicle speed information, steering angle information, battery information, etc.), and the commuting route is indicated by the vehicle's location information and driving route information. The server control unit 2 can identify the vehicle usage pattern by understanding the time of day the vehicle is used, the duration of vehicle use (e.g., the time from when the vehicle's power switch (also called the ignition switch or main switch) is turned on to when it is turned off, the time the doors are opened and closed), or the trend of the location where the vehicle is used, based on the information included in the vehicle data.

[0015] The server control unit 2 may identify the vehicle usage pattern based on multiple pieces of information, including time information, information indicating the vehicle's driving status, and vehicle location information, included in the vehicle data. For example, consider a vehicle usage pattern in which a user boards the vehicle and maintains a stationary state for a predetermined period of time. The server control unit 2 can identify that a user has boarded the vehicle from the door opening and closing information, and can identify the vehicle's stationary state and / or stationary time from the vehicle's location information and switch information indicating whether the vehicle's power switch is switched off or on. In this way, the server control unit 2 can identify the vehicle usage pattern.

[0016] The server control unit 2 determines the transmission schedule for vehicle data according to the specified usage pattern. The transmission schedule is a communication plan that defines the timing of vehicle data transmission from the vehicle to the server 1. Regarding wireless communication between the server 1 and the vehicles, if many vehicles communicate with the server 1 at the same time, the communication load on the wireless communication will increase, which may lead to restrictions on wireless communication, making it impossible to send or receive large amounts of data, or causing the time required for data transmission and reception to increase. The server 1 acquires vehicle data from many vehicles. Therefore, in this embodiment, in order to reduce the communication load on the wireless communication, the transmission schedule for vehicle data is determined for each vehicle.

[0017] For example, if a user frequently uses their vehicle during specific times, such as during commuting hours, the time frame for transmitting vehicle data should also be aligned with commuting hours. Conversely, if a vehicle is used infrequently and the distance traveled per trip is short (for example, driving a few kilometers once a week), it is best to transmit vehicle data to server 1 as soon as the vehicle is used. In other words, in usage patterns where vehicle usage is infrequent or concentrated in specific time slots, the time frame for transmitting vehicle data may be limited. Therefore, the server control unit 2 determines the transmission schedule so as not to restrict the time frame for transmitting vehicle data from the server side.

[0018] On the other hand, if a vehicle is used frequently and without bias in usage time, there will be many opportunities to transmit vehicle data. Therefore, for vehicles used in a manner that results in many opportunities to transmit vehicle data and / or many available transmission times, the server control unit 2 determines the transmission schedule to transmit vehicle data during times when the communication load is low. Furthermore, for example, if a vehicle is used mostly during times of low communication load, such as late at night, the server control unit 2 determines the transmission schedule to transmit vehicle data during late-night hours when the communication load is low.

[0019] The server control unit 2 determines a transmission schedule for each vehicle, assigns a VIN (vehicle identification information) to the determined transmission schedule, and then notifies each vehicle of the transmission schedule. The vehicles transmit vehicle data to server 1 according to the transmission schedule determined by server 1.

[0020] Furthermore, the server control unit 2 may calculate the transmission priority of vehicle data for each of multiple vehicles based on at least one of the following: the number of times vehicle data has been transmitted, the transmission frequency, and the amount of vehicle data. For example, vehicles that are used infrequently, or vehicles that have had vehicle data transmitted infrequently, will not have vehicle data stored in the database 3. Therefore, when the server 1 performs a remote diagnosis, for example, the amount of vehicle data to be diagnosed will be small, and the server control unit 2 may not be able to identify a vehicle abnormality through remote diagnosis, or may not be able to detect a vehicle abnormality early. For this reason, the server control unit 2 calculates the transmission priority so that the less frequently vehicle data has been transmitted, the higher the transmission priority. Similarly, the server control unit 2 calculates the transmission priority so that the less frequently vehicle data has been transmitted, or the less vehicle data stored in the database 3, the higher the transmission priority. The amount of vehicle data is the amount of data stored in the database 3 for each vehicle.

[0021] The server control unit 2 determines a transmission schedule for each of the multiple vehicles according to the transmission priority. For example, for vehicles with high transmission priority, the transmission schedule is determined so that there are no restrictions on the transmission time, and the vehicle can transmit vehicle data as quickly as possible when it is able to do so. On the other hand, for vehicles with low transmission priority, the transmission schedule is determined so that the transmission time is restricted to a time when the communication load is low, or the amount of data per transmission is restricted.

[0022] Next, the components of the vehicle control system 100 will be described. The communication unit 10 controls the in-vehicle communication device to connect to a communication network such as an internet line (mobile line) and communicates with the server 1.

[0023] The management ECU 30 connects multiple ECUs downstream and forwards signals transmitted from one ECU to another. In other words, the management ECU 30 functions as a gateway. The management ECU 30 is connected to the communication unit 10 and performs tasks such as software updates, remote diagnostics, and transmission of vehicle data based on commands input from the communication unit 10.

[0024] The management ECU 30 has a memory 30a. The management ECU 30 acquires vehicle data from multiple downstream ECUs and stores it in the memory 30a. The memory 30a stores update data for updating the software of the downstream ECUs, application data for realizing various functions, etc. The vehicle data may be stored in the memory 30a with an ID assigned to it so that the type of vehicle data and the ECU from which the vehicle data is acquired can be distinguished. When the management ECU 30 receives a request from the server 1 to collect vehicle data, it identifies the vehicle data corresponding to the request from the recorded data in the memory 30a and transmits it to the server 1 via the communication unit 10. For example, when performing a software update, the management ECU 30 acquires update data from the server 1 and stores it in the memory 30a. The management ECU 30 then transmits the update data to the ECU to be updated at a predetermined timing, such as during a time when the communication capacity of buses 400, 500, and 600 is low. Furthermore, for example, when adding an application in response to a request from a user or system, the management ECU 30 retrieves the data for the additional application from the server 1 and stores it in memory 30a. If the additional application is to be processed under the control of the management ECU 30, the management ECU 30a starts the additional application stored in memory. On the other hand, if the additional application is to be processed by a downstream ECU, the management ECU 30 may send the data for the additional application stored in memory 30a to the downstream ECU in order to install the additional application on the downstream ECU.

[0025] Memory 30a should use a large-capacity recording medium so that it can store vehicle data and the like acquired from multiple downstream ECUs. Although each of the multiple downstream ECUs has its own memory, the storage capacity of the memory of the downstream ECUs is small, as is the storage capacity of the memory 30a of the management ECU 30.

[0026] The management ECU 30 connects to the VCM 40 via bus 400, to the ADCU 50 via bus 500, and to the BCM 60 via bus 600.

[0027] This section describes the software update process performed by the management ECU 30. The management ECU 30 receives a software update command from the server 1 via the communication unit 10 to perform the software update. Based on the software update command, the management ECU 30 identifies the target ECU for software update, or an ECU that is eligible for software update. The target ECU is an ECU connected downstream of the management ECU 30, such as the VCM 40, ADCU 50, and BCM 60, or an ECU connected downstream of the VCM 40, ADCU 50, and BCM 60. The management ECU 30 downloads the software update data from the server 1 and stores it in the memory 30a within the management ECU 30. The management ECU 30 assigns a software update ID to the target ECU and sends and receives signals to and from the target ECU in order to send and receive the data necessary for the software update.

[0028] The target ECU has memory for storing software. In the software update sequence control, the target ECU communicates with the management ECU 30 to identify the version information and software associated with the software update ID from the data stored in memory, and then transmits the version information of the target ECU, installs the software, and activates the software. Specifically, when the target ECU receives the software, the software is written to the target ECU's memory (installation). With both the old and new software stored in memory, the target ECU switches the software to be processed from the old software to the new software (activation). In this embodiment, the process for such software updates does not necessarily have to be performed in a continuous sequence; the target ECU may first perform the software installation and then, separately, perform the activation when the management ECU 30 receives an update start request.

[0029] Remote diagnosis by the management ECU 30 will now be described. The management ECU 30 receives a diagnostic command from the server 1 via the communication unit 10 to perform remote diagnosis. Based on the diagnostic command, the management ECU 30 identifies the target ECU to be remotely diagnosed. The target ECU is an ECU connected downstream of the management ECU 30, or downstream of the VCM 40, ADCU 50, and BCM 60. The management ECU 30 assigns a diagnostic ID to the target ECU and transmits and receives signals with the target ECU in order to send and receive data used for remote diagnosis.

[0030] The target ECU stores diagnostic data in its memory, such as fault codes (DTCs), ECU logs, or data indicating the vehicle's driving status, as diagnostic data used for diagnosis. In the diagnostic sequence control, the target ECU communicates with the management ECU 30 to identify data associated with a diagnostic ID from the data stored in its memory, and transmits the identified diagnostic data to the management ECU 30. The management ECU 30 transmits the diagnostic data transmitted from the target ECU to the server 1. As a result, the management ECU 30 obtains diagnostic data from the target ECU that is used to diagnose the vehicle's condition. The management ECU 30 then transmits the diagnostic data obtained from the target ECU to the server 1 via the communication unit 10. The management ECU 30 may perform a remote diagnosis immediately after receiving a diagnostic command from the server 1, or it may perform a remote diagnosis at a predetermined execution timing. The predetermined execution timing may be a periodic timing such as once a day, or it may be the timing of switching the power switch (ignition switch or power switch) on and off.

[0031] VCM40, ADCU50, and BCM60 are ECUs and are connected downstream of the management ECU30 via buses 400, 500, and 600. Note that the communication unit 10, management ECU30, VCM40, ADCU50, and BCM60 are examples of multiple ECUs included in a vehicle, and the vehicle may include other ECUs. Furthermore, the management ECU30 is not limited to CM40, ADCU50, and BCM60, and may be connected to other ECUs.

[0032] The VCM (Vehicle Control Module) 40 is a control unit that controls the vehicle's drivetrain. The VCM 40 monitors the amount the accelerator pedal is pressed and controls the drivetrain, including the motor and engine. The VCM 40 stores vehicle data, such as control parameters of the drivetrain, in memory 40a while the vehicle is running. The control parameters of the drivetrain include the motor output torque, engine torque, and battery charge level. The upper limit capacity of memory 40a is smaller than the upper limit capacity of memory 30a. Downstream of the VCM 40 are connected an INV (Inverter) 41, a BMS (Battery Management System) 42, etc. The INV 41 is connected to bus 401, which branches off from bus 400 downstream of the VCM 40. The INV 41 is connected between the vehicle battery and the vehicle motor and converts the voltage of the vehicle battery to output to the vehicle motor. The BMS42 is a control unit (ECU) for controlling the charging and discharging of the vehicle battery. The BMS42 is connected to bus 402, which branches off from bus 400 downstream of the VCM40. If the vehicle is an ICE vehicle or a hybrid vehicle, the engine is connected downstream of the VCM40. Note that, in addition to the INV41 and BMS42, other devices such as a DCDC converter may be connected downstream of the VCM40.

[0033] The ADCU (Assisted Driving Control Unit) 50 is a control unit that assists in the driving of the vehicle. During autonomous driving, the ADCU 50 stores vehicle data indicating the surrounding environment of the vehicle in memory 50a. This vehicle data indicating the surrounding environment includes, for example, images captured by an onboard camera and measurement data from measurement sensors such as LiDAR 52. The upper limit capacity of memory 50a is smaller than the upper limit capacity of memory 30a. Cameras 51 and LiDAR 52 are connected downstream of the ADCU 50. Camera 51 is connected to bus 501, which branches off from bus 500 downstream of the ADCU 50. LiDAR 52 is connected to bus 502, which branches off from bus 500 downstream of the ADCU 50. The ADCU 50 detects white lines from the images captured by camera 51 and performs steering control to prevent the vehicle from deviating from its lane. Furthermore, the ADCU 50 measures the distance to the preceding vehicle from the data detected by the LiDAR 52, maintains the distance between the preceding vehicle and its own vehicle, and performs steering control and / or vehicle speed control to follow the preceding vehicle. Downstream of the ADCU 50, a memory containing high-precision map data may be connected in addition to the camera 51 and LiDAR 52. The ADCU 50 may also use a high-precision map to recognize the road layout and perform autonomous driving control that is appropriate to the current road conditions, in addition to lane departure prevention control and preceding vehicle following control.

[0034] The BCM (Body Control Module) 60 is a control unit that controls the overall functions of the vehicle body, including interior and exterior lighting, doors, windows, mirrors, and wipers. The BCM 60 stores vehicle data, including the operation history of in-vehicle equipment, in memory 60a. The upper limit of memory 60a is smaller than the upper limit of memory 30a. Downstream of the BCM 60 are connected the ACU (Airbag control Unit) 61, Meter 62, etc. The ACU 61 is connected to bus 601, which branches off from bus 600 downstream of the BCM 60. The Meter 62 is connected to bus 602, which branches off from bus 600 downstream of the ADCU 50. The ACU 61 is an airbag control unit (ECU). The Meter 62 displays speed, etc. Furthermore, downstream of the BCM60, other devices such as HVAC (Heating Ventilation and Air-Conditioning) may be connected, in addition to the ACU61 and Meter62.

[0035] Bus 400 is a bus that groups the VCM 40 and multiple ECUs downstream of the VCM 40. Bus 400 branches downstream of the VCM 40, and the branched buses 401 and 402 are each connected to an ECU or load. Note that buses 401 and 402 may be connected to more than one ECU or load, or multiple ECUs and / or multiple loads. Buses 500-502 and 600-602 have the same communication network as buses 400-402. Note that an ECU or load may be connected between the management ECU 30 and the VCM 40, ADCU 50, and BCM 60. In this way, the vehicle control system 100 consists of multiple control groups divided according to the basic configuration of the vehicle. These control groups are also called domains. For example, in the example in Figure 1, there is a vehicle drive system domain including the VCM 40, a vehicle driving support system domain including the ADCU 50, and a body domain including the BCM 60. The domains include a multimedia domain that controls information display within the vehicle, a powertrain domain that controls the engine, and a chassis domain that controls the steering mechanism. By defining the domain configuration, the configurations of buses 400-402, 500-502, and 600-602 can be separated.

[0036] Incidentally, the memory 30a of the management ECU 30 requires a large-capacity recording medium to meet the needs described below. The ECU's software and applications are expected to be updated or added after the vehicle is shipped, and furthermore, software and application updates may be carried out not only by the vehicle manufacturer but also by other companies or individuals. For example, if an application to the vehicle is added or changed from outside the vehicle, the vehicle control system 100 needs to send the application data to the ECU to be updated. Also, by designing the management ECU 30 so that the application's functions can be realized through the management ECU 30's processing, the application data can be stored in the management ECU 30's memory 30a rather than in the memory of the downstream ECU. Furthermore, since the management ECU 30 can communicate directly with the server 1 via the communication unit 10, when application updates or changes are anticipated, it is necessary to give the management ECU 30 the functions that can be realized by the application, thereby increasing the number of applications processed by the management ECU 30. To meet these needs, it is preferable to use a large-capacity recording medium for the memory 30a.

[0037] Furthermore, as the storage capacity of memory 30a increases, the amount of vehicle data transmitted and received between the vehicle and server 1 also increases. Therefore, in a communication network that wirelessly connects server 1 and multiple vehicles, if an attempt is made to send or receive a large amount of vehicle data during times of heavy communication load or in areas with heavy communication load, there is a possibility that the vehicle data may not be able to be sent to server 1.

[0038] Therefore, the management ECU 30 identifies the communication load of the wireless communication between the server 1 and the vehicle, and extracts vehicle data to send to the server 1 according to the communication load. The management ECU 30 may measure the communication speed and / or the amount of data transmitted during wireless communication in order to identify the communication load of the wireless communication. For example, the management ECU 30 connects to a base station on the communication network to enable wireless communication with the server 1 via a communication unit. The management ECU 30 may identify the current communication load by actually measuring the communication load from the strength of the radio waves emitted from the base station or the communication speed when connecting to the base station. Alternatively, the management ECU 30 may identify the communication load from the time of day when communicating with the server 1 or from the location information of the vehicle. For example, the communication load will be small when there are few vehicles communicating with the server 1, such as during late-night hours, or when there are few vehicles in the area centered on the base station. The management ECU 30 may store map data showing communication time period information and area information that indicates differences in the magnitude of the communication load in memory 30a, and identify the current communication load by referring to the map data.

[0039] The management ECU 30 may identify the communication load of wireless communication from past communication history. For example, when the management ECU 30 transmits vehicle data from the communication unit 11 to the server 1, it stores the transmission time and communication speed as communication history in memory 30a. The management ECU 30 may then identify time periods with high communication speeds as time periods with low communication loads from the communication history.

[0040] The management ECU 30 transmits vehicle data with an importance higher than the importance threshold (hereinafter also referred to as "first vehicle data") to the server 1 when the communication load is greater than a predetermined value, and transmits vehicle data to the server 1 that includes at least vehicle data with an importance of or less than the importance threshold (hereinafter also referred to as "second vehicle data") when the communication load is less than or equal to the predetermined value. The importance threshold is a threshold used to classify the importance of the data to be transmitted. The importance threshold may be changed according to the magnitude of the communication load, for example, or it may be a fixed value. For example, the importance threshold may be a variable value, such that the greater the communication load, the higher the importance threshold. In other words, when the management ECU 30 transmits vehicle data during a time when the communication load is greater than a predetermined value, it transmits vehicle data with high importance and does not transmit vehicle data with low importance. On the other hand, when the management ECU 30 transmits vehicle data during a time when the communication load is less than or equal to the predetermined value, it controls the communication unit 11 to transmit vehicle data that includes not only high-importance data but also low-importance data.

[0041] The importance of vehicle data represents the importance of the data stored in memory 30a that should be uploaded to server 1 as quickly as possible. The importance of vehicle data is determined by the vehicle's condition, functions, etc. For example, if the battery is degraded, the importance of battery information will be higher than the importance of battery information in its initial state. Also, if some in-vehicle equipment is diagnosed as potentially malfunctioning, the importance of the vehicle data for the diagnosed in-vehicle equipment will be higher than the importance of other normal in-vehicle equipment. The diagnosis may be performed by the remote diagnosis described above or by the vehicle's self-diagnosis. Furthermore, if a vehicle warning light is displayed, the importance of the vehicle data for the in-vehicle equipment that caused the warning light to be displayed will be higher. In addition, the importance of vehicle data for in-vehicle equipment related to basic vehicle driving functions such as steering, engine, and motor will be higher than the importance of in-vehicle equipment such as seat heaters and reading lights.

[0042] For example, the management ECU 30 stores a map in memory 30a that associates the type of vehicle data with its importance level. When transmitting vehicle data, if the current communication load is high, the management ECU 30 extracts the first vehicle data assigned to an importance level higher than the importance threshold on the map from the vehicle data (recorded data) in memory 30a. The second vehicle data is not extracted. If the importance level is set in multiple stages, the vehicle data is extracted in order from the highest importance level. The management ECU 30 then controls the communication unit 11 to transmit the extracted vehicle data to the server 1.

[0043] The management ECU 30 may adjust the importance level on the map according to the status of the in-vehicle equipment and vehicle load. For example, if the battery is degrading, there is a possibility of an abnormality in the in-vehicle equipment, or a vehicle warning light is displayed, the importance level may be adjusted so that the importance of the vehicle data for the relevant in-vehicle equipment or load increases. The importance level may also be adjusted according to a command from the server control unit 2. For example, if the server 1 is collecting vehicle data in a way that collects a lot of information about the battery installed in the vehicle, the server control unit 2 will send an adjustment command to the vehicle to increase the importance of the battery information. The server control unit 2 may also send an adjustment command for each vehicle after specifying the type of vehicle data. For example, if the vehicle is used in a way that involves long periods of stopping after the vehicle's power switch is turned on, the battery may degrade quickly. Therefore, the battery control information may be adjusted by sending an adjustment command to the vehicle to increase the importance of the battery information according to the specified vehicle usage pattern. The management ECU 30 may then adjust the importance level according to the adjustment command from the server 1.

[0044] When the management ECU 30 transmits vehicle data, if the current communication load is low, it may extract the vehicle data stored in the memory 30a without performing data extraction according to importance. That is, if the data with high importance is not left in the memory 30a, the management ECU 30 will extract the second vehicle data whose importance is below the importance threshold. On the other hand, if the data with high importance remains in the memory 30a, the management ECU 30 will extract the first vehicle data and the second vehicle data. Then, the management ECU 30 controls the communication unit 11 to transmit the extracted vehicle data to the server 1.

[0045] As described above, in this embodiment, the ECU control system 1000 includes a management ECU 30 that stores the vehicle data acquired from the in-vehicle device in the memory 30a and transmits the vehicle data to the server 1 via the communication unit 11. The management ECU 30 identifies the communication load of the wireless communication. When the communication load is greater than a predetermined value, it transmits the first vehicle data to the server 1. When the communication load is below the predetermined value, it transmits the vehicle data including at least the second vehicle data to the server 1. Thereby, according to the communication load of the wireless communication between the vehicle and the server, the vehicle data with a large data volume can be transmitted to the server 1.

[0046] Also, in this embodiment, the server control unit 2 identifies the usage pattern of the vehicle based on at least one of the time information included in the vehicle data, the information indicating the running state of the vehicle, and the position information of the vehicle, determines a transmission schedule that defines the timing for transmitting the vehicle data from the vehicle to the server 1 according to the usage pattern, and notifies the vehicle of the transmission schedule. Thereby, according to the communication load of the wireless communication between the vehicle and the server, the vehicle data with a large data volume can be transmitted to the server 1.

[0047] Also, in the present embodiment, the server control unit 2 calculates the transmission priority of vehicle data for each of a plurality of vehicles based on at least one of the number of times of transmission of vehicle data, the transmission frequency, and the amount of vehicle data acquired from the vehicle, and determines a transmission schedule for each of the plurality of vehicles according to the transmission priority. Thereby, vehicle data with a large data amount can be transmitted to the server 1 according to the communication load of wireless communication between the plurality of vehicles and the server.

[0048] Also, in the present embodiment, the ECU control method executed by the management ECU 30 includes a step of specifying the communication load of wireless communication between the server 1 and the vehicle, a step of storing vehicle data acquired from in-vehicle devices in the memory 30a, and a transmission step of transmitting the vehicle data to the server 1 via the communication unit 11. And the transmission step includes a step of transmitting first vehicle data whose importance is higher than the importance threshold to the server when the communication load is greater than a predetermined value, and a step of transmitting vehicle data including at least second vehicle data whose importance is less than or equal to the importance threshold to the server when the communication load is less than or equal to the predetermined value.

[0049] Note that in the present embodiment, the server control unit 2 does not necessarily determine the transmission schedule. In the present embodiment, the management ECU 30 extracts vehicle data to be transmitted to the server 1 according to the communication load and the importance of the vehicle data and transmits it to the server 1. By such control of the management ECU 30, it is possible to transmit a data amount according to the communication load. Further, the management ECU 30 may transmit to the server 1 via the communication unit 11 in accordance with the transmission schedule determined by the server control unit 2.

[0050] 1 Server 2 Server control unit 3 Database 10 Communication unit 30 Management ECU 30a Memory 40 VCM 40a Memory 50 ADCU 50a Memory 60 BCM 60a Memory 100 Vehicle control system 400 - 402, 500 - 502, 600 - 602 Bus 1000 ECU control system

Claims

1. An ECU control system comprising: a communication unit that performs wireless communication with a server; a management ECU that stores vehicle data acquired from in-vehicle equipment in memory and transmits the vehicle data to the server via the communication unit, wherein the management ECU identifies the communication load of the wireless communication, transmits first vehicle data whose importance is higher than an importance threshold to the server if the communication load is greater than a predetermined value, and transmits the vehicle data to the server, including at least second vehicle data whose importance is less than or equal to the importance threshold if the communication load is less than or equal to the predetermined value.

2. An ECU control system according to claim 1, comprising a server control unit provided on the server for collecting vehicle data, wherein the server control unit identifies the usage pattern of the vehicle based on at least one of the following pieces of information: time information, information indicating the driving state of the vehicle, and location information of the vehicle, determines a transmission schedule that defines the timing for transmitting the vehicle data from the vehicle to the server in accordance with the usage pattern, and notifies the vehicle of the transmission schedule.

3. An ECU control system according to claim 2, wherein the server control unit calculates a transmission priority for the vehicle data for each of the multiple vehicles based on at least one of the number of transmissions of the vehicle data, the transmission frequency, and the amount of vehicle data acquired from the vehicle, and determines a transmission schedule for each of the multiple vehicles according to the transmission priority.

4. An ECU control method executed by a management ECU installed in a vehicle, comprising: a step of identifying the communication load of wireless communication between a server and a vehicle; a step of storing vehicle data acquired from an in-vehicle device in memory; and a transmission step of transmitting the vehicle data to the server via a communication unit, wherein the transmission step includes: if the communication load is greater than a predetermined value, transmitting first vehicle data whose importance is greater than an importance threshold to the server; and if the communication load is less than or equal to the predetermined value, transmitting the vehicle data to the server, including at least second vehicle data whose importance is less than or equal to the importance threshold.

Citation Information

Patent Citations

  • Vehicle communication system

    JP2018090007A

  • Vehicle communication system and communication device

    JP2023167665A

  • Information provision system, server and information provision method

    WO2017199287A1