JP2021065007A - Notification system - Google Patents

Abstract

To create a charging schedule for a power storage device included in a vehicle by means of a server, and immediately notifying a user of the vehicle of the created charging schedule at a prescribed notification timing.SOLUTION: A notification system 1 includes a vehicle 50, a portable terminal 80, and a server 30. The vehicle 50 is configured to repeatedly transmit information about a charging schedule for a battery 130 to the server 30 during a target time period. The server 30 is configured to create a charging schedule for the battery 130 by using the information received from the vehicle 50 during the target time period, and repeatedly transmit the created charging schedule to the portable terminal 80. The portable terminal 80 is configured to, when a prescribed notification timing comes, notify a user of the vehicle 50 of the latest one of the charging schedules received from the server 30 during the target time period.SELECTED DRAWING: Figure 3

Description

The present disclosure relates to a notification system that notifies a vehicle user of a charging schedule.

According to Japanese Patent Application Laid-Open No. 2017-041984 (Patent Document 1), a server provided outside the vehicle estimates the departure time of the parked vehicle, and the estimated departure time is used to schedule the charging of the in-vehicle battery. The technology to create is disclosed.

JP-A-2017-041984

In the notification system described in Patent Document 1, information on the charging schedule (hereinafter, also referred to as "charging information") is transmitted from the vehicle to the server. The server creates a charging schedule using the charging information received from the vehicle, and transmits the created charging schedule to each of the vehicle and the mobile terminal. The vehicle charges the in-vehicle battery according to the charging schedule received from the server. The mobile terminal displays the charging schedule received from the server to the user of the vehicle.

In the above notification system, after the vehicle arrives at the charging location, the server creates a charging schedule based on the charging information received from the vehicle, and transmits the created charging schedule to each of the vehicle and the mobile terminal. In such a notification system, it is caused by a processing delay (that is, a delay due to the time required for the server to create a charging schedule) and a communication delay (that is, a delay due to the time required for the server to send the charging schedule to the mobile terminal). As a result, the display of the charging schedule on the mobile terminal tends to be delayed. Therefore, in the notification system described in Patent Document 1, it is difficult to immediately notify the user of the charging schedule when a predetermined notification timing (for example, the timing when the vehicle arrives at the charging place) arrives. is there.

The present disclosure has been made to solve the above problems, and an object thereof is to create a charging schedule of a power storage device provided in a vehicle by a server, and notify the user of the vehicle of the created charging schedule. It is to provide a notification system that can immediately notify at the timing.

The notification system according to the present disclosure includes a vehicle provided with a power storage device, a notification device for notifying a user of the vehicle, and a server provided outside the vehicle. The vehicle is configured to repeatedly transmit information about the charging schedule of the power storage device (that is, charging information) to the server in a predetermined period. The server is configured to repeatedly create a charging schedule for the power storage device using the charging information received from the vehicle and transmit the created charging schedule to the notification device in a predetermined period. The notification device is configured to notify the user of the vehicle of the latest charging schedule among the charging schedules received from the server when a predetermined notification timing arrives in a predetermined period. Hereinafter, the above "predetermined period" is also referred to as a "target period".

In the above notification system, the server repeatedly creates and transmits a charging schedule during the target period. Then, when the predetermined notification timing arrives, the notification device notifies the user of the vehicle of the latest charging schedule among the charging schedules received from the server. Since the notification device notifies the charging schedule already held when the predetermined notification timing arrives, the charging schedule can be notified immediately without being affected by either the processing delay or the communication delay described above. it can. According to the above notification system, the charging schedule of the power storage device provided in the vehicle can be created by the server, and the created charging schedule can be immediately notified to the user of the vehicle at a predetermined notification timing.

The charging schedule is information indicating a charging start time and a charging end time. The target period may be a period from when the vehicle start switch is turned on to when it is turned off. The target period may be set to end when the notification timing arrives. The start switch is a switch for starting the vehicle system. When the start switch is turned on, the vehicle system is started, and when the start switch is turned off, the vehicle system is stopped.

The interval at which the vehicle repeatedly transmits charging information and the interval at which the server repeatedly creates and transmits a charging schedule may be 1 second or more and 1 hour or less, or 1 minute or more and 30 minutes or less. Good.

The server predicts the time when the vehicle departs from the charging location (hereinafter, also simply referred to as “departure time”) using the charging information received from the vehicle, and predicts the predicted departure time (hereinafter, “predicted departure time””. Also referred to as) may be configured to create a charging schedule. The charging information includes the SOC (State Of Charge) of the power storage device, and the server may create a charging schedule so that the SOC of the power storage device reaches a predetermined SOC value by the predicted departure time. SOC indicates the remaining amount of electricity stored, and for example, the ratio of the current amount of electricity stored to the amount of electricity stored in a fully charged state is expressed by 0 to 100%.

The server acquires the time when the vehicle arrives at the charging place (hereinafter, also simply referred to as "arrival time") and the staying time of the vehicle at the charging place (hereinafter, also simply referred to as "staying time"), and the arrival time. And the staying time may be used to determine the predicted departure time. The server may obtain the predicted departure time on the assumption that the timing of receiving the charging information from the vehicle is the arrival time. The charging information includes information for learning the staying time, and the server may obtain the predicted departure time by using the staying time learned from the charging information.

The predetermined notification timing may be a timing at which the charging equipment and the vehicle are electrically connected via a charging cable. The predetermined notification timing may be the timing when the vehicle start switch is turned off. The predetermined notification timing may be fixed or variable.

The information from the vehicle to the server may be sent directly from the vehicle to the server, or may be sent from the vehicle to the server via another device. The vehicle may be an electric vehicle. An electric vehicle is a vehicle configured to travel using electric power stored in a power storage device mounted on the vehicle. The vehicle may be configured to be remotely controllable or autonomously driven. The notification device may be mounted on the vehicle or may be carried by a user of the vehicle (for example, an occupant or an administrator). The notification device may be mounted on a mobile terminal (that is, an electronic device portable by the user).

According to the present disclosure, a notification system capable of creating a charging schedule of a power storage device provided in a vehicle by a server and immediately notifying the created charging schedule to a user of the vehicle at a predetermined notification timing is provided. Becomes possible.

It is a figure which shows the structure of the vehicle which concerns on embodiment of this disclosure. It is a figure which shows the schematic structure of the notification system which concerns on embodiment of this disclosure. It is a figure which shows the detailed structure of the vehicle, the server, and the mobile terminal included in the notification system which concerns on embodiment of this disclosure. It is a figure for demonstrating the process which a vehicle and a mobile terminal shown in FIG. 3 repeatedly execute in a target period. It is a figure for demonstrating the process which a vehicle, a server, and a mobile terminal shown in FIG. 3 execute after the notification timing arrives. It is a figure which shows an example of the notification screen used in the process of FIG. It is a figure which shows an example of the operation of the vehicle and the mobile terminal shown in FIG. It is a flowchart which shows the process which the vehicle shown in FIG. 3 executes in a target period. It is a flowchart which shows the detail of the notification processing executed in the processing of FIG. It is a flowchart which shows the process executed by the server shown in FIG. It is a flowchart which shows the process which the mobile terminal shown in FIG. 3 executes. It is a flowchart which shows the modification of the notification processing shown in FIG.

Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings. In the figure, the same or corresponding parts are designated by the same reference numerals, and the description thereof will not be repeated.

The notification system according to this embodiment includes a plurality of vehicles. A plurality of vehicles in the notification system may have different configurations from each other, but in this embodiment, they have the same configuration from each other. Hereinafter, each of the plurality of vehicles included in the notification system will be referred to as "vehicle 50", and each of the plurality of charging facilities included in the notification system will be referred to as "EVSE40", except for the case where they will be described separately. EVSE means Electric Vehicle Supply Equipment.

FIG. 1 is a diagram showing a configuration of a vehicle according to this embodiment. With reference to FIG. 1, the vehicle 50 includes a battery 130 that stores electric power for traveling. The battery 130 includes a secondary battery such as a lithium ion battery or a nickel metal hydride battery. In this embodiment, as the secondary battery, an assembled battery including a plurality of lithium ion batteries is adopted. An assembled battery is composed of a plurality of cells (generally also referred to as "cells") electrically connected to each other. In addition, instead of the secondary battery, another power storage device such as an electric double layer capacitor may be adopted. The battery 130 according to this embodiment corresponds to an example of the "power storage device" according to the present disclosure.

The vehicle 50 includes an electronic control unit (hereinafter, referred to as “ECU (Electronic Control Unit)”) 150. The ECU 150 is configured to control the charging of the battery 130. Further, the ECU 150 is configured to control communication with the outside of the vehicle 50. The vehicle 50 further includes a monitoring module 131 that monitors the status of the battery 130. The monitoring module 131 includes various sensors for detecting the state of the battery 130 (for example, voltage, current, and temperature), and outputs the detection result to the ECU 150. The ECU 150 can acquire the state of the battery 130 (for example, temperature, current, voltage, SOC (State Of Charge), and internal resistance) based on the output of the monitoring module 131 (that is, the detected values of various sensors). .. The vehicle 50 may be an electric vehicle (EV) capable of traveling using only the electric power stored in the battery 130, or both the electric power stored in the battery 130 and the output of the engine (not shown). It may be a plug-in hybrid vehicle (PHV) that can be used and run. In this embodiment, the vehicle 50 is driven by the user, but the vehicle 50 may be configured to be self-driving.

The vehicle 50 can charge the battery 130 by receiving electric power from the EVSE 40. The vehicle 50 includes an inlet 110 and a charger 120 corresponding to the power supply system of the EVSE 40. The inlet 110 is configured to receive electric power supplied from the outside of the vehicle 50. Although only the inlet 110 and the charger 120 are shown in FIG. 1, the vehicle 50 has a plurality of power supply systems for each power supply system so as to support a plurality of types of power supply systems (for example, AC system and DC system). Inlet and charger may be provided.

A charging cable 42 is connected to the EVSE 40. The charging cable 42 may be always connected to the EVSE 40, or may be detachable from the EVSE 40. The charging cable 42 has a connector 43 at the tip and includes a power line inside. The connector 43 of the charging cable 42 can be connected to the inlet 110. By connecting the connector 43 of the charging cable 42 connected to the EVSE 40 to the inlet 110 of the vehicle 50, the EVSE 40 and the vehicle 50 are electrically connected. This makes it possible to supply electric power from the EVSE 40 to the vehicle 50 through the charging cable 42.

The charger 120 is located between the inlet 110 and the battery 130. The charger 120 includes a relay that switches the connection / disconnection of the power path from the inlet 110 to the battery 130, and a power conversion circuit (neither of which is shown). The power conversion circuit may include at least one of a rectifier circuit, a PFC (Power Factor Correction) circuit, an isolation circuit (for example, an isolation transformer), a DC / DC converter, an inverter, and a filter circuit. Each of the relay and the power conversion circuit included in the charger 120 is controlled by the ECU 150. The vehicle 50 further includes a monitoring module 121 that monitors the status of the charger 120. The monitoring module 121 includes various sensors for detecting the state of the charger 120 (for example, voltage, current, and temperature), and outputs the detection result to the ECU 150. In this embodiment, the monitoring module 121 is configured to detect the voltage and current input to the power conversion circuit and the voltage and current output from the power conversion circuit.

By connecting the EVSE 40 outside the vehicle 50 and the inlet 110 via the charging cable 42, it becomes possible to transfer electric power between the EVSE 40 and the vehicle 50. Therefore, external charging by the vehicle 50 (that is, charging the battery 130 of the vehicle 50 by receiving electric power from the outside of the vehicle 50) becomes possible. Power for external charging is supplied to the inlet 110 from, for example, the EVSE 40 through the charging cable 42. The charger 120 is configured to convert the electric power received by the inlet 110 into electric power suitable for charging the battery 130, and supply the converted electric power to the battery 130. When the external charging is executed, the relay of the charger 120 is closed (connected state), and when the external charging is not executed, the relay of the charger 120 is opened (disconnected state).

The ECU 150 includes a processor 151, a RAM (Random Access Memory) 152, a storage device 153, and a timer 154. As the processor 151, for example, a CPU (Central Processing Unit) can be adopted. The RAM 152 functions as a working memory for temporarily storing the data processed by the processor 151. The storage device 153 is configured to be able to store the stored information. The storage device 153 includes, for example, a ROM (Read Only Memory) and a rewritable non-volatile memory. In addition to the program, the storage device 153 stores information used in the program (for example, maps, mathematical formulas, and various parameters). In this embodiment, the processor 151 executes the program stored in the storage device 153 to execute various controls in the ECU 150. However, various controls in the ECU 150 are not limited to execution by software, and can also be executed by dedicated hardware (electronic circuit). The number of processors included in the ECU 150 is arbitrary, and processors may be prepared for each predetermined control.

The timer 154 is configured to notify the processor 151 of the arrival of the set time. At the time set in the timer 154, the timer 154 transmits a signal to the processor 151 to that effect. In this embodiment, a timer circuit is adopted as the timer 154. However, the timer 154 may be realized by software instead of hardware (timer circuit). Further, the ECU 150 can acquire the current time by using a real-time clock (RTC) circuit (not shown) built in the ECU 150.

The vehicle 50 further includes a traveling drive unit 140, an input device 160, a notification device 170, a communication device 180, and a drive wheel W. The drive system of the vehicle 50 is not limited to the front wheel drive shown in FIG. 1, and may be rear wheel drive or four-wheel drive.

The traveling drive unit 140 includes a PCU (Power Control Unit) and an MG (Motor Generator) (not shown), and is configured to drive the vehicle 50 using the electric power stored in the battery 130. The PCU is configured to include, for example, a control device including a processor, an inverter, a converter, a relay (hereinafter referred to as "SMR (System Main Relay)"), and (none of which are shown). To. The control device of the PCU is configured to receive an instruction (control signal) from the ECU 150 and control the inverter, converter, and SMR of the PCU according to the instruction. MG is, for example, a three-phase AC motor generator. The MG is driven by the PCU and is configured to rotate the drive wheels W. Further, the MG is configured to perform regenerative power generation and supply the generated power to the battery 130. The SMR is configured to switch connection / disconnection of the power path from the battery 130 to the PCU. The SMR is closed (connected) when the vehicle 50 is running.

The input device 160 is a device that receives input from the user. The input device 160 is operated by the user and outputs a signal corresponding to the user's operation to the ECU 150. The communication method may be wired or wireless. Examples of the input device 160 include various switches, various pointing devices, a keyboard, and a touch panel. The input device 160 may be an operation unit of a car navigation system. The input device 160 may be a smart speaker that accepts voice input.

The notification device 170 is configured to notify the user of the vehicle 50 (for example, the occupant of the vehicle 50) when requested by the ECU 150. The notification device 170 may include at least one of a display device (for example, a touch panel display), a speaker (for example, a smart speaker), and a lamp (for example, a MIL (fault warning light)). The notification device 170 may be a meter panel, a head-up display, or a car navigation system.

The communication device 180 includes various communication I / Fs (interfaces). The communication device 180 may include a DCM (Data Communication Module). The ECU 150 is configured to perform wireless communication with a communication device outside the vehicle 50 through the communication device 180.

Although not shown, the vehicle 50 includes various sensors (for example, a position sensor, an outside air temperature sensor, a vehicle speed sensor, an odometer, etc.) that detect the state of the vehicle 50 in real time. The state of the vehicle 50 is sequentially detected and recorded in the storage device 153 of the ECU 150. The position sensor may be a sensor using GPS (Global Positioning System). The position sensor may be included in a car navigation system (not shown) mounted on the vehicle 50.

In recent years, electric power systems that depend on large-scale power plants (centralized energy resources) owned by electric power companies have been reviewed, and energy resources owned by each consumer (hereinafter, also referred to as "DSR (Demand Side Resources)") are referred to as electric power. Construction of a mechanism to utilize it in the system is underway. The DSR functions as a distributed energy resource (hereinafter, also referred to as “DER (Distributed Energy Resources)”).

VPP (Virtual Power Plant) has been proposed as a mechanism for utilizing DSR in electric power systems. VPP is a mechanism that bundles a large number of DERs (for example, DSR) by advanced energy management technology using IoT (Internet of Things) and makes these DERs function as if they were one power plant by remote and integrated control. Is. In VPP, an electric power company that bundles DERs and provides energy management services is called an "aggregator". The electric power company can adjust the supply and demand balance of electric power by demand response (hereinafter, also referred to as “DR”) by cooperating with an aggregator, for example.

DR is a method of adjusting the balance between supply and demand of electric power by making a predetermined request to each consumer by a demand response signal (hereinafter, also referred to as “DR signal”). The DR signal includes a DR signal that requests suppression of power demand or reverse power flow (hereinafter, also referred to as “lower DR signal”) and a DR signal that requests an increase in power demand (hereinafter, also referred to as “up DR signal”). It is roughly divided into two types.

The notification system according to this embodiment is applied to a VGI (Vehicle Grid Integration) system. In this embodiment, an electric vehicle equipped with a power storage device (that is, the vehicle 50 described above) is adopted as the DSR for realizing VPP.

FIG. 2 is a diagram showing a schematic configuration of the notification system 1 according to this embodiment. Although FIG. 2 shows only one vehicle, one EVSE, and one aggregator server, the notification system 1 includes a plurality of each of the vehicle, the EVSE, and the aggregator server. The number of vehicles, EVSEs, and aggregator servers included in the notification system 1 is independently arbitrary, and may be 10 or more, or 100 or more. Each vehicle included in the notification system 1 may be a vehicle owned by an individual (POV) or a vehicle managed by a MaaS (Mobility as a Service) operator (MaaS vehicle). Although only one mobile terminal is shown in FIG. 2, the mobile terminal is carried by each user of the vehicle. The plurality of mobile terminals in the notification system 1 may have different configurations from each other, but in this embodiment, they have the same configuration from each other. Hereinafter, each of the plurality of mobile terminals included in the notification system 1 will be referred to as "mobile terminal 80", except for cases where the description will be made separately. Although FIG. 2 illustrates a home-use EVSE, the notification system 1 may include a public EVSE that can be used by an unspecified number of users. The notification system 1 may include an EVSE installed in a commercial facility, a convenience store, a service area, or a gas station where the vehicle temporarily stops.

With reference to FIG. 2, the notification system 1 includes a power transmission / distribution company server 10 (hereinafter, also simply referred to as “server 10”), a smart meter 11, and an aggregator server 30 (hereinafter, also simply referred to as “server 30”). , EVSE 40, vehicle 50 (see FIG. 1), HEMS-GW (Home Energy Management System-GateWay) 60, data center 70, mobile terminal 80, and power system PG. The power system PG is configured to supply power to each EVSE included in the notification system 1. The mobile terminal 80 according to this embodiment corresponds to an example of the "notification device" according to the present disclosure. In this embodiment, as the mobile terminal 80, a smartphone equipped with a touch panel display (hereinafter, may be referred to as “TPD”) is adopted. However, the present invention is not limited to this, and any mobile terminal can be adopted as the mobile terminal 80, and a tablet terminal, a smartphone, a wearable device (for example, a smart watch), an electronic key, a service tool, or the like can also be adopted.

The server 10 is a server belonging to a power transmission and distribution business operator. In this embodiment, the electric power company also serves as a power generation business operator and a power transmission and distribution business operator. The electric power company constructs an electric power network (that is, an electric power system PG) by a power plant and a power transmission and distribution facility (not shown), and maintains and manages a server 10, a smart meter 11, EVSE40, HEMS-GW60, and an electric power system PG. In this embodiment, the electric power company corresponds to the system operator who operates the electric power system PG.

An electric power company can make a profit by, for example, doing business with a consumer who uses electric power (for example, an individual or a corporation). Power companies provide smart meters to each consumer. For example, the smart meter 11 is provided to the user of the vehicle 50 shown in FIG. Identification information for identifying each smart meter (hereinafter, also referred to as “meter ID”) is given to each smart meter, and the server 10 manages the measured values of each smart meter by distinguishing them by the meter ID. .. The electric power company can grasp the electric power consumption for each consumer based on the measured value of each smart meter.

In the notification system 1, identification information (ID) for identifying a plurality of aggregators is given to each aggregator. The server 10 manages the information for each aggregator by distinguishing it by the ID of the aggregator. Aggregators provide energy management services by bundling the amount of electricity controlled by consumers in their jurisdiction. The aggregator can control the amount of electric power by requesting each consumer to adjust the supply and demand by the DR signal.

The server 30 is a server belonging to the aggregator. The server 30 according to this embodiment corresponds to an example of the "server" according to the present disclosure. The server 30 includes a control device 31, a storage device 32, and a communication device 33. The control device 31 includes a processor, performs predetermined information processing, and is configured to control the communication device 33. The storage device 32 is configured to be able to store various types of information. The communication device 33 includes various communication I / Fs. The control device 31 is configured to communicate with the outside through the communication device 33. The DSR managed by the aggregator (and thus the server 30) in the notification system 1 is an electric vehicle (for example, a POV or MaaS vehicle). The consumer can control the amount of electric power by the electric vehicle. Identification information (hereinafter, also referred to as “vehicle ID”) for identifying each vehicle 50 included in the notification system 1 is given to each vehicle 50. The server 30 manages the information for each vehicle 50 by distinguishing it by the vehicle ID. The vehicle ID may be VIN (Vehicle Identification Number). The aggregator may procure electricity supply capacity (capacity) not only from the vehicle 50 but also from resources other than the vehicle 50 (for example, a vending machine, a plant factory, or biomass). Aggregators can benefit from, for example, doing business with electric power companies. The aggregator may be divided into a higher-level aggregator that contacts a power transmission and distribution business operator (for example, an electric power company) and a lower-level aggregator that contacts a consumer.

The data center 70 includes a control device 71, a storage device 72, and a communication device 73. The control device 71 includes a processor, performs predetermined information processing, and is configured to control the communication device 73. The storage device 72 is configured to be able to store various types of information. The communication device 73 includes various communication I / Fs. The control device 71 is configured to communicate with the outside through the communication device 73. The data center 70 is configured to manage information of a plurality of registered mobile terminals (including the mobile terminal 80). The information of the mobile terminal includes not only the information of the terminal itself (for example, the communication address of the mobile terminal) but also the information about the user who carries the mobile terminal (for example, the vehicle ID of the vehicle 50 belonging to the user). Identification information for identifying the mobile terminal (hereinafter, also referred to as “terminal ID”) is given to each mobile terminal, and the data center 70 manages the information for each mobile terminal by distinguishing it by the terminal ID. The terminal ID also functions as information for identifying the user (user ID).

Predetermined application software (hereinafter, simply referred to as "application") is installed in the mobile terminal 80, and the mobile terminal 80 exchanges information with each of the server 30, HEMS-GW 60, and the data center 70 through the application. Is configured to do. The mobile terminal 80 is configured to wirelessly communicate with each of the server 30, the HEMS-GW 60, and the data center 70, for example, via the Internet. By operating the mobile terminal 80, the user can transmit information indicating the user's situation to the data center 70. As an example of the information indicating the user's situation, there is information indicating whether or not the user is in a situation capable of supporting DR. Each of the server 30 and the data center 70 is configured to separately store the information received from the mobile terminal 80 for each terminal ID.

The vehicle 50 shown in FIG. 2 is electrically connected to the outdoor EVSE 40 via a charging cable 42 in a state of being parked in a parking space of a house (for example, a user's home). The EVSE 40 is a non-public charging facility used only by the user and the user's family. By connecting the connector 43 of the charging cable 42 connected to the EVSE 40 to the inlet 110 of the vehicle 50, communication between the vehicle 50 and the EVSE 40 becomes possible, and the power supply circuit 41 provided in the EVSE 40 to the vehicle 50 (and thus the vehicle 50) , Battery 130) can be supplied with electric power. The power supply circuit 41 is configured to convert the electric power supplied from the electric power system PG into electric power suitable for external charging, and output the converted electric power to the charging cable 42.

The power supply circuit 41 is connected to the power system PG provided by the electric power company via the smart meter 11. The smart meter 11 is configured to measure the amount of electric power supplied from the EVSE 40 to the vehicle 50. The smart meter 11 is configured to measure the power consumption every predetermined time (for example, every 30 minutes), store the measured power usage, and transmit it to each of the server 10 and the HEMS-GW 60. .. As a communication protocol between the smart meter 11 and the server 10, for example, IEC (DLMS / COSEM) can be adopted. Further, the server 10 transmits the measured value of the smart meter 11 to the server 30 at any time. The server 10 may transmit periodically, or may transmit in response to a request from the server 30.

The HEMS-GW 60 is configured to transmit information on energy management (for example, information indicating the usage status of electric power) to each of the server 30, the data center 70, and the mobile terminal 80. The HEMS-GW 60 is configured to receive a measured value of electric energy from the smart meter 11. The communication method between the smart meter 11 and the HEMS-GW 60 is arbitrary, and may be 920 MHz band low power wireless communication or PLC (Power Line Communication). The HEMS-GW 60 and the EVSE 40 are configured to be able to communicate with each other via, for example, a LAN (Local Area Network). The LAN may be a wired LAN or a wireless LAN. The standard for communication between HEMS-GW60 and EVSE40 may be any of ECHONET Lite, SEP (Smart Energy Profile) 2.0, and KNX.

The server 10 and the server 30 are configured to be able to communicate with each other via, for example, a VPN (Virtual Private Network). The communication protocol between the server 10 and the server 30 may be OpenADR. The server 30 and the data center 70 are configured to be able to communicate with each other via, for example, the Internet. The communication protocol between the server 30 and the data center 70 may be OpenADR. The server 30 can acquire information about the user from the data center 70. Each of the server 30 and the data center 70 and the HEMS-GW 60 are configured to be able to communicate with each other via, for example, the Internet. The communication protocol between each of the server 30 and the data center 70 and the HEMS-GW 60 may be OpenADR.

The communication device 180 mounted on the vehicle 50 is configured to wirelessly communicate with the server 30 via, for example, a mobile communication network (telematics). The signal exchanged between the vehicle 50 and the server 30 may be encrypted by a method specified by the aggregator.

The communication device 180 mounted on the vehicle 50 is configured to communicate with the EVSE 40 via the charging cable 42. The communication method between the EVSE 40 and the vehicle 50 is arbitrary, and may be, for example, CAN (Controller Area Network) or PLC. The standard for communication between the EVSE 40 and the vehicle 50 may be ISO / IEC15118 or IEC61851.

In this embodiment, the communication device 180 and the mobile terminal 80 are configured to communicate wirelessly with each other. The ECU 150 (FIG. 1) can control the mobile terminal 80 by wireless communication to cause the mobile terminal 80 to notify the user. The communication between the communication device 180 and the mobile terminal 80 may be short-range communication (for example, direct communication in the vehicle and in the vicinity of the vehicle) such as Bluetooth (registered trademark).

In this embodiment, communication is not performed between the server 30 and the EVSE 40, but the server 30 and the EVSE 40 may be configured to be able to communicate with each other. The server 30 may be configured to communicate with the vehicle 50 via the EVSE 40. The EVSE 40 may be configured to be communicable with the EVSE management cloud. The communication protocol between the EVSE 40 and the EVSE management cloud may be OCPP (Open Charge Point Protocol).

The server 30 is configured to sequentially acquire information regarding the charging schedule of the battery 130 (that is, charging information) from the vehicle 50 and store the information in association with the vehicle ID of the vehicle 50. In this embodiment, the position of the vehicle 50, the charging cable connection state, the battery state, the arrival time of the vehicle 50 (that is, the time when the vehicle 50 arrives at the charging place), and the departure time of the vehicle 50 (that is, that is). The time when the vehicle 50 departs from the charging place) is included in the charging information. In the example shown in FIG. 2, the user's home is the charging place. The charging cable connection state is information indicating whether or not the connector 43 of the charging cable 42 is connected to the inlet 110. The battery state includes the capacity of the battery 130, the SOC value of the battery 130, information indicating whether or not the battery 130 is being charged, and the magnitude of the charging power of the battery 130. In this embodiment, the timing at which the connector 43 of the charging cable 42 is connected to the inlet 110 is defined as the arrival time. However, the arrival time is not limited to this, and the arrival time may be the timing when the start switch of the vehicle 50 is turned off, and the position of the vehicle 50 is within the peripheral range of the charging place (for example, EVSE 40 shown in FIG. 2). It may be the timing of entering. In this embodiment, the timing at which the start switch of the vehicle 50 is turned on is set as the departure time. However, the departure time is not limited to this, and the departure time may be the timing when the connector 43 of the charging cable 42 is disconnected from the inlet 110, and the position of the vehicle 50 is around the charging place (for example, EVSE 40 shown in FIG. 2). It may be the timing out of the range. The start switch is a switch generally called a "power switch" or an "ignition switch".

The server 30 is configured to create a charging schedule for the battery 130 mounted on the vehicle 50 by using the charging information received from the vehicle 50. The charging schedule is information indicating a charging start time and a charging end time. The charging schedule may further indicate the charging power (power profile) during the charging period (ie, the period from the charging start time to the charging end time). In this embodiment, the server 30 creates the first charging schedule and the second charging schedule described below.

The server 30 is configured to predict the departure time of the vehicle 50 using the charging information received from the vehicle 50 and create a first charging schedule using the predicted departure time. The server 30 sequentially updates the first charging schedule based on the charging information of the vehicle 50 and the predicted departure time, and transmits the updated first charging schedule to the vehicle 50. The first charging schedule is also transmitted to the mobile terminal 80 carried by the user of the vehicle 50. Details of the method for creating the first charging schedule will be described later.

When the server 30 receives the DR execution instruction instructing the lower DR from the server 10, the server 30 is configured to create a second charging schedule by using the DR execution instruction and the charging information of the vehicle 50. Hereinafter, the operations of the servers 10 and 30 when the second charging schedule is created by the server 30 will be described.

The server 10 is configured to perform power leveling using DR (demand response). When the server 10 performs power leveling, it first transmits a signal (hereinafter, also referred to as “DR participation request”) requesting each aggregator server (including the server 30) to participate in the DR. The DR participation request includes the area covered by the DR, the type of DR (for example, lowered DR or raised DR), and the DR period. When the server 30 receives the DR participation request from the server 10, the server 30 is configured to obtain the DR possible amount (that is, the amount of power that can be adjusted according to the DR) and transmit it to the server 10. The server 30 can obtain the DR possible amount based on, for example, the total DR capacity (that is, the DR compatible capacity) of each consumer in the jurisdiction.

The server 10 determines the DR amount for each aggregator (that is, the power adjustment amount requested to the aggregator) based on the DR possible amount received from each aggregator server, and instructs each aggregator server (including the server 30) to execute the DR. Send a signal to This signal corresponds to a DR execution instruction. The DR execution instruction includes the target area of the DR, the type of DR (for example, lowered DR or raised DR), the amount of DR for the aggregator, and the DR period (that is, the DR start time and the DR end time). Upon receiving the DR execution instruction, the server 30 selects the vehicle 50 requesting participation in the DR from the DR-compatible vehicles 50. Hereinafter, each of the selected vehicles 50 will also be referred to as a “DR vehicle”. After selecting the DR vehicle, the server 30 transmits the DR signal to each DR vehicle. The DR signal includes the type of DR (eg, lowered DR or raised DR), the amount of DR for the DR vehicle, and the period of DR.

The server 30 sequentially transmits a second charging schedule instead of the first charging schedule described above to the DR vehicle requested to participate in the lowered DR. Specifically, each time the server 30 receives charging information from the DR vehicle requesting participation in the lowered DR, the server 30 updates the second charging schedule based on the received charging information, and also updates the updated second charging. Send the schedule to the DR vehicle. The second charging schedule is also transmitted to the mobile terminal 80 carried by the user of the DR vehicle. Details of the method for creating the second charging schedule will be described later.

The ECU 150 is configured to receive a DR signal from the outside of the vehicle through the communication device 180. When the ECU 150 receives the above DR signal, the user of the vehicle 50 can contribute to the supply and demand adjustment of the power system PG by charging according to the DR signal using the EVSE 40 and the vehicle 50. According to the agreement between the user of the vehicle 50 and the electric power company (for example, the electric power company or the aggregator), when the user of the vehicle 50 contributes to the supply and demand adjustment of the power system PG, the electric power company provides an incentive according to the amount of contribution. It may be paid to the user of the vehicle 50.

The method by which the electric power company measures the above contribution amount is arbitrary. The electric power company may obtain the above contribution amount using the measured value of the smart meter 11. In addition to the smart meter 11, the notification system 1 may include a watt hour meter (for example, another smart meter) for measuring the contribution amount. The electric power company may obtain the above contribution amount using the measured value of the electric energy meter (not shown) built in the EVSE 40. The electric power company may obtain the above-mentioned contribution amount by using the measured value of the sensor (for example, monitoring modules 121 and 131) mounted on the vehicle 50. The portable charging cable may be provided with a meter function, and the electric power company may obtain the above contribution amount based on the amount of electric power measured by the charging cable. A user ID may be assigned to each charging cable so that when the user uses the charging cable, the user ID is automatically transmitted from the charging cable to the server of the electric power company (for example, server 10 or 30). .. By doing so, the electric power company can identify which user performed the charging / discharging.

In the notification system 1 according to this embodiment, the server 30 creates a charging schedule based on the charging information received from the vehicle 50. Then, the mobile terminal 80 notifies the charging schedule created by the server 30. As an example of the notification method, it is conceivable that the server 30 creates a charging schedule and transmits the created charging schedule to the mobile terminal 80 after the predetermined notification timing is reached. However, in such a notification method, it depends on the processing delay (that is, the delay due to the time required for the server 30 to create the charging schedule) and the communication delay (that is, the time required for the server 30 to transmit the charging schedule to the mobile terminal 80). Due to the delay), the notification of the charging schedule by the mobile terminal 80 is likely to be delayed.

Therefore, in the notification system 1 according to this embodiment, the vehicle 50, the server 30, and the mobile terminal 80 have the configurations described below, so that the charging schedule created by the server 30 is transmitted to the user of the vehicle 50. It is possible to immediately notify at a predetermined notification timing. FIG. 3 is a diagram showing a detailed configuration of the ECU 150, the server 30, and the mobile terminal 80 of the vehicle 50.

With reference to FIG. 3, the mobile terminal 80 includes a control device 81, a storage device 82, a communication device 83, and a TPD (touch panel display) 84. The control device 81 includes a processor, performs predetermined information processing, and is configured to control the communication device 83 and the TPD 84. The storage device 82 is configured to be able to store various types of information. The communication device 83 includes various communication I / Fs. The control device 81 is configured to communicate with the outside through the communication device 83. The mobile terminal 80 is carried by the user of the vehicle 50, and the TPD 84 notifies (for example, display) the user of the vehicle 50. The notification is not limited to the display, and may be performed by voice.

The server 30 is configured to be able to communicate with each of the communication device 180 of the vehicle 50 and the mobile terminal 80. The server 30 includes an information management unit 301, a learning unit 302, a prediction unit 303, a schedule creation unit 304, and a selection unit 305. In the server 30 according to this embodiment, each of the above parts is embodied by the processor of the control device 31 shown in FIG. 2 and the program executed by the processor. However, the present invention is not limited to this, and each of the above parts may be embodied by dedicated hardware (electronic circuit).

The ECU 150 includes an information management unit 501, a notification control unit 502, and a charge control unit 503. In the ECU 150 according to this embodiment, each of the above parts is embodied by the processor 151 shown in FIG. 1 and the program executed by the processor 151. However, the present invention is not limited to this, and each of the above parts may be embodied by dedicated hardware (electronic circuit).

The information management unit 501 of the ECU 150 acquires the charging information described above by using the outputs of various sensors mounted on the vehicle 50. The information management unit 501 is configured to repeatedly transmit charging information to the server 30 at predetermined intervals (hereinafter, also referred to as "transmission intervals") in a predetermined target period. In this embodiment, the period from when the start switch of the vehicle 50 is turned on to when it is turned off (generally referred to as "1 trip") is set as the target period. However, the present period is not limited to this, and the target period may be a period shorter than one trip. The transmission interval can be set arbitrarily. In this embodiment, 10 minutes is adopted as the transmission interval. However, the present invention is not limited to this, and the transmission interval may be 30 seconds or 1 hour. The information management unit 301 of the server 30 is configured to receive the charging information from the vehicle 50 and store it in the storage device 32. The information management unit 301 stores the charging information in the storage device 32 in association with the reception timing. Further, the information management unit 301 is configured to receive the DR execution instruction and the electricity charge information from the server 10 and store them in the storage device 32.

The learning unit 302 of the server 30 uses the charging information stored in the storage device 32 (for example, the history information of the vehicle 50) to stay in the vehicle 50 (that is, after the vehicle 50 arrives at the charging location, the charging location). Time to depart). Among the charging information received from the vehicle 50, the information management unit 301 classifies the data used for learning the staying time (hereinafter, also referred to as “learning data”) for each charging location and stores it in the storage device 32. The learning data may be stored separately for each charging location position, or may be separately stored for each category that classifies the charging location. The location of the charging location may be specified by latitude and longitude. The category for classifying the charging location can be arbitrarily set, but it may be a category such as home / work / other. The learning unit 302 may specify the place where the vehicle 50 is charged by the position of the vehicle 50 at the time of charging. In this embodiment, the position, arrival time, and departure time of the vehicle 50 are adopted as learning data. In this embodiment, the learning unit 302 learns the staying time using the historical data of the arrival time and the departure time stored in the storage device 32. The learning unit 302 distinguishes the learning result (that is, the learned staying time) for each charging place and stores it in the storage device 32. The learning method is arbitrary. AI (artificial intelligence) may be used for learning.

The prediction unit 303 of the server 30 estimates the next charging location of the vehicle 50, and acquires the staying time learned for the estimated next charging location from the storage device 32. The prediction unit 303 may estimate the next charging location using the current position of the vehicle 50. For example, the prediction unit 303 may estimate that among the pre-registered charging locations, the charging location closest to the current position of the vehicle 50 is the next charging location. In addition, the prediction unit 303 may estimate the next charging location using the current time. For example, the prediction unit 303 may estimate that the next charging place is home when the current time is included in a predetermined time zone (for example, a time zone when the user returns home).

The prediction unit 303 predicts the next departure time of the vehicle 50 by using the stay time learned for the next charging place (that is, the next stay time predicted from the past data), and predicts the next departure time (that is, the predicted next departure time). That is, the predicted departure time) is associated with the next charging location and stored in the storage device 32. The prediction unit 303 predicts the next departure time each time the information management unit 301 receives charging information from the vehicle 50. For example, the prediction unit 303 assumes that the timing when the information management unit 301 receives the charging information from the vehicle 50 is the next arrival time (that is, the time when the vehicle 50 arrives at the next charging place), and the next arrival time and the next stay Predict the next departure time based on time. The prediction unit 303 may predict that the timing at which the next stay time has elapsed from the next arrival time is the next departure time.

The schedule creation unit 304 of the server 30 uses the SOC of the battery 130 included in the charging information received from the vehicle 50 and the next departure time predicted as described above (that is, the predicted departure time) to perform the first charging schedule. To create. For example, the schedule creation unit 304 creates a first charging schedule so that the SOC of the battery 130 has a predetermined SOC value (for example, an SOC value indicating full charge) at the predicted departure time.

The schedule creation unit 304, when creating the first charging schedule, is based on the charging start time and the remaining charging time (that is, the time required for the SOC of the battery 130 to reach a predetermined SOC value by external charging). The charging end time may be determined. The schedule creation unit 304 may determine the timing at which the remaining charging time has elapsed from the charging start time as the charging end time. The schedule creation unit 304 can estimate the remaining charge time by using the SOC of the battery 130 received from the vehicle 50 and the charge rate. The charging rate may be a value estimated by the schedule creation unit 304 or a predetermined value. The schedule creation unit 304 may estimate the charging rate using the output voltage (for example, 100V or 200V) of the EVSE 40 installed at the next charging location. The remaining charge time may be calculated in the vehicle 50 and transmitted from the vehicle 50 to the server 30.

The schedule creation unit 304 may determine the charging start time of the first charging schedule by using the electricity charge information acquired from the server 10 by the information management unit 301. For example, the schedule creation unit 304 determines the charging start time and the charging end time of the first charging schedule so that the charging is completed by the predicted departure time and the charging is executed in the time zone when the electricity charge is low. You may. Further, the schedule creation unit 304 sets the charging start time and charging end of the first charging schedule so that the time from the charging end time (that is, the timing when the SOC of the battery 130 reaches the predetermined SOC value) to the predicted departure time is shortened. The time may be determined. If the battery 130 is left in a high SOC state for a long time, the deterioration of the battery 130 tends to progress.

The schedule creation unit 304 stores the first charging schedule created as described above in the storage device 32 in association with the vehicle ID. Further, when the information management unit 301 receives the DR execution instruction from the server 10, the schedule creation unit 304 creates the second charging schedule described below.

When the information management unit 301 receives the DR execution instruction from the server 10, the selection unit 305 selects the number of vehicles 50 required to respond to the request of the server 10. Each vehicle 50 selected by the selection unit 305 corresponds to a DR vehicle. The schedule creation unit 304 creates a temporary charging schedule for each DR vehicle based on the charging information of each DR vehicle and the content of the DR execution instruction. The created temporary charging schedule corresponds to the DR period for each DR vehicle. The tentative charging schedule specifies the date and rough time zone for requesting charging. The information management unit 301 transmits a DR signal including a temporary charging schedule created by the schedule creation unit 304 to the user of each DR vehicle, and gives the user an answer (answer back) as to whether or not to approve the DR signal. Request. The DR signal may be transmitted to the communication device 180 mounted on the DR vehicle, or may be transmitted to the mobile terminal 80 carried by the user of the DR vehicle.

When the information management unit 301 receives a reply of "not approving" from any of the users, the information management unit 301 notifies the schedule creation unit 304 and the selection unit 305 to that effect. The schedule creation unit 304 and the selection unit 305 exclude the vehicle 50 belonging to the user who did not approve from the candidates for the DR vehicle, and start over from the selection of the DR vehicle. When the information management unit 301 receives the answers of "approve" from all the users, the selection unit 305 determines each vehicle 50 belonging to the approved user as a DR vehicle. The information management unit 301 notifies the user of each DR vehicle that the electric power transaction has been completed, and stores the vehicle ID of each DR vehicle in the storage device 32 in association with the DR execution instruction.

After the DR vehicle is determined, the schedule creation unit 304 uses the SOC of the battery 130 included in the charging information received from each DR vehicle and the DR signal (for example, DR period and DR amount) for each DR vehicle. Create a second charging schedule for the DR vehicle. For example, when a plurality of DR vehicles are sequentially externally charged by a relay method, a second charging schedule for each DR vehicle may be created so that the DR vehicle having a lower SOC of the battery 130 will be charged longer. .. The schedule creation unit 304 stores the second charging schedule created as described above in the storage device 32 in association with the vehicle ID.

The schedule creation unit 304 creates the second charging schedule for each DR vehicle. Each time the information management unit 301 receives charging information from the DR vehicle, the server 30 creates a second charging schedule by the schedule creation unit 304, and the created second charging schedule is transmitted to the DR vehicle and the DR vehicle by the information management unit 301. The information is transmitted to each of the mobile terminals 80 carried by the user. Further, the schedule creation unit 304 creates the above-mentioned first charging schedule for the vehicle 50 other than the DR vehicle (hereinafter, also referred to as “non-DR vehicle”). The server 30 creates a first charging schedule by the schedule creation unit 304 each time the information management unit 301 receives charging information from the non-DR vehicle, and the information management unit 301 non-DRs the created first charging schedule. The information is transmitted to each of the vehicle and the mobile terminal 80 carried by the user.

When the information management unit 501 of the ECU 150 receives either the first charging schedule or the second charging schedule from the server 30, the information management unit 501 stores the received charging schedule in the storage device 153. Further, when the control device 81 of the mobile terminal 80 receives either the first charging schedule or the second charging schedule from the server 30, the control device 81 stores the received charging schedule in the storage device 82. Each of the ECU 150 and the mobile terminal 80 may save each charging schedule sequentially received from the server 30 in association with the reception time. When each of the ECU 150 and the mobile terminal 80 receives a new charging schedule from the server 30, the past charging schedule received before this may be deleted, or the newly received charging schedule may be deleted from the past. It may be accumulated in addition to the charging schedule. Further, when the amount of data related to the charging schedule stored in each of the storage devices 82 and 153 exceeds a predetermined value, the oldest charging schedule may be deleted in order.

The charge control unit 503 is configured to control the charge of the battery 130 by controlling the charger 120. The storage device 153 of the ECU 150 stores a timer charge flag indicating whether or not a timer charge is reserved. When the timer charge flag is ON, it means that the timer charge is reserved in the ECU 150. When the timer charge flag is OFF, it means that the timer charge is not reserved in the ECU 150. When the timer charge is reserved in the ECU 150, the charge control unit 503 automatically executes the timer charge according to the latest charging schedule stored in the storage device 153. Timer charging starts with the arrival of the start time of the charging schedule and ends with the arrival of the end time of the charging schedule.

In this embodiment, the charge control unit 503 turns on the timer charge flag when a predetermined reservation condition is satisfied. Reservation conditions can be set arbitrarily. Further, the user can reserve the timer charge or cancel the timer charge reservation for the ECU 150 by operating the input device 160 (FIG. 1) or the mobile terminal 80 (FIG. 2). .. Further, the user can update the charging schedule stored in the storage device 153 by operating the input device 160 (FIG. 1) or the mobile terminal 80 (FIG. 2). By reserving timer charging after updating the charging schedule, the user can cause the charge control unit 503 to execute timer charging at any charging schedule.

When a predetermined notification timing arrives, the control device 81 of the mobile terminal 80 controls the TPD 84 to display the latest charging schedule among the charging schedules received from the server 30 to the user of the vehicle 50. In this embodiment, the notification timing is set in the notification control unit 502 of the ECU 150. The notification timing may be set in advance in the notification control unit 502, or the user may set the notification timing in the notification control unit 502 through the input device 160 (FIG. 1) or the mobile terminal 80 (FIG. 2). When the notification timing arrives, the notification control unit 502 notifies the mobile terminal 80 to that effect. In this embodiment, the timing at which the start switch of the vehicle 50 is turned off is adopted as the notification timing. When the start switch of the vehicle 50 is turned off, the notification control unit 502 transmits a signal indicating that the notification timing has arrived (hereinafter, also referred to as a “timing signal”) to the mobile terminal 80 through the communication device 180. Upon receiving the timing signal, the mobile terminal 80 carried by the user of the non-DR vehicle notifies the user of the latest first charging schedule. When the mobile terminal 80 carried by the user of the DR vehicle receives the timing signal, the mobile terminal 80 notifies the user of the latest second charging schedule.

FIG. 4 is a diagram for explaining a process repeatedly executed by the server 30, the vehicle 50, and the mobile terminal 80 during the target period. The “server” in FIG. 4 means the server 30.

With reference to FIGS. 1 to 3 and FIG. 4, the vehicle 50 transmits charging information to the server 30. The server 30 creates a charging schedule for the battery 130 (for example, a first charging schedule or a second charging schedule) using the charging information received from the vehicle 50. After that, the server 30 transmits the created charging schedule to each of the vehicle 50 and the mobile terminal 80. Each of the vehicle 50 and the mobile terminal 80 stores the charging schedule received from the server 30. During the target period, the server 30, the vehicle 50, and the mobile terminal 80 repeatedly execute the process shown in FIG.

FIG. 5 is a diagram for explaining the processing executed by the server 30, the vehicle 50, and the mobile terminal 80 after the notification timing has arrived. The “server” in FIG. 5 means the server 30.

With reference to FIGS. 1 to 3 and FIG. 5, when a predetermined notification timing arrives, the mobile terminal 80 notifies the user of the vehicle 50 the latest charging schedule among the plurality of charging schedules received from the server 30 during the target period. Notify against. For example, the TPD 84 displays a screen for notifying the user of the charging schedule (hereinafter, also referred to as a “notification screen”). After that, the mobile terminal 80 receives a schedule change from the user during a predetermined period (hereinafter, also referred to as a "change period"). The change period can be set arbitrarily. During the change period, the TPD 84 continuously displays the notification screen.

FIG. 6 is a diagram showing an example of the notification screen. With reference to FIGS. 1 to 3 and FIG. 6, this notification screen includes a message M1, a schedule display unit M2, a change button M3, and an approval button M4. The user can confirm the current charging schedule by looking at the schedule display unit M2. The schedule display unit M2 shown in FIG. 6 indicates the charging schedule in characters, but the charging schedule display method is arbitrary. For example, the charging schedule may be shown in a graph. Since the notification screen is displayed on the TPD 84 of the mobile terminal 80, the user can perform a touch panel operation on the notification screen. When the user presses the change button M3, a schedule change screen (not shown) is displayed on the TPD 84, and the current charging schedule can be changed. When the user changes the charging schedule, the current charging schedule in the mobile terminal 80 is updated. When the charging schedule is changed by the user, the TPD 84 displays the notification screen again. At this time, the changed charging schedule is displayed on the schedule display unit M2. When the user presses the approval button M4, the change period ends. Further, the change period ends even when a predetermined time elapses without the user performing an operation while the TPD 84 displays the notification screen.

With reference to FIG. 5 again, if the charging schedule is changed by the user during the change period, the mobile terminal 80 sets the latest charging schedule (that is, the changed charging schedule) to each of the vehicle 50 and the server 30. Send to. Each of the vehicle 50 and the server 30 stores the charging schedule received from the mobile terminal 80. Then, when the change period ends, a signal indicating that the charging schedule has been confirmed (hereinafter, also referred to as a “confirmation signal”) is transmitted from the mobile terminal 80 to each of the vehicle 50 and the server 30. As a result, timer charging according to the fixed charging schedule is reserved for the vehicle 50. The changed charging schedule and the confirmation signal may be transmitted from the mobile terminal 80 to the server 30 and then transmitted from the server 30 to the vehicle 50.

In this embodiment, the target period starts when the start switch of the vehicle 50 is turned on, and ends when the start switch of the vehicle 50 is turned off. Further, the timing when the start switch of the vehicle 50 is turned off corresponds to the notification timing. FIG. 7 is a diagram showing an example of the operation of the vehicle 50 and the mobile terminal 80. With reference to FIG. 7, the vehicle 50 repeatedly transmits the charging information to the server 30 during the target period. Further, each of the vehicle 50 and the mobile terminal 80 repeatedly receives the charging schedule from the server 30 during the target period. When the start switch of the vehicle 50 is turned off, the mobile terminal 80 notifies the user of the vehicle 50 of the latest charging schedule among the charging schedules received from the server 30.

FIG. 8 is a flowchart showing a process executed by the ECU 150 of the vehicle 50 during the target period. The process shown in this flowchart is repeatedly executed at a predetermined cycle.

In step 11 (hereinafter, simply referred to as “S”) 11 with reference to FIGS. 1 to 3 and FIG. 8, the ECU 150 determines whether or not the period is within the target period. During the period when the start switch of the vehicle 50 is ON, YES is determined in S11, and the process proceeds to S12. On the other hand, if NO (not within the target period) is determined in S11, the process does not proceed to S12, and the process of S11 is repeated.

In S12, the ECU 150 determines whether or not the predetermined transmission timing has been reached. The transmission timing corresponds to the transmission interval described above. In this embodiment, since the transmission interval is 10 minutes, the transmission timing comes every 10 minutes. When the transmission timing comes (YES in S12), the ECU 150 transmits the charging information to the server 30 in S13. After that, the process proceeds to S14. On the other hand, if NO is determined in S12, the process proceeds to S14 without going through S13.

In S14, it is determined whether or not the ECU 150 has received the charging schedule (that is, the charging schedule transmitted in S25 of FIG. 10 described later) from the server 30. When the ECU 150 receives the charging schedule (YES in S14), the ECU 150 stores the charging schedule in the storage device 153 in S15. When the vehicle 50 is a non-DR vehicle, the ECU 150 receives the first charging schedule from the server 30 and stores it in the storage device 153. When the vehicle 50 is a DR vehicle, the ECU 150 receives the second charging schedule from the server 30 and stores it in the storage device 153. After that, the process proceeds to S16. On the other hand, if NO is determined in S14, the process proceeds to S16 without going through S15.

In S16, the ECU 150 determines whether or not the predetermined notification timing has been reached. In this embodiment, when the start switch of the vehicle 50 is turned off, YES is determined in S16, and the process proceeds to S17. Further, when the start switch of the vehicle 50 is turned off, the vehicle system (and thus the ECU 150) is put into a stopped state (Ready-off state), and the vehicle 50 is put into a parked state. On the other hand, if NO (not the notification timing) is determined in S16, the process returns to S11.

In S17, the ECU 150 executes a predetermined notification process. FIG. 9 is a flowchart showing details of the notification process executed in S17 of FIG.

In S110, the ECU 150 transmits a timing signal (that is, a signal indicating that the notification timing has arrived) to the mobile terminal 80 with reference to FIGS. 1 to 3 and FIG. In S120, it is determined whether or not the ECU 150 has received the charging schedule (that is, the charging schedule transmitted in S37 of FIG. 11 described later) from the mobile terminal 80. When the ECU 150 receives the charging schedule (YES in S120), the ECU 150 stores the charging schedule in the storage device 153 in S130. After that, the process proceeds to S140. On the other hand, if NO is determined in S120, the process proceeds to S140 without going through S130.

In S140, the ECU 150 determines whether or not the charging schedule has been finalized. The ECU 150 determines whether or not the charging schedule has been determined based on the presence or absence of reception of the confirmation signal (that is, the signal transmitted in S39 of FIG. 11 described later). While it is determined as NO in S140, the processes of S120 to S140 are repeated. When the ECU 150 receives the confirmation signal from the mobile terminal 80, it is determined as YES in S140, and the process proceeds to S150.

In this embodiment, if YES is determined in S140, the above-mentioned reservation condition is satisfied. When the reservation condition is satisfied, the ECU 150 turns on the timer charging flag (initial value is OFF) (S150). As a result, timer charging is reserved in the ECU 150. The timer charging reserved in the ECU 150 is executed according to the latest charging schedule among the charging schedules stored in the storage device 153 in S15 of FIG. 8 and S130 of FIG.

When the process of S150 of FIG. 9 is executed, the process of S17 of FIG. 8 ends. After that, the process returns to S11 in FIG.

FIG. 10 is a flowchart showing a process executed by the server 30. The process shown in this flowchart is repeatedly executed at a predetermined cycle. The process shown in FIG. 10 is executed in parallel with the process shown in FIG.

With reference to FIGS. 10 and 3 together with FIGS. 1 to 3, in S21, it is determined whether or not the control device 31 of the server 30 has received the DR execution instruction from the server 10. When the control device 31 receives the DR execution instruction (YES in S21), the control device 31 selects the DR vehicle in S22. After that, the process proceeds to S23. On the other hand, if NO is determined in S21, the process proceeds to S23 without going through S22.

In S23, it is determined whether or not the control device 31 has received the charging information (that is, the charging information transmitted in S13 of FIG. 8) from the vehicle 50. When the control device 31 receives the charging information (YES in S23), the control device 31 creates and saves the charging schedule using the charging information in S24. The server 30 receives charging information from each vehicle 50 included in the notification system 1. The control device 31 creates a charging schedule for each vehicle, associates the created charging schedule with the vehicle ID, and stores it in the storage device 32. Further, in S25, the control device 31 transmits the charging schedule created in S24 to each of the vehicle 50 and the mobile terminal 80 (more specifically, the mobile terminal carried by the user of the vehicle 50). The control device 31 transmits a charging schedule corresponding to the vehicle ID to each vehicle 50 and each mobile terminal 80. When the server 30 receives the charging information from the non-DR vehicle, the control device 31 creates a first charging schedule and returns it. When the server 30 receives the charging information from the DR vehicle, the control device 31 creates a second charging schedule and returns it.

After the processing of S25, the processing proceeds to S26. If NO is determined in S23, the process proceeds to S26 without going through S24 and S25. In S26, it is determined whether or not the control device 31 has received the charging schedule (that is, the charging schedule transmitted in S37 of FIG. 11 described later) from the mobile terminal 80. When the control device 31 receives the charging schedule (YES in S26), the control device 31 stores the charging schedule in the storage device 32 in S27. After that, the process returns to S21. On the other hand, if NO is determined in S26, the process returns to S21 without going through S27.

FIG. 11 is a flowchart showing a process executed by the mobile terminal 80. The process shown in this flowchart is repeatedly executed at a predetermined cycle. The process shown in FIG. 11 is executed in parallel with the process shown in FIGS. 8 and 10.

With reference to FIGS. 1 to 3, in S31, whether or not the control device 81 of the mobile terminal 80 has received the charging schedule (that is, the charging schedule transmitted in S25 of FIG. 10) from the server 30. To judge. When the control device 81 receives the charging schedule (YES in S31), the control device 81 stores the charging schedule in the storage device 82 in S32. When the mobile terminal 80 is carried by a user of a non-DR vehicle, the control device 81 receives the first charging schedule from the server 30 and stores it in the storage device 82. When the mobile terminal 80 is carried by the user of the DR vehicle, the control device 81 receives the second charging schedule from the server 30 and stores it in the storage device 82. After that, the process proceeds to S33. On the other hand, if NO is determined in S31, the process proceeds to S33 without going through S32.

In S33, the control device 81 determines whether or not the predetermined notification timing has been reached. In this embodiment, when the control device 81 receives the timing signal (that is, the signal transmitted in S110 of FIG. 9) from the vehicle 50, it is determined that the notification timing has been reached. When the control device 81 receives the timing signal (YES in S33), the process proceeds to S34. On the other hand, if NO (not the notification timing) is determined in S33, the process returns to S31.

In S34, the control device 81 controls the TPD 84 to notify the user of the vehicle 50 of the latest charging schedule among the plurality of charging schedules received in S31. In this embodiment, the TPD 84 displays a notification screen (for example, the notification screen shown in FIG. 6). After that, the control device 81 receives the schedule change from the user in the predetermined change period. The user can change the charging schedule by operating the touch panel on the notification screen.

In S35, the control device 81 determines whether or not the schedule has been changed by the user. When the charging schedule is changed by the user (YES in S35), the control device 81 updates the current charging schedule (that is, the charging schedule notified in S34) to the changed charging schedule in S36. Further, in S37, the control device 81 transmits the changed charging schedule to each of the server 30 and the vehicle 50 belonging to the user who carries the mobile terminal 80.

After the processing of S37, the processing proceeds to S38. If NO is determined in S35, the process proceeds to S38 without going through S36 and S37. In S38, the control device 81 determines whether or not the change period has expired. During the period determined to be NO (the change period has not ended) in S38, the processes of S34 to S38 are repeated. When the change period ends (YES in S38), the control device 81 notifies each of the server 30 and the vehicle 50 belonging to the user who carries the mobile terminal 80 in S39 that the charging schedule has been confirmed. .. In this embodiment, the control device 81 transmits the above-mentioned confirmation signal. After that, the process returns to S31.

As described above, the notification system 1 according to this embodiment includes a vehicle 50 including a battery 130, a mobile terminal 80 that notifies a user of the vehicle 50, a communication device 180 of the vehicle 50, and a mobile terminal 80. A server 30 configured to be able to communicate with each of the above is provided. The vehicle 50 is configured to repeatedly transmit information regarding the charging schedule of the battery 130 (that is, charging information) to the server 30 during the target period (see FIG. 8). The server 30 is configured to repeatedly create a charging schedule for the battery 130 using the charging information received from the vehicle 50 and transmit the created charging schedule to the mobile terminal 80 during the target period (FIG. FIG. 10). The mobile terminal 80 is configured to notify the user of the vehicle 50 of the latest charging schedule among the charging schedules received from the server 30 when a predetermined notification timing arrives in the target period (S33 in FIG. 11). , S34). In such a notification system 1, since the mobile terminal 80 notifies the charging schedule already held when the predetermined notification timing arrives, it is immediately affected by neither the processing delay nor the communication delay described above. The charging schedule can be notified.

In the above embodiment, the ECU 150 of the vehicle 50 executes the reserved timer charging. However, the present invention is not limited to this, and the battery 130 may be charged by the server 30 remotely controlling the vehicle 50 according to the charging schedule.

In the above embodiment, the server 30 is configured to create both a first charging schedule and a second charging schedule. However, the present invention is not limited to this, and the server 30 may be configured to create only one of the first charging schedule and the second charging schedule. The server 30 may be configured to create and transmit a charging schedule (eg, at least one of a first charging schedule and a second charging schedule) only when requested by the user of the vehicle 50.

In the above embodiment, the mobile terminal 80 is adopted as a notification device that notifies the user of the vehicle 50 of the charging schedule. However, the present invention is not limited to this, and instead of the mobile terminal 80, the notification device 170 (FIG. 1) mounted on the vehicle 50 may be adopted. By controlling the notification device 170, the ECU 150 can notify the user (for example, the occupant) of the vehicle 50. The ECU 150 may be configured to execute the process shown in FIG. 12 instead of the process shown in FIG. 9 in S17 of FIG. FIG. 12 is a flowchart showing a modified example of the notification process shown in FIG.

With reference to FIGS. 1 to 3, in S210, the ECU 150 controls the notification device 170 to set the latest charging schedule among the plurality of charging schedules received in S14 of FIG. 8 to the user of the vehicle 50. Notify. After that, the ECU 150 receives a schedule change from the user during a predetermined change period. The user can change the charging schedule by operating the input device 160.

In S220, the ECU 150 determines whether or not the schedule has been changed by the user. When the charging schedule is changed by the user (YES in S220), the ECU 150 updates the current charging schedule (that is, the charging schedule notified in S210) to the changed charging schedule in S230. Further, the ECU 150 transmits the changed charging schedule to the server 30 in S240.

After the processing of S240, the processing proceeds to S250. If NO is determined in S220, the process proceeds to S250 without going through S230 and S240. In S250, the ECU 150 determines whether or not the change period has expired. During the period determined to be NO (the change period has not ended) in S250, the processes of S210 to S250 are repeated. When the change period ends (YES in S250), the ECU 150 notifies the server 30 of the confirmation of the charging schedule in S260. After that, the ECU 150 turns on the timer charging flag (initial value is OFF) in S270. As a result, timer charging is reserved in the ECU 150. When the process of S270 of FIG. 12 is executed, the process of S17 of FIG. 8 ends. After that, the process returns to S11 in FIG.

In the above-described embodiment and modification, the schedule change from the user is accepted in S35 to S38 in FIG. 11 and S220 to S250 in FIG. However, it is not essential to accept the schedule change from the user after notifying the user of the charging schedule, and it may be omitted.

In the above-described embodiment and modification, timer charging is automatically reserved in S150 of FIG. 9 and S270 of FIG. However, it is not essential that the timer charge is automatically reserved when the charging schedule is fixed, and it may be omitted.

The configuration of the vehicle is not limited to the configuration shown in FIG. For example, the vehicle may be configured for non-contact charging. Further, the vehicle may be a bus or a truck.

The configuration of the notification system is not limited to the configuration shown in FIG. The electric power company may be spun off by business. The power generation company and the power transmission and distribution company may be different companies. In the above embodiment, the electric power company requests the aggregator to participate in the DR, but the electric power market may request the aggregator to participate in the DR. Aggregators may profit from trading in the electricity market (eg, trading capacity or operating power). Further, the server provided outside the vehicle and creating a charging schedule using the information received from the vehicle is not limited to the aggregator server, and manages the vehicle for a purpose different from that of the aggregator (for example, car sharing). It may be a server.

The embodiments disclosed this time should be considered to be exemplary in all respects and not restrictive. The scope of the present invention is shown by the scope of claims rather than the description of the embodiment described above, and is intended to include all modifications within the meaning and scope equivalent to the scope of claims.

1 Notification system, 10 Transmission and distribution company server, 11 Smart meter, 30 Aggregator server, 31,71,81 Control device, 32,72,82 Storage device, 33,73,83 Communication device, 41 Power supply circuit, 42 Charging cable , 43 connectors, 50 vehicles, 60 HEMS-GW, 70 data centers, 80 mobile terminals, 110 inlets, 120 chargers, 121,131 monitoring modules, 130 batteries, 140 driving units, 150 ECUs, 151 processors, 152 RAM, 153 Storage device, 154 timer, 160 input device, 170 notification device, 180 communication device, 301 information management unit, 302 learning unit, 303 prediction unit, 304 schedule creation unit, 305 selection unit, 501 information management unit, 502 notification control unit , 503 Charge control unit, PG power system, W drive wheel.

Claims (1)

Vehicles equipped with power storage devices and
A notification device that notifies the user of the vehicle and
It is equipped with a server provided outside the vehicle.
The vehicle is configured to repeatedly transmit information about the charging schedule of the power storage device to the server in a predetermined period.
The server is configured to repeatedly create a charging schedule for the power storage device using the information received from the vehicle and transmit the created charging schedule to the notification device in the predetermined period.
The notification device is configured to notify the user of the vehicle of the latest charging schedule among the charging schedules received from the server when a predetermined notification timing arrives in the predetermined period. ..

Images