In-vehicle communication device and push server

Abstract

To immediately complete start of an on-vehicle electronic control unit to which push data is transmitted.SOLUTION: When a push server 3 receives a request for transmitting push data from an application serer 2 and an on-vehicle communication instrument 4 receives the push data from the push server, the on-vehicle communication instrument transmits the received push data to an on-vehicle ECU 5. The on-vehicle communication instrument 4 comprises a start control unit 4a that, when a start initiating instruction is notified to the push server from the application server immediately after the start of a cloud-side application and thereby the start initiation instruction is notified from the push server, causes an on-vehicle electronic control unit, to which the push data is transmitted, to initiate start processing.SELECTED DRAWING: Figure 1

Description

Technical Field

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

Background Art

[0002] As one of the remote request services for accessing the applications of the in-vehicle system from outside the vehicle, a push system for transmitting push data is provided. The push system includes an application server and a push server provided on the cloud side, and an in-vehicle communication device and an in-vehicle electronic control unit (hereinafter referred to as in-vehicle ECU (Electronic Control Unit)) provided on the vehicle side. When the application on the cloud side is activated by, for example, a smartphone terminal and 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. 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 the application on the in-vehicle system side mounted on the in-vehicle ECU (see, for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] For push data to be transmitted to the application on the in-vehicle system, the in-vehicle ECU must have completed its startup process and be running. However, depending on the ECU configuration and function arrangement, the startup time required from the start to the completion of the startup process for the in-vehicle ECU may be long. Therefore, in a configuration where the in-vehicle communication device initiates the startup process for the in-vehicle ECU upon receiving push data sent from the push server, the in-vehicle ECU may not be running when the communication device sends the push data to the in-vehicle ECU. In that case, it becomes difficult to provide remote request services immediately, resulting in inferior serviceability and marketability.

[0005] The present invention has been made in view of the above circumstances, and its purpose is to provide an in-vehicle communication device and a push server that can immediately activate an in-vehicle electronic control device which is the destination of push data, thereby improving serviceability and marketability. [Means for solving the problem]

[0006] According to the in-vehicle communication device (4) described in claim 1, when a push server receives a request to send push data from the application server and receives push data from the push server, it transmits the received push data to the in-vehicle electronic control unit. When the startup control unit (4a) receives a startup start instruction from the application server to the push server immediately after the cloud-side application is started and the push server notifies it of the startup start instruction, it causes the in-vehicle electronic control unit, which is the destination of the push data, to start the startup process.

[0007] When a startup command is received from the push server, the in-vehicle electronic control unit (ECC) is instructed to begin the startup process. When the cloud-side application starts up, the ECC, which is the destination of the push data, immediately begins the startup process, allowing the ECC to complete its startup immediately. This reduces the possibility that the ECC may not be started up when the in-vehicle communication device sends the push data to the ECC, and allows the application on the in-vehicle system side installed in the ECC to start up immediately, thereby improving serviceability and marketability.

[0008] According to the push server (3) described in claim 7, upon receiving a request to send push data from the application server, it sends the push data to the in-vehicle communication device. The startup start instruction notification unit (3a) notifies the in-vehicle communication device, which is the destination of the push data, of the startup start instruction when it receives a startup start instruction from the application server immediately after the cloud-side application starts up.

[0009] Immediately after the cloud-side application starts, when the application server notifies a startup command, this command is also sent to the in-vehicle communication device, which is the destination of the push data. When the cloud-side application starts, the in-vehicle electronic control unit, which is the destination of the push data, immediately starts up, allowing the in-vehicle electronic control unit to complete startup immediately. This reduces the possibility that the in-vehicle electronic control unit is not already started when the in-vehicle communication device sends the push data to the in-vehicle electronic control unit, allowing the application on the in-vehicle system side installed in the in-vehicle electronic control unit to start up immediately, thereby improving serviceability and marketability. [Brief explanation of the drawing]

[0010] [Figure 1] This figure shows the first embodiment and the overall configuration of the push system. [Figure 2] Functional block diagram of 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 third embodiment [Figure 6] A fourth embodiment is shown, along with a functional block diagram of the in-vehicle communication device and push server. [Figure 7] Sequence diagram [Figure 8] Sequence diagram [Modes for carrying out the invention]

[0011] Several embodiments will be described below with reference to the drawings. Parts common to multiple embodiments may be omitted from the description.

[0012] (First Embodiment) The first embodiment will be described with reference to Figures 1 to 3. The push system 1 shown in Figure 1 comprises an application server 2 and a push server 3 located on the cloud side, and an in-vehicle communication device 4 and an in-vehicle ECU 5 located on the vehicle side. The in-vehicle ECU 5 is equipped with an in-vehicle system application 6 for realizing remote request services. 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 the application on the cloud side is launched, for example, by a smartphone terminal.

[0013] For example, when a user activates an application on their smartphone to remotely start the air conditioning before getting into the vehicle or lock the doors after getting in, and performs a predetermined operation, a request to send push data to start the air conditioning or lock the doors is sent from the application server 2 to the push server 3. This push data is then transmitted to the in-vehicle ECU 5 via the in-vehicle communication device 4, and finally to the application 6 on the in-vehicle system side that implements the air conditioning start, door lock, etc.

[0014] Figure 1 illustrates a configuration where one push server 3 is provided for multiple application servers 2 on the cloud side, but a configuration where multiple push servers 3 are provided for multiple application servers 2 is also possible. Similarly, on the vehicle side, a configuration where one in-vehicle communication device 4 is provided for multiple in-vehicle ECUs 5 is illustrated, but a configuration where multiple in-vehicle communication devices 4 are provided for multiple in-vehicle ECUs 5 is also possible.

[0015] The push system 1 employs an automotive wireless communication platform 7. The automotive wireless communication platform 7 is implemented by the ACP Cloud 8 on the cloud side and the ACP Engine 9 on the vehicle side, enabling a secure connection between the application server 2 and the application 6 anytime, anywhere. In detail, the power state of the in-vehicle ECU 5 differs from one another; for example, the power is turned off when the vehicle is parked. Furthermore, the system configuration, including the in-vehicle ECU 5, differs from one vehicle to another. The automotive wireless communication platform 7 hides these differences in the power state of the in-vehicle ECU 5 and the differences in the system configuration of each vehicle from the application server 2. As a result, a pseudo-always-on connection is achieved on a vehicle-by-vehicle basis, making it appear as if all in-vehicle ECU 5 are constantly connected to an external network.

[0016] The following describes the cloud-side system and the vehicle-side in-vehicle system on which the Automotive Wireless Communication Platform 7 is installed. (1) Cloud-side system First, the in-vehicle system on the vehicle side will be described. The application server 2 is a server that functions as a source for sending push data. The application server 2 manages at least one of the application ID and the token that identifies 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 together with the message body to be sent to the application 6. When the application server 2 uses the token as request information, it reads out the token associated with the push data destination. The token is key information for determining the push data destination in the push server 3, the in-vehicle system, etc.

[0017] The push server 3 is a source for sending push data and includes the configuration of the ACP cloud 8 that realizes the cloud-side function 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 the control program stored in the storage medium 12 by the processor 10 to perform various operations and realizes the cloud-side function of the automotive wireless communication platform 7.

[0018] The push server 3 connects a communication line by wireless communication via a mobile communication network to the in-vehicle communication device 4 and can send push data to the in-vehicle communication device 4 while the communication line is connected. The mobile communication network includes, for example, a mobile phone network, Wi-Fi (registered trademark), and V2X (Vehicle-to-Anything), etc. When the push server 3 receives a push data transmission request from the application server 2, it selects the in-vehicle communication device 4 that is the push data destination and sends the push data to the selected in-vehicle communication device 4 as the destination.

[0019] The push server 3 provides functions such as authentication of communication partners, encryption of communication content, and detection of tampering through TLS (Transport Layer Security) processing, etc., 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.

[0020] The push server 3 can retry sending push data within a predetermined time. When sending push data, there are scenarios where an immediate response from the in-vehicle system is required and scenarios where it is sufficient for the push data to reach the notification destination, and a retry deadline is set according to the required response. When the transmission of push data fails, the push server 3 retries sending the push data within a predetermined time before the expiration of the retry deadline based on the retry deadline set according to the content of the push data. When the retry deadline expires while the transmission of push data fails, the push server 3 determines that the transmission of the push data has failed and terminates the retry of sending the push data.

[0021] (2) In-vehicle system on the vehicle side Next, the in-vehicle system on the vehicle side will be described. The in-vehicle communication device 4 is also called a TCU (Telematics Control Unit) or DCM (Data Communication Module), etc., and is the destination of push data, and includes the configuration of the ACP engine 9 that realizes the vehicle-side functions of the automotive wireless communication platform 7. 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 control programs stored in the storage medium 15 by the processor 13 to perform various operations and realizes the vehicle-side functions of the automotive wireless communication platform 7.

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

[0023] The in-vehicle communication device 4 connects to the push server 3 via a wireless communication line over 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 push data from the push server 3, it selects an in-vehicle ECU 5 as the destination and sends the push data to the selected in-vehicle ECU 5.

[0024] The in-vehicle communication device 4 provides functions such as authentication of the communication partner, encryption of communication content, and detection of tampering through TLS processing, and also provides data communication functions using TCP / IP, UDP / IP, and other protocols. Secure data communication may be enabled 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.

[0025] The in-vehicle communication device 4 can maintain an online state connected to the communication network even when the vehicle's main power is off, specifically when the ignition is off, such as when the vehicle is parked. The in-vehicle communication device 4 monitors the connection status via wireless communication with the push server 3 and the progress of push data transmission on the in-vehicle network. The in-vehicle communication device 4 works in cooperation with the push server 3 to enable mutual connection verification between the in-vehicle communication device 4 and the push server 3. This mutual connection verification between the in-vehicle communication device 4 and the push server 3 is sometimes referred to as liveness monitoring.

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

[0027] 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 will be sent. The destination information may also be called the recipient information. The destination information is information that allows the identification of the in-vehicle ECU 5 to which the push data will be sent from among multiple in-vehicle ECU 5s. The in-vehicle communication device 4 obtains the destination information by referring to the application ID or token. The status information is information that allows the identification of 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 a startup state to a hibernation state, etc., due to the ignition being turned off, etc. At this time, the in-vehicle ECU 5 can receive startup requests with low power consumption, but data communication is impossible. If the power of the in-vehicle ECU 5 identified as the destination based on the status information is in the off state, the in-vehicle communication device 4 performs a startup process to start the in-vehicle ECU 5 and turn on the power (startup state).

[0028] The in-vehicle ECU 5 is equipped with one or more applications 6 and is capable of executing 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 using the processor, and operates as an end ECU that is the final destination for 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, it identifies registration information that matches the application ID or token associated with the push data, identifies the application 6 to which the push data will be transmitted from among the multiple applications 6, and transmits the push data to the application 6 identified as the destination.

[0029] The in-vehicle ECU 5 provides encryption processing functionality, enabling 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's power is off to conserve power. In this case, the in-vehicle ECU 5 is also disconnected from the communication network. Note that some in-vehicle ECU 5 do not need to have the application 6 installed. Also, the in-vehicle communication device 4 may be provided in the in-vehicle system in a configuration that also serves as the in-vehicle ECU 5, and may be capable of installing the application 6.

[0030] In the configuration described above, as previously mentioned, in a configuration where the in-vehicle communication device 4 initiates the startup process of the in-vehicle ECU 5 upon receiving push data transmitted from the push server 3, there is a possibility that the in-vehicle ECU 5 may not have started up at the time the in-vehicle communication device 4 transmits the push data to the in-vehicle ECU 5. In this regard, in this embodiment, the in-vehicle communication device 4 and the push server 3 each have the following functions.

[0031] As shown in Figure 2, the in-vehicle communication device 4 comprises a startup control unit 4a and a first startup completion notification unit 4b. When the startup control unit 4a receives a startup start instruction from the push server 3, it causes the in-vehicle ECU 5, which is the destination of the push data, to start the startup process in a low-power state. At this time, the startup control unit 4a does not cause the in-vehicle ECU 5, which is not the destination of the push data, to start the startup process. When the first startup completion notification unit 4b receives a startup completion notification indicating that the in-vehicle ECU 5 has completed startup, it notifies the push server 3 of the startup completion notification.

[0032] The push server 3 comprises a startup start instruction notification unit 3a and a second startup completion notification unit 3b. When the startup start instruction notification unit 3a receives a startup start instruction from the application server 2 immediately after the cloud-side application starts up, it notifies the in-vehicle communication device 4, which is the destination for push data, of the startup start instruction. When the second startup completion notification unit 3b receives a startup completion notification from the in-vehicle communication device 4, it notifies the startup completion notification to the application server 2.

[0033] The operation of the above configuration will be explained with reference to Figure 3. When the application server 2 identifies, for example, that a user has performed an operation to launch a smartphone application on a smartphone terminal (A1), it notifies the push server 3 of a launch start command (S1). When the push server 3 receives the launch start command from the application server 2, it notifies the launch start command to the in-vehicle communication device 4 (S2). When the in-vehicle communication device 4 receives the launch start command from the push server 3, it notifies the launch start command to the in-vehicle ECU 5, which is the destination of the push data (S3). In other words, the in-vehicle communication device 4 identifies the in-vehicle ECU 5, which is the destination of the push data, and notifies the launch start command only to the in-vehicle ECU 5, which is the destination of the push data, and does not notify the launch start command to the in-vehicle ECU 5 that is not the destination of the push data.

[0034] When the in-vehicle ECU 5 receives a startup command from the in-vehicle communication device 4, it transitions from sleep mode to low power mode and starts the startup process (B1). When the in-vehicle ECU 5 completes the startup process (B2:YES), it notifies the in-vehicle communication device 4 of the startup completion notification indicating that it has completed the startup process (S4). When the in-vehicle communication device 4 receives the startup completion notification from the in-vehicle ECU 5, it notifies the push server 3 of the startup completion notification (S5). When the push server 3 receives the startup completion notification from the in-vehicle communication device 4, it notifies the application server 2 of the startup completion notification (S6).

[0035] When the application server 2 identifies that a user has performed a predetermined operation for the remote request service (A2), it sends a push data transmission request to the push server 3 (S7). When the push server 3 receives the push data transmission request from the application server 2, it sends the push data to the in-vehicle communication device 4 (S8). When the in-vehicle communication device 4 receives the push data sent from the push server 3, it sends the push data to the in-vehicle ECU 5 (S9). When the in-vehicle ECU 5 receives the push data sent from the in-vehicle communication device 4, it 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 (B3).

[0036] As described above, the first embodiment provides the following advantages and benefits. When the in-vehicle communication device 4 receives a startup instruction from the push server 3, it is configured to start the startup process on the in-vehicle ECU 5. When the cloud-side application starts up, the startup process on the in-vehicle ECU 5, which is the destination of the push data, is immediately started, allowing the in-vehicle ECU 5 to be started up immediately. This reduces the possibility that the in-vehicle ECU 5 is not already started when the in-vehicle communication device 4 sends the push data to the in-vehicle ECU 5, allowing the application on the in-vehicle system side installed in the in-vehicle ECU 5 to start up immediately, thereby improving serviceability and marketability.

[0037] In the push server 3, when a startup start command is notified from the application server 2 immediately after the cloud-side application starts, the startup start command is notified to the in-vehicle communication device 4, which is the destination of the push data. When the cloud-side application starts, the startup process is immediately started on the in-vehicle ECU 5, which is the destination of the push data, so that the in-vehicle ECU 5 can be started up immediately. This reduces the possibility that the in-vehicle ECU 5 is not already started when the in-vehicle communication device 4 sends the push data to the in-vehicle ECU 5, and the application on the in-vehicle system side installed on the in-vehicle ECU 5 can be started immediately, thereby improving serviceability and marketability.

[0038] (Second Embodiment) A second embodiment will be described with reference to Figure 4. In the in-vehicle communication device 4, the startup control unit 4a holds startup target information that can identify the in-vehicle ECU5 to be started, and identifies the in-vehicle ECU5 to be started based on the startup target information. The push server 3 transmits push data to the in-vehicle ECU5 identified based on the startup target information.

[0039] The function of the above configuration will be explained by referring to it. The in-vehicle communication device 4 holds activation target information, for example, that is pre-configured by the vehicle manufacturer (C1). When the in-vehicle communication device 4 receives a startup start instruction from the push server 3, it refers to the activation target information and identifies the in-vehicle ECU5 to be activated based on the activation target information (C2). The in-vehicle communication device 4 identifies the in-vehicle ECU5 identified based on the activation target information as the destination for the push data and notifies the startup start instruction to the in-vehicle ECU5, which is the destination for the push data (S3). From here on, the same processing as in the first embodiment is performed.

[0040] As described above, according to the second embodiment, the vehicle ECU5 to be started is identified based on the startup target information, the vehicle ECU5 identified based on the startup target information is identified as the destination for push data, and a startup start instruction is notified to the vehicle ECU5, which is the destination for push data. This makes it possible to balance the trade-off relationship between improving serviceability and marketability with reducing vehicle power consumption.

[0041] For example, in vehicles with small battery capacities, such as inexpensive compact cars and kei cars, where the risk of insufficient charging is relatively high, there is a strong need to reduce unnecessary vehicle power consumption. For instance, by registering only applications that require immediate activation, such as door locking, as launch targets in the launch target information, and excluding applications that do not require immediate activation, such as starting the air conditioner, from the launch target, it is possible to reduce vehicle power consumption while prioritizing the launch of applications that require immediate activation.

[0042] On the other hand, in vehicles such as electric vehicles in environments where charging facilities are readily available, the need to suppress unnecessary vehicle power consumption is not as high. For example, by registering not only applications that require immediate action, such as door locking, but also applications that do not require immediate action, such as starting the air conditioner, as launch targets in the launch target information, many applications can be launched simultaneously regardless of whether immediate action is required or not.

[0043] (Third embodiment) A second embodiment will be described with reference to Figure 5. In the in-vehicle communication device 4, the startup control unit 4a synchronizes the startup target information with the push server 3. The function of the above configuration will be explained by referring to it.

[0044] The push server 3 holds the information to be activated (D1), and when it updates the information to be activated (D2), it transmits the information to the in-vehicle communication device 4 (S10). When the in-vehicle communication device 4 receives the information to be activated transmitted from the push server 3, it updates the information it holds (C3) and synchronizes the information with the push server 3. From this point onward, the same processing as in the second embodiment is performed.

[0045] As described above, according to the third embodiment, the activation target information is synchronized between the in-vehicle communication device 4 and the push server 3. The trade-off relationship between improving serviceability and marketability and reducing vehicle power consumption can be freely changed according to the needs of the vehicle and the user, thereby improving convenience.

[0046] For example, in vehicles where there is not a strong need to reduce vehicle power consumption during normal use, the need to reduce vehicle power consumption arises when traveling long distances in order to ensure sufficient driving range. By updating the activation target information held in the push server 3 and synchronizing the activation target information between the in-vehicle communication device 4 and the push server 3, it is possible to flexibly respond to changes in the operating environment.

[0047] (Fourth Embodiment) A fourth embodiment will be described with reference to Figures 6 to 8. The push server 3 includes a startup start instruction notification unit 3a, a second startup completion notification unit 3b, a session establishment unit 3c, and a destination determination unit 3d.

[0048] The session establishment unit 3c establishes a session with the application 6 when it receives a startup completion notification from the in-vehicle communication device 4. The destination determination unit 3d determines the destination of the push data.

[0049] The operation of the above configuration will be explained with reference to Figures 7 and 8. When the push server 3 receives a startup completion notification from the in-vehicle communication device 4, it establishes a session with application 6. The push server 3 manages the establishment of the session with application 6 and determines whether the session was successfully established. As shown in Figure 7, the push server 3 determines that the session with application 6 was successfully established (D3), and upon receiving a push data transmission request sent from application server 2, it determines the destination of the push data (D4) and directly transmits the push data to application 6, which successfully established the session (S11).

[0050] Meanwhile, as shown in Figure 8, the push server 3 determines that session establishment with application 6 has failed (D5), and upon receiving a push data transmission request from application server 2, it transmits the push data to the in-vehicle communication device 4 (S12). Upon receiving the push data transmitted from push server 3, the in-vehicle communication device 4 transmits the push data to the in-vehicle ECU 5 (S13). Upon receiving the push data transmitted from the in-vehicle communication device 4, the in-vehicle ECU 5 transmits the push data to application 6 corresponding to the push data, starts application 6, and controls the remote request service corresponding to the push data (B3).

[0051] As described above, according to the fourth embodiment, a session is established between the application, which is the destination of the push data, and the push server 3. By directly sending the push data from the push server 3 to the in-vehicle ECU 5 and eliminating the processing of the in-vehicle communication device 4, the transmission time required to send the push data from the push server 3 to the in-vehicle ECU 5 can be shortened, thereby improving immediacy.

[0052] (Other embodiments) This disclosure is described in accordance with the embodiments, but is not limited to those embodiments or structures. This disclosure also includes various modifications and variations within the equivalence range. In addition, various combinations and forms, as well as other combinations and forms that include only one, more, or fewer of those elements, fall within the scope and concept of this disclosure.

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

[0054] The processor 10 of the push server 3 and the processor 13 of the in-vehicle communication device 4 each include at least one processing core such as a CPU (Central Processing Unit). The processing circuits including each processor 10 and 13 may be configured primarily with FPGAs (Field-Programmable Gate Arrays) and ASICs (Application-Specific Integrated Circuits).

[0055] 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 and 15 may be changed as appropriate. For example, each storage medium 12 and 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 electrically connected to the processing circuits of the push server 3 and the in-vehicle communication device 4 by being inserted into a slot. Furthermore, each storage medium 12 and 15 may be an optical disk or a hard disk drive, etc., which serve as the basis for copying programs.

[0056] The control unit and its method described herein may be implemented by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by a computer program. Alternatively, the control unit and its method described herein may be implemented by a dedicated computer provided by configuring a processor by one or more dedicated hardware logic circuits. Alternatively, the control unit and its method described herein may be implemented by one or more dedicated computers configured by a combination of a processor and memory programmed to perform one or more functions and a processor configured by one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by the computer on a computer-readable non-transitional tangible recording medium.

[0057] This disclosure includes, in addition to the invention described in the claims, the following inventions: [1] An in-vehicle communication device (4) transmits the received push data to an in-vehicle electronic control unit when it receives a push data transmission request from the application server to the push server, An in-vehicle communication device comprising a startup control unit (4a) that, upon receiving a startup start instruction from the application server to the push server immediately after the cloud-side application is launched, causes the push server to start the startup process on the in-vehicle electronic control unit, which is the destination of the push data.

[0058] [2] The startup control unit causes the on-board electronic control unit that is the destination of the push data to start the startup process, and does not cause the on-board electronic control unit that is not the destination of the push data to start the startup process [1] on-board communication device.

[0059] [3] The startup control unit identifies the in-vehicle electronic control device to be started based on the startup target information, as described in [1] or [2].

[0060] [4] The startup control unit synchronizes the startup target information with the push server, as described in [3].

[0061] [5] The startup control unit causes the on-board electronic control unit, which is the destination for push data, to start the startup process in a low-power state. (The on-board communication device is one of the devices described in any one of the items from [1] to [4].)

[0062] [6] An in-vehicle communication device as described in any one of [1] to [5], further comprising a first startup completion notification unit (4b) that, when the in-vehicle electronic control device completes the startup process, notifies the push server of the startup completion notification indicating that the in-vehicle electronic control device has completed the startup process.

[0063] [7] A push server (3) that receives a request to send push data from an application server and sends the push data to the in-vehicle communication device, A push server equipped with a startup command notification unit (3a) that notifies the in-vehicle communication device, which is the destination of push data, of the startup command when a startup command is notified from the application server immediately after the cloud-side application is started.

[0064] [8] The in-vehicle communication device is configured to notify the push server of a startup completion notification indicating that the in-vehicle electronic control device has completed its startup process when the in-vehicle electronic control device has completed its startup process. A push server as described in [7], which includes a second startup completion notification unit (3b) that notifies the application server of the startup completion notification when the in-vehicle communication device notifies the application server of the startup completion notification.

[0065] [9] A push server as described in [7] or [8], which includes a session establishment unit (3c) that establishes a session with an application when a startup completion notification is received from the in-vehicle communication device.

[0066]

[10] A push server as described in any one of the items [7] to [9], which, upon successful establishment of a session by the session establishment unit, directly transmits push data to the application that successfully established the session.

[0067]

[11] A push server as described in

[10] , comprising a destination determination unit (3d) that determines the destination of push data.

[0068]

[12] A push server according to claim [9] or

[10] , wherein if the session establishment unit fails to establish a session, push data is transmitted to the in-vehicle communication device. [Explanation of Symbols]

[0069] In the diagram, 1 is the push system, 2 is the application server, 3 is the push server, 3a is the startup start instruction notification unit, 3b is the second startup completion notification unit, 3c is the session establishment unit, 3d is the destination determination unit, 4 is the in-vehicle communication device, 4a is the startup control unit, 4b is the first startup completion notification unit, 5 is the in-vehicle ECU, and 6 is the application.

Claims

1. An in-vehicle communication device (4) receives a push data transmission request from an application server to a push server, and when the push server receives the push data, it transmits the received push data to an in-vehicle electronic control unit, An in-vehicle communication device comprising a startup control unit (4a) that, upon receiving a startup start instruction from the application server to the push server immediately after the cloud-side application is started, causes the push server to start the startup process in the in-vehicle electronic control unit which is the destination of the push data.

2. The in-vehicle communication device according to claim 1, wherein the startup control unit causes the in-vehicle electronic control unit that is the destination of the push data to start the startup process, and does not cause the in-vehicle electronic control unit that is not the destination of the push data to start the startup process.

3. The in-vehicle communication device according to claim 1, wherein the startup control unit identifies the in-vehicle electronic control device to be started, based on the startup target information, in order to initiate the startup process.

4. The in-vehicle communication device according to claim 3, wherein the startup control unit synchronizes the startup target information with the push server.

5. The in-vehicle communication device according to claim 1, wherein the startup control unit causes the in-vehicle electronic control unit, which is the destination for push data, to start the startup process in a low-power state.

6. An in-vehicle communication device according to any one of claims 1 to 5, further comprising a first startup completion notification unit (4b) that, when the in-vehicle electronic control device completes the startup process, notifies the push server of the startup completion notification indicating that the in-vehicle electronic control device has completed the startup process.

7. A push server (3) that receives a request to send push data from an application server and sends the push data to an in-vehicle communication device, A push server equipped with a startup command notification unit (3a) that notifies the in-vehicle communication device, which is the destination of push data, of the startup command when a startup command is notified from the application server immediately after the cloud-side application is started.

8. The in-vehicle communication device is configured to notify the push server of a startup completion notification indicating that the in-vehicle electronic control unit has completed its startup process when the in-vehicle electronic control unit has completed its startup process. The push server according to claim 7, further comprising a second startup completion notification unit (3b) that notifies the application server of the startup completion notification when the in-vehicle communication device notifies the application server of the startup completion notification.

9. The push server according to claim 8, further comprising a session establishment unit (3c) that establishes a session with an application when a startup completion notification is received from the in-vehicle communication device.

10. The push server according to claim 9, which, upon successful establishment of a session by the session establishment unit, directly transmits push data to the application that successfully established the session.

11. A push server according to claim 10, further comprising a destination determination unit (3d) for determining the destination of push data.

12. A push server according to claim 9 or 10, which transmits push data to the in-vehicle communication device if the session establishment unit fails to establish a session.

Images