Intermediary device, intermediary method, and intermediary program

Abstract

By periodically receiving vehicle data from the ECU or VCU and storing the time-series data, it becomes possible to request the calculation software to calculate battery consumption using the predicted data, even if communication with the ECU or VCU is interrupted. [Solution] The intermediary application comprises a first communication unit that receives a first calculation request from the navigation application, a second communication unit that periodically receives vehicle data, including at least the vehicle's battery level, from the ECU or VCU installed in the vehicle, a storage unit that stores time-series data of the received vehicle data, and a third communication unit that sends a second calculation request including prediction data to calculation software that calculates a predicted value of the battery level at the time of arrival at the destination, and receives the battery consumption calculation result from the calculation software, and the first communication unit sends the calculation result to the navigation application.

Description

Technical Field

[0001] The present invention relates to an intermediary device, an intermediary method, and an intermediary program.

Background Art

[0002] In the technical field of electric vehicles, from the viewpoints of increasing the driving range and reducing the electricity cost, attempts have been made to select a driving route that minimizes the consumption of the battery mounted on the vehicle by calculating the consumption of the battery.

[0003] Patent Document 1 discloses a driving route selection system for an electric truck that can further improve the electricity cost. This driving route selection system includes a map information acquisition means, a transport weight information acquisition means, a variation information estimation means, and an optimal route selection means. The map information acquisition means acquires map information including the transport start point information of the electric truck and the transport route information from the transport start point to the luggage loading / unloading point. The transport weight information acquisition means acquires transport weight information including the initial weight information of the initial load loaded at the transport start point and the loading / unloading weight information of the luggage loaded / unloaded at the luggage loading / unloading point. The variation information acquisition means estimates the variation information of the total load weight that varies during transportation based on the transport weight information. The optimal route selection means selects an optimal route based on the basic information including the map information and the variation information.

[0004] Patent Document 2 discloses an information providing device that can provide useful information regarding the drivable distance, taking into account the characteristic that fuel efficiency changes significantly depending on the route. This information providing device sets multiple provisional destinations in dispersed directions based on the current location of the electric vehicle and searches for each route to each of the multiple provisional destinations. Furthermore, this information providing device calculates the drivable distance for each of the searched routes based on the current battery level and provides information based on the calculated distances. In this way, when no guided route to a destination has been set, this information providing device does not provide information indicating the drivable distance for a specific single route, but rather provides information that takes into account the multiple drivable distances calculated for multiple dispersed routes.

[0005] Patent Document 3 discloses an information processing device that can contribute to promoting the switch of internal combustion engine vehicle users to BEVs. In this information processing device, a control unit acquires the operation history of an internal combustion engine vehicle over a first period. The control unit determines whether battery charging will be required during the operation of the first BEV, assuming that the first BEV is operated according to the operation schedule shown in the acquired operation history. If it is determined that battery charging will be required during the operation of the first BEV, the control unit generates first information including information regarding the charging timing and charging location, and outputs the generated first information through a first terminal. [Prior art documents] [Patent Documents]

[0006] [Patent Document 1] Japanese Patent Publication No. 2018-017672 [Patent Document 2] Japanese Patent Publication No. 2020-112425 [Patent Document 3] Japanese Patent Publication No. 2023-076183 [Overview of the project] [Problems that the invention aims to solve]

[0007] With the increasing popularity of electric vehicles, numerous application development vendors are developing apps (navigation apps) that allow users to view battery consumption and, consequently, driving routes that minimize consumption—in other words, eco-routes—on their devices (such as smartphones). This will increase convenience for electric vehicle users, as they can check their battery consumption (remaining charge) and eco-routes on their devices.

[0008] However, vendors lack the information necessary to calculate power consumption for each individual vehicle, such as battery consumption calculation methods and real-time vehicle data, which limits the improvement of the app's calculation accuracy.

[0009] Furthermore, vendors are developing fault prediction apps that can diagnose and even predict vehicle failures. However, similar to the power consumption issue mentioned above, these apps lack the necessary information for fault diagnosis and prediction, which is expected to limit the accuracy of their calculations.

[0010] The present invention provides an intermediary device, an intermediary method, and an intermediary program capable of improving the computational accuracy of an application. [Means for solving the problem]

[0011] To achieve the aforementioned objectives, the intermediary device according to the present invention has the following features. A first communication unit receives a first calculation request from a first computing device, which includes at least the estimated time of arrival at the destination. A second communication unit periodically receives vehicle data, including at least the vehicle's battery level, from a vehicle control device mounted on the vehicle. A storage unit for storing the time-series data of the received vehicle data, The system includes a second computing device that calculates a predicted value of the remaining battery charge at the time of arrival at the destination, a third communication unit that transmits a second calculation request including the time-series data to the second computing device, and receives the calculation result from the second computing device, The first communication unit transmits the calculation result to the first computing device. Intermediary device.

[0012] To achieve the aforementioned objectives, the mediation method according to the present invention is characterized by the following: The first computing device receives a first calculation request that includes at least the estimated time of arrival at the destination. The vehicle control unit installed in the vehicle periodically receives vehicle data, including at least the vehicle's battery level. The time-series data of the received vehicle data is stored, A second calculation request including the time-series data is transmitted to a second computing device that calculates a predicted value of the remaining battery charge at the time of arrival at the destination, and the calculation result is received from the second computing device. The calculation result is transmitted to the first computing device. A mediation method using an intermediary device.

[0013] To achieve the aforementioned objectives, the mediation program according to the present invention has the following features: The steps include receiving a first calculation request from a first computing device, which includes at least the estimated time of arrival at the destination, The steps include receiving vehicle data periodically from a vehicle control device installed in the vehicle, including at least the vehicle's battery level, The steps include storing the time-series data of the received vehicle data, The steps include sending a second calculation request, including the time-series data, to a second computing device that calculates a predicted value of the remaining battery charge at the time of arrival at the destination, and receiving the calculation result from the second computing device, The steps include transmitting the calculation result to the first computing device, An intermediary program that causes a computer to execute a command. [Effects of the Invention]

[0014] According to the present invention, by periodically receiving vehicle data from a vehicle control device and storing the time-series data thereof, even when communication with the vehicle control device is interrupted, the mediation device can request the second computing device to calculate a predicted value of the remaining battery level at the time of arrival at the destination using the time-series data. Further, since the calculation result by the second computing device is transmitted to the first computing device via the mediation device, the accuracy of the calculation by the first computing device can be improved.

[0015] The present invention has been briefly described above. Further, the details of the present invention will be further clarified by reading through the embodiments (hereinafter referred to as "embodiments") for carrying out the invention described below with reference to the accompanying drawings.

Brief Description of the Drawings

[0016] [Figure 1] FIG. 1 is a network configuration diagram of a mediation system according to the first embodiment. [Figure 2] FIG. 2 is a block diagram of a terminal device in the mediation system according to the first embodiment. [Figure 3] FIG. 3 is a block diagram of a vehicle in the mediation system according to the first embodiment. [Figure 4] FIG. 4 is a block diagram of a first cloud server in the mediation system according to the first embodiment. [Figure 5] FIG. 5 is a sequence diagram showing data exchange among a terminal device, a vehicle, and a first cloud server in the mediation system according to the first embodiment. [Figure 6] FIG. 6 is a sequence diagram showing the authentication process among a terminal device, a vehicle, and a first cloud server in the mediation system according to the first embodiment. [Figure 7] FIG. 7 is a block diagram of a terminal device in a mediation system related to battery failure prediction. [Figure 8] FIG. 8 is a block diagram of a first cloud server in a mediation system related to battery failure prediction. [Figure 9]Figure 9 is a sequence diagram showing the exchange of data between the terminal device, the vehicle, and the first cloud server in the intermediary system for battery failure prediction. [Figure 10] Figure 10 is a block diagram of a vehicle in the mediation system according to the second embodiment. [Figure 11] Figure 11 is a sequence diagram showing the exchange of data between a terminal device, a vehicle, and a first cloud server in the mediation system according to the second embodiment. [Figure 12] Figure 12 shows a specific example of steps S41 to S44 in Figure 11. [Figure 13] Figure 13 is a table showing the calculation conditions for calculating battery consumption in the mediation system according to the third embodiment. [Figure 14] Figure 14 is a sequence diagram showing the exchange of data between a terminal device and a vehicle in the mediation system according to the third embodiment. [Figure 15] Figure 15 is a network configuration diagram of the intermediary system according to the fourth embodiment. [Figure 16] Figure 16 is a block diagram of the second cloud server in the intermediary system according to the fourth embodiment. [Figure 17] Figure 17 shows an example of weight information based on a delivery plan, which is held in the operation management database of the intermediary system according to the fourth embodiment. [Figure 18] Figure 18 is a block diagram of the terminal device in the mediation system according to the fifth embodiment. [Figure 19] Figure 19 is a sequence diagram showing the exchange of data between a terminal device, a vehicle, and the first cloud server in the mediation system according to the fifth embodiment. [Figure 20] Figure 20 is an explanatory diagram regarding the prediction of battery level during communication interruption in the mediation system according to the fifth embodiment. [Figure 21] Figure 21 is an explanatory diagram regarding the prediction of battery remaining charge when communication is interrupted while using vehicle equipment in the mediation system according to the fifth embodiment. [Figure 22] Figure 22 is a block diagram of the terminal device in the mediation system according to the sixth embodiment. [Figure 23] Figure 23 is a sequence diagram showing the exchange of data between a terminal device and a vehicle in the mediation system according to the sixth embodiment. [Modes for carrying out the invention]

[0017] Specific embodiments of the present invention will be described below with reference to the figures.

[0018] (First Embodiment) Figure 1 shows a system configuration diagram of the mediation system 100 according to the first embodiment. The mediation system 100 includes terminal devices 10 that can communicate with each other via a network N such as the Internet, a vehicle 20, and a first cloud server 30. The mediation system 100 is a system that can mediate information such as the battery consumption of the vehicle 20 according to the driving route, and eco-routes that can reduce battery consumption, for example, when the vehicle 20 is an electric vehicle.

[0019] Terminal device 10 is an electronic terminal used by users, including the driver of vehicle 20, and is a mobile device such as a smartphone, mobile phone, or tablet. Terminal device 10 can wirelessly connect to network N via base station B using a mobile phone network such as LTE (Long Term Evolution) or 5G.

[0020] Vehicle 20, like terminal device 10, can wirelessly connect to network N via base station B. The first cloud server 30 can communicate with terminal device 10 and vehicle 20 via network N. The first cloud server 30 is a server operated by, for example, the manufacturer of vehicle 20, and holds data related to the manufactured vehicle.

[0021] Figure 2 is a block diagram of the terminal device 10 in the mediation system 100 according to the first embodiment. The terminal device 10 includes a control unit 11, a transmitting / receiving unit 12, a navigation application 13, and a mediation application 14. The control unit 11 is a computer, processor (arithmetic unit) that controls the overall operation of the terminal device 10, and causes the terminal device 10 to execute predetermined processes by reading various programs, applications, data, etc. from a storage device (not shown).

[0022] The transmitting / receiving unit 12 is the part that transmits and receives data with external devices, including the vehicle 20 and the first cloud server 30, via the network N and base station B.

[0023] Navigation app 13 is an application that can provide users of terminal device 10 with information such as the battery consumption of the vehicle 20 according to the driving route, and eco-routes that can reduce battery consumption. Navigation app 13 is launched when the user of terminal device 10 taps an icon. Navigation app 13 is developed by, for example, an application development vendor and is provided by the user by downloading it to terminal device 10 via the network N. With the spread of electric vehicles, an unspecified number of application development vendors are developing navigation apps 13 that can display battery consumption and, consequently, driving routes that can reduce consumption, i.e., eco-routes, on terminal device 10.

[0024] The navigation app 13 can display battery consumption on a display (not shown) of the terminal device 10, and can also display an eco-route on the map on the display. Users can check the battery consumption (remaining charge) and the eco-route on the terminal device 10, thus increasing convenience. In addition, the navigation app 13 may display routes on the map that meet specified conditions, such as routes with shorter travel times or routes that allow arrival at the destination by a specified time, from among multiple route options from the starting point to the destination, not only the eco-route but also routes with shorter travel times. The navigation app 13 may also display battery consumption (remaining charge) along with the route that meets the specified conditions. However, the navigation app 13 may be stored on another cloud server, and the terminal device 10 may only display the processing results of the navigation app 13.

[0025] The intermediary application 14 includes a first communication unit 15, a second communication unit 16, a third communication unit 17, an authentication unit 18, and a verification unit 19. The intermediary application 14 is developed, for example, by the manufacturer of the vehicle 20 or by the developer of the vehicle control unit ECU 21 or VCU 24 (see Figure 3), which is the vehicle control device of the vehicle 20, as described later. The intermediary application 14 is provided, for example, by being downloaded by the user to the terminal device 10 via the network N. As described later, the intermediary application 14 links the navigation application 13, the ECU 21 or VCU 24 of the vehicle 20, and the calculation software 32 (see Figure 4) of the first cloud server 30. The intermediary application 14 is an application aimed at improving the calculation accuracy of the navigation application 13 by mediating the exchange of necessary data between these components. The intermediary application 14 has no user interface and continues to run in the background at all times. Details of the intermediary application 14 will be described later.

[0026] Figure 3 is a block diagram of a vehicle 20 in the intermediary system 100 according to the first embodiment. The vehicle 20 includes an ECU 21, a BMS 22, a PCU 23, a VCU 24, a weight scale 25, other units 26, a vehicle data storage unit 27, and a transmitting / receiving unit 28. The ECU 21 stands for Electronic Control Unit, and is a computer or processor that controls all systems of the vehicle 20. Each block constituting the vehicle 20 exchanges data via the vehicle network.

[0027] BMS22 stands for Battery Management System, and it is a system that provides the ECU21 with information on the vehicle 20's battery status (remaining capacity [Ah], SOC [%]: State of Charge, power supply voltage [V], etc.) and is responsible for the safe control of the battery. PCU23 stands for Power Control Unit, and it is a system that manages the power of the vehicle 20, and includes an inverter for motor control, a DC-DC converter for voltage boosting, etc.

[0028] VCU24 stands for Vehicle Control Unit, also known as integrated vehicle control electronic equipment. It is a unit that integrates and controls the power supply, drive force control, body control, etc., of the vehicle 20 into a single ECU21. The VCU24 is also a computer or processor that controls all systems of the vehicle 20. The ECU21 or VCU24 is sometimes called a vehicle control device that performs overall control of the vehicle 20, and operates, for example, with pre-installed firmware. In addition, the ECU21 or VCU24 and the BMS22 may cooperate to transmit vehicle data, including at least the battery level of the vehicle 20.

[0029] The weighing scale 25 is a measuring instrument that measures the weight of the vehicle 20 and can calculate the total weight, including the weight of the cargo and the weight of the passengers. Other units 26 is a general term for other equipment in the vehicle 20 that consumes power, including air conditioning equipment. The vehicle data storage unit 27 acquires, stores, and updates real-time vehicle data via the vehicle network. The vehicle data includes at least the basic characteristics of the vehicle 20, which may include battery characteristics, motor characteristics, vehicle weight, etc. Furthermore, the vehicle data may include variable conditions that change in real time depending on the situation, which may include battery level, battery temperature, power consumption of equipment, cargo weight, etc. Real-time vehicle data includes the latest vehicle data.

[0030] The transmitting / receiving unit 28 is the part that transmits and receives data with external devices, including the terminal device 10 and the first cloud server 30, via the network N and base station B.

[0031] Figure 4 is a block diagram of the first cloud server 30 in the intermediary system 100 according to the first embodiment. The first cloud server 30 includes a control unit 31, calculation software 32, a vehicle DB (database) 33, and a transmitting / receiving unit 34. The control unit 31 is a computer, or processor (arithmetic unit), that controls the overall operation of the first cloud server 30.

[0032] The calculation software 32 is an application that calculates the battery consumption of a vehicle. The vehicle database 33 is a database that holds vehicle data for each vehicle, which is necessary for the calculation software 32 to calculate the battery consumption. The transmission / reception unit 34 is the part that transmits and receives data with external devices, including the terminal device 10 and the vehicle 20, via the network N.

[0033] The navigation application 13 of the terminal device 10 is an application stored in a storage device (not shown), but when loaded into the control unit 11, it functions as a first computing device or program that causes the terminal device 10 to perform a predetermined calculation (operation). The calculation software 32 of the first cloud server 30 is also an application stored in a storage device (not shown), but when loaded into the control unit 31, it functions as a second computing device or program that causes the first cloud server 30 to perform a predetermined calculation (operation).

[0034] Similarly, the intermediary application 14 of the terminal device 10 is an application stored in a storage device (not shown), but when loaded into the control unit 11, it functions as an intermediary device or intermediary program that causes the terminal device 10 to perform a predetermined calculation (operation). Such an intermediary device or intermediary program executes an intermediary method including the process shown in the sequence diagram described later. This concept is common to all embodiments in this specification.

[0035] Figure 5 is a sequence diagram showing the exchange of data between the terminal device 10, the vehicle 20, and the first cloud server 30 in the mediation system 100 according to the first embodiment. In this figure, the navigation application 13 is stored in the terminal device 10 as shown in Figure 2, but a similar sequence will be established even if the navigation application 13 is stored in another cloud server.

[0036] First, authentication is performed between the terminal device 10, the vehicle 20, and the first cloud server 30 to confirm that they are appropriate partners for sending and receiving data (step S1). During this authentication process, the consistency between the version of the calculation software 32 on the first cloud server 30 and the firmware version of the ECU 21 or VCU 24 on the vehicle 20 may be checked, and a mechanism may be incorporated to upgrade the versions if they differ. The detailed authentication process will be explained with reference to Figure 6.

[0037] After authentication is complete, the navigation app 13 sends a first calculation request to the intermediary app 14 at any time (step S2). The first calculation request is a request from the navigation app 13 to calculate the battery consumption during driving a predetermined route from the starting point to the destination, and corresponds to a trigger signal for a series of processes. The first calculation request includes information such as altitude and vehicle speed for the predetermined route. An example of the information such as altitude and vehicle speed included in the first calculation request is shown in graphs (1) and (2) in Figure 12.

[0038] When the first communication unit 15 of the intermediary application 14 receives a first calculation request from the navigation application 13, the second communication unit 16 of the intermediary application 14 transmits a request for real-time vehicle data to the vehicle 20 via the transmitting / receiving unit 12 (step S3). When the ECU 21 or VCU 24 of the vehicle 20 receives the request for vehicle data via the transmitting / receiving unit 28, the ECU 21 or VCU 24 transmits the real-time vehicle data stored in the vehicle data storage unit 27 to the terminal device 10 via the transmitting / receiving unit 28 (step S4).

[0039] When the second communication unit 16 of the intermediary application 14 receives vehicle data from the ECU 21 or VCU 24 of the vehicle 20 via the transmitting / receiving unit 12, the third communication unit 17 of the intermediary application 14 sends a second calculation request, including the vehicle data, to the first cloud server 30 via the transmitting / receiving unit 12 (step S5). When the calculation software 32 of the first cloud server 30 receives the second calculation request via the transmitting / receiving unit 34, it calculates the battery consumption. The calculation software 32 sends the calculation result of the battery consumption to the terminal device 10 via the transmitting / receiving unit 34 (step S6).

[0040] Even if the total battery charge from the start to the end of the driving route does not reach zero, the battery charge may drop below zero at some point along the route. In such cases, the calculation software 32 may, in addition to the calculation results, transmit information R indicating the change in battery charge over time. Information R can be used to communicate that there is a possibility of running out of battery power at some point along the driving route.

[0041] When the third communication unit 17 of the intermediary application 14 receives the calculation result from the calculation software 32 via the transmitting / receiving unit 12, the first communication unit 15 transmits the calculation result to the navigation application 13 (step S7). The navigation application 13 proposes an eco-route to the user in the form of a display on the terminal device 10, and navigation is performed (step S8).

[0042] Navigation app 13 has been used by terminal device users for some time, and it can display battery consumption on the terminal device's display (display unit) and also display eco-routes on the map on the display. However, the developer of navigation app 13 does not have the information necessary to calculate power consumption for each individual vehicle, such as the method for calculating battery consumption or real-time vehicle data. Therefore, navigation app 13 developed under these circumstances has difficulty performing accurate calculations for each individual vehicle, and there are limitations to improving the calculation accuracy of the app.

[0043] On the other hand, the system of this embodiment is provided with an intermediary application 14 having a first communication unit 15, a second communication unit 16, and a third communication unit 17. The first communication unit 15 can receive a first calculation request from the navigation application 13 (step S2). The second communication unit 16 can receive vehicle data from the ECU 21 or VCU 24 (step S4). The third communication unit 17 can send a second calculation request including vehicle data to the calculation software 32 (step S5) and receive the calculation result from the calculation software 32 (step S6). As a result, the first communication unit 15 can send the calculation result to the navigation application 13 (step S7). The intermediary application 14 coordinates the navigation application 13, the ECU 21 or VCU 24, and the calculation software 32, and mediates the exchange of necessary data between them.

[0044] In other words, according to the intermediary application 14 of this embodiment, even if the first computing device, the navigation application 13, the second computing device, the calculation software 32, and the vehicle data are not located in the same place, the intermediary application 14 will exchange the necessary data. In this way, the calculation software 32 can be made to perform calculations with high accuracy based on the vehicle data. Furthermore, since the highly accurate calculation results from the calculation software 32 are transmitted to the navigation application 13, the accuracy of the calculations performed by the navigation application 13 can be improved.

[0045] In this embodiment in particular, the first communication unit 15 receives a request to calculate an eco-route as a first calculation request from the navigation application 13 (step S2), and the third communication unit 17 sends a request to calculate battery consumption as a second calculation request to the calculation software 32 (step S5). The first communication unit 15 also receives the battery consumption calculation result from the calculation software 32 (step S6). As a result, the calculation software 32 calculates the battery consumption based on vehicle data, and a highly accurate battery consumption calculation result is sent to the navigation application 13, thereby improving the accuracy of the eco-route calculation by the navigation application 13.

[0046] Figure 6 is a sequence diagram showing the authentication process (step S1 in Figure 5) between the terminal device 10, the vehicle 20, and the first cloud server 30 in the intermediary system 100 according to the first embodiment. The terminal device 10 and the ECU 21 or VCU 24 of the vehicle 20 are pre-paired and connected via short-range communication. When the vehicle 20 is powered on (step S11), the ECU 21 or VCU 24 of the vehicle 20 performs a poll to request a connection from the terminal device 10 via the transceiver unit 28 (step S12). The data transmitted when polling, i.e., when confirming existence (polling data), includes information that forms the basis of the security code.

[0047] When the intermediary application 14 of the terminal device 10 receives polling data via the transceiver unit 12, the intermediary application 14 transmits a security code to the vehicle 20 via the transceiver unit 12 (step S13). The ECU 21 or VCU 24 of the vehicle 20 receives the security code via the transceiver unit 28. If the security code is correct, the ECU 21 or VCU 24 transmits the vehicle 20's ID (vehicle identification information) and the firmware that controls the operation of the ECU 21 or VCU 24 to the terminal device 10 via the transceiver unit 28 (step S14). The ECU 21 or VCU 24 determines whether the received security code is correct based on whether the information was generated based on the information transmitted during polling. Furthermore, the ECU 21 or VCU 24 stores the terminal device 10's ID (terminal device identification information) obtained when the security code was received in a storage device (not shown) or the like (step S15). The ID of the terminal device 10 that is saved is the ID of the terminal device 10 that was last paired, that is, the terminal device 10 that was last connected.

[0048] On the other hand, upon receiving the vehicle ID and firmware of the vehicle 20, the authentication unit 18 of the intermediary application 14 checks whether the vehicle ID received from the ECU 21 or VCU 24 is already registered (step S16). If the authentication unit 18 confirms that it is already registered, the intermediary application 14 saves the vehicle ID and firmware version of the vehicle 20 to a storage device (not shown) or the like (step S17). If it is not confirmed that it is already registered, the process ends.

[0049] Navigation app 13 starts up when the user of terminal device 10 inputs a startup command, such as tapping an icon (step S18). At this point, the user interface (UI) of navigation app 13 is not yet displayed on the display of terminal device 10. The first communication unit 15 of the intermediary app 14 requests the version of navigation app 13 from navigation app 13 (step S19), and navigation app 13 sends its own version to the intermediary app 14 (step S20). The intermediary app 14 saves the version of navigation app 13 to a storage device (not shown). Also, the third communication unit 17 of the intermediary app 14 requests the version of calculation software 32 from the calculation software 32 of the first cloud server 30 (step S21), and calculation software 32 sends its own version to the intermediary app 14 (step S22). The intermediary app 14 saves the version of calculation software 32 to a storage device (not shown). The verification unit 19 of the intermediary application 14 performs a consistency check to determine whether the registered vehicle ID and firmware version, the version of the navigation application 13, and the version of the calculation software 32 of the first cloud server 30 are consistent with each other (step S23).

[0050] If the verification in step S23 confirms consistency, the first communication unit 15 of the intermediary application 14 sends a signal to the navigation application 13 indicating consistency OK (step S24). Upon receiving this signal, the navigation application 13 displays its UI on the display and completes the startup (step S25). If consistency is not confirmed in step S23, the process may be terminated, or the intermediary application 14 may display a message to the user via the display of the terminal device 10 prompting them to update.

[0051] Subsequently, the connection between terminal device 10 and vehicle 20 is disconnected, for example, when terminal device 10 moves outside vehicle 20, and then reconnected. At this point, vehicle 20's ECU 21 or VCU 24 resumes polling terminal device 10 to request a connection (step S26). When terminal device 10's intermediary application 14 receives the polling data, it sends a security code to vehicle 20 (step S27). Vehicle 20's ECU 21 or VCU 24 compares the ID of terminal device 10 obtained upon receiving the security code with the ID of the last connected terminal device 10, which was saved in step S15 (step S28). If the security code is correct, it sends the ID of vehicle 20 and the firmware that controls the operation of ECU 21 or VCU 24 to terminal device 10 (step S29).

[0052] The intermediary application 14 stores the vehicle ID and firmware version of the vehicle 20 in a storage device (not shown) or the like (step S30). The verification unit 19 of the intermediary application 14 checks whether the registered vehicle ID and firmware version, the version of the navigation application 13, and the version of the calculation software 32 of the first cloud server 30 are consistent with each other (step S31). After the consistency check, authentication is successful, so the navigation application 13 sends the first calculation request to the intermediary application 14 as shown in step S2 of Figure 5 (step S32), and then proceeds to the process shown in Figure 5. If consistency is not confirmed, the process is stopped, and the intermediary application 14 may display a message to the user via the display of the terminal device 10 instructing them to restart the operation from the beginning.

[0053] According to the intermediary application 14 of this embodiment, the authentication unit 18 and the verification unit 19 perform authentication of the ECU 21 or VCU 24 and consistency verification with the navigation application 13 and the calculation software 32 (steps S16 to S23), thereby increasing the reliability of cooperation with each application.

[0054] Furthermore, vendors are developing fault prediction apps that can diagnose vehicle faults and even predict them, but, similar to the power consumption mentioned above, they lack the information necessary for fault diagnosis and prediction, so it is expected that there will be limitations to improving the calculation accuracy of such fault prediction apps. The intermediary app 14 in the first embodiment described above improves the calculation accuracy of the navigation app 13 that calculates eco-routes, but the intermediary app 14 can also be applied to the calculation accuracy of fault prediction apps. In this case, the "navigation app 13" in the above configuration can be replaced with the "battery fault prediction app 13A" described later, and the calculation software 32 can perform the calculations necessary for fault prediction.

[0055] (Battery failure prediction) Figures 7 to 9 illustrate the mediation system for battery failure prediction. Figure 7 is a block diagram of terminal device 10A, Figure 8 is a block diagram of the first cloud server 30A, and Figure 9 is a sequence diagram showing data exchange between terminal device 10A, vehicle 20, and first cloud server 30A. The following explanation will focus on the differences from the mediation system described with reference to Figures 1 to 5.

[0056] The terminal device 10A shown in Figure 7 is equipped with a battery failure prediction application 13A instead of the navigation application 13 provided by the terminal device 10 shown in Figure 2. The battery failure prediction application 13A predicts battery failures in the vehicle 20 and improves the accuracy of the calculation by using the calculation results from the first cloud server 30A. The first cloud server 30A shown in Figure 8 is equipped with a battery database (DB) 33A instead of the vehicle DB 33 provided by the first cloud server 30 shown in Figure 4. The battery DB 33A is a database that holds the battery characteristics of each battery installed in the vehicle 20, which is necessary for the calculation software 32 of the first cloud server 30A to predict battery failures. Battery characteristics include the initial capacity of the battery, the type, and thresholds described later. The configuration of the vehicle 20 in this intermediary system is the same as in Figure 3, but the difference is that the vehicle data storage unit 27 stores the battery charge / discharge cycle history as vehicle data. The battery charge / discharge cycle history refers to the number of times the battery has been charged and discharged. For example, it may count the number of times the battery has been charged from 0% to 100%, or the number of times the battery has been charged from 20% to 80%.

[0057] In the sequence shown in Figure 9, first, authentication is performed between the terminal device 10A, the vehicle 20, and the first cloud server 30A to confirm whether they are appropriate partners for sending and receiving data (step S1, see Figure 6). After authentication is successful, the battery failure prediction application 13A sends a first calculation request to the intermediary application 14 at any time (step S2). Here, the first calculation request is a calculation request for battery failure prediction from the battery failure prediction application 13A, and corresponds to the trigger signal for the series of processes.

[0058] When the first communication unit 15 of the intermediary application 14 receives a first calculation request from the battery failure prediction application 13A, the second communication unit 16 of the intermediary application 14 transmits a request for real-time vehicle data to the vehicle 20 via the transmitting / receiving unit 12 (step S3). When the ECU 21, VCU 24, or BMS 22 of the vehicle 20 receives this request for vehicle data via the transmitting / receiving unit 28, the ECU 21, VCU 24, or BMS 22 transmits the real-time vehicle data stored in the vehicle data storage unit 27 to the terminal device 10A via the transmitting / receiving unit 28 (step S4). The real-time vehicle data includes the latest vehicle data. The vehicle data transmitted to the terminal device 10 includes the current battery capacity and the battery charge / discharge cycle history.

[0059] The second communication unit 16 of the intermediary application 14 receives vehicle data transmitted from the vehicle 20's ECU 21, VCU 24, or BMS 22 in step S4 via the transmitting / receiving unit 12. Then, the third communication unit 17 of the intermediary application 14 sends a second calculation request, including the current battery capacity and charge / discharge cycle history, to the first cloud server 30A via the transmitting / receiving unit 12 (step S5). When the calculation software 32 of the first cloud server 30A receives the second calculation request via the transmitting / receiving unit 34, it performs a battery failure prediction calculation.

[0060] Specifically, the calculation software 32 first calculates the battery degradation rate according to the following formula. Degradation rate (%) = ((Initial capacity - Current capacity) / Initial capacity) * 100

[0061] Next, the calculation software 32 calculates the remaining battery life based on the above degradation rate and the charge / discharge cycle history (also called "number of cycles") according to the following formula.

[0062]

number

[0063] Here, the threshold depends on the type of battery, and the value stored in the battery DB33A for each battery is used.

[0064] As an example of calculating remaining lifespan, if a lithium-ion battery has an initial capacity of 100 ampere-hours (Ah), a degradation rate of 10%, a charge / discharge cycle history (number of cycles) of 100, and a threshold of 80%, then the remaining lifespan (%) = 100 - (10% × (1 - (100 / 80))) = 100 - (10% × 0.25) = 100 - 2.5 = 97.5%.

[0065] The calculation software 32 outputs a battery failure prediction result based on the remaining lifespan calculation result. For example, if the remaining lifespan is higher than 90%, it will be considered "no problem"; if the remaining lifespan is between 80% and 90%, it will be considered "battery failure is approaching, replacement is recommended"; and if the remaining lifespan is 80% or less, it will be considered "you should replace it immediately".

[0066] The calculation software 32 transmits the battery failure prediction result as a calculation result to the terminal device 10A via the transmitting / receiving unit 34 (step S6).

[0067] When the third communication unit 17 of the intermediary application 14 receives the calculation result from the calculation software 32 via the transmitting / receiving unit 12, the first communication unit 15 transmits the calculation result to the battery failure prediction application 13A (step S7). The battery failure prediction application 13A presents the battery failure prediction result to the user in the form of a display on the terminal device 10A or by audio output (step S8A).

[0068] (Second Embodiment) Figure 10 is a block diagram of the vehicle 20 in the mediation system 100 according to the second embodiment. The overall configuration of the mediation system 100 according to the second embodiment is the same as that of the mediation system 100 according to the first embodiment shown in Figure 1. However, the ECU 21 or VCU 24 in the vehicle 20 has calculation software (second calculation device) 29. In Figure 10, an example is shown in which the ECU 21 has the calculation software 29. This calculation software 29 has the function of performing calculations equivalent to those performed by the calculation software 32 of the first cloud server 30 in the first embodiment.

[0069] Figure 11 is a sequence diagram showing the exchange of data between the terminal device 10, the vehicle 20, and the first cloud server 30 in the mediation system 100 according to the second embodiment. Steps S1 to S6 are the same as in the first embodiment in Figure 5 and represent processing when the system is operating normally.

[0070] In this embodiment, it is assumed that communication between the first cloud server 30 and the terminal device 10 is interrupted due to a change in the communication environment, etc. Due to the interruption of communication, the terminal device 10 cannot have the calculation software 32 of the first cloud server 30 perform calculations. Therefore, the third communication unit 17 of the terminal device 10 stops receiving calculation results from the calculation software 32. On the other hand, in this embodiment, since the ECU 21 or VCU 24 of the vehicle 20 has calculation software 29, the terminal device 10 attempts to have the ECU 21 or VCU 24 perform calculations.

[0071] As shown in Figure 11, after communication is disconnected, the navigation application 13 sends a first calculation request to the intermediary application 14 at any time (step S41). Then, the second communication unit 16 of the intermediary application 14 sends a second calculation request to the ECU 21 or VCU 24 of the vehicle 20 via the transceiver unit 12 (step S42). When the ECU 21 or VCU 24 receives the second calculation request via the transceiver unit 28, the calculation software 29 performs a calculation of battery consumption using the real-time vehicle data of the vehicle 20 stored in the vehicle data storage unit 27. Then, the ECU 21 or VCU 24 sends the calculation result to the terminal device 10 via the transceiver unit 28 (step S43).

[0072] When the second communication unit 16 of the intermediary application 14 receives the calculation result from the ECU 21 or VCU 24 of the vehicle 20, the first communication unit 15 transmits the calculation result to the navigation application 13 (step S44). The navigation application 13 proposes an eco-route to the user in the form of a display on the terminal device 10, and navigation is performed (step S45).

[0073] Figure 12 shows a specific example of steps S41 to S44 in Figure 11. The second communication unit 16 of the intermediary application 14 transmits a second calculation request to the ECU 21 or VCU 24 of the vehicle 20 via the transmitting / receiving unit 12 (step S42). In this case, the intermediary application 14 may transmit to the ECU 21 or VCU 24, along with the second calculation request, the assumed altitude and vehicle speed data corresponding to the route that the vehicle 20 should travel, which were included in the first calculation request, as shown in graphs (1) and (2). When the ECU 21 or VCU 24 receives the second calculation request via the transmitting / receiving unit 28, the calculation software 29 performs a calculation of battery consumption using the real-time vehicle data of the vehicle 20 stored in the vehicle data storage unit 27 and the graphs (1) and (2). Since the intermediary application 14 defines the route to be calculated, the processing load on the ECU 21 or VCU 24 can be reduced.

[0074] According to the intermediary application 14 of this embodiment, if calculation results are not received from the calculation software 32 of the first cloud server 30, a second calculation request is sent to the ECU 21 or VCU 24 of the vehicle 20, and the calculation results are received by the ECU 21 or VCU 24 of the vehicle 20. Therefore, even if communication with the calculation software 32 is interrupted, highly accurate calculation results can be sent to the navigation application 13, improving the accuracy of calculations performed by the navigation application 13.

[0075] (Third embodiment) The intermediary system 100 according to the third embodiment is based on the contents of the second embodiment, and the vehicle 20 has the configuration shown in Figure 10, but there is a risk that the computational load on the ECU 21 or VCU 24 will increase. Therefore, in this embodiment, the ECU 21 or VCU 24 does not use a complex calculation formula to calculate the battery consumption, but prepares the calculation conditions necessary for the calculation in advance. The ECU 21 or VCU 24 then uses these calculation conditions to calculate the battery consumption for each of the multiple sections included in the pre-specified driving route.

[0076] Figure 13 is a table listing the calculation conditions for battery consumption. The table in this example includes calculation conditions such as base driving performance, uphill performance, vehicle weight, and temperature performance. Base driving performance is the battery consumption (kWh) according to the speed at which vehicle 20 travels on a flat road, and is the basic condition. Uphill performance is a coefficient (uphill coefficient) multiplied by the base driving performance according to the road gradient. Vehicle weight is a coefficient (load coefficient) multiplied by the base driving performance according to the load weight. Temperature performance is a coefficient (temperature coefficient) multiplied by the base driving performance according to the ambient temperature.

[0077] When using the above calculation conditions, the battery consumption for each of the multiple sections included in the driving route can be calculated using the following formula (1).

[0078] Section battery consumption (kWh) = base driving performance × time × uphill coefficient × vehicle weight coefficient × temperature coefficient ... (1)

[0079] The total battery consumption for the entire route can be calculated by summing the battery consumption for each section mentioned above.

[0080] Figure 14 is a sequence diagram showing the exchange of data between the terminal device 10 and the vehicle 20 in the mediation system 100 according to the third embodiment, and corresponds to steps S41 to S44 in Figures 11 and 12.

[0081] The navigation app 13 sends a first calculation request to the intermediary app 14 at any time (step S51). In this embodiment, the first calculation request is not just a simple calculation request, but includes the specification of a route that includes multiple sections, such as section 1, section 2, ... section N. In response, the second communication unit 16 of the intermediary app 14 sends the calculation conditions for the first section, section 1, along with the second calculation request to the ECU 21 or VCU 24 of the vehicle 20 via the transmitting / receiving unit 12 (step S52). Next, the ECU 21 or VCU 24 receives the second calculation request and the calculation conditions for section 1 via the transmitting / receiving unit 28. Then, the calculation software 29 uses the real-time vehicle data of the vehicle 20 stored in the vehicle data storage unit 27 and the calculation conditions for section 1 to calculate the battery consumption of section 1 based on equation (1) (step S53). Finally, the ECU 21 or VCU 24 sends the calculation result for section 1 to the terminal device 10 via the transmitting / receiving unit 28 (step S54).

[0082] Similarly, the intermediary application 14 sends the calculation conditions for the second section, section 2, along with the second calculation request to the ECU 21 or VCU 24, and the ECU 21 or VCU 24 receives the second calculation request and the calculation conditions for section 2. Then, the calculation software 29 uses the real-time vehicle data of the vehicle 20 stored in the vehicle data storage unit 27 and the calculation conditions for section 2 to perform the calculation of the battery consumption for section 2 based on equation (1) (steps S55 to S57).

[0083] After repeating the above process for each section, the intermediary application 14 sends a second calculation request along with the calculation conditions for the last Nth section, section N, to the ECU 21 or VCU 24, and the ECU 21 or VCU 24 receives the second calculation request and the calculation conditions for section N. Then, the calculation software 29 uses the real-time vehicle data of the vehicle 20 stored in the vehicle data storage unit 27 and the calculation conditions for section N to calculate the battery consumption for section N based on equation (1) (steps S58 to S60).

[0084] The intermediary application 14 calculates the total battery consumption for the entire route by summing up the battery consumption for all sections calculated above, and the first communication unit 15 transmits the calculation result to the navigation application 13 in the same way as step S44 in Figures 11 and 12 (step S61).

[0085] Compared to cases where complex calculation formulas are used to calculate battery consumption, in this embodiment, the ECU21 or VCU24 performs the calculation of battery consumption based on pre-prepared calculation conditions, thereby suppressing an increase in the computational load on the ECU21 or VCU24.

[0086] Furthermore, the first communication unit 15 of the intermediary application 14 receives a first calculation request from the navigation application 13, which includes the specification of a route including multiple sections, and the second calculation request includes calculation conditions for each of the multiple sections. The second communication unit 16 of the intermediary application 14 receives the calculation results for each of the multiple sections from the ECU 21 or VCU 24.

[0087] In other words, according to the intermediary application 14 of this embodiment, in response to a request for ecoroute calculation including multiple sections, the intermediary application 14 transmits calculation conditions for each of the multiple sections to the ECU 21 or VCU 24. Therefore, the ECU 21 or VCU 24 can perform calculations for each of the multiple sections. Since the route is divided into multiple sections and the ECU 21 or VCU 24 can perform calculations for each section, the increase in computational load on the ECU 21 or VCU 24 can be suppressed.

[0088] (Fourth Embodiment) Figure 15 is a network configuration diagram of the intermediary system 100 according to the fourth embodiment. The intermediary system 100 according to this embodiment includes a second cloud server 40 in addition to the configuration of the intermediary system 100 according to the first embodiment shown in Figure 1. While the first cloud server 30 is a server operated by, for example, the manufacturer of the vehicle 20, the second cloud server 40 is a server operated by, for example, a business operator (taxi operator, transportation operator, etc.) that operates the vehicle 20, and holds data related to vehicle operation management.

[0089] Figure 16 is a block diagram of the second cloud server 40. The second cloud server 40 includes a control unit 41, an operation management DB 43, and a transmission / reception unit 44. The control unit 41 and the transmission / reception unit 44 are the same as those of the control unit 31 and transmission / reception unit 34 of the first cloud server 30, respectively.

[0090] The operation management DB 43 is a database that holds various data related to vehicle operation management. For example, the operation management DB 43 holds data on changes in the weight of cargo or people based on the delivery plan, i.e., weight information based on the delivery plan. In the example in Figure 17, the cargo weight decreases from weight W0 at the start of delivery to weight W1 as a result of unloading at a point at distance D1, and then decreases to weight W2 as a result of further unloading at a point at distance D2. The second cloud server 40 transmits the data from the operation management DB 43 to the terminal device 10 via the transmission / reception unit 44, thereby improving the accuracy of the calculations of the navigation application 13.

[0091] If the operation management DB 43 holds data on cargo weight, for example, as shown in Figure 17, the navigation app 13 may request cargo weight information from the second cloud server 40 prior to the first calculation request (step S2) in Figure 5, and receive the cargo weight information from the second cloud server 40. Subsequently, the navigation app 13 passes the cargo weight information to the intermediary app 14 along with the first calculation request (step S2). Furthermore, the intermediary app 14 sends a request for vehicle data to the ECU 21 or VCU 24 of the vehicle 20 (step S3), and receives vehicle data from the ECU 21 or VCU 24 (step S4).

[0092] Subsequently, the intermediary application 14 sends a second calculation request to the first cloud server 30 (step S5). The second calculation request includes the vehicle data received in step S4, as well as the cargo weight information received from the second cloud server 40. The intermediary application 14 receives the calculation result from the calculation software 32 of the first cloud server 30 (step S6) and passes the calculation result to the navigation application 13. This allows the cargo weight information based on the delivery plan, which is stored in the operation management DB 43, to be reflected in the calculation result. Furthermore, if the intermediary application 14 can obtain weight information such as the actual cargo weight from the ECU 21 or VCU 24, it can receive vehicle data including the weight information and provide it to the calculation software 32, thereby improving the accuracy of the battery level calculation by the calculation software 32.

[0093] (Fifth embodiment) Figure 18 is a block diagram of the terminal device 10 in the mediation system 100 according to the fifth embodiment. The overall configuration of the mediation system 100 according to the fifth embodiment is the same as that of the mediation system 100 according to the first embodiment shown in Figure 1. The terminal device 10 of this embodiment has a configuration similar to the terminal device 10 in Figure 2, but the mediation application 14 has a storage unit 51. The storage unit 51 stores time-series data of the current battery level of the vehicle 20, received from the ECU 21 or VCU 24 of the vehicle 20 via the transmitting / receiving unit 12. The battery level received from the ECU 21 or VCU 24 may be the current battery level (predicted value) predicted in the BMS 22.

[0094] Figure 19 is a sequence diagram showing data exchange between the terminal device 10, the vehicle 20, and the first cloud server 30 in the mediation system 100 according to the fifth embodiment. Figure 20 is an explanatory diagram regarding battery level prediction during communication interruption in the mediation system 100 according to the fifth embodiment. Step S1 is authentication, as in the first embodiment (see Figures 5 and 6).

[0095] In this embodiment, it is assumed that communication between the terminal device 10 and the vehicle 20 may be interrupted, for example, when the user of the terminal device 10 leaves the vehicle 20 while holding the terminal device 10. To prepare for such a communication interruption, the second communication unit of the intermediary application 14 of the terminal device 10 sends a periodic data request to the vehicle 20 via the transmitting / receiving unit 12 in advance, requesting vehicle data periodically (step S71). When the ECU 21 or VCU 24 of the vehicle 20 receives the vehicle data request via the transmitting / receiving unit 28, the ECU 21 or VCU 24 periodically transmits the vehicle data stored in real time in the vehicle data storage unit 27 to the terminal device 10 via the transmitting / receiving unit 28 (step S72). The vehicle data includes the current (latest) predicted battery level.

[0096] The second communication unit 16 of the intermediary application 14 periodically receives vehicle data from the vehicle 20's ECU 21 or VCU 24 via the transmitting / receiving unit 12. The intermediary application 14 can determine the time when the vehicle data was received, for example, by using a timing function such as an internal counter of the terminal device 10. The storage unit 51 of the intermediary application 14 stores the periodically received vehicle data as time-series data (step S73). In the example shown in Figure 20, the battery levels RE1 and RE2 received at times T1 and T2 are stored in the storage unit 51 as time-series data.

[0097] While vehicle data is being periodically stored, a situation may occur where communication between the terminal device 10 and the vehicle 20, and consequently between the ECU 21 or VCU 24, is interrupted. In the example in Figure 20, time T3 represents the time of the communication interruption, and the battery level RE3 transmitted immediately before is also stored in the storage unit 51 as time-series data. Under these circumstances, the navigation application 13 sends a first calculation request to the intermediary application 14 at an arbitrary timing (time T4 in the example in Figure 20) (step S74). Here, the first calculation request includes information on the estimated time of arrival at the destination (time T5 in the example in Figure 6). Then, the third communication unit 17 of the intermediary application 14 sends a second calculation request, including the time-series data of the battery level stored in the storage unit 51, to the first cloud server 30 via the transmitting / receiving unit 12 (step S75). The intermediary application 14 sends to the first cloud server 30 the second calculation request, including information on the estimated time of arrival at the destination, time-series data of the battery level, and the elapsed time from time T3, when communication was lost, to time T4, when the first calculation request was received, i.e., the communication disconnection time. If the intermediary application 14 obtains a timestamp indicating the transmission time from, for example, the ECU 21 or VCU 24, it may determine the communication disconnection time based on the timestamp.

[0098] When the calculation software 32 of the first cloud server 30 receives a second calculation request via the transmitting / receiving unit 34, it calculates a predicted value of the battery remaining capacity at the time of arrival at the destination, i.e., performs a battery remaining capacity prediction, based on the time-series data of the battery remaining capacity and the communication disconnection time. The calculation software 32 can calculate a predicted value of battery consumption from the battery capacity and the calculation result of the battery remaining capacity prediction. The calculation software 32 transmits the calculation result of the battery remaining capacity prediction to the terminal device 10 via the transmitting / receiving unit 34 (step S76). In the example in Figure 6, the battery remaining capacity RE5 at the predicted arrival time T5 at the destination is the calculation result of the battery remaining capacity prediction.

[0099] When the third communication unit 17 of the intermediary application 14 receives the calculation result from the calculation software 32 via the transmitting / receiving unit 12, the first communication unit 15 transmits the calculation result to the navigation application 13 (step S77). When communication is interrupted, steps S74 to S77 are repeatedly executed.

[0100] The calculation software 32 of the first cloud server 30 predicts the remaining battery level based on time-series data of the remaining battery level and the communication disconnection time. In predicting the remaining battery level, factors such as the driving status (idling, driving at average speed, etc.) including speed information included in the vehicle data, battery temperature, and the use and power consumption of various units (vehicle equipment, electrical components) including the air conditioner and refrigerator are taken into consideration. For example, if the most recently received vehicle data includes information that the terminal device 10 has been removed from the cradle, it may be determined that the vehicle is idling.

[0101] Referring to Figure 21, the battery level prediction during communication interruption when vehicle equipment is used, as performed by the calculation software 32 of the first cloud server 30, will be explained. Graph L1 shows the time-series change of the predicted battery level when vehicle equipment such as the air conditioning system is not used, from departure TA1 to arrival at destination TA4. This battery level prediction data is past data of the same vehicle, pre-stored in the vehicle DB 33 of the first cloud server 30, and stores the predicted battery level for each hour. For example, past data of the same type of vehicle may be used. Graph L2, shown as a solid line, is a graph (time-series data) of the actual battery level received from the vehicle when vehicle equipment such as the air conditioning system is used. The predicted battery level at request TA3 is calculated based on the differences d1, d2, and d3 between the battery level in graph L1, which is past data, and the values ​​in graph L1 corresponding to the actual values ​​RE11, RE12, and RE13 shown in graph L2 up to communication interruption TA2. In this calculation, the calculation software 32 can obtain a predicted value for the battery level at TA3 at the time of the request by subtracting the average of the differences d1, d2, and d3 from the battery level in graph L1 at TA3 at the time of the request. Furthermore, the calculation software 32 can obtain a predicted value for the battery level at the destination by using the battery level in graph L1, the average of the differences d1, d2, and d3, and the estimated time of arrival at the destination (TA4 at the time of arrival at the destination).

[0102] In Figure 21, graph L3, shown as a dashed line, is a graph of the predicted battery remaining capacity, taking into account the weight of the cargo, when vehicle equipment such as air conditioning is used. In the example of graph L3, the predicted battery remaining capacity is shown when the cargo weight is constant, but the calculation software 32 of the first cloud server 30 may also use weight information based on the delivery plan (see, for example, Figure 17) stored in the operation management DB 43. By using weight information based on the delivery plan, the calculation software 32 can improve the accuracy of the battery remaining capacity prediction. In Figure 21, graph L4, shown as a dashed line, is a graph of the predicted battery remaining capacity when information that the cargo weight decreases at the unloading point is used based on the delivery plan. At TA5, the arrival at the unloading point, the cargo weight becomes lighter, so the slope of the predicted battery remaining capacity graph after TA5, the arrival at the unloading point, becomes gentler. Conversely, if the cargo weight increases, the slope of the predicted battery remaining capacity graph becomes steeper.

[0103] Returning to Figure 19, when the user of terminal device 10, who is holding terminal device 10, returns to vehicle 20, and communication is restored, re-authentication is performed in the same manner as in step S1 (step S78). From there, the same process as in step S2 onwards in Figure 5 is performed. Note that re-authentication may be performed between a vehicle different from the one previously authenticated.

[0104] According to the intermediary application 14 of this embodiment, the storage unit 51 stores time-series data of the remaining battery level, and receives the calculation result of the battery level prediction calculated from the calculation software 32 based on the time-series data and the communication interruption time. In this way, even if communication with the ECU 21 or VCU 24 is interrupted, the intermediary application 14 can periodically request the calculation result of the battery level prediction from the calculation software 32 using the time-series data of the remaining battery level that has been stored.

[0105] Furthermore, similar to the embodiment described above, the first communication unit 15 of the intermediary application 14 can receive an eco-route calculation request as a first calculation request from the navigation application 13. Therefore, the intermediary application 14 obtains a highly accurate battery level prediction calculation result based on vehicle data and transmits it to the navigation application 13, so that even if communication with the ECU 21 or VCU 24 is interrupted, a decrease in calculation accuracy during eco-route calculation can be suppressed.

[0106] Furthermore, if the vehicle data includes speed information for the vehicle 20, the calculation software 32 of the first cloud server 30 can perform a highly accurate battery level prediction based on the speed information.

[0107] (Sixth Embodiment) Figure 22 is a block diagram of the terminal device 50 in the mediation system 100 according to the sixth embodiment. The mediation system 100 according to the sixth embodiment does not necessarily require the first cloud server 30 in the first embodiment shown in Figure 1.

[0108] If the intermediary application 14 is developed by the vehicle manufacturer 20 or the developer of the ECU 21 or VCU 24, providing the navigation application 13 with the calculation package necessary for calculating battery consumption would result in disclosing confidential calculation information to the developer of the navigation application 13. This could cause disadvantages for the vehicle manufacturer 20 or the developer of the ECU 21 or VCU 24.

[0109] In this embodiment, as will be described later, the intermediary application 14 only passes the calculation results to the navigation application 13, thus preventing the disclosure of confidential calculation information to the application developer of the navigation application 13. For this reason, the terminal device 50 of this embodiment has a configuration similar to the terminal device 10 in Figure 2, but the intermediary application 14 includes a package acquisition unit 61, a request reception unit 62, a vehicle data reception unit 63, a calculation unit 64, and a provision unit 65.

[0110] The package acquisition unit 61 requests a calculation package containing a program for calculating battery consumption from the ECU 21 or VCU 24 installed in the vehicle 20, and acquires the calculation package from the ECU 21 or VCU 24. The request reception unit 62 receives a request for battery consumption calculation from the navigation application 13 that calculates the eco-route.

[0111] The vehicle data receiving unit 63 requests vehicle data, including the basic characteristics of the vehicle 20, from the ECU 21 or VCU 24 in response to a calculation request, and receives the vehicle data from the ECU 21 or VCU 24. The calculation unit 64 uses the calculation package and vehicle data to calculate the battery consumption. The providing unit 65 provides the calculation results from the calculation unit 64 to the navigation application 13.

[0112] Figure 23 is a sequence diagram showing the exchange of data between the terminal device 50 and the vehicle 20 in the mediation system 100 according to the sixth embodiment. Step S1 is authentication, as in the first embodiment (see Figures 5 and 6), but the first cloud server 30 is not required.

[0113] The package acquisition unit 61 of the intermediary application 14 transmits a calculation package request, which includes a program for calculating battery consumption, to the vehicle 20 via the transmitting / receiving unit 12 (step S81). The ECU 21 or VCU 24 of the vehicle 20 receives the calculation package request via the transmitting / receiving unit 28 and transmits the calculation package to the terminal device 50 (step S82). The package acquisition unit 61 of the intermediary application 14 acquires the calculation package via the transmitting / receiving unit 12.

[0114] The request receiving unit 62 receives a request from the navigation application 13 to calculate battery consumption at any time (step S83). Then, the vehicle data receiving unit 63 requests vehicle data, including the basic characteristics of the vehicle 20, from the ECU 21 or VCU 24 of the vehicle 20 via the transmitting / receiving unit 12 in response to the calculation request (step S84). The ECU 21 or VCU 24 receives the request for vehicle data via the transmitting / receiving unit 28 and transmits the real-time vehicle data stored in the vehicle data storage unit 27 to the terminal device 50 (step S85).

[0115] When the vehicle data receiving unit 63 of the intermediary application 14 receives vehicle data in real time via the transmitting / receiving unit 12, the calculation unit 64 uses the calculation package and vehicle data to calculate the battery consumption, and the providing unit 65 provides the calculation result from the calculation unit 64 to the navigation application 13 (step S86). The navigation application 13 proposes an eco-route to the user in the form of a display on the terminal device 50, and navigation is performed (step S87).

[0116] According to the intermediary application 14 of this embodiment, the intermediary application 14 calculates battery consumption and provides the result to the navigation application 13. Therefore, the navigation application 13 can perform highly accurate eco-route calculations without disclosing the calculation package itself, which is confidential information about the vehicle 20, to the navigation application 13 on the application developer's side. In addition, operational costs for storing programs and data in the cloud, as with the first cloud server 30, are not required.

[0117] The package acquisition unit 61 may also acquire the computation package in step S82 by receiving and decrypting the encrypted computation package. This reduces the risk of information leakage because the encrypted computation package is transmitted. A publicly known public key scheme or the like can be used for encryption.

[0118] The intermediary application 14 in each of the embodiments described above improves the calculation accuracy of the navigation application 13 that calculates eco-routes. However, the intermediary application 14 can also be applied to improve the calculation accuracy of a failure prediction application that performs calculations related to failure prediction as a predetermined calculation. In this case, the "navigation application 13" in the above configuration can be replaced with the "battery failure prediction application 13A".

[0119] The present invention is not limited to the embodiments described above, and various modifications are possible within the scope of the claims. Embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present invention. For example, the improvement of battery level calculation accuracy using weight information held by the operation management DB43 in the fourth embodiment is also applicable to other embodiments.

[0120] Herein, the features of the embodiments of the mediation device, mediation method, and mediation program according to the present invention described above are briefly summarized and listed below in [1] to [6].

[0121] [1] A first communication unit (first communication unit 15) receives a first calculation request from a first computing device (navigation app 13) which includes at least an estimated time of arrival at the destination, A second communication unit (16) periodically receives vehicle data, including at least the remaining battery level of the vehicle, from a vehicle control device (ECU21, VCU24, or BMS22) mounted on the vehicle (20), A storage unit (51) that stores the time-series data of the received vehicle data, The system includes a second computing device (calculation software 32) that calculates a predicted value of the remaining battery charge at the time of arrival at the destination, a third communication unit (17) that transmits a second calculation request including the time-series data to the second computing device, and receives the calculation result from the second computing device, The first communication unit transmits the calculation result to the first computing device. Intermediary device (intermediary application 14).

[0122] According to the intermediary device configured as described in [1] above, by periodically receiving vehicle data from the vehicle control device and storing the time-series data, even if communication with the vehicle control device is interrupted, the intermediary device can use the time-series data to request the second computing device to calculate a predicted value of the battery level at the time of arrival at the destination. Furthermore, since the calculation results from the second computing device are transmitted to the first computing device via the intermediary device, the accuracy of the calculations performed by the first computing device can be improved.

[0123] [2] The first communication unit receives from the first computing device a calculation request for ecoroute as the first calculation request. The intermediary device described in [1] above.

[0124] According to the intermediary device configured as described in [2] above, the second computing device predicts the remaining battery level based on vehicle data and transmits highly accurate calculation results to the first computing device. Therefore, even if communication with the vehicle control device is interrupted, it is possible to suppress a decrease in calculation accuracy during eco-route calculation.

[0125] [3] The vehicle data includes the speed information of the vehicle, The third communication unit transmits the second calculation request, which includes the time-series data and the speed information, to the second computing device. The intermediary device described in [1] or [2] above.

[0126] According to the intermediary device configured as described in [3] above, the second computing device that receives the second calculation request can perform a highly accurate battery level prediction based on the speed information.

[0127] [4] The second calculation request includes weight information based on the delivery plan, The third communication unit receives the calculation result, which takes the weight information into account, from the second computing device. An intermediary device as described in any one of the above [1] to [3].

[0128] According to the intermediary device configured as described in [4] above, the second computing device that receives the second calculation request can perform a highly accurate battery remaining charge prediction that takes into account the weight information based on the delivery plan.

[0129] [5] The first computing device (navigation app 13) receives a first calculation request that includes at least the estimated time of arrival at the destination, The vehicle control unit (ECU21 or VCU24) mounted on the vehicle (20) periodically receives vehicle data, including at least the remaining battery level of the vehicle. The time-series data of the received vehicle data is stored, A second calculation request including the time-series data is sent to a second computing device (calculation software 32) which calculates a predicted value of the remaining battery charge at the time of arrival at the destination, and the calculation result is received from the second computing device. The calculation result is transmitted to the first computing device. A mediation method using an intermediary device.

[0130] According to the mediation method of the configuration described in [5] above, by periodically receiving vehicle data from the vehicle control device and storing the time-series data, even if communication with the vehicle control device is interrupted, the mediation device can use the time-series data to request the second computing device to calculate a predicted value of the battery level at the time of arrival at the destination. Furthermore, since the calculation results from the second computing device are transmitted to the first computing device via the mediation device, the accuracy of the calculations by the first computing device can be improved.

[0131] [6] The first calculation request is received from the first computing device (navigation app 13), which includes at least the estimated time of arrival at the destination. The steps include receiving vehicle data periodically from a vehicle control unit (ECU21 or VCU24) mounted on the vehicle (20), including at least the remaining battery level of the vehicle, The steps include storing the time-series data of the received vehicle data, The steps include sending a second calculation request, including the time-series data, to a second computing device (calculation software 32) that calculates a predicted value of the remaining battery charge at the time of arrival at the destination, and receiving the calculation result from the second computing device, The steps include transmitting the calculation result to the first computing device, An intermediary program that causes a computer to execute a command.

[0132] According to the intermediary program configured as described in [6] above, the intermediary device periodically receives vehicle data from the vehicle control device and stores the time-series data. This allows the intermediary device to use the time-series data to request the second computer to calculate a predicted value of the battery level at the time of arrival at the destination, even if communication with the vehicle control device is interrupted. Furthermore, since the calculation results from the second computer are transmitted to the first computer via the intermediary device, the accuracy of the calculations performed by the first computer can be improved. [Explanation of symbols]

[0133] 10, 10A Terminal device 11 Control Unit 12 Transmitter / Receiver 13. Navigation app (First computing device) 13A Battery Failure Prediction App 14. Intermediary application (intermediary device) 15. First Communications Department 16. Second Communications Department 17. Third Communications Department 18. Authentication Department 19. Verification Section 20 vehicles 21. ECU (Vehicle Control Unit) 22 BMS (Vehicle Control System) 23 PCU 24 VCU (Vehicle Control Unit) 25 Weight scale 26 Other Units 27 Vehicle data storage unit 28 Transmitter / Receiver 29. Calculation software (Second computing device) 30, 30A First Cloud Server 31 Control Unit 32. Calculation software (Second computing device) 33 Vehicle Database 33A Battery DB 34 Transmitter / Receiver 40 Second Cloud Server 41 Control Unit 43 Operation management DB 44 Transmitter / Receiver Unit 50 Terminal devices 51 Storage section 61 Package Acquisition Section 62 Request Reception Department 63 Vehicle data receiving unit 64 Calculation section 65 Providing Department 100 Intermediary Systems

Claims

1. A first communication unit receives a first calculation request from a first computing device, which includes at least the estimated time of arrival at the destination. A second communication unit periodically receives vehicle data, including at least the vehicle's battery level, from a vehicle control device mounted on the vehicle. A storage unit for storing the time-series data of the received vehicle data, The system includes a second computing device that calculates a predicted value of the remaining battery charge at the time of arrival at the destination, a third communication unit that transmits a second calculation request including the time-series data to the second computing device, and receives the calculation result from the second computing device, The first communication unit transmits the calculation result to the first computing device. Intermediary device.

2. The first communication unit receives an ecoroute calculation request as the first calculation request from the first computing device. The intermediary device according to claim 1.

3. The vehicle data includes the speed information of the vehicle, The third communication unit transmits the second calculation request, which includes the time-series data and the speed information, to the second computing device. The intermediary device according to claim 1.

4. The second calculation request includes weight information based on the delivery plan, The third communication unit receives the calculation result, which takes the weight information into account, from the second computing device. The intermediary device according to claim 1.

5. The first computing device receives a first calculation request that includes at least the estimated time of arrival at the destination. The vehicle control unit installed in the vehicle periodically receives vehicle data, including at least the vehicle's battery level. The time-series data of the received vehicle data is stored, A second calculation request, including the time-series data, is transmitted to a second computing device that calculates a predicted value of the remaining battery charge at the time of arrival at the destination, and the calculation result is received from the second computing device. The calculation result is transmitted to the first computing device. A mediation method using an intermediary device.

6. The steps include receiving a first calculation request from a first computing device, which includes at least the estimated time of arrival at the destination, The steps include receiving vehicle data periodically from a vehicle control device installed in the vehicle, including at least the vehicle's battery level, The steps include storing the time-series data of the received vehicle data, The steps include sending a second calculation request, including the time-series data, to a second computing device that calculates a predicted value of the remaining battery charge at the time of arrival at the destination, and receiving the calculation result from the second computing device, The steps include transmitting the calculation result to the first computing device, An intermediary program that causes a computer to execute a command.

Images