Information transmission method and communication device

Abstract

The information transmission method of the present application is a method of push transmission of information based on wireless communication from the outside of a vehicle to a vehicle-mounted ECU. In the information transmission method, in processing performed by a processor, there are included: a step of receiving push information from an external transmission source (S47); a step of grasping ECU information related to the vehicle-mounted ECU (40) that is a notification destination of the push information (S50); and a step of implementing notification of the push information corresponding to the grasped ECU information (S53).

Description

[0001] Cross-references to related applications

[0002] This application is based on Japanese Patent Application No. 2020-201139, filed in Japan on December 3, 2020, and is incorporated herein by reference in its entirety. Technical Field

[0003] This specification discloses information sending methods and communication devices for pushing and sending information. Background Technology

[0004] Patent Document 1 discloses a technology that uses a push information server as an intermediary to send commands from an external vehicle information server to an onboard unit mounted in the vehicle. The onboard unit is capable of sending and receiving information with external devices via a communicator.

[0005] Patent Document 1: Japanese Patent Application Publication No. 2019-192953

[0006] In recent years, there has been a trend to maintain the communicator's connection to the network even when the vehicle's power is off. Generally, when the vehicle's power is off, the power to the vehicle ECU, such as the one in Patent Document 1, is also off. In this case, even if communication with the communicator is possible, it is practically impossible to send push notifications to the vehicle ECU. As described above, the convenience of sending push notifications to the vehicle ECU may become insufficient in the technology of Patent Document 1. Summary of the Invention

[0007] The purpose of this disclosure is to provide an information sending method and communication device that can improve the convenience of push notifications.

[0008] To achieve the above objectives, one disclosed method is an information transmission method that pushes information from outside the vehicle to at least one on-board ECU via wireless communication. The process, executed by at least one processor, includes the following steps: receiving push information from an external transmission source; acquiring ECU information related to the on-board ECU that is the notification destination of the push information; and notifying the recipient of the push information corresponding to the acquired ECU information.

[0009] Another disclosed method is a communication device in a vehicle equipped with at least one on-board ECU, which receives information pushed and transmitted from outside the vehicle via wireless communication. The communication device includes: a push receiving unit for receiving push information from an external transmission source; a grasping unit for grasping ECU information related to the on-board ECU that is the notification destination of the push information; and a transmission control unit for implementing the notification of the push information corresponding to the grasped ECU information.

[0010] Based on these methods, the receiving side, which receives push notifications from an external source, obtains ECU information related to the vehicle ECU at the notification destination of the push notification, and then sends push notifications to the vehicle ECU corresponding to that ECU information. Therefore, even if the sending source of the push notification does not have detailed information related to the vehicle ECU, the push notification can still reach the correct notification destination. This improves the convenience of push notification delivery.

[0011] Another disclosed method is an information transmission method in which information is pushed from outside the vehicle to an on-board ECU of at least one of multiple vehicles based on wireless communication. The process executed by at least one processor includes the following steps: determining a wireless communication device associated with the vehicle that is the destination of the push information based on request information obtained from the request source of the push information, and sending the push information to the wireless communication device that has the function of determining the on-board ECU that is the notification destination of the push information.

[0012] According to this method, the sending source of the push notification determines the wireless communication device associated with the vehicle that is the destination of the push notification, based on the request information obtained from the requesting source. Furthermore, the wireless communication device receiving the push notification can identify the on-board ECU that is the notification destination. Therefore, even if the requesting source does not have detailed information related to the vehicle and its system architecture, the push notification can still reach the correct notification destination. This improves the convenience of push notification delivery.

[0013] Furthermore, the reference numbers in parentheses in the claims are merely examples of the correspondence between the specific structures described later and the embodiments, and do not impose any limitation on the scope of the technology. Attached Figure Description

[0014] Figure 1 This is a diagram showing an overall image of a push distribution system according to one embodiment of the present disclosure.

[0015] Figure 2 This is a diagram showing the structure of cloud systems and vehicle systems.

[0016] Figure 3 This is a timing diagram showing the detailed registration sequence of the vehicle-mounted communicator to the push server.

[0017] Figure 4 It is a sequence diagram that shows the details of the payment sequence of the tokens used to associate the application with the application server.

[0018] Figure 5 Is with Figure 6Together, they form a sequence diagram that details the push distribution sequence from the application server to the application.

[0019] Figure 6 Is with Figure 5 Together, they form a sequence diagram that details the timing of push notifications and distribution. Detailed Implementation

[0020] Figure 1 and Figure 2 The push distribution system shown in one embodiment of this disclosure can push information from an application server 140 located on the cloud to an application 40a operating in an in-vehicle ECU 40. The push distribution system employs an automotive wireless communication platform 100. The automotive wireless communication platform 100 can establish a secure connection between the application server 140 and the application 40a at all times and in all locations. For example, when the vehicle Au is parked, the power to the in-vehicle ECU 40 is turned off. Furthermore, the structure of the in-vehicle system containing the in-vehicle ECU 40 differs from that of each vehicle Au. The automotive wireless communication platform 100 hides these differences in power state and system structure from the application server 140 side. As a result, on a per-vehicle Au basis, all in-vehicle ECUs 40 achieve a simulated constant connection, as if they were always connected to an external network.

[0021] The following sections will describe in detail the cloud-side system of the automotive wireless communication platform 100 and the in-vehicle systems of each vehicle's Au.

[0022] Multiple application servers 140 and at least one push server 110 are set up on the cloud side as an implementation system for push distribution services corresponding to in-vehicle applications.

[0023] Application server 140 is the request source for push notifications. Application server 140 has an ID management unit 141. The ID management unit 141 manages at least one of the following: an application ID that identifies application 40a and a token (described later). When requesting push notifications from push server 110, application server 140 provides either the application ID or a token as request information, along with the message body sent to application 40a. In this embodiment, a token is primarily used as the request information. Application server 140 reads the token associated with the destination of the push notification from ID management unit 141. The token is key information used by push server 110 and in-vehicle systems, etc., to determine the destination of the push notification.

[0024] Push server 110 is the source of push notifications. Push server 110 is connected to multiple application servers 140. Push server 110 can exchange information with the vehicle-mounted communicator 10 installed in the vehicle Au via wireless communication through a mobile communication network. Push server 110 can communicate with the vehicle-mounted communicator 10 not only through mobile phone lines, but also through wireless communication such as Wi-Fi (registered trademark) and V2X. Based on distribution requests from application servers 140, push server 110 pushes information wirelessly to the vehicle-mounted ECU 40 of at least one of the multiple vehicle Au units.

[0025] The push server 110 is a computing device primarily comprising a processor 111, RAM 112, and storage medium 113. The push server 110 includes a cryptographic processing unit 131 and a cloud communication unit 132. The cryptographic processing unit 131 provides functions such as authentication of communication objects, encryption of communication content, and tamper detection through TLS (Transport Layer Security) processing. Through the cryptographic processing unit 131, the push server 110 can securely communicate with each application server 140 and each vehicle-mounted communicator 10. The cloud communication unit 132 provides data communication functionality. Specifically, the cloud communication unit 132 can implement data communication using TCP / IP, UDP / IP, and protocols other than these. The push server 110 conducts data communication with each application server 140 and each vehicle-mounted communicator 10 via the cloud communication unit 132.

[0026] The push server 110 is a server device included in the ACP (Automotive Communication Platform) cloud 110a, which implements the cloud-side functions of the automotive wireless communication platform 100. The push server 110 implements the main functions of the ACP cloud 110a. Based on the push information distribution request from the application server 140, the ACP cloud 110a selects the vehicle Au (vehicle communicator 10) as the destination and pushes information to the selected vehicle Au. The push server 110 implements the functions of the ACP cloud 110a by executing a program stored in the storage medium 113 by the processor 111. The push server 110 includes a push distribution unit 121, a progress monitoring unit 122, and an ID management unit 127, which are functional units of the ACP cloud 110a. Furthermore, the ID management unit 127 can also be installed on a different computing device (hardware) than the push server 110.

[0027] Based on the push information distribution request from the application server 140, the push distribution unit 121, in cooperation with the cloud communication unit 132, distributes the push information to the vehicle communication device 10. The push distribution unit 121 uses the token obtained from the application server 140 as the request information as the key, and determines the vehicle communication device 10 as the destination of the push information based on the ID information managed by the ID management unit 127.

[0028] The push distribution unit 121 can repeatedly send push information to the vehicle communicator 10 within a specified time. In detail, push distribution can be performed in scenarios where an immediate response from the vehicle system is required, or in scenarios where the push information only needs to be delivered to the notification destination. Therefore, a distribution period (hereinafter, retry period) corresponding to the requested response is set in the push distribution. If sending push information to the vehicle communicator 10 fails, the push distribution unit 121, based on the retry period set according to the content of the push information, repeatedly sends push information to the vehicle communicator 10 within a specified time before the retry period expires. If the retry period has elapsed while the push information has failed to be sent to the vehicle communicator 10, the push distribution unit 121 determines that the push distribution has failed and terminates the sending of the push information.

[0029] The progress monitoring unit 122 monitors the connection status of the vehicle-mounted communicator 10 to the network and the progress status of push transmission. For example, if the vehicle-mounted communicator 10 is not connected to the network, the progress monitoring unit 122 notifies the application server 140, which is the source of the distribution request, of the push distribution failure (see reference). Figure 5 (S44). In the event that the transfer of push information to the notification destination fails within the vehicle system, which is the destination of the push information, the progress monitoring unit 122, in addition to a notification indicating the transfer failure, also receives reason information associated with the failure from the vehicle communicator 10 (the progress monitoring unit 22 described later). Based on the notification received from the vehicle communicator 10 and the reason information, the progress monitoring unit 122 notifies the application server 140, which is the source of the distribution request, of the push distribution failure (see S44). Figure 5 S52 and Figure 6 (S68).

[0030] The ID management unit 127 manages information indicating which vehicle Au and which on-board ECU 40 among multiple vehicle Au contains application 40a. Specifically, the ID management unit 127 manages the association between application ID, ECU ID, and TCU ID. The application ID, ECU ID, and TCU ID are synchronized with the information registered in the vehicle communicator 10. The application ID is the identification information for application 40a. The ECU ID is the identification information for the on-board ECU 40. The TCU ID is the identification information for the vehicle communicator 10 (vehicle Au). The application ID, ECU ID, and TCU ID registered in the ID management unit 127 are synchronized with the information registered in the vehicle communicator 10 (hereinafter referred to as the ID management unit 27).

[0031] The ID management unit 127 manages the combination of application ID, ECU ID, and TCU ID using a unique ID such as a token. The token represents the association information between application 40a, vehicle ECU 40, and vehicle communicator 10. Even if the same application 40a is installed in multiple vehicle Au units and these application IDs are identical, the ACP cloud 110a can use the token to set the application 40a installed in a specific vehicle Au and a specific vehicle ECU 40 as the notification destination. The ID management unit 127 collaborates with the cloud communication unit 132 to notify the vehicle communicator 10 of the issued token.

[0032] ID Management Unit 127 can manage the validity and invalidation of tokens by invalidating and reissuing them. Thus, an expiration date is set in the token, and the token can be discarded. As an example, ID Management Unit 127 can, when a user changes vehicles (such as shared cars) shared by multiple users, invalidate existing tokens issued to previous users and issue new tokens to new users.

[0033] The vehicle-mounted system installed in each vehicle Au consists of at least one vehicle-mounted communicator 10 and multiple vehicle-mounted ECUs 40, etc.

[0034] The vehicle-mounted communicator 10, referred to as a TCU (Telematics Control Unit) or DCM (Data Communication Module), is capable of wireless communication between the vehicle system and external sources. The vehicle-mounted communicator 10 is the destination for push notifications, receiving push information from the push server 110, which acts as the external source, via various wireless communications such as mobile phone lines, Wi-Fi, and V2X. The vehicle-mounted communicator 10 connects to multiple vehicle-mounted ECUs 40 via the in-vehicle network. The vehicle-mounted communicator 10 performs the processing of transferring the push information received from the push server 110 to the vehicle-mounted ECUs 40, which serve as the notification destination of the push information, and application 40a.

[0035] The vehicle-mounted communicator 10 is a control device that includes a microcontroller as its main component. This microcontroller has a processor 11, RAM 12, and storage medium 13. The vehicle-mounted communicator 10 also includes a password processing unit 31 providing password processing functions and a TCU communication unit 32 providing data communication functions. The vehicle-mounted communicator 10 can establish secure communication with the push server 110 and each vehicle-mounted ECU 40 through the password processing unit 31. The vehicle-mounted communicator 10 can transmit and receive data with the push server 110 and each vehicle-mounted ECU 40 through the TCU communication unit 32. The TCU communication unit 32 can implement data communication using protocols such as TCP / IP, UDP / IP, and others.

[0036] Even when the vehicle communication unit 10 is parked and the main power supply of the vehicle's Au, specifically the ignition, is off, it can maintain an online connection to the network. The vehicle communication unit 10 operates the ACP engine 10a, which implements the functions of the automotive wireless communication platform 100. In a vehicle Au equipped with one or more vehicle ECUs 40, the ACP engine 10a receives information pushed via wireless communication from outside the vehicle Au and transfers the received push information to the vehicle ECU 40 that serves as the notification destination. The vehicle communication unit 10 implements the functions of the ACP engine 10a by having the processor 11 execute a program stored in the storage medium 13. The vehicle communication unit 10 includes a push receiving unit 21, a progress monitoring unit 22, an address recognition unit 23, a start indication unit 24, and a transmission control unit 25, which are functional units of the ACP engine 10a.

[0037] The push receiving unit 21, progress monitoring unit 22, address identification unit 23, and start instruction unit 24 are functional units that perform actions as push clients. The push receiving unit 21 receives push information from the push distribution unit 121, which is the sending source.

[0038] The progress monitoring unit 22 monitors the wireless connection status between the push server 110 and the push transmission progress status in the in-vehicle network. The progress monitoring unit 22 can cooperate with the progress monitoring unit 122 of the push server 110 to confirm the interconnection between the vehicle communicator 10 and the push server 110 (hereinafter, live / dead monitoring). Furthermore, if the push information fails to reach its destination, the progress monitoring unit 22 notifies the sending source of the push transmission failure along with the reason information associated with the failure. As an example, if the application 40a, which is the destination, or the vehicle ECU 40, disappears from the in-vehicle network, the progress monitoring unit 22 associates this reason information with the push transmission failure and notifies the push server 110, the sending source, of the push transmission failure (see reference). Figure 5 (S47). In the event that the delivery of push information to application 40a fails, the progress monitoring unit 122 associates such reason information with the push delivery failure notification to the push server 110, which is the sending source (see S47). Figure 6 (S67).

[0039] The address identification unit 23 acquires ECU information related to the vehicle ECU 40 that becomes the notification destination of the push notification. Specifically, the address identification unit 23 acquires address information and status information as ECU information. The address information is the information used to determine the vehicle ECU 40 that becomes the notification destination of the push notification from among multiple vehicle ECUs 40. The address identification unit 23 obtains the address information by referring to the information managed by the ID management unit 27, specifically each ID information or token. The status information is information indicating the power status (on / off state) of the vehicle ECU 40 that has been identified as the address. In detail, the so-called power-off state here refers to the state in which the vehicle ECU 40 transitions from the start state to the rest state due to the ignition being turned off, etc. At this time, the vehicle ECU 40 can receive start requests in a power-saving manner, but on the other hand, it is in a state in which communication performed by the ECU communication unit 52 (described later) is not possible.

[0040] Based on the status information obtained by the address recognition unit 23, the start-up instruction unit 24 performs a start-up process to start the vehicle ECU 40 and turn its power on (start-up state) when the power supply of the vehicle ECU 40 identified as the address is in the off state. The start-up instruction unit 24 cooperates with the power control unit 36 ​​to output a start-up control signal (start-up request) to the target vehicle ECU 40 to turn its power on (start-up state).

[0041] The transmission control unit 25 selects the vehicle ECU 40 to be the target of push notification based on the address information held by the address recognition unit 23. The transmission control unit 25, in cooperation with the TCU communication unit 32, notifies the selected vehicle ECU 40 of the push notification. When the vehicle ECU 40 is powered off, the transmission control unit 25 waits for the power to be turned on through a startup process. The transmission control unit 25 then provides the push notification to the vehicle ECU 40 that is powered on.

[0042] ID Management Unit 27 manages which vehicle ECU 40 is located where the application 40a, which becomes the destination of push notifications, is located. Application IDs, ECU IDs, and tokens are registered in ID Management Unit 27. ID Management Unit 27 obtains the application ID associated with each application 40a and the ECU ID associated with each vehicle ECU 40 from each vehicle ECU 40. ID Management Unit 27 notifies ID Management Unit 127 of ACP Cloud 110a of the obtained application ID and ECU ID, along with the TCU ID associated with Vehicle Communicator 10. Through this process, the ID information registered in ID Management Units 27 and 127 is synchronized. ID Management Unit 27 receives the token issued by ID Management Unit 127. ID Management Unit 27 transfers the received token to the vehicle ECU 40 associated with that token.

[0043] The vehicle-mounted ECU 40 can execute one or more applications 40a. Application 40a becomes the notification destination for push information distributed from the push server 110. The vehicle-mounted ECU 40 is equivalent to a terminal ECU. Unlike the vehicle-mounted communicator 10, the vehicle-mounted ECU 40 is, in principle, in a powered-off state to suppress power consumption when the vehicle's Au power is off. At this time, the vehicle-mounted ECU 40's connection to the network is also disconnected. Alternatively, some vehicle-mounted ECUs 40 may not have applications 40a installed. Furthermore, the vehicle-mounted communicator 10 can also be configured in the vehicle system as a structure that accommodates the vehicle-mounted ECU 40, capable of executing applications 40a.

[0044] The vehicle-mounted ECU 40 is a control device that includes a microcontroller as its main component, and includes a password processing unit 51, an ECU communication unit 52, and a power control unit 56. The password processing unit 51 provides password processing functions to establish secure communication between the vehicle-mounted ECU 40 and the vehicle-mounted communicator 10. The ECU communication unit 52 transmits and receives data with the TCU communication unit 32. The power control unit 56 is a control unit that switches the power supply state of the vehicle-mounted ECU 40. Based on receiving a power-on request from the power control unit 36, the power control unit 56 switches the power supply of the vehicle-mounted ECU 40 from the off state to the on state.

[0045] The vehicle ECU 40 includes an information acquisition unit 41, an application identification unit 42, and an ID management unit 43, and serves as a functional unit of the ACP client 44 that relays data between the ACP engine 10a and the application 40a.

[0046] The information acquisition unit 41 collaborates with the ECU communication unit 52 to acquire push notifications sent from the vehicle communicator 10. The push notifications acquired by the information acquisition unit 41 are associated with a token (or application ID).

[0047] If the push notification is received by the information acquisition unit 41, the application identification unit 42 identifies the application 40a that is the destination of the push notification from among multiple applications 40a. The application identification unit 42 determines the application 40a to which the push notification is being transferred by referring to the application ID and token registered in the ID management unit 43 and retrieving the registration information that matches the token associated with the push notification.

[0048] In the ID Management Unit 43, the Application ID and token for identifying the application 40a can be registered by reference by the Application Identification Unit 42. The Application ID is information issued by each application 40a. The ID Management Unit 43 obtains the unique Application ID from each application 40a and notifies the ACP Engine 10a of the Application ID through the ECU Communication Unit 52. The token is information paid from the ACP Cloud 110a. The ID Management Unit 43 obtains the token paid to the ACP Engine 10a through the ECU Communication Unit 52.

[0049] Next, based on Figures 3-6 , refer to Figure 1 and Figure 2 The following details the timing processes implemented on the cloud-side system and between various vehicle-mounted systems.

[0050] Figure 3 The TCU ID registration sequence shown is implemented between the ACP engine 10a and the ACP cloud 110a, for example, when the vehicle communicator 10 is started and initially becomes online. Specifically, the registration sequence is initiated by the ACP engine 10a when the vehicle communicator 10 installed on a new vehicle Au is started, when the swapped vehicle communicator 10 is initially started, or when it changes from a non-communicating state to a communicating state. By registering the sequence, the monitoring of the liveness / liveness of the vehicle communicator 10 and the push server 110 is made effective.

[0051] In S11 and S12, the ACP engine 10a, which has become online, notifies the ACP cloud 110a of the inherent TCU ID associated with the vehicle communicator 10. Specifically, in S11, as part of the TCU ID management process, the TCU ID of the vehicle communicator 10 is read out. In S12, the ACP cloud 110a requests the registration of the TCU ID read out in S11.

[0052] In S13, ACP Cloud 110a performs TCU ID management processing based on the registration request obtained in S12. Specifically, in S13, the TCU ID is associated with the connection destination information and registered with the ID Management Department 127.

[0053] In S14-S16, liveness / death monitoring is performed. This monitoring checks whether the vehicle-mounted communicator 10 is online. Specifically, in S14 and S16, the ACP cloud 110a and the ACP engine 10a monitor each other's connection status. In S15, a specified control packet for liveness / death monitoring is sent from the ACP engine 10a to the ACP cloud 110a. The processes in S14-S16 are repeated at regular time intervals.

[0054] Figure 4 The token payment sequence shown is implemented, for example, when application 40a is installed in the vehicle ECU 40, or when the user of the vehicle Au is changed. Through the token payment sequence, the synchronization of multiple ID information managed by each ID management unit 27, 43, 127, and 141, as well as the tokens, is achieved. Based on the token payment sequence, the terminal-to-terminal association between application server 140 and application 40a is completed.

[0055] In S21, application 40a sends a message requesting to obtain a token to ACP client 44. In S21, the application ID is notified to ACP client 44.

[0056] In S22, as part of the application ID management process, ACP client 44 associates the application ID with application 40a and registers it with ID management department 43. Furthermore, if a token that has already been issued is registered in ACP client 44, ACP client 44 can also implement payment of the token to application 40a after associating the application ID with the token.

[0057] In S23, an ACP client 44 sends a message requesting to obtain a token to the ACP engine 10a. In S23, in addition to the application ID notified from the application 40a, the ECU ID associated with the vehicle ECU 40 is also notified to the ACP engine 10a.

[0058] In S24, as part of ECU ID management, the ACP engine 10a registers the application ID and ECU ID with the ID management unit 27 while associating them. Then, in S25, as part of TCU ID management, the ACP engine 10a registers the TCU ID with the ID management unit 27 while associating it with both the application ID and ECU ID. By associating multiple IDs through S21 to S25, the ACP engine 10a can identify the application 40a as the destination of a push notification when it receives one. As a result, the differences in the ECU structure of each vehicle's in-vehicle system are hidden from the ACP cloud 110a side.

[0059] In S26, a message requesting to obtain a token is sent from ACP engine 10a to ACP cloud 110a. In S26, the application ID, ECU ID, and TCU ID are notified to ACP cloud 110a.

[0060] In S27, as part of the ID management process, the application ID, ECU ID, and TCU ID are associated with each other and registered in the ID management unit 127. Additionally, in S27, the ID management unit 127 of the ACP cloud 110a issues a token as a unique ID associated with the identification information of the application 40a, the vehicle ECU 40, and the vehicle communicator 10—that is, a combination of each ID. After issuing the token, the ID management unit 127 continues the association management of each ID and the token.

[0061] In S28, the token issued in S27 is paid from ACP Cloud 110a to ACP Engine 10a. ACP Engine 10a stores the token obtained from ACP Cloud 110a in ID Management Department 27. In S29, the payment of the token from ACP Engine 10a to ACP Client 44 is implemented.

[0062] In S30, as part of the management of the application ID and token, the ACP client 44 associates the token with the application ID and registers it with the ID management department 43. In S31, the payment of the token from the ACP client 44 to the application 40a is implemented.

[0063] In S32, as part of the token management process, application 40a associates the token with the application ID. In S33, as part of the application ID management process, the association management between the application ID and the token is implemented.

[0064] In S34, the application ID and token are notified to the specific application server 140 associated with the service provided by application 40a. This completes the association between the services of application 40a and application server 140. In S35, as part of the management of the application ID and token, application server 140 registers the application ID and token notified from application 40a with the ID management unit 141, linking them together. By sharing the token, application server 140 becomes capable of sending push notifications to token-based destinations. Meanwhile, application 40a becomes capable of receiving push services.

[0065] Figure 5 and Figure 6 The push distribution sequence shown begins when push distribution is decided upon in the application server 140. Through the push distribution sequence, push information is distributed to the application 40a designated as the notification destination by the application server 140. Furthermore, during the push distribution sequence, the progress monitoring unit 22 of the ACP engine 10a sequentially notifies the progress monitoring unit 122 of the ACP cloud 110a of the progress. Then, the ACP cloud 110a notifies the application server 140 of the push distribution progress. By sequentially replying to messages during this push distribution process, the application server 140 can track the location of the push information and whether the push to the application 40a was successfully sent. Moreover, the tracking of push distribution progress performed by the application server 140 can be arbitrarily omitted if it is not required by the service.

[0066] In S41, the application server 140 sends a message requesting the implementation of push distribution to the ACP cloud 110a. In S41, the application server 140 uses a token as a key to request the implementation of push distribution from the ACP cloud 110a. In S41a, the ACP cloud 110a sends a message to the application server 140 notifying it of receipt of the push distribution request.

[0067] In S41b, the destination of the push notification is identified. In S41b, ACP Cloud 110a determines the vehicle communicator 10 (ACP engine 10a) associated with the vehicle Au, which is the destination of the push notification, based on a token obtained from the application server 140, which is the request source for the push notification. Specifically, ACP Cloud 110a retrieves the vehicle communicator 10 with the TCU ID associated with the obtained token, referring to the storage information of ID Management Unit 127. In S42, ACP Cloud 110a returns information about the vehicle communicator 10, which identifies the destination of the push notification, to the application server 140 as a progress notification.

[0068] In S43, ACP cloud 110a monitors the connection status of the vehicle communicator 10 determined in S41b and determines whether the vehicle communicator 10 is online. If the vehicle communicator 10 is offline, in S44, ACP cloud 110a notifies application server 140 of a push delivery failure message. In this case, ACP cloud 110a also notifies application server 140 that the vehicle communicator 10 is offline, as a reason for the delivery failure. As described above, it is also possible to wait for the vehicle communicator 10 to connect to the network until the specified retry period has elapsed.

[0069] On the other hand, when the vehicle communicator 10 is online, in steps S45 and S46, the distribution of push notifications to the vehicle communicator 10 begins. In step S46, a token is sent to the ACP engine 10a at least once. Then, in step S47, the ACP engine 10a receives the message body and token of the push notification sent from the ACP cloud 110a in step S46. In step S48, as a notification of push notification distribution progress, the ACP engine 10a returns a message indicating that the push notification distribution has been received to the ACP cloud 110a. In step S49, the ACP cloud 110a notifies the application server 140 of the push notification distribution progress.

[0070] In S50, the ECU information related to the vehicle ECU 40 that becomes the notification destination of the push notification is obtained, and the distribution destination of the push notification is identified. In this S50, the ACP engine 10a determines the vehicle ECU 40 with the ECU ID associated with the received token by referring to the storage information of the ID management unit 27. When the received token exists in the storage information of the ID management unit 27, the ACP engine 10a obtains the address information of the vehicle ECU 40 that is determined to be the notification destination of the push notification from among multiple vehicle ECUs 40, and the status information indicating the power status of the determined vehicle ECU 40.

[0071] On the other hand, if the received token is not stored in the ID management department 27's storage information, in S51, ACP engine 10a notifies ACP cloud 110a of a push delivery failure message. In this case, ACP engine 10a also notifies ACP cloud 110a that the push delivery address is unclear, as a reason for the delivery failure. In S52, ACP cloud 110a forwards the failure notification and reason information received from ACP engine 10a to application server 140. Furthermore, for example, the push delivery address may become unclear due to changes or deletions to application 40a, or changes to users.

[0072] In S53, the ACP engine 10a implements a notification of push information corresponding to the ECU information obtained in S50. In S53, push information is provided to the ACP client 44 of the identified vehicle ECU 40. If the power supply to the identified vehicle ECU 40 is off, in S54, the ACP engine 10a sends a start control request message to the vehicle ECU 40. Sending the start control request message is equivalent to a start process that initiates the start of the vehicle ECU 40.

[0073] In S55, the on-board ECU 40, having received the start request message for start control, returns a message indicating that it has received start control to the ACP engine 10a. In S56 and S57, as a progress notification for push distribution, a message indicating the start of start of the on-board ECU 40 is sequentially sent to the ACP cloud 110a and the application server 140.

[0074] In S58, the startup control initiated by the power control unit 56 turns on the vehicle ECU 40 (startup state). Thus, the vehicle ECU 40 becomes effectively communicable. In S59, a message indicating that the power is on (startup complete) is sent from the ACP client 44 to the ACP engine 10a. In S60 and S61, as a progress notification for push distribution, a message indicating that the power of the vehicle ECU 40 is on is sequentially sent to the ACP cloud 110a and the application server 140.

[0075] In S62, the ACP engine 10a sends a push notification to the ACP client 44 of the vehicle ECU 40, whose power is turned on through the startup process. In S62, at least one token is sent to the ACP client 44. In S63, as a progress notification of the push notification distribution, the ACP client 44 returns a message indicating that it has received the push notification distribution to the ACP engine 10a. In S64 and S65, the message indicating that the push notification distribution has been received by the ACP client 44 is sequentially sent to the ACP cloud 110a and the application server 140.

[0076] Here, when push delivery from ACP engine 10a to ACP client 44 fails, in S66, ACP client 44 notifies ACP engine 10a of the push delivery failure message. In this case, ACP client 44 also notifies ACP engine 10a that the push delivery address is unclear, as a reason for the delivery failure. In S67 and S68, the failure notification and reason information returned to ACP engine 10a are sequentially sent to ACP cloud 110a and application server 140.

[0077] In S69, ACP client 44 receives the message body of the push notification. In S69a, as a progress notification of push distribution, ACP client 44 returns a message indicating that push reception is complete to ACP engine 10a. In S69b and S69c, the message indicating that push reception by ACP client 44 is complete is sequentially sent to ACP cloud 110a and application server 140.

[0078] In S70, the destination of the push notification is identified. In S70, the ACP client 44 determines the application 40a as the notification destination for the push message. In S71 and S72, the ACP client 44 provides the push message, i.e., the message body, to the application 40a identified in S70. In S73, the application 40a returns a message indicating that it has received the service based on the push notification to the ACP client 44. In S74 and S75, the ACP engine 10a and the ACP cloud 110a are notified that the push message has arrived at the notification destination application 40a. Then, in S76, a push progress notification indicating successful push delivery is sent to the application server 140, which is the sending source. As a result, in S77, application communication (data communication) between application 40a and application server 140 begins. As an example, in S77, application 40a sends the service information requested by the push message to application server 140.

[0079] If within the specified retry period, each sending source will repeatedly send push information based on the above push distribution sequence. In this case, the sending side of the push information can grasp the status of the destination through push progress notifications or distribution failure notifications. Therefore, the sending side of the push information will resend the push information within the retry period of repeated push information sending and if it can grasp that the failure reason shown in the reason information has been eliminated. Such redistribution processing can be appropriately implemented by ACP Cloud 110a, ACP Engine 10a, and ACP Client 44.

[0080] In the embodiment described above, the receiving side (ACP engine 10a) that receives push notifications from the external source (ACP cloud 110a) knows ECU information related to the vehicle ECU 40 that is the notification destination of the push notification. Furthermore, the push notification corresponding to this ECU information is sent to the vehicle ECU 40. Therefore, for example, even if the source sending the push notification does not have detailed information related to the vehicle ECU 40, such as the structure of the vehicle system and the power switch status, the push notification can still reach the correct notification destination. Therefore, the convenience of push notification delivery can be improved.

[0081] Furthermore, in this embodiment, the vehicle ECU 40 that is the notification destination of the push message is determined from among multiple vehicle ECUs 40. The push message is then provided to the determined vehicle ECU 40. As described above, if the receiving side of the push message can determine the vehicle ECU 40 that is the notification destination of the push message, the push message can reach the correct vehicle ECU 40 even if the sending source of the push message does not know the specific structure of the vehicle system.

[0082] Furthermore, in this embodiment, the power state of the vehicle ECU 40 that is the notification destination of the push message is determined. Then, the push message is provided to the vehicle ECU 40, which is in a powered-on state. As described above, if the receiving side of the push message is limited to providing push messages to vehicle ECU 40 in a powered-on state, the push message can reach the correct vehicle ECU 40 even if the sending source of the push message does not know the power state of the vehicle ECU 40.

[0083] Furthermore, in this embodiment, when the power supply to the vehicle ECU 40, which is the destination of the push notification, is off, a startup process is performed to start the vehicle ECU 40. Then, the push notification is provided to the vehicle ECU 40, whose power supply has been turned on through the startup process. Therefore, even in scenarios where the vehicle ECU 40 is off, such as when the vehicle is parked, the source of the push notification can distribute the push notification without knowing the on / off state of the vehicle ECU 40. This further improves the convenience of push notification delivery.

[0084] Furthermore, in this embodiment, the application 40a to which the push notification is destined is determined from among multiple applications 40a operating in a vehicle ECU 40. Then, the push notification is provided to the determined application 40a. As described above, if the vehicle ECU 40 can determine the application 40a to which the push notification is destined, the push notification can reach the correct application 40a even if the source of the push notification does not know the application structure within the vehicle system. Therefore, the convenience of push notification delivery can be further improved.

[0085] Furthermore, in this embodiment, if the push notification fails to reach its destination, the push failure, along with the reason for the failure, is sent to the sending source. Therefore, even without knowledge of the vehicle-side system architecture, ACP Cloud 110a and application server 140 can still monitor the push distribution status. This further improves the convenience of push notifications.

[0086] Furthermore, in this embodiment, a successful push notification is sent to the sending source once the push information reaches its destination. Therefore, even without knowledge of the vehicle-side system architecture, ACP Cloud 110a and application server 140 can still monitor the push distribution status. This further enhances the convenience of push notification delivery.

[0087] Furthermore, in this embodiment, the sending source (ACP cloud 110a) of the push notification determines the vehicle communicator 10 associated with the vehicle Au that is the destination of the push notification based on the request information obtained from the push notification request source (application server 140). Additionally, the vehicle communicator 10 receiving the push notification can determine the vehicle ECU 40 that is the notification destination of the push notification. Therefore, even if the push notification request source does not have detailed information related to the vehicle Au and its system structure, the push notification can still reach the correct notification destination. Thus, the convenience of push notification can be improved.

[0088] Here, the response required for push notifications varies depending on the content of the service provided. For example, in providing a service such as unlocking a vehicle's doors (e.g., the ECU 40 instructing the door to unlock), a push notification requires a higher response time. Conversely, push notifications used solely for informational purposes do not require a higher response time. Therefore, the ACP Cloud 110a can set a retry period corresponding to the content of the service provided through push notifications and repeatedly send information within that retry period.

[0089] Furthermore, in this embodiment, if the push notification fails, ACP Cloud 110a receives reason information associated with the failure. Moreover, if ACP Cloud 110a has determined that the reason for the failure has been eliminated, it will resend the push notification within the retry period. This retry implementation maintains the quality of the push delivery service and improves the success rate of push delivery.

[0090] Furthermore, in this embodiment, the ACP cloud 110a is associated with combinations of IDs that respectively identify the vehicle communicator 10, the vehicle ECU 40, and the application 40a, and a token is issued to determine the notification destination of the push notification. Moreover, the application ID is incorporated into the token in this embodiment. Using such a token, even if the IDs may be duplicated, the correct push notification distribution destination can be determined.

[0091] Furthermore, the token in this embodiment has an expiration date. Therefore, in shared cars or similar services where the user changes, push notifications can be sent only during the period a specific user is using the service. As a result, the convenience of push notifications is further improved.

[0092] Furthermore, in the above embodiment, the vehicle-mounted communicator 10 is equivalent to a "wireless communicator" and a "communication device," and the address identification unit 23 is equivalent to a "control unit." In addition, the address information and status information are equivalent to "ECU information," the TCU ID and ECUID are equivalent to "identification information," and the application ID and token are equivalent to "request information."

[0093] (Other implementation methods)

[0094] The above describes one embodiment of the present disclosure, but the present disclosure is not limited to the above embodiment and can be applied to various embodiments and combinations without departing from the spirit of the present disclosure.

[0095] In Variation 1 of the above-described embodiment, only one vehicle ECU 40 is provided in the vehicle system to activate application 40a. In this Variation 1, the function of obtaining address information from the ACP engine 10a and determining the vehicle ECU 40 that becomes the notification destination of the push message from among multiple vehicle ECUs 40 can be omitted. As described above, the vehicle ECU 40 that becomes the address for push notification can be one or multiple.

[0096] In Variation 2 of the above-described embodiment, the functions of acquiring status information and determining the power status of the vehicle ECU 40, which is the notification destination of the push information, and the processing function of starting the vehicle ECU 40 are omitted from the ACP engine 10a.

[0097] In Variation 3 of the above-described embodiment, only one application 40a is mounted in the vehicle ECU 40. In this Variation 3, the function of determining the application 40a as the notification destination of the push message from multiple applications 40a is omitted from the ACP client 44.

[0098] In Variation 4 of the above-described implementation, a portion of the function of notifying ACP Cloud 110a of the progress and successful distribution of push notifications is omitted. Such progress monitoring is preferably necessary before progress monitoring is performed by ACP Cloud 110a. On the other hand, since the notification from ACP Cloud 110a to application server 140 depends on the purpose of push distribution in the service, it can be arbitrary in Variation 4. In addition, in Variation 4, the process of setting a retry period and repeatedly sending push notifications is omitted.

[0099] In Variation 5 of the above-described embodiment, no expiration date is set for the token. Furthermore, in Variation 6 of the above-described embodiment, the token issuance function is omitted. In Variation 6, the ACP cloud 110a uses the application ID as a key to identify the vehicle communicator 10 sending push notifications. Additionally, the ACP engine 10a uses the application ID as a key to identify the vehicle ECU 40 sending push notifications.

[0100] In the above embodiments, the functions provided by the vehicle-mounted communicator 10 and the ACP cloud 110a can also be provided through software and hardware executing the software, software only, hardware only, or a combination thereof. Furthermore, when such functions are provided by electronic circuits as hardware, each function can also be provided through digital circuits or analog circuits that include multiple logic circuits.

[0101] In the above embodiments, each processor 11, 111 is hardware integrated with RAM 12, 112 for computational processing, and constitutes the main structure of the computer implementing the information transmission method of this disclosure. Each processor 11, 111 is a structure that includes at least one CPU (Central Processing Unit) or similar computational core. The processing circuit including processors 11, 111 can also be a structure based on FPGA (Field-Programmable Gate Array) and ASIC (Application-Specific Integrated Circuit).

[0102] Storage media 13 and 113 are non-volatile storage media. Various programs (such as information transmission programs) executed by processors 11 and 111 are stored in each storage medium 13 and 113. The form of such storage media 13 and 113 can be appropriately changed. For example, storage media 13 and 113 are not limited to a structure mounted on a circuit board; they can be provided in the form of a memory card, inserted into a slot, and electrically connected to the processing circuitry of the vehicle communicator 10 and the push server 110. Furthermore, storage media 13 and 113 can also be optical discs or hard disk drives, which serve as the basis for program copying.

[0103] The control unit and method described in this disclosure can also be implemented by a dedicated computer, which constitutes a processor programmed to perform one or more functions embodied by a computer program. Alternatively, the apparatus and method described in this disclosure can also be implemented by dedicated hardware logic circuitry. Alternatively, the apparatus and method described in this disclosure can also be implemented by one or more dedicated computers consisting of a processor executing a computer program and a combination of one or more hardware logic circuits. Furthermore, the computer program can also be stored as instructions executed by a computer on a computer-readable non-transferable tangible recording medium.

Claims

1. An information transmission method, which is a method for pushing and transmitting information from outside a vehicle to at least one on-board ECU based on wireless communication. A process executed by at least one processor includes the following steps: Receive push information from the aforementioned external sending sources; Possessing ECU information related to the aforementioned vehicle ECU that becomes the primary destination of the aforementioned push notifications; and The notification of the aforementioned push information corresponding to the ECU information implemented and mastered. When the push notification cannot be sent to the vehicle ECU, the failure to send the push notification, along with a first reason associated with the failure, is notified to the external sending source. The first reason indicates that due to a change in the vehicle's user or a change or deletion of an application that serves as a second notification destination (different from the first notification destination), the vehicle ECU that was the first notification destination for the push notification has disappeared, or the sending of the push notification to the vehicle ECU has failed. If the vehicle ECU determines that the application is unclear, it sends a second reason information to the vehicle indicating that the destination of the notification sent is unclear.

2. The information sending method according to claim 1, wherein, In the step of obtaining the aforementioned ECU information, the vehicle ECU that becomes the notification destination of the aforementioned push information is determined from among the multiple aforementioned vehicle ECUs. In the step of notifying the aforementioned push information, the aforementioned push information is provided to the identified vehicle ECU.

3. The information sending method according to claim 1, wherein, In the steps of obtaining the aforementioned ECU information, the power status of the aforementioned vehicle ECU, which is the notification destination of the aforementioned push information, is determined. In the step of notifying the aforementioned push information, the aforementioned push information is provided to the aforementioned vehicle ECU, which is in the powered-on state.

4. The information sending method according to claim 3, wherein, It also includes the following steps: when the power supply to the aforementioned vehicle ECU, which is the notification destination of the aforementioned push message, is in a powered-off state, a startup process is implemented to start the aforementioned vehicle ECU. In the step of notifying the above-mentioned push information, the push information is provided to the vehicle ECU whose power is turned on through the above-mentioned startup process.

5. The information sending method according to claim 1, wherein, It also includes the following steps: The application that becomes the notification destination of the push message is determined from among multiple applications operating in one of the aforementioned vehicle ECUs. The aforementioned push notification information will be provided to the identified applications.

6. The information transmission method according to any one of claims 1 to 5, wherein, It also includes the following steps: when the above-mentioned push information arrives at the notification destination, a notification of successful push sending is sent to the above-mentioned sending source.

7. The information sending method according to claim 1, wherein, The aforementioned push notification was sent when the vehicle ECU did not request the sending of the aforementioned push notification information.

8. A communication device, in a vehicle equipped with at least one on-board ECU, receiving information pushed and transmitted wirelessly from outside the vehicle. The aforementioned communication device includes: The push receiving unit receives push information from the aforementioned external sending source; The control unit controls the ECU information related to the aforementioned vehicle ECU that becomes the first notification destination of the aforementioned push notification; and The control unit sends a notification to the aforementioned push information corresponding to the ECU information it has acquired. When the push notification cannot be sent to the vehicle ECU, the failure to send the push notification, along with a first reason associated with the failure, is notified to the external sending source. The first reason indicates that due to a change in the vehicle's user or a change or deletion of an application that serves as a second notification destination (different from the first notification destination), the vehicle ECU that was the first notification destination for the push notification has disappeared, or the sending of the push notification to the vehicle ECU has failed. If the vehicle ECU determines that the application is unclear, it sends a second reason information to the vehicle indicating that the destination of the notification sent is unclear.

9. An information transmission method, comprising pushing and transmitting information from outside a vehicle to an on-board ECU of at least one of a plurality of vehicles based on wireless communication. A process executed by at least one processor includes the following steps: Based on the request information obtained from the request source of the aforementioned push notification, the wireless communication device associated with the aforementioned vehicle, which is the destination of the push notification, is determined. The wireless communication device, which has the function of determining the vehicle ECU as the first notification destination of the aforementioned push information, sends the push information. When the push notification cannot be sent to the vehicle ECU, the failure to send the push notification, along with a first reason associated with the failure, is notified to the external sending source. The first reason indicates that due to a change in the vehicle's user or a change or deletion of an application that serves as a second notification destination (different from the first notification destination), the vehicle ECU that was the first notification destination for the push notification has disappeared, or the sending of the push notification to the vehicle ECU has failed. If the vehicle ECU determines that the application is unclear, it sends a second reason information to the vehicle indicating that the destination of the notification sent is unclear.

10. The information transmission method according to claim 9, wherein, It also includes the following steps: When the aforementioned push notification fails, obtain information about the reason associated with the failure. The aforementioned push message will be sent again only after the retry period for repeatedly sending the push message has been completed and the failure reason indicated in the aforementioned reason information has been eliminated.

11. The information transmission method according to claim 9 or 10, wherein, It also includes the following steps: issuing a token for determining the notification destination of the push message, associated with a combination of identification information that respectively identifies the wireless communication device, the vehicle ECU, and the application operating in the vehicle ECU. In the step of determining the aforementioned wireless communication device, the aforementioned token is used to determine the aforementioned destination of the aforementioned push information.

12. The information transmission method according to claim 11, wherein, The above tokens have a validity period set.

Images