Charging notification server

Abstract

To provide a charging notification server for determining and notifying necessity of charging a battery about a vehicle regardless of the existence / nonexistence of mounting of a battery sensor.SOLUTION: A charging notification server for performing notification about a battery mounted on a vehicle includes a first reception part for receiving either of first vehicle data including a battery SOC being a storage ratio of a battery or second vehicle data that does not include the battery SOC from the vehicle, a second reception part for receiving information about a charged state of the battery from an external apparatus connected to the vehicle if the first reception part receives second vehicle data, a conversion part for converting information about the charged state of the battery into the battery SOC, a determination part for determining the necessity of charging the battery on the basis of the battery SOC, and a transmission part for transmitting a charging request of the battery in the case of determining that battery charging is necessary.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a server or the like that provides notifications regarding a battery installed in a vehicle. [Background technology]

[0002] Non-Patent Document 1 discloses a system that prevents vehicles in stock at a vehicle dealer from notifying each vehicle of the timing for supplementary charging. In this system, a server receives vehicle data including the battery status acquired by a battery sensor mounted on the vehicle, and determines whether or not the battery needs to be charged based on this vehicle data. If it determines that charging is necessary, the server notifies a vehicle dealer that has the vehicle in stock of a request to charge the battery. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] Japan Institute of Invention and Innovation, Disclosure of Technical Information, No. 2023-500561 Summary of the Invention [Problem to be solved by the invention]

[0004] In the system described in Non-Patent Document 1, the server cannot receive vehicle data, including battery status, from vehicles that are not equipped with a battery sensor. As a result, the server cannot determine whether or not the battery needs to be charged for vehicles that are not equipped with a battery sensor, and cannot provide the necessary notification.

[0005] It is possible to manage the batteries of vehicles that do not have battery sensors using a management system different from the management system for vehicles that have battery sensors. However, in this case, it becomes necessary to manage the batteries of multiple vehicles using multiple management systems, which creates a problem that vehicle dealers and other businesses have to manage the vehicles and keep track of their information in a complicated manner.

[0006] The present disclosure has been made in consideration of the above-mentioned problems, and aims to provide a charging notification server that can determine whether or not the batteries of multiple vehicles need to be charged and provide notification, regardless of whether or not they are equipped with battery sensors. [Means for solving the problem]

[0007] In order to solve the above problem, one aspect of the disclosed technology is a charge notification server that provides notifications regarding a battery installed in a vehicle, and includes: a first receiving unit that receives from the vehicle either first vehicle data including a battery SOC, which is the battery's charge rate, or second vehicle data that does not include the battery SOC; a second receiving unit that, when the first receiving unit receives the second vehicle data, receives information regarding the battery's state of charge from an external device connected to the vehicle; a conversion unit that converts the information regarding the battery's state of charge into a battery SOC; a determination unit that determines whether the battery needs to be charged based on the battery SOC; and a transmission unit that, when it is determined that the battery needs to be charged, sends a request to charge the battery. [Effects of the Invention]

[0008] The charging notification server of the present disclosure has the function of converting information regarding the battery charging state into battery SOC, so it can determine whether or not the batteries of multiple vehicles need charging and provide the necessary notifications, regardless of whether or not they are equipped with battery sensors. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a schematic configuration diagram of a vehicle management system including a charging notification server according to an embodiment of the present invention; [Figure 2] A flowchart illustrating a process executed by a vehicle. [Figure 3] Flowchart explaining the process performed by the measuring instrument [Figure 4] Flowchart explaining the process executed by the charging notification server [Figure 5] A flowchart illustrating a process performed by a vehicle dealer. DETAILED DESCRIPTION OF THE INVENTION

[0010] For sensor-less vehicles whose battery state of charge (SOC) cannot be measured by a sensor, the charge notification server of the present disclosure acquires battery information that can be measured by a measuring instrument externally connected to the sensor-less vehicle, and determines whether or not the battery needs to be charged based on the battery SOC derived from this battery information. This allows charging-related notifications to be sent to both sensor-equipped vehicles and sensor-less vehicles using the same vehicle management system. Hereinafter, an embodiment of the present disclosure will be described in detail with reference to the drawings.

[0011] <Embodiment> [composition] Fig. 1 is a diagram showing a schematic configuration of a vehicle management system 1 including a charging notification server 20 according to an embodiment of the present disclosure. The vehicle management system 1 illustrated in Fig. 1 has a configuration in which a vehicle dealer 10 and the charging notification server 20 are communicably connected via a network. Note that the number of vehicle dealers 10 constituting the vehicle management system 1 is not limited to one, and may be multiple.

[0012] The vehicle dealership 10 is a store such as a dealer that has stored vehicles such as pre-sale inventory vehicles and pre-delivery vehicles. The stored vehicles owned by the vehicle dealership 10 are classified into "sensor-equipped vehicles 11," which are vehicles equipped with a battery sensor (B sensor) that can acquire the status of an on-board battery (not shown), and "sensor-unequipped vehicles 12," which are vehicles that are not equipped with this battery sensor. The stored vehicles owned by the vehicle dealership 10 are identified and managed in advance by the charge notification server 20 using unique identification information (such as a VIN) assigned to each vehicle.

[0013] The sensor-equipped vehicle 11 and the sensor-non-equipped vehicle 12 each include a communication function unit (such as a DCM) that can transmit various data related to the vehicle (hereinafter referred to as "vehicle data") to the charge notification server 20. The vehicle data (first vehicle data) transmitted by the sensor-equipped vehicle 11 to the charge notification server 20 includes at least the charge storage rate of the on-board battery (hereinafter referred to as "battery SOC"), the integrated value of the current flowing from the on-board battery while the vehicle is kept (parked) at the vehicle dealership 10 (hereinafter referred to as "dark current integrated value"), and the number of days the vehicle has been kept at the vehicle dealership 10 (hereinafter referred to as "number of parked days"). Furthermore, the vehicle data (second vehicle data) transmitted by the sensor-non-equipped vehicle 12 to the charge notification server 20 does not include the battery SOC or dark current integrated value that can be acquired by a battery sensor, but includes at least the number of parked days. These vehicle data (first and second) are linked to the vehicle's unique identification information and transmitted to the charge notification server 20, for example, when the ignition switch of the stored vehicle is turned on (IG-ON) by a worker at the vehicle dealership 10. Note that in order to accurately manage the state of the in-vehicle battery, it is desirable to transmit the vehicle data to the charge notification server 20 periodically (for example, every few days or weeks).

[0014] The vehicle dealer 10 also owns a measuring instrument 13 that can be connected to the sensor-less vehicle 12. The measuring instrument 13 is an external device (such as a battery tester) that can measure information related to the state of the vehicle battery (such as a health check) by being connected to the sensor-less vehicle 12 by a worker at the vehicle dealer 10 or the like. The measuring instrument 13 measures the voltage and current of the vehicle battery as information related to the state of the vehicle battery, and determines whether the state of charge of the vehicle battery is good or bad based on the measured values and predetermined determination conditions. The measuring instrument 13 also has a communication function unit that communicates with the charge notification server 20, and can transmit the determination result related to the state of charge of the vehicle battery to the charge notification server 20, linked with identification information unique to the vehicle. It is desirable that this determination result, like the second vehicle data, is also periodically transmitted from the measuring instrument 13 to the charge notification server 20.

[0015] Furthermore, the vehicle dealership 10 owns an information terminal device 14 for managing the status of the onboard battery of the stored vehicle. This information terminal device 14 can receive information regarding the charge status of the onboard battery of the stored vehicle from the charge notification server 20 and display the received information on a predetermined screen. An example of the information that the information terminal device 14 receives from the charge notification server 20 is a "charge request" that notifies the user that the onboard battery needs to be charged. A worker at the vehicle dealership 10 can check the charge request displayed on the screen of the information terminal device 14 and appropriately charge the onboard battery of the vehicle for which this charge request has been made, thereby preventing the stored vehicle from running out of battery power. The worker at the vehicle dealership 10 can update the information by inputting the completion of onboard battery charging into the information terminal device 14, or can report (upload) the information from the information terminal device 14 to the charge notification server 20.

[0016] The charging notification server 20 is a server that collects various information from a plurality of vehicles, including vehicles stored at the vehicle dealership 10, and manages the status of the plurality of vehicles in an integrated manner. The charging notification server 20 of this embodiment manages at least the charging status of the on-board battery as the vehicle status.

[0017] This charging notification server 20 has a function (first receiving unit) of receiving first vehicle data including battery SOC from a sensor-equipped vehicle 11 owned by a vehicle dealership 10 and receiving second vehicle data from a sensor-less vehicle 12, a function (second receiving unit) of receiving a judgment result as information regarding the battery's charging state from a measuring instrument 13, a function (conversion unit) of converting the judgment result received from the measuring instrument 13 into battery SOC, a function (judgment unit) of determining whether or not the on-board battery needs to be charged based on the received or converted battery SOC, and a function (transmission unit) of sending a request to charge the on-board battery to the vehicle dealership 10 that stores the vehicle in question if it is determined that the on-board battery needs to be charged. The details of each of these functions provided in the charge notification server 20 will be described later.

[0018] [control] Next, with further reference to FIGS. 2 to 5, the control performed by each component of the vehicle management system 1 including the charge notification server 20 according to this embodiment will be described.

[0019] (1) Vehicle processing (Figure 2) 2 is a flowchart illustrating processing executed in vehicles (sensor-equipped vehicle 11 and sensor-unequipped vehicle 12) stored by vehicle dealership 10. The processing shown in FIG. 2 is executed individually for each vehicle.

[0020] (Step S201) The vehicle determines whether the ignition switch is turned on (IG-ON state). If the ignition switch of the vehicle is turned on (YES in step S201), the process proceeds to step S202.

[0021] (Step S202) The vehicle acquires vehicle data. If the vehicle is a sensor-equipped vehicle 11, first vehicle data including information on the battery SOC, the dark current integrated value, and the number of days parked is acquired. If the vehicle is a sensor-unequipped vehicle 12, second vehicle data including information on the number of days parked is acquired. The dark current integrated value and the number of days parked acquired as the first vehicle data may be differential values from the previous first vehicle data, or may be cumulative values up to that point. Once the vehicle data (first or second) is acquired by the vehicle, the process proceeds to step S203.

[0022] (Step S203) The vehicle transmits the acquired vehicle data (first or second) to the charge notification server 20. When transmission of the vehicle data is completed, the processing in the vehicle is completed.

[0023] (2) Instrument processing (Figure 3) Fig. 3 is a flowchart illustrating processing executed in the measuring instrument 13 owned by the vehicle dealer 10. The processing shown in Fig. 3 may be performed in parallel with the processing for transmitting second vehicle data by the sensor-non-equipped vehicle 12, or may be performed in response to a contact from the charge notification server 20 that has received the second vehicle data.

[0024] (Step S301) The measuring instrument 13 determines whether or not it is connected to the sensor-non-equipped vehicle 12. If the measuring instrument 13 is connected to the sensor-non-equipped vehicle 12 (step S301, Yes), the process proceeds to step S302.

[0025] (Step S302) The measuring instrument 13 determines the state of charge of the on-board battery in the connected sensor-less vehicle 12 (hereinafter referred to as the "connected vehicle"). This determination is made based on the voltage and current of the on-board battery, and can output a result such as "The on-board battery is sufficiently charged and in good condition," as an example. Whether the on-board battery is in good condition is determined based on determination conditions pre-installed in the measuring instrument 13. Once the measuring instrument 13 determines the state of charge of the on-board battery in the connected vehicle, the process proceeds to step S303.

[0026] (Step S303) The measuring instrument 13 transmits the determination result regarding the state of charge of the on-board battery of the connected vehicle to the charge notification server 20. When the transmission of the determination result is completed, the processing in the measuring instrument 13 is completed.

[0027] (3) Charging notification server processing (Figure 4) Fig. 4 is a flowchart illustrating the processing executed in the charge notification server 20. The processing shown in Fig. 4 is executed individually for each piece of vehicle data received from a vehicle.

[0028] (Step S401) The charge notification server 20 receives vehicle data (first vehicle data or second vehicle data) from a vehicle (sensor-equipped vehicle 11 or sensor-non-equipped vehicle 12). When the vehicle data is received by the charge notification server 20, the process proceeds to step S402.

[0029] (Step S402) The charge notification server 20 determines whether the received vehicle data is first vehicle data or second vehicle data. This determination can be made by checking whether the vehicle data includes battery SOC information or by checking identification information unique to the vehicle. If the vehicle data received by the charge notification server 20 is first vehicle data (step S402, first), the process proceeds to step S405. On the other hand, if the vehicle data received by the charge notification server 20 is second vehicle data (step S402, second), the process proceeds to step S403.

[0030] (Step S403) Since the received vehicle data is the second vehicle data, the charge notification server 20 determines whether or not it has received a determination result regarding the state of charge of the on-board battery of the target vehicle from the meter 13 connected to the target vehicle (sensor-unequipped vehicle 12) that is the sender of this second vehicle data. Then, when the charge notification server 20 has received a determination result regarding the state of charge of the on-board battery of the target vehicle from the meter 13 (Yes in step S403), the process proceeds to step S404.

[0031] (Step S404) The charge notification server 20 converts the determination result received from the meter 13 into the battery SOC of the onboard battery of the target vehicle. The conversion method is not particularly limited, but examples include converting the state of charge of the onboard battery that is determined to be "excellent" to "battery SOC = 90%," and converting the state of charge of the onboard battery that is determined to be "good" to "battery SOC = 75%." Furthermore, the battery SOC may be converted based on a value that includes a certain margin of safety relative to the standard design value, rather than the actual standard design value of the onboard battery. Once the determination result has been converted into battery SOC by the charge notification server 20, the process proceeds to step S405.

[0032] (Step S405) The charge notification server 20 derives the current battery SOC of the on-board battery. Specifically, when the vehicle data is first vehicle data, the battery SOC included in the first vehicle data is used as a reference, and the charge notification server 20 subtracts the charge storage rate of the on-board battery that decreases during parking from the date the first vehicle data was received until today (the time of derivation) to derive the current battery SOC. The charge storage rate that decreases during parking of the sensor-equipped vehicle 11 can be estimated from the integrated dark current value included in the first vehicle data and the number of days the vehicle has been parked. When the vehicle data is second vehicle data, the charge notification server 20 uses the battery SOC converted in step S404 above as a reference, and subtracts the charge storage rate of the on-board battery that decreases during parking from the date the second vehicle data was received until today (the time of derivation) to derive the current battery SOC. The charge storage rate that decreases during parking of the sensor-non-equipped vehicle 12 can be estimated based on the number of days the vehicle has been parked included in the second vehicle data and a predetermined average dark current value per day of parking. It is desirable to set this average dark current value per day of parking so that the battery SOC calculated taking into account the worst-case design value for each vehicle model is lower than the actual battery SOC. Once the current battery SOC of the on-board battery is calculated by charge notification server 20, the process proceeds to step S406.

[0033] (Step S406) The charge notification server 20 determines whether or not charging of the in-vehicle battery is necessary based on the current battery SOC derived in step S405. This determination is typically made by comparing the battery SOC with a predetermined threshold. The threshold is a predetermined SOC value set based on the capacity, dark current value, etc. of the in-vehicle battery. This threshold is preferably set to an SOC value that allows some margin before the battery runs out, rather than an SOC value that poses a risk of immediate battery death. If the charge notification server 20 determines that charging of the in-vehicle battery is necessary (step S406, Yes), the process proceeds to step S407. On the other hand, if the charge notification server 20 determines that charging of the in-vehicle battery is not necessary (step S406, No), the process proceeds to step S408.

[0034] (Step S407) The charge notification server 20 transmits a charge request to the vehicle dealership 10, notifying the dealership 10 of the timing when the on-board battery needs to be charged. This charge request may be for immediate charging, or may be for a time period (for example, charging within two days). This time period can be set arbitrarily based on the dark current value while the vehicle is parked. When the charge notification server 20 transmits the on-board battery charge request to the dealership 10, the process proceeds to step S408.

[0035] (Step S408) The charge notification server 20 determines whether new vehicle data (first vehicle data or second vehicle data) has been received from the vehicle (sensor-equipped vehicle 11 or sensor-non-equipped vehicle 12) from which the battery SOC of the current on-board battery was derived. If the charge notification server 20 determines that new vehicle data has been received (step S408, Yes), the process proceeds to step S402, where the battery SOC of the current on-board battery is re-derived based on this newly received vehicle data. On the other hand, if the charge notification server 20 determines that new vehicle data has not been received (step S408, No), the process proceeds to step S405, where the battery SOC of the current on-board battery is updated based on the previously received vehicle data.

[0036] (4) Vehicle dealer processing (Figure 5) Fig. 5 is a flowchart illustrating the processing executed in the information terminal device 14 of the vehicle dealership 10. The processing shown in Fig. 5 is always performed while the information terminal device 14 is in operation.

[0037] (Step S501) The information terminal device 14 of the vehicle dealership 10 determines whether or not a charge request has been received from the charge notification server 20. When the information terminal device 14 receives a charge request, the process proceeds to step S502.

[0038] (Step S502) The information terminal device 14 of the vehicle dealership 10 displays the received charging request on the screen of the information terminal device 14. The format of the screen display is not particularly limited, except that the charging request is displayed in association with identification information unique to the vehicle. When the charging request is displayed on the screen by the information terminal device 14, the process proceeds to step S503.

[0039] (Step S503) A worker at the vehicle dealership 10 or the like charges the vehicle's onboard battery based on the charging request displayed on the screen of the information terminal device 14. This charging may be performed until the vehicle is fully charged (SOC = 100%), or may be performed until the SOC reaches a predetermined value (e.g., 80%) that takes into account the lifespan of the onboard battery. Once the onboard battery of the vehicle is charged by a worker at the vehicle dealership 10 or the like, the process proceeds to step S504.

[0040] (Step S504) When the charging operation of the vehicle's onboard battery is completed, the worker at the vehicle dealership 10 or the like inputs charging completion information into the information terminal device 14, thereby erasing the charging request displayed on the screen of the information terminal device 14. By configuring the vehicle management system 1 in this manner, it is possible to prevent the onboard battery charging operation from being left unperformed. If the vehicle is a sensor-free vehicle 12, the processing by the meter 13 (FIG. 3) may be performed after the charging operation of the onboard battery is completed. When the charging request displayed on the screen of the information terminal device 14 is erased by the worker at the vehicle dealership 10 or the like, the process proceeds to step S501.

[0041] <Actions and Effects> As described above, the charging notification server 20 according to one embodiment of the present disclosure is configured to receive second vehicle data that does not include the battery SOC from the sensor-less vehicle 12, and also to receive a determination result regarding the battery's state of charge from the measuring instrument 13, and convert this determination result into a battery SOC.

[0042] With this configuration, the sensor-less vehicle 12 can be managed in the same vehicle management system 1 as the sensor-equipped vehicle 11, which can receive first vehicle data including the battery SOC, and it can be determined whether or not the battery needs to be charged based on the battery SOC.If it is determined that the battery needs to be charged, a request to charge the battery can be sent to the vehicle dealership 10.

[0043] This charging request allows the vehicle dealer 10 to easily check which vehicles require battery charging. Furthermore, the vehicle dealer 10 can prevent batteries from being left uncharged by continuing to display the charging request on the screen of the information terminal device 14 until the battery is charged.

[0044] The above describes one embodiment of the disclosed technology, but the present disclosure can be understood as not only a charging notification server, but also a method executed by a charging notification server equipped with a processor and memory, a program that executes the method, a computer-readable non-transitory storage medium that stores the program, or a system that includes a charging notification server, a vehicle dealership, etc. [Industrial Applicability]

[0045] The charging notification server of the present disclosure can be used when it is desired to notify vehicle dealers and the like of whether or not the on-board batteries of vehicles in stock need to be charged. [Explanation of symbols]

[0046] 1. Vehicle management system 10 Vehicle dealership 11 Sensor-equipped vehicles 12 Vehicles without sensors 13 Measuring Instruments 14 Information terminal device 20 Charging notification server

Claims

1. A charging notification server that provides notifications regarding a battery installed in a vehicle, a first receiving unit that receives, from the vehicle, either first vehicle data including a battery SOC that is a charge rate of the battery or second vehicle data that does not include the battery SOC; a second receiving unit that receives information about a state of charge of the battery from an external device connected to the vehicle when the first receiving unit receives the second vehicle data; a conversion unit that converts information about the state of charge of the battery into the battery SOC; a determination unit that determines whether or not the battery needs to be charged based on the battery SOC; a transmission unit that transmits a request to charge the battery when it is determined that charging of the battery is necessary.

2. 2. The charging notification server according to claim 1, wherein the first receiving unit receives the first vehicle data from a vehicle equipped with a sensor capable of acquiring the battery SOC, and receives the second vehicle data from a vehicle not equipped with the sensor.

3. 3. The charging notification server according to claim 1, wherein the determination unit determines whether or not the battery needs to be charged based on the battery SOC received by the first receiving unit or the battery SOC converted by the conversion unit, and an average dark current value per parking day during a parking period of the vehicle.

4. The charge notification server according to claim 1 , wherein the transmission unit transmits a request to charge the battery to a vehicle dealership that keeps the vehicle.

Images