Vehicle communication device and push server

Abstract

To make it possible to appropriately receive push data transmitted from a push server without the push server continuously re-trying transmission of the push data.SOLUTION: Because of a push server 3 receiving a push data transmission request from an application server 2, when an in-vehicle communication apparatus 4 receives push data from the push server, the in-vehicle communication apparatus transmits the received push data to an in-vehicle ECU 5. The in-vehicle communication apparatus 4 includes: a reset executable determination unit 4a that determines whether reset is executable; and a during-reset information notification unit 4b that, when it is determined that reset is executable, associates during-reset information indicating that reset is in progress with apparatus identification information that can identify its own apparatus, and notifies the push server, before starting to execute the reset.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an in-vehicle communication device and a push server. [Background technology]

[0002] A push system that transmits push data is provided as one of the remote request services for accessing an application of an in-vehicle system from outside the vehicle. The push system includes an application server and a push server on the cloud side, and an in-vehicle communication device and an in-vehicle electronic control unit (hereinafter referred to as an in-vehicle ECU (Electronic Control Unit)) on the vehicle side. When an application on the cloud side is launched by, for example, a smartphone terminal, the push server receives a request to transmit push data from the application server, and transmits the push data to the in-vehicle communication device. The in-vehicle communication device transmits the push data transmitted from the push server to the in-vehicle ECU, and transmits the push data to an application on the in-vehicle system side that is installed in the in-vehicle ECU (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2019-192953 Summary of the Invention [Problem to be solved by the invention]

[0004] An in-vehicle communication device that transmits push data received from a push server to an in-vehicle ECU needs to be reset for purposes such as software updates, state recovery, and memory cleanup. While the in-vehicle communication device is resetting, it is unable to communicate data with the push server. This state remains inactive until the in-vehicle communication device completes startup and establishes a connection to the push server. From outside the vehicle, this state is perceived only as an offline state where data communication is not possible between the in-vehicle communication device and the push server. In other words, the push server cannot determine whether the inability to communicate data is temporary because the in-vehicle communication device is resetting, or whether the inability to communicate data is due to some kind of abnormality. Therefore, if an application server sends a push data transmission request to the push server while the in-vehicle communication device is resetting, the push server will continue to fail to transmit the push data and will continue to retry until the in-vehicle communication device completes startup and establishes a connection to the communication line.

[0005] The present invention has been made in consideration of the above-mentioned circumstances, and its object is to provide an in-vehicle communication device that can properly receive push data transmitted from a push server without the push server continuously retrying to transmit the push data, and a push server that can properly transmit push data to the in-vehicle communication device. [Means for solving the problem]

[0006] According to the in-vehicle communication device (4) described in claim 1, when the push server receives a push data transmission request from the application server, the in-vehicle communication device (4) transmits the received push data from the push server to the in-vehicle electronic control device. Based on the operating state of the aircraft If it is determined that the reset is executable, the resetting information notification unit (4b) notifies the push server of resetting information indicating that the reset is in progress, in association with device identification information that can identify the device itself, before starting the resetting.

[0007] Based on the operating state of the aircraft If it is determined that a reset can be performed, before starting the reset, resetting information indicating that a reset is in progress is associated with the device identification information and notified to the push server. By notifying the push server of the resetting information in association with the device identification information, the push server can identify that the in-vehicle communication device identified by the device identification information is in the process of resetting, and can suspend transmission of push data until the in-vehicle communication device completes startup and reconnects the communication line. In other words, the push server can avoid continuous failures in sending push data and continuous retries to send the push data. This allows the push server to properly receive push data from the push server without the push server continuously retrying to send the push data.

[0008] According to the push server (3) of claim 6, when a push data transmission request is received from the application server, the push server (3) transmits the push data to the in-vehicle communication device and Based on the operating state of the in-vehicle communication device When the in-vehicle communication device executes a reset, the communication line between the in-vehicle communication device and the in-vehicle communication device is disconnected. The resetting information setting unit (3a) sets resetting information indicating that the in-vehicle communication device is being reset, in association with the in-vehicle communication device that notified the resetting information. When the resetting information determination unit (3b) receives a push data transmission request from the application server, it determines whether resetting information has been set in association with the in-vehicle communication device that is the destination of the push data. When it is determined that resetting information has been set, the transmission suspension unit (3c) suspends the transmission of the push data and waits for completion of reconnection of the communication line that was disconnected when the in-vehicle communication device executed the reset. When completion of reconnection of the communication line is achieved, the information transmission unit (3d) releases the suspension of transmission of the push data and transmits the suspended push data to the in-vehicle communication device.

[0009] When a push data transmission request is received from the application server, if resetting information is set in association with the in-vehicle communication device to which the push data is to be transmitted, the transmission of the push data is suspended and the in-vehicle communication device Based on the operating state of the in-vehicle communication device The device waits for the communication line that was disconnected when the device executed a reset to be reconnected. When the communication line is reconnected, the hold on transmission of the push data is released, and the held push data is sent to the in-vehicle communication device. By holding off the transmission of the push data while the in-vehicle communication device is being reset, it is possible to prevent the push server from continuing to fail to send the push data until the in-vehicle communication device has completed startup and reconnected the communication line, and it is also possible to prevent the push server from continuing to retry sending the push data. This allows the push data to be sent appropriately to the in-vehicle communication device. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 shows the overall configuration of a push system according to a first embodiment. [Figure 2] Functional block diagram of the in-vehicle communication device and push server [Figure 3] Sequence diagram [Figure 4] Sequence diagram showing the second embodiment [Figure 5] Sequence diagram showing the second embodiment [Figure 6] Sequence diagram showing the second embodiment [Figure 7] FIG. 10 is a functional block diagram of an in-vehicle communication device and a push server according to a third embodiment. [Figure 8] Sequence diagram [Figure 9] Sequence diagram showing the fourth embodiment [Figure 10] Sequence diagram showing the fifth embodiment [Figure 11] Sequence diagram showing the fifth embodiment [Figure 12] Sequence diagram showing the sixth embodiment [Figure 13]Sequence diagram showing the seventh embodiment DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, several embodiments will be described with reference to the drawings. Descriptions of parts common to several embodiments may be omitted. (First embodiment) A first embodiment will be described with reference to Fig. 1 to Fig. 3. The push system 1 shown in Fig. 1 includes an application server 2 and a push server 3 provided on the cloud side, and an in-vehicle communication device 4 and an in-vehicle ECU 5 provided on the vehicle side. The in-vehicle ECU 5 is equipped with an in-vehicle system application 6 for implementing a remotely requested service. The push system 1 is a system that enables the transmission of push data from the application server 2 to the in-vehicle system application 6 when a cloud-side application is launched by, for example, a smartphone terminal.

[0012] For example, when a user launches an application on a smartphone terminal to remotely start the air conditioner before getting in the car or lock the doors after getting in the car and performs a specified operation, a request to send push data instructing the user to start the air conditioner or lock the doors is sent from the application server 2 to the push server 3, and the push data is sent to the in-vehicle ECU 5 via the in-vehicle communication device 4, and then transmitted to the application 6 on the in-vehicle system side that realizes the start of the air conditioner, the locking of the doors, etc.

[0013] 1 illustrates a configuration in which one push server 3 is provided for multiple application servers 2 on the cloud side, but a configuration in which multiple push servers 3 are provided for multiple application servers 2 may also be used. Also, while a configuration in which one in-vehicle communication device 4 is provided for multiple in-vehicle ECUs 5 on the vehicle side is illustrated, a configuration in which multiple in-vehicle communication devices 4 are provided for multiple in-vehicle ECUs 5 may also be used.

[0014] The push system 1 employs an automotive wireless communication platform 7. The automotive wireless communication platform 7 is realized by an ACP cloud 8 on the cloud side and an ACP engine 9 on the vehicle side, enabling a secure connection between the application server 2 and the application 6 anytime, anywhere. Specifically, the in-vehicle ECU 5 is powered off when the vehicle is parked, for example, and the power supply states vary from vehicle to vehicle. Furthermore, the system configurations including the in-vehicle ECU 5 differ from vehicle to vehicle. The automotive wireless communication platform 7 conceals these differences in the power supply states of the in-vehicle ECU 5 and the system configurations of each vehicle from the application server 2. As a result, a pseudo-constant connection can be realized, as if all the in-vehicle ECUs 5 on a vehicle-by-vehicle basis were constantly connected to an external network.

[0015] The cloud-side system and the vehicle-side in-vehicle system on which the automotive wireless communication platform 7 is installed will be described below. (1) Cloud system First, the in-vehicle system on the vehicle side will be described. The application server 2 is a server that functions as a sender of a push data transmission request. The application server 2 manages at least one of an application ID and a token that identify the application 6. When the application server 2 sends a push data transmission request to the push server 3, it provides the application ID or the token as request information along with the message body to be sent to the application 6. When the application server 2 uses a token as request information, it reads out the token associated with the destination of the push data. The token is key information that determines the destination of the push data in the push server 3, the in-vehicle system, etc.

[0016] The push server 3 is a sender of push data and includes the configuration of an ACP cloud 8 that implements cloud-side functions of the automotive wireless communication platform 7. The push server 3 mainly comprises a microcontroller having a processor 10, a RAM 11, and a storage medium 12. The push server 3 executes a control program stored in the storage medium 12 by the processor 10 to perform various operations and implements cloud-side functions of the automotive wireless communication platform 7.

[0017] The push server 3 connects a communication line for wireless communication via a mobile communication network with the in-vehicle communication device 4, and is capable of transmitting push data to the in-vehicle communication device 4 while the communication line is connected. Mobile communication networks include, for example, a mobile phone network, Wi-Fi (registered trademark), and V2X (Vehicle-to-Anything). When the push server 3 receives a request to transmit push data from the application server 2, it selects an in-vehicle communication device 4 as a destination of the push data, and transmits the push data to the in-vehicle communication device 4 selected as the destination.

[0018] The push server 3 provides functions such as authenticating the communication partner, encrypting the communication content, and detecting tampering using TLS (Transport Layer Security) processing, and also provides functions for data communication using TCP / IP, UDP / IP, and other protocols, enabling secure data communication between the application server 2 and the in-vehicle communication device 4.

[0019] The push server 3 can retry sending the push data within a predetermined time period. When sending push data, there are situations where an immediate response from the in-vehicle system is required, and situations where it is sufficient for the push data to reach the notification destination, and a retry deadline is set according to the required response. If the push server 3 fails to send the push data, it retries to send the push data within a predetermined time period before the retry deadline, which is set according to the content of the push data. If the retry deadline has passed without the push data being sent successfully, the push server 3 determines that the push data transmission has failed and ends the retry attempts to send the push data.

[0020] (2) On-board system on the vehicle side Next, the vehicle-side in-vehicle system will be described. The in-vehicle communication device 4 is called a TCU (Telematics Control Unit) or DCM (Data Communication Module), and is the destination of push data. It includes the configuration of an ACP engine 9 that implements the vehicle-side functions of the automotive wireless communication platform 7. The in-vehicle communication device 4 mainly comprises a microcontroller having a processor 13, RAM 14, and storage medium 15. The in-vehicle communication device 4 executes various operations by using the processor 13 to execute control programs stored in the storage medium 15, thereby implementing the vehicle-side functions of the automotive wireless communication platform 7.

[0021] The in-vehicle communication device 4 is connected to a plurality of in-vehicle ECUs 5 via an in-vehicle network. Examples of the in-vehicle network include Ethernet (registered trademark), CAN (Controller Area Network) (registered trademark), FLEXRAY (registered trademark), CXPI (Clock Extension Peripheral Interface) (registered trademark), and LIN (Local Interconnect Network). An in-vehicle network is provided for each system, such as a powertrain system, a chassis system, a body system, a multimedia system, and a safety system.

[0022] The in-vehicle communication device 4 connects a communication line for wireless communication via a mobile communication network with the push server 3, and can receive push data from the in-vehicle communication device 4 while the communication line is connected. When the in-vehicle communication device 4 receives push data from the push server 3, it selects an in-vehicle ECU 5 as a transmission destination and transmits the push data to the in-vehicle ECU 5 selected as the transmission destination.

[0023] The in-vehicle communication device 4 provides functions such as authentication of the communication partner, encryption of communication content, and tamper detection through TLS processing, etc., as well as functions for data communication using TCP / IP, UDP / IP, and other protocols. Secure data communication may be possible between the in-vehicle communication device 4 and the push server 3, and between the in-vehicle communication device 4 and the in-vehicle ECU 5.

[0024] The in-vehicle communication device 4 can maintain an online state connected to the communication network even when the main power supply of the vehicle is off, specifically, when the so-called ignition is off, for example, while the vehicle is parked. The in-vehicle communication device 4 monitors the connection state with the push server 3 via wireless communication and the progress state of push data transmission in the in-vehicle network. The in-vehicle communication device 4 cooperates with the push server 3 to enable interconnection confirmation between the in-vehicle communication device 4 and the push server 3. The interconnection confirmation between the in-vehicle communication device 4 and the push server 3 is sometimes referred to as alive monitoring.

[0025] If the push data does not reach the destination, the in-vehicle communication device 4 notifies the sender of the failure to send the push data together with reason information associated with the failure. For example, if the application 6 or the in-vehicle ECU 5 to which the push data is to be sent does not exist on the in-vehicle network, the in-vehicle communication device 4 notifies the sender of the failure to send the push data, associated with such reason information, to the push server 3.

[0026] The in-vehicle communication device 4 identifies destination information and status information as ECU information related to the in-vehicle ECU 5 to which the push data is to be sent. The destination information is sometimes referred to as destination information. The destination information is information that can identify the in-vehicle ECU 5 to which the push data is to be sent from among multiple in-vehicle ECUs 5. The in-vehicle communication device 4 acquires the destination information by referencing an application ID or a token. The status information is information that can identify the power state (on / off state) of the in-vehicle ECU 5 identified as the destination. More specifically, the power-off state here refers to a state in which the in-vehicle ECU 5 has transitioned from an activated state to a hibernation state, for example, due to the ignition being turned off. In this state, the in-vehicle ECU 5 can receive a startup request with low power consumption, but is unable to communicate data. If the in-vehicle ECU 5 identified as the destination based on the status information is in a power-off state, the in-vehicle communication device 4 performs startup processing to activate the in-vehicle ECU 5 and turn its power on (activated state).

[0027] The in-vehicle ECU 5 is equipped with one or more applications 6 and is capable of executing the applications. The in-vehicle ECU 5 mainly comprises a microcontroller having a processor (not shown), RAM (not shown), and a storage medium (not shown). The in-vehicle ECU 5 performs various operations by executing a control program stored in the storage medium with the processor, and operates as an end ECU that is the final destination of push data transmitted from the push server 3. When the in-vehicle ECU 5 receives push data transmitted from the in-vehicle communication device 4, the in-vehicle ECU 5 identifies registration information that matches the application ID or token associated with the push data, identifies an application 6 from among the multiple applications 6 that is to be the destination of the push data, and transmits the push data to the application 6 identified as the destination.

[0028] The in-vehicle ECU 5 provides a cryptographic processing function and enables secure data communication between the in-vehicle communication device 4 and the application 6. Unlike the in-vehicle communication device 4, the in-vehicle ECU 5 is generally turned off when the vehicle power is off to reduce power consumption. At this time, the in-vehicle ECU 5 is also disconnected from the communication network. Note that some of the in-vehicle ECUs 5 may not be equipped with the application 6. Furthermore, the in-vehicle communication device 4 may be provided in the in-vehicle system as a configuration that also functions as the in-vehicle ECU 5, and may be capable of being equipped with the application 6.

[0029] In the above configuration, as mentioned above, the in-vehicle communication device 4 needs to be reset periodically for purposes such as software update, state restoration, memory cleanup, etc. However, if the application server 2 sends a push data transmission request to the push server 3 while the in-vehicle communication device 4 is reset, the push server 3 will continue to fail to transmit the push data and will continue to retry transmitting the push data until the in-vehicle communication device 4 completes startup and completes connection of the communication line. In this regard, in this embodiment, the in-vehicle communication device 4 and the push server 3 each have the following functions.

[0030] 2, the vehicle-mounted communication device 4 includes a reset execution possibility determination unit 4a and a resetting flag notification unit 4b. The resetting flag notification unit 4b corresponds to a resetting information notification unit.

[0031] When a request event such as software update, state restoration, or memory cleanup occurs, the reset execution possibility determination unit 4a determines whether a reset can be executed by determining the operating state at that time. For example, if the reset execution possibility determination unit 4a determines that data communication with the in-vehicle ECU 5 is not in progress and that executing a reset will not cause any problems, it determines that a reset can be executed. On the other hand, if the reset execution possibility determination unit 4a determines that data communication with the in-vehicle ECU 5 is in progress and that executing a reset may cause problems such as data loss or data omission, it determines that a reset cannot be executed.

[0032] When the reset execution possibility determination unit 4a determines that the reset is executable, the reset in progress flag notification unit 4b notifies the push server 3 of the reset in progress flag, which indicates that the reset is in progress, before starting the reset execution, in association with a device ID that can identify the in-vehicle communication device 4. The device ID corresponds to device identification information.

[0033] The push server 3 includes a resetting flag setting unit 3a, a resetting flag determination unit 3b, a transmission suspension unit 3c, and an information transmission unit 3d. The resetting flag setting unit 3a corresponds to the resetting information setting unit, and the resetting flag determination unit 3b corresponds to the resetting information determination unit.

[0034] When a resetting flag is notified from an in-vehicle communication device 4, the resetting flag setting unit 3a identifies the in-vehicle communication device 4 that notified the resetting flag based on the device ID associated with the resetting flag, and sets the resetting flag in association with the in-vehicle communication device 4 that notified the resetting flag.

[0035] When the resetting flag determining unit 3b receives a request to send push data from the application server 2, it determines whether or not a resetting flag is set in association with the in-vehicle communication device 4 that is the destination of the push data.

[0036] When the reset flag determination unit 3b determines that a reset flag is set in association with the vehicle-mounted communication device 4 to which the push data is to be sent, the transmission suspension unit 3c suspends the sending of the push data and waits for the completion of reconnection of the communication line that was disconnected when the vehicle-mounted communication device 4 executed the reset.

[0037] When the reconnection of the communication line is completed, the information transmitting unit 3d releases the hold on transmission of the push data by the transmission holding unit 3c, and transmits the hold on the push data to the vehicle-mounted communication device 4.

[0038] The operation of the above configuration will be described with reference to FIG. When a request event such as software update, state restoration, or memory cleanup occurs, the in-vehicle communication device 4 determines whether a reset can be performed by determining the operating state at that time. If the in-vehicle communication device 4 determines that a reset can be performed (A1), it notifies the push server 3 of a resetting flag (S1). When the push server 3 is notified of the resetting flag from the in-vehicle communication device 4, it sets the resetting flag in association with the in-vehicle communication device 4 that is the sender of the resetting flag (B1). After notifying the push server 3 of the resetting flag, the in-vehicle communication device 4 disconnects the communication line connected to the push server 3 (A2) and performs the reset (A3).

[0039] Here, when the push server 3 receives a request to send push data sent from the application server 2 (S2), it determines whether a resetting flag has been set in association with the in-vehicle communication device 4 that is the destination of the push data. When the push server 3 determines that a resetting flag has been set in association with the in-vehicle communication device 4 that is the destination of the push data (B2), it suspends the transmission of the push data (S3). The push server 3 waits for the completion of reconnection of the communication line that was disconnected when the in-vehicle communication device 4 that is the destination of the push data executed a reset (B3). In other words, by suspending the transmission of the push data, the push server 3 does not treat the transmission of the push data as a failure even if the communication line with the in-vehicle communication device 4 that is the destination of the push data is not connected.

[0040] When the in-vehicle communication device 4 completes the reset and startup (A4), it reconnects the communication line that was disconnected with the push server 3 (A5). When the push server 3 determines that the communication line has been reconnected, it releases the hold on transmission of the push data (B4) and transmits the hold on the push data to the in-vehicle communication device 4 (S3). When the in-vehicle communication device 4 receives the push data transmitted from the push server 3, it transmits the received push data to the in-vehicle ECU 5 (S4). When the push server 3 determines that transmission of the push data to the in-vehicle communication device 4 has been completed (B5), it notifies the application server 2 of a transmission completion notification (S5). When the in-vehicle ECU 5 receives the push data transmitted from the in-vehicle communication device 4, it transmits the push data to the application 6 corresponding to the push data, activates the application 6, and controls the remote request service corresponding to the push data.

[0041] As described above, the first embodiment provides the following advantageous effects. When the in-vehicle communication device 4 determines that a reset can be performed, it notifies the push server 3 of a resetting flag associated with the device ID before starting the reset. By notifying the push server 3 of the resetting flag associated with the device ID, the push server 3 can identify that the in-vehicle communication device 4 identified by the device ID is being reset, and can suspend transmission of push data until the in-vehicle communication device 4 completes startup and reconnects the communication line. In other words, the push server 3 can avoid continuous failures in sending push data and continuous retries to send the push data. This allows the push server 3 to properly receive push data from the push server 3 without the push server 3 continuously retrying to send the push data.

[0042] When the push server 3 receives a push data transmission request from the application server 2, if a resetting flag is set in association with the in-vehicle communication device 4 to which the push data is to be transmitted, the push server 3 suspends transmission of the push data and waits for the reconnection of the communication line that was disconnected when the in-vehicle communication device 4 executed the reset. When the reconnection of the communication line is completed, the hold on transmission of the push data is released and the held push data is transmitted to the in-vehicle communication device 4. By the push server 3 suspending transmission of the push data while the in-vehicle communication device 4 is being reset, it is possible to avoid the push server 3 continuing to fail to transmit the push data until the in-vehicle communication device 4 completes startup and completes connection of the communication line, and it is also possible to avoid the push server 3 continuing to retry transmitting the push data. This allows the push data to be transmitted appropriately to the in-vehicle communication device 4.

[0043] (Second embodiment) The second embodiment will be described with reference to Figures 4 to 6. In the in-vehicle communication device 4, before starting execution of a reset, the reset information notification unit 4b notifies the push server 3 of a resetting flag indicating that a reset is in progress, and also notifies the push server 3 of time information indicating an estimated time until reconnection of the communication line is completed or time information indicating an estimated time at which reconnection is completed.

[0044] When the in-vehicle communication device 4 determines that a reset can be performed (A1), it notifies the push server 3 of a resetting flag (S1) and notifies the push server 3 of time information or time information (S11). When the push server 3 is notified of the resetting flag from the in-vehicle communication device 4, it sets the resetting flag in association with the in-vehicle communication device 4 that is the sender of the resetting flag (B1), and when the in-vehicle communication device 4 notifies it of the time information or time information, it stores the notified time information or time information (B11).

[0045] In this case, when the push server 3 receives a request to send push data from the application server 2 while the resetting flag is set and determines that the resetting flag is set in association with the in-vehicle communication device 4 to which the push data is to be sent (B2), it determines whether the scheduled time or scheduled time has arrived based on the stored time information or time information (B12).If the push server 3 determines that the scheduled time or scheduled time has not arrived (B12: NO), it notifies the application server 2 of a transmission pending response (S12) and suspends the transmission of the push data (B3).

[0046] On the other hand, if the push server 3 determines that the scheduled time has arrived or that the scheduled time has passed, it notifies the application server 2 of a transmission failure response (S13), releases the hold on the transmission of the push data (B4), and stops waiting for the completion of reconnection of the communication line that was disconnected when the in-vehicle communication device 4, the destination of the push data, executed a reset. In other words, by releasing the hold on the transmission of the push data, the push server 3 processes the failure of the transmission of the push data as a result of the communication line not being connected to the in-vehicle communication device 4, the destination of the push data.

[0047] As described above, according to the second embodiment, the push server 3 can accurately determine that the offline state is temporary by receiving time information or time-of-day information from the in-vehicle communication device 4. Furthermore, it is possible to appropriately deal with the fact that the time required for resetting differs for each in-vehicle communication device 4.

[0048] (Third embodiment) The third embodiment will be described with reference to Fig. 7 and Fig. 8. As shown in Fig. 7, the in-vehicle communication device 4 includes a reset execution possibility determination unit 4a, a reset in-progress flag notification unit 4b, a reset execution reservation unit 4c, and a reset execution reservation release unit 4d.

[0049] The reset execution reservation unit 4c reserves the execution of the reset when a reset execution reservation request is notified from the push server 3. The reset execution reservation release unit 4d releases the reservation of the reset when a certain time has passed since the execution of the reset was reserved, or when a reset execution reservation release request is notified from the push server 3.

[0050] The push server 3 includes a reset flag setting unit 3a, a reset flag determination unit 3b, a transmission hold unit 3c, an information transmission unit 3d, as well as a schedule presence / absence determination unit 3e, a reset execution hold request notification unit 3f, and a reset execution hold request release notification unit 3g.

[0051] The schedule presence / absence determination unit 3e determines whether or not there is a schedule to transmit the push data within a predetermined time. When the schedule presence / absence determination unit 3e determines that there is a schedule to transmit the push data within the predetermined time, the reset execution hold request notifying unit 3f notifies the in-vehicle communication device 4 of a reset execution hold request. The reset execution hold request release notifying unit 3g notifies the in-vehicle communication device 4 of a reset execution hold release request.

[0052] The operation of the above configuration will be described with reference to FIG. When the push server 3 receives a resetting flag from the in-vehicle communication device 4, it sets the resetting flag in association with the in-vehicle communication device 4 that sent the resetting flag (B1), and determines whether or not there is a plan to transmit push data within a predetermined time (B21). If the push server 3 determines that there is a plan to transmit push data within the predetermined time (B21: YES), it notifies the in-vehicle communication device 4 of a reset execution suspension request (S21).

[0053] When the in-vehicle communication device 4 receives a request to suspend the execution of the reset from the push server 3, the in-vehicle communication device 4 suspends the execution of the reset (A21), monitors the time that has elapsed since the execution of the reset was suspended, and determines whether or not the time that has elapsed since the execution of the reset was suspended has reached a certain time (A22).

[0054] If the push server 3 receives a request to send push data from the application server 2 before a certain period of time has elapsed since the execution of the reset was suspended in the in-vehicle communication device 4 (S22), the push server 3 transmits the push data to the in-vehicle communication device 4 (S23) because the execution of the reset is suspended in the in-vehicle communication device 4. When the in-vehicle communication device 4 receives the push data transmitted from the push server 3, the in-vehicle communication device 4 transmits the received push data to the in-vehicle ECU 5 (S24).

[0055] When the in-vehicle communication device 4 determines that a certain time has elapsed since the execution of the reset was suspended (A22: YES), it releases the suspension of the execution of the reset (A23), disconnects the communication line connected to the push server 3 (A2), and executes the reset (A3). After this, the same processing as in the first embodiment is performed.

[0056] As described above, according to the third embodiment, the push server 3 sets the resetting flag, but if it determines that the push data is scheduled to be transmitted within a predetermined time, it notifies the in-vehicle communication device 4 of a reset execution suspension request, thereby making it possible to transmit the push data to the in-vehicle communication device 4 before the in-vehicle communication device 4 executes the reset. Furthermore, when a certain time has elapsed since the execution of the reset was suspended, the in-vehicle communication device 4 can execute the reset.

[0057] (Fourth embodiment) The fourth embodiment will be described with reference to FIG. When the push server 3 determines that the push data is scheduled to be sent within a predetermined time (B21: YES), it notifies the vehicle-mounted communication device 4 of a reset execution hold request (S21), and when a certain time has elapsed since notifying the vehicle-mounted communication device 4 of the reset execution hold request, it notifies the vehicle-mounted communication device 4 of a reset execution hold release request (S25).

[0058] If the push server 3 receives a request to send push data from the application server 2 before notifying the in-vehicle communication device 4 of the request to release the pending reset execution (S22), the in-vehicle communication device 4 has pending the execution of the reset, so the push server 3 sends the push data to the in-vehicle communication device 4 (S23). If the in-vehicle communication device 4 receives the push data sent from the push server 3, the in-vehicle communication device 4 sends the received push data to the in-vehicle ECU 5 (S24).

[0059] When the in-vehicle communication device 4 receives the request to release the pending reset execution from the push server 3, it releases the pending reset execution (A23), disconnects the communication line connected to the push server 3 (A2), and executes the reset (A3). After this, the same processing as in the first embodiment is performed.

[0060] As described above, according to the fourth embodiment, as in the third embodiment, the push server 3 sets a reset in progress flag, but when it determines that push data is scheduled to be transmitted within a predetermined time, it notifies the in-vehicle communication device 4 of a reset execution suspension request, thereby making it possible to transmit the push data to the in-vehicle communication device 4 before the in-vehicle communication device 4 executes the reset. Also, by the push server 3 notifying the in-vehicle communication device 4 of the reset execution suspension request, the in-vehicle communication device 4 can execute the reset.

[0061] (Fifth embodiment) The fifth embodiment will be described with reference to FIGS. When the in-vehicle communication device 4 receives a request to release the pending reset execution from the push server 3, it releases the pending reset execution (A23), and when it determines that the reset can be executed (A1), it notifies the push server 3 of a resetting flag (S1). When the push server 3 receives the resetting flag from the in-vehicle communication device 4, it sets the resetting flag in association with the in-vehicle communication device 4 that is the sender of the resetting flag (B1). After notifying the push server 3 of the resetting flag, the in-vehicle communication device 4 disconnects the communication line connected to the push server 3 (A2), and executes the reset (A3).

[0062] As described above, according to the fifth embodiment, when the vehicle-mounted communication device 4 determines that the reset can be executed after canceling the pending execution of the reset, it can notify the push server 3 of the reset in progress flag.

[0063] (Sixth embodiment) The sixth embodiment will be described with reference to FIG. The push server 3 determines whether or not there is a plan to transmit the push data within a predetermined time (B31). If the push server 3 determines that there is no plan to transmit the push data within the predetermined time (B31: NO), it sets a resetting flag (B1) and notifies the in-vehicle communication device 4 of a reset execution request (S31).

[0064] When the in-vehicle communication device 4 receives a reset execution request from the push server 3, it determines whether or not the reset can be executed, and if it determines that the reset can be executed (A1), it disconnects the communication line connected to the push server 3 (A2) and executes the reset (A3). After this, the same processing as in the first embodiment is performed.

[0065] As described above, according to the sixth embodiment, the push server 3 notifying the in-vehicle communication device 4 of a reset execution request can trigger the in-vehicle communication device 4 to execute a reset.

[0066] (Seventh embodiment) The seventh embodiment will be described with reference to Fig. 13. The push server 3 determines whether or not there is a plan to transmit push data within a predetermined time (B31). If the push server 3 determines that there is no plan to transmit push data within the predetermined time (B31: NO), it notifies the in-vehicle communication device 4 of a reset execution request (S31).

[0067] When the in-vehicle communication device 4 is notified of a reset execution request from the push server 3, it determines whether or not the reset is executable, and if it determines that the reset is executable (A1), it notifies the push server 3 of a resetting flag (S1). When the push server 3 is notified of the resetting flag from the in-vehicle communication device 4, it sets the resetting flag in association with the in-vehicle communication device 4 that is the sender of the resetting flag (B1). After notifying the push server 3 of the resetting flag, the in-vehicle communication device 4 disconnects the communication line connected to the push server 3 (A2) and executes the reset (A3). From this point on, the same processing as in the first embodiment is performed.

[0068] As described above, according to the seventh embodiment, similar to the sixth embodiment, the in-vehicle communication device 4 can execute a reset when the push server 3 notifies the in-vehicle communication device 4 of a reset execution request.

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

[0070] In the embodiment, each function provided by the push server 3 and the in-vehicle communication device 4 can be provided by software and hardware that executes the software, software only, hardware only, or a combination thereof. Furthermore, when such a function is provided by an electronic circuit as hardware, each function can also be provided by a digital circuit including a large number of logic circuits or an analog circuit.

[0071] The processor 10 of the push server 3 and the processor 13 of the in-vehicle communication device 4 each include at least one arithmetic core such as a CPU (Central Processing Unit). The processing circuit including each of the processors 10 and 13 may be mainly composed of an FPGA (Field-Programmable Gate Array) and an ASIC (Application-Specific Integrated Circuit).

[0072] The storage medium 12 of the push server 3 and the storage medium 15 of the in-vehicle communication device 4 each include a non-volatile storage medium. The form of each storage medium 12, 15 may be changed as appropriate. For example, each storage medium 12, 15 is not limited to being mounted on a circuit board, but may be provided in the form of a memory card or the like, and may be inserted into a slot to be electrically connected to the processing circuit of the push server 3 and the in-vehicle communication device 4. Furthermore, each storage medium 12, 15 may be an optical disk or a hard disk drive, etc., from which a program is copied.

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

[0074] In the drawing, 1 is a push system, 2 is an application server, 3 is a push server, 3a is a resetting flag setting unit (resetting information setting unit), 3b is a resetting flag determination unit (resetting information determination unit), 3c is a transmission hold unit, 3d is an information transmission unit, 3e is a schedule existence determination unit, 3f is a reset execution hold request notification unit, 3g is a reset execution hold request notification unit, 4 is an in-vehicle communication device, 4a is a reset execution possibility determination unit, 4b is a resetting flag notification unit (resetting information notification unit), 4c is a reset execution hold unit, 4d is a reset execution hold release unit, 5 is an in-vehicle ECU, and 6 is an application.

Claims

1. an in-vehicle communication device (4) that, when receiving push data from the push server in response to a request for sending push data from an application server, transmits the received push data to an in-vehicle electronic control device; A reset execution possibility determination unit (4a) for determining whether or not a reset can be executed based on an operating state of the own device; and a resetting in progress information notification unit (4b) that, when it is determined that a reset can be performed, notifies the push server of resetting in progress information indicating that a reset is in progress, before starting the reset execution, by associating the resetting in progress information with device identification information that can identify the vehicle-mounted communication device.

2. 2. The vehicle-mounted communication device according to claim 1, wherein the resetting information notification unit notifies the push server of the resetting information, and also notifies the push server of time information indicating a scheduled time until reconnection of the communication line is completed or time information indicating a scheduled time at which reconnection is completed.

3. 3. The vehicle-mounted communication device according to claim 1, further comprising a reset execution reservation unit (4c) that reserves the execution of the reset when a reset execution reservation request is notified from the push server.

4. 4. The vehicle-mounted communication device according to claim 3, further comprising a reset execution hold release section (4d) for releasing the hold of the reset execution when a certain time has elapsed since the hold of the reset execution.

5. 4. The vehicle-mounted communication device according to claim 3, further comprising a reset execution hold release unit (4d) that releases the hold on reset execution when a request to release the hold on reset execution is notified from the push server.

6. A push server (3) that, upon receiving a request to transmit push data from an application server, transmits the push data to an in-vehicle communication device, and disconnects a communication line between the in-vehicle communication device and the in-vehicle communication device as the in-vehicle communication device executes a reset based on an operation state of the in-vehicle communication device, a resetting information setting unit (3a) for setting resetting information indicating that the in-vehicle communication device is being reset in association with the in-vehicle communication device that is a source of the resetting information; a resetting information determination unit (3b) that, when receiving a request to transmit push data from the application server, determines whether or not resetting information is set in association with an in-vehicle communication device that is a transmission destination of the push data; a transmission suspension unit (3c) that suspends transmission of push data when it is determined that the resetting information is set, and waits for completion of reconnection of the communication line that was disconnected as a result of the in-vehicle communication device executing the reset; and an information transmitting unit (3d) that, when the communication line is reconnected, releases the hold on transmission of the push data and transmits the hold on the push data to the vehicle-mounted communication unit.

7. 7. The push server according to claim 6, wherein when the resetting information is notified from the vehicle-mounted communication device, the resetting information setting unit sets the resetting information in association with the vehicle-mounted communication device that has notified the resetting information.

8. the in-vehicle communication device is configured to suspend execution of the reset when a reset execution suspension request is notified from the push server; a schedule existence / non-existence determination unit (3e) for determining whether or not there is a schedule for transmitting push data within a predetermined time; 8. The push server according to claim 6, further comprising a reset execution hold request notifying unit (3f) that notifies the vehicle-mounted communication device of the reset execution hold request when it is determined that the push data is scheduled to be transmitted within a predetermined time.

9. the in-vehicle communication device is configured to release the hold of the reset execution when a request to release the hold of the reset execution is notified from the push server; The push server according to claim 8, further comprising a reset execution hold release request notification unit (3g) that notifies the vehicle-mounted communication device of the reset execution hold release request after the reset execution hold request notification unit notifies the vehicle-mounted communication device of the reset execution hold request.

Images