WO2023218910A1 - In-vehicle communication device and push server - Google Patents

Abstract

Upon receipt of push data from a push server (3) due to the push server receiving a request to transmit push data from an app server 2, an in-vehicle communication device (4) transmits the received push data to an in-vehicle ECU (5). The in-vehicle communication device comprises a reset execution possibility determination unit (4a) that determines whether a reset can be executed, and a reset-in-progress information notification unit (4b) that, if it is determined that a reset can be executed, notifies the push server of reset-in-progress information indicating that a reset is in progress in association with device identification information enabling self-identification of the device, the notification being performed before starting execution of the reset.

Description

In-vehicle communication device and push server Cross-reference of related applications

This application is based on Japanese Application No. 2022-079541 filed on May 13, 2022, and the contents thereof are incorporated herein.

The present disclosure relates to an in-vehicle communication device and a push server.

A push system that transmits push data is provided as one of the remote request services for accessing applications in the in-vehicle system from outside the vehicle. In the push system, an application server and a push server are provided on the cloud side, and an on-board communication device and an on-board electronic control unit (hereinafter referred to as an on-board ECU (Electronic Control Unit)) are provided on the vehicle side. When a cloud-side application is activated by, for example, a smartphone terminal, and a push data transmission request is received from the application server, the push server 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 installed in the in-vehicle ECU (for example, see Patent Document 1).

JP 2019-192953 Publication

The in-vehicle communication device that transmits the push data received from the push server to the in-vehicle ECU needs to be reset for the purpose of, for example, software update, state recovery, memory cleanup, etc. During the reset, the in-vehicle communication device is unable to communicate data with the push server, and continues to be in a state where it is unable to communicate data until the startup is completed and the communication line is connected to the push server. At this time, from outside the vehicle, it can only be recognized that data communication between the in-vehicle communication device and the push server is offline and data communication is not possible. In other words, the push server cannot recognize whether data communication is temporarily unavailable due to the in-vehicle communication device being reset, or whether data communication is disabled due to the occurrence of some kind of abnormality. Therefore, if the app server sends a request to send push data to the push server while the in-vehicle communication device is being reset, the push server will fail to send the push data until the in-vehicle communication device completes startup and completes the communication line connection. It will continue to retry sending push data.

The present disclosure aims to appropriately receive push data sent from a push server without the push server continuously retrying the transmission of push data, and to appropriately send push data to an in-vehicle communication device.

According to one aspect of the present disclosure, when the in-vehicle communication device receives push data from the push server as a result of the push server receiving a push data transmission request from the application server, the in-vehicle communication device transmits the received push data to the in-vehicle electronic control device. Send to device. The reset executable determination unit determines whether or not reset is executable. When it is determined that the reset can be executed, the resetting information notification unit sends the resetting information indicating that the reset is in progress to device identification information that can identify the device itself, before starting the reset. Correspond and notify the push server.

If it is determined that the reset is executable, the push server is notified of the resetting information indicating that the reset is in progress, in association with the device identification information, before starting the reset. By associating the resetting information with the device identification information and notifying the push server, the push server can identify that the in-vehicle communication device specified by the device identification information is being reset, and the in-vehicle communication device is Push data transmission can be stopped until startup is complete and the communication line is reconnected. That is, the push server can avoid continuing to fail in transmitting push data, and can avoid continuing to retry transmitting push data. Thereby, the push data can be appropriately received from the push server without the push server continuously retrying the transmission of the push data.

According to one aspect of the present disclosure, when the push server receives a push data transmission request from the application server, the push server transmits the push data to the in-vehicle communication device, and also transmits the push data to the in-vehicle communication device as the in-vehicle communication device executes a reset. The communication line with the machine will be disconnected. The resetting information setting unit sets resetting information indicating that the in-vehicle communication device is being reset in association with the in-vehicle communication device that is the notification source of the resetting information. Upon receiving a push data transmission request from the application server, the resetting information determination unit determines whether or not resetting information is set in association with the in-vehicle communication device to which the push data is transmitted. When it is determined that the resetting information is set, the transmission holding unit holds the transmission of push data and waits for the completion of reconnection of the communication line that was disconnected when the in-vehicle communication device executed the reset. do. When the reconnection of the communication line is completed, the information transmitter releases the pending transmission of the push data and transmits the push data whose transmission has been suspended to the in-vehicle communication device.

When a push data transmission request is received from the app server, if it is associated with the in-vehicle communication device that is the destination of the push data and reset information is set, the push data transmission is suspended and the in-vehicle communication device now waits for the reconnection of the communication line that was disconnected due to the reset being executed. When the communication line is reconnected, the push data transmission suspension is released and the push data whose transmission was suspended is sent to the in-vehicle communication device. By suspending push data transmission while the in-vehicle communication device is being reset, the push server will prevent the push server from continuing to fail in sending push data until the in-vehicle communication device completes startup and reconnects the communication line. This can prevent the push server from continually retrying to send push data. Thereby, push data can be appropriately transmitted to the on-vehicle communication device.

The above objects and other objects, features and advantages of the present disclosure will become more apparent from the following detailed description with reference to the accompanying drawings. The drawing is
FIG. 1 shows a first embodiment and is a diagram showing the overall configuration of a push system, FIG. 2 is a functional block diagram of the in-vehicle communication device and push server, FIG. 3 is a sequence diagram, FIG. 4 is a sequence diagram showing the second embodiment, FIG. 5 is a sequence diagram showing the second embodiment, FIG. 6 is a sequence diagram showing the second embodiment, FIG. 7 shows a third embodiment and is a functional block diagram of an in-vehicle communication device and a push server, FIG. 8 is a sequence diagram, FIG. 9 is a sequence diagram showing the fourth embodiment, FIG. 10 is a sequence diagram showing the fifth embodiment, FIG. 11 is a sequence diagram showing the fifth embodiment, FIG. 12 is a sequence diagram showing the sixth embodiment, FIG. 13 is a sequence diagram showing the seventh embodiment.

Hereinafter, a plurality of embodiments will be described with reference to the drawings. Descriptions of common parts in multiple embodiments may be omitted.
(First embodiment)
A first embodiment will be described with reference to FIGS. 1 to 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 on-vehicle communication device 4 and an on-vehicle ECU 5 provided on the vehicle side. The in-vehicle ECU 5 is equipped with an in-vehicle system application 6 for realizing a remote request service. The push system 1 is a system that allows push data to be transmitted from the application server 2 to the application 6 on the in-vehicle system when an application on the cloud side is activated by, for example, a smartphone terminal.

For example, when a user remotely starts an application such as starting the air conditioner before boarding or locking the doors after boarding the vehicle and performs a predetermined operation, the application server 2 sends a request to send push data instructing the user to start the air conditioner or lock the doors. The push data is sent to the push server 3, and the push data is sent to the on-vehicle ECU 5 via the on-board communication device 4, and is transmitted to the application 6 on the in-vehicle system side that starts the air conditioner, locks the doors, etc.

Although FIG. 1 illustrates a configuration in which one push server 3 is provided for multiple application servers 2 on the cloud side, multiple push servers 3 are provided for multiple application servers 2. It is also possible to have a configuration in which Furthermore, on the vehicle side, although a configuration in which one on-vehicle communication device 4 is provided for a plurality of on-board ECUs 5 is illustrated, a plurality of on-board communication devices 4 are provided for a plurality of on-board ECUs 5. It may be a configuration.

The push system 1 employs an automotive wireless communication platform 7. The functions of the automotive wireless communication platform 7 are realized by the ACP cloud 8 on the cloud side and the ACP engine 9 on the vehicle side, and enable secure connection between the application server 2 and the application 6 anytime and anywhere. To explain in detail, the on-vehicle ECU 5 is powered off when the vehicle is parked, for example, and the power states are different from each other. Furthermore, the system configurations including the on-vehicle ECU 5 are different in each vehicle. The automotive wireless communication platform 7 hides such differences in the power state of the in-vehicle ECU 5 and differences in the system configuration of each vehicle from the application server 2 side. As a result, it is possible to realize a pseudo constant connection as if all the in-vehicle ECUs 5 were always connected to the network outside the vehicle on a vehicle-by-vehicle basis.

The cloud-side system and vehicle-side in-vehicle system in which the automotive wireless communication platform 7 is installed will be described below.
(1) Cloud-side system First, the in-vehicle system on the vehicle side will be explained. The application server 2 is a server that functions as a push data transmission request source. The application server 2 manages at least one of an application ID and a token that identify the application 6. When transmitting a push data transmission request to the push server 3, the application server 2 provides the application ID or token as request information along with the message body to be transmitted to the application 6. When using a token as request information, the application server 2 reads the token associated with the destination of the push data. The token serves as key information for determining the destination of push data in the push server 3, in-vehicle system, and the like.

The push server 3 is a transmission source of push data, and includes the configuration of an ACP cloud 8 that realizes the functions of the cloud side of the automotive wireless communication platform 7. The push server 3 mainly includes 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 using the processor 10 to perform various operations, and realizes cloud-side functions of the automotive wireless communication platform 7.

The push server 3 connects a communication line with the in-vehicle communication device 4 through wireless communication via a mobile communication network, and can transmit push data to the in-vehicle communication device 4 while the communication line is connected. . Mobile communication networks include, for example, mobile phone networks, Wi-Fi (registered trademark), V2X (Vehicle-to-Anything), and the like. When the push server 3 receives the push data transmission request from the application server 2, it selects the in-vehicle communication device 4 to which the push data is to be sent, and transmits the push data to the selected in-vehicle communication device 4 as the destination.

The push server 3 provides functions such as authentication of the communication partner, encryption of communication contents, and detection of tampering through TLS (Transport Layer Security) processing, etc., and also uses TCP/IP, UDP/IP, and other protocols. It provides secure data communication functions between the application server 2 and the in-vehicle communication device 4.

The push server 3 can retry sending push data within a predetermined period of time. When transmitting push data, there are situations in which an immediate response from the in-vehicle system is required and situations in which it is sufficient for the push data to reach the notification destination, and a retry deadline is set depending on the requested response. When the push data transmission fails, the push server 3 retries the push data transmission within a predetermined time period before the expiration of the retry time limit based on the retry time limit set according to the content of the push data. If the retry period elapses while the push data transmission fails, the push server 3 determines that the push data transmission has failed, and ends the retry of the push data transmission.

(2) Vehicle-side in-vehicle system Next, the vehicle-side in-vehicle system will be explained. The in-vehicle communication device 4 is called a TCU (Telematics Control Unit) or DCM (Data Communication Module), etc., and is a push data transmission destination, and is a configuration of an ACP engine 9 that realizes the functions of the automotive wireless communication platform 7 on the vehicle side. including. The in-vehicle communication device 4 mainly includes a microcontroller having a processor 13, a RAM 14, and a storage medium 15. The in-vehicle communication device 4 executes the control program stored in the storage medium 15 by the processor 13 to perform various operations, and realizes the functions of the automotive wireless communication platform 7 on the vehicle side.

The in-vehicle communication device 4 is connected to a plurality of in-vehicle ECUs 5 through an in-vehicle network. Examples of in-vehicle networks 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). ) etc. The in-vehicle network is provided for each system, such as the powertrain system, chassis system, body system, multimedia system, and safety system.

The in-vehicle communication device 4 connects a communication line with the push server 3 through wireless communication via a mobile communication network, 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 the push data from the push server 3, it selects the in-vehicle ECU 5 as the destination, and transmits the push data to the in-vehicle ECU 5 selected as the destination.

The in-vehicle communication device 4 provides functions such as authentication of the communication partner, encryption of communication contents, and detection of tampering through TLS processing, etc., and also supports data communication using TCP/IP, UDP/IP, and protocols other than these. Provide functionality. Secure data communication may be possible between the vehicle-mounted communication device 4 and the push server 3 and between the vehicle-mounted communication device 4 and the vehicle-mounted ECU 5, respectively.

The in-vehicle communication device 4 can maintain an online state connected to the communication network even when the vehicle is parked, for example, and the main power source of the vehicle is off, specifically, the so-called ignition is off. The in-vehicle communication device 4 monitors the connection state via wireless communication with the push server 3 and the progress state of transmitting push data in the in-vehicle network. The in-vehicle communication device 4 cooperates with the push server 3 and enables mutual connection confirmation between the in-vehicle communication device 4 and the push server 3. The mutual connection confirmation between the on-vehicle communication device 4 and the push server 3 is sometimes referred to as life-and-death monitoring.

If the push data does not reach the destination, the in-vehicle communication device 4 notifies the transmission source of the failure of the push data transmission along with the reason information associated with the failure. As an example, if the application 6 or the in-vehicle ECU 5 to which the push data is to be transmitted does not exist in the in-vehicle network, the in-vehicle communication device 4 associates the push data transmission failure with such reason information at the source. A notification is sent to a certain push server 3.

The in-vehicle communication device 4 specifies destination information and status information as ECU information regarding the in-vehicle ECU 5 to which the push data is to be transmitted. The destination information may also be referred to as destination information. The destination information is information that allows identification of the in-vehicle ECU 5 to which the push data is to be transmitted from among the plurality of in-vehicle ECUs 5. The in-vehicle communication device 4 refers to the application ID or token to obtain destination information. The status information is information that can specify the power state (on/off state) of the in-vehicle ECU 5 specified as the transmission destination. To be more specific, the power-off state here refers to a state in which the in-vehicle ECU 5 has transitioned from a startup state to a hibernation state or the like by turning off the ignition or the like. At this time, the in-vehicle ECU 5 is able to receive the activation request with low power consumption, but is unable to perform data communication. When the power of the vehicle-mounted ECU 5 specified as a transmission destination based on the status information is in the OFF state, the vehicle-mounted communication device 4 performs a startup process of activating the vehicle-mounted ECU 5 to turn the power on (starting state).

The in-vehicle ECU 5 is equipped with one or more applications 6 and can execute the applications. The in-vehicle ECU 5 mainly includes a microcontroller having a processor (not shown), a RAM (not shown), and a storage medium (not shown). The in-vehicle ECU 5 uses a processor to execute a control program stored in a storage medium to perform various operations, and operates as an end ECU that is the final destination of push data sent from the push server 3. When the in-vehicle ECU 5 receives the 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, and transmits the push data from among the plurality of applications 6. The destination application 6 is specified, and the push data is transmitted to the application 6 specified as the transmission destination.

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 basically turned off in order to reduce power consumption when the vehicle is powered off. At this time, the in-vehicle ECU 5 is also disconnected from the communication network. Note that the application 6 may not be installed in some of the in-vehicle ECUs 5. Further, the in-vehicle communication device 4 may be provided in the in-vehicle system as a configuration that also serves as the in-vehicle ECU 5, and may be capable of mounting the application 6.

In the above configuration, as described above, the in-vehicle communication device 4 needs to be reset periodically for the purpose of updating software, restoring the status, cleaning up the memory, etc., but while the in-vehicle communication device 4 is being reset, the application server 2 sends a push data transmission request to the push server 3, the push server 3 continues to fail in transmitting the push data until the in-vehicle communication device 4 completes startup and completes the communication line connection, and the push server 3 fails to transmit the push data. I'll keep retrying. In this regard, in this embodiment, the in-vehicle communication device 4 and the push server 3 each have the following functions.

As shown in FIG. 2, the in-vehicle communication device 4 includes a reset executable determination section 4a and a reset flag notification section 4b. The resetting flag notification section 4b corresponds to a resetting information notification section.

For example, when a request event such as software update, status restoration, memory cleanup, etc. occurs, the reset executable determination unit 4a determines whether or not the reset is executable by determining the operating state at that time. For example, if the reset executable determination unit 4a determines that data communication is not in progress with the in-vehicle ECU 5 and that no problem will occur even if the reset is executed, the reset executable determination unit 4a determines that the reset is executable. On the other hand, if the reset executable determination unit 4a determines that data communication is in progress with the in-vehicle ECU 5 and that there is a possibility that problems such as data loss or data loss will occur if the reset is executed, the reset executable determination unit 4a determines that the reset is not executable. judge.

When the reset executable determination unit 4a determines that the reset can be executed, the reset flag notification unit 4b sends a reset flag indicating that the reset is in progress to the in-vehicle communication before starting the reset execution. The device 4 is associated with an identifiable device ID and notified to the push server 3. The device ID corresponds to device identification information.

The push server 3 includes a resetting flag setting section 3a, a resetting flag determining section 3b, a transmission holding section 3c, and an information transmitting section 3d. The resetting flag setting section 3a corresponds to a resetting information setting section, and the resetting flag determining section 3b corresponds to a resetting information determining section.

When the resetting flag setting unit 3a is notified of the resetting flag from the in-vehicle communication device 4, the resetting flag setting unit 3a identifies the in-vehicle communication device 4 that is the notification source of the resetting flag based on the device ID associated with the resetting flag. , the resetting flag is set in association with the in-vehicle communication device 4 that is the notification source of the resetting flag.

When the resetting flag determining unit 3b receives a push data transmission request from the application server 2, it determines whether the resetting flag is set in association with the in-vehicle communication device 4 to which the push data is transmitted. do.

When the reset flag determining unit 3b determines that the reset flag is set in association with the in-vehicle communication device 4 that is the destination of the push data, the transmission suspension unit 3c suspends the transmission of the push data. Then, the in-vehicle communication device 4 waits for the completion of reconnection of the communication line that was disconnected due to the execution of the reset.

When the reconnection of the communication line is completed, the information transmitting unit 3d cancels the suspension of transmission of the push data by the transmission suspension unit 3c, and transmits the push data whose transmission was suspended to the in-vehicle communication device 4.

The operation of the above configuration will be explained with reference to FIG. 3.
When a request event such as software update, status restoration, memory cleanup, etc. occurs, the in-vehicle communication device 4 determines the operating state at that time and determines whether a reset can be executed. When the in-vehicle communication device 4 specifies that the reset is executable (A1), it notifies the push server 3 of the reset 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 source of the resetting flag (B1). After notifying the resetting flag to the push server 3, the in-vehicle communication device 4 disconnects the communication line connected to the push server 3 (A2) and executes a reset (A3).

Here, when the push server 3 receives the push data transmission request sent from the application server 2 (S2), a reset flag is set in association with the in-vehicle communication device 4 that is the destination of the push data. Determine whether or not there is. When the push server 3 specifies that the reset flag is set in association with the in-vehicle communication device 4 that is the destination of the push data (B2), the push server 3 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 due to the in-vehicle communication device 4, which is the destination of the push data, executing the reset (B3). That is, by suspending the transmission of push data, the push server 3 does not treat the push data transmission as a failure even if the communication line is not connected to the in-vehicle communication device 4 to which the push data is transmitted. .

When the in-vehicle communication device 4 completes the reset and completes the startup (A4), it reconnects the disconnected communication line with the push server 3 (A5). When the push server 3 specifies that the reconnection of the communication line has been completed, it releases the pending transmission of the push data (B4), and transmits the push data whose transmission was pending 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 identifies completion of transmission of the push data to the in-vehicle communication device 4 (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, the in-vehicle ECU 5 transmits the push data to the application 6 corresponding to the push data, starts the application 6, and controls the remote request service corresponding to the push data. conduct.

As explained above, according to the first embodiment, the following effects can be obtained. When the in-vehicle communication device 4 determines that the reset is executable, the in-vehicle communication device 4 associates the reset flag with the device ID and notifies the push server 3 before starting the reset. By associating the resetting flag with the device ID and notifying the push server 3, the push server 3 can identify that the in-vehicle communication device 4 specified by the device ID is being reset, and the in-vehicle communication device The transmission of push data can be stopped until the communication line is completely reconnected after the start-up of the mobile terminal 4 is completed. That is, the push server 3 can avoid continuing to fail in transmitting push data, and can avoid continuing to retry transmitting push data. Thereby, the push data can be appropriately received from the push server 3 without the push server 3 continuously retrying the transmission of the push data.

When the push server 3 receives a push data transmission request from the application server 2, if it is associated with the in-vehicle communication device 4 that is the destination of the push data and the reset flag is set, the push data is transmitted. The on-vehicle communication device 4 waits for the reconnection of the communication line that was disconnected due to the reset to be completed. When the reconnection of the communication line is completed, the transmission suspension of the push data is released, and the push data whose transmission has been suspended is transmitted to the in-vehicle communication device 4. By suspending push data transmission while the in-vehicle communication device 4 is being reset, the push server 3 fails to send push data until the in-vehicle communication device 4 completes startup and completes connection of the communication line. It is possible to avoid the push server 3 from continuing to retry sending push data. Thereby, push data can be appropriately transmitted to the vehicle-mounted communication device 4.

(Second embodiment)
A second embodiment will be described with reference to FIGS. 4 to 6. In the in-vehicle communication device 4, the reset information notification unit 4b notifies the push server 3 of a reset flag indicating that the reset is in progress before starting the reset, and also completes reconnection of the communication line. The push server 3 is notified of time information indicating the scheduled time until or the scheduled time for reconnection completion.

When the in-vehicle communication device 4 specifies that the reset is executable (A1), it notifies the push server 3 of the 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 transmission source of the in-vehicle communication device 4 (B1). When time information or time information is notified from , the notified time information or time information is stored (B11).

In this case, the push server 3 receives a push data transmission request from the application server 2 while the resetting flag is being set, and the resetting flag is set in association with the in-vehicle communication device 4 that is the destination of the push data. When it is determined that the scheduled time has been reached (B2), it is determined whether the scheduled time or scheduled time has been reached 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 been reached (B12: NO), it notifies the application server 2 of a transmission pending response (S12) and suspends the transmission of push data (B3).

On the other hand, if the push server 3 determines that the scheduled time or scheduled time has been reached, it notifies the application server 2 of a transmission failure response (S13), releases the push data transmission hold (B4), and transmits the push data. Waiting for the completion of reconnection of the communication line that was disconnected when the in-vehicle communication device 4 executed the reset is canceled. That is, by canceling the suspension of push data transmission, the push server 3 determines that the push data transmission has failed because the communication line is not connected to the in-vehicle communication device 4, which is the destination of the push data. do.

As explained above, according to the second embodiment, the push server 3 is notified of the time information or time information from the in-vehicle communication device 4, so that it is possible to accurately determine that the offline state is temporary. . Further, it is possible to appropriately deal with the fact that the time required for resetting differs depending on the vehicle-mounted communication device 4.

(Third embodiment)
A third embodiment will be described with reference to FIGS. 7 to 8. As shown in FIG. 7, the in-vehicle communication device 4 includes a reset executable determination section 4a, a reset flag notification section 4b, a reset execution suspension section 4c, and a reset execution suspension release section 4d.

When the reset execution suspension unit 4c is notified of the reset execution suspension request from the push server 3, it suspends the execution of the reset. The reset execution suspension release unit 4d releases the reset execution suspension when a certain period of time has elapsed since the reset execution was suspended, or when a reset execution suspension release request is notified from the push server 3.

The push server 3 includes, in addition to a reset flag setting section 3a, a reset flag determination section 3b, a transmission suspension section 3c, and an information transmission section 3d, a schedule determination section 3e, a reset execution suspension request notification section 3f, and a reset execution suspension request notification section 3f. , and a reset execution hold request release notification section 3g.

The schedule determination unit 3e determines whether there is a schedule to transmit push data within a predetermined time. When the schedule determination unit 3e determines that there is a plan to transmit push data within a predetermined time, the reset execution suspension request notifying unit 3f notifies the in-vehicle communication device 4 of a reset execution suspension request. The reset execution hold request release notification unit 3g notifies the in-vehicle communication device 4 of the reset execution hold release request.

The operation of the above configuration will be explained with reference to FIG. 8.
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 source of the resetting flag (B1), and sends the push data to a predetermined value. It is determined whether there is a plan to transmit within the time (B21). When the push server 3 determines that push data is scheduled to be transmitted within a predetermined time (B21: YES), it notifies the in-vehicle communication device 4 of a reset execution hold request (S21).

When the in-vehicle communication device 4 is notified of the reset execution suspension request from the push server 3, it suspends the execution of the reset (A21), monitors the elapsed time since suspending the reset execution, and suspends the execution of the reset. It is determined whether the elapsed time since then has reached a certain time (A22).

If the push server 3 receives a request to send push data from the application server 2 before the elapsed time since the execution of the reset was suspended in the in-vehicle communication device 4 reaches a certain time (S22), the in-vehicle communication device 4 resets. Since the execution of is pending, the push data is transmitted to the on-vehicle communication device 4 (S23). 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 (S24).

When the in-vehicle communication device 4 determines that the elapsed time since suspending the reset execution has reached a certain time (A22: YES), it releases the suspension of the reset execution (A23), and performs communication with the push server 3. The connected communication line is disconnected (A2), and a reset is executed (A3). From this point on, the same processing as in the first embodiment is performed.

As explained above, according to the third embodiment, the reset flag is set in the push server 3, but when it is determined that there is a plan to send push data within a predetermined time, a reset execution pending request is sent to the in-vehicle communication device. By notifying the vehicle-mounted communication device 4, the push data can be transmitted to the vehicle-mounted communication device 4 before the vehicle-mounted communication device 4 executes the reset. Furthermore, when the elapsed time since the execution of the reset is suspended reaches a certain time, the in-vehicle communication device 4 can execute the reset.

(Fourth embodiment)
A fourth embodiment will be described with reference to FIG. 9.
When the push server 3 determines that push data is scheduled to be transmitted within a predetermined time (B21: YES), it notifies the in-vehicle communication device 4 of a reset execution pending request (S21), and sends the reset execution pending request to the in-vehicle communication device 4. When a predetermined period of time has elapsed since the notification to the on-vehicle communication device 4, a reset execution hold release request is sent to the in-vehicle communication device 4 (S25).

When the push server 3 receives the push data transmission request from the application server 2 (S22) before notifying the in-vehicle communication device 4 of the reset execution hold release request, the in-vehicle communication device 4 determines that the reset execution is on hold. Therefore, the push data is transmitted to the in-vehicle communication device 4 (S23). 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 (S24).

When the in-vehicle communication device 4 is notified of the reset execution hold release request from the push server 3, it releases the reset execution hold (A23) and disconnects the communication line connected to the push server 3 (A2). ), execute the reset (A3). From this point on, the same processing as in the first embodiment is performed.

As described above, according to the fourth embodiment, similar to the third embodiment, the reset flag is set in the push server 3, but when it is determined that there is a plan to send push data within a predetermined time, By notifying the in-vehicle communication device 4 of the reset execution hold request, push data can be transmitted to the in-vehicle communication device 4 before the in-vehicle communication device 4 executes the reset. Further, the push server 3 notifies the vehicle-mounted communication device 4 of the reset execution suspension request, so that the vehicle-mounted communication device 4 can execute the reset.

(Fifth embodiment)
A fifth embodiment will be described with reference to FIGS. 10 and 11.
When the in-vehicle communication device 4 is notified of the reset execution hold release request from the push server 3, it releases the reset execution hold (A23), and when it specifies that the reset can be executed (A1), it pushes the reset flag. Notify the server 3 (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 source of the resetting flag (B1). After notifying the resetting flag to the push server 3, the in-vehicle communication device 4 disconnects the communication line connected to the push server 3 (A2) and executes a reset (A3).

As described above, according to the fifth embodiment, when the in-vehicle communication device 4 specifies that the reset can be executed after canceling the suspension of reset execution, the in-vehicle communication device 4 notifies the push server 3 of the reset flag. I can do it.

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

When the in-vehicle communication device 4 is notified of the reset execution request from the push server 3, it determines whether or not the reset can be executed, and if it specifies that the reset can be executed (A1), it communicates with the push server 3. The communication line connected between them is disconnected (A2), and a reset is executed (A3). From this point on, the same processing as in the first embodiment is performed.

As described above, according to the sixth embodiment, the push server 3 notifies the vehicle-mounted communication device 4 of a reset execution request, which allows the vehicle-mounted communication device 4 to execute the reset.

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

When the in-vehicle communication device 4 is notified of the reset execution request from the push server 3, it determines whether or not the reset can be executed, and when it specifies that the reset can be executed (A1), it pushes the resetting flag. Notify the server 3 (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 source of the resetting flag (B1). After notifying the resetting flag to the push server 3, the in-vehicle communication device 4 disconnects the communication line connected to the push server 3 (A2) and executes a reset (A3). From this point on, the same processing as in the first embodiment is performed.

As described above, according to the seventh embodiment, similarly to the sixth embodiment, when the push server 3 notifies the in-vehicle communication device 4 of a reset execution request, the in-vehicle communication device 4 executes the reset. be able to.

(Other embodiments)
Although the present disclosure has been described with reference to examples, it is understood that the present disclosure is not limited to these examples or structures. The present disclosure also includes various modifications and equivalent modifications. In addition, various combinations and configurations, as well as other combinations and configurations that include only one, more, or less than one element, are within the scope and scope of the present disclosure.

In the embodiment, each function provided by the pusher server 3 and the in-vehicle communication device 4 can be provided by software and hardware that executes it, only software, only hardware, or a complex combination thereof. . Furthermore, when such functions are provided by electronic circuits as hardware, each function can also be provided by digital circuits including multiple logic circuits, or by analog circuits.

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 configured mainly using an FPGA (Field-Programmable Gate Array) and an ASIC (Application-Specific Integrated Circuit).

The storage medium 12 of the push server 3 and the storage medium 15 of the in-vehicle communication device 4 each include a nonvolatile 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 a configuration provided on a circuit board, but may be provided in the form of a memory card or the like, and may be provided in a slot portion. The configuration may be such that the push server 3 and the processing circuit of the in-vehicle communication device 4 are electrically connected by being inserted into the push server 3 and the processing circuit of the vehicle-mounted communication device 4. Furthermore, each of the storage media 12 and 15 may be an optical disk, a hard disk drive, or the like that serves as a copy source for the program.

The control unit and the method described in the present disclosure are realized by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by a computer program. It's okay. Alternatively, the controller and techniques described in this disclosure may be implemented by a dedicated computer provided by configuring the processor with one or more dedicated hardware logic circuits. Alternatively, the control unit and its method described in the present disclosure may be implemented using a combination of a processor and memory programmed to execute one or more functions and a processor configured with one or more hardware logic circuits. It may be implemented by one or more dedicated computers configured. The computer program may also be stored as instructions executed by a computer on a computer-readable non-transitory tangible storage medium.

Claims (9)

1. An in-vehicle communication device (4) that, upon receiving push data from the push server as a result of the push data transmission request being received from the application server, transmits the received push data to the in-vehicle electronic control device,
   a reset executable determination unit (4a) that determines whether or not reset is executable;
   When it is determined that the reset can be executed, before starting the reset execution, the resetting information indicating that the reset is in progress is associated with the device identification information that can identify the device itself, and sent to the push server. An in-vehicle communication device comprising: a resetting information notification unit (4b) that provides notification.
2. In addition to notifying the push server of the resetting information, the resetting information notification unit also sends time information indicating the scheduled time until the reconnection of the communication line is completed or time information indicating the scheduled time to complete the reconnection. The in-vehicle communication device according to claim 1, wherein the in-vehicle communication device notifies the push server.
3. The in-vehicle communication device according to claim 1 or 2, further comprising a reset execution suspension unit (4c) that suspends execution of the reset when a reset execution suspension request is notified from the push server.
4. The in-vehicle communication device according to claim 3, further comprising a reset execution suspension release unit (4d) that releases the suspension of reset execution after a certain period of time has passed since execution of the reset was suspended.
5. The in-vehicle communication device according to claim 3, further comprising a reset execution hold release unit (4d) that releases the reset execution hold when a reset execution hold release request is notified from the push server.
6. When a push data transmission request is received from the application server, the push data is sent to the in-vehicle communication device, and as the in-vehicle communication device executes a reset, the communication line with the in-vehicle communication device is disconnected. A push server (3),
   a resetting information setting unit (3a) that sets resetting information indicating that the in-vehicle communication device is being reset in association with the in-vehicle communication device that is the notification source of the resetting information;
   Upon receiving a push data transmission request from the application server, a resetting information determining unit (3b) determines whether or not resetting information is set in association with the in-vehicle communication device to which the push data is transmitted. and,
   When it is determined that the resetting information is set, sending of push data is put on hold, and the transmission is put on hold to wait for the reconnection of the communication line that was disconnected when the in-vehicle communication device executed the reset. Part (3c) and
   A push server comprising: an information transmitter (3d) that releases the pending transmission of push data when the communication line is reconnected and transmits the push data whose transmission was pending to the in-vehicle communication device.
7. The resetting information setting unit sets the resetting information in association with the in-vehicle communication device that is the notification source of the resetting information, when the resetting information is notified from the in-vehicle communication device. push server.
8. The in-vehicle communication device is configured to suspend execution of the reset when notified of a reset execution suspension request from the push server,
   a schedule determination unit (3e) that determines whether there is a schedule to transmit push data within a predetermined time;
   8. The vehicle according to claim 6, further comprising: a reset execution suspension request notification unit (3f) that notifies the in-vehicle communication device of the reset execution suspension request when it is determined that push data is scheduled to be transmitted within a predetermined time. push server.
9. The in-vehicle communication device is configured to release the reset execution hold when notified of the reset execution hold release request from the push server,
   A claim comprising: a reset execution hold release request notification unit (3g) that notifies the in-vehicle communication device of the reset execution hold release request after the reset execution hold request notification unit notifies the reset execution hold request to the in-vehicle communication device. Push server described in Section 8.

Images