Patent Application
20130339108
The disclosure relates to a system and method for managing demand charge tariffs for electric power, in particular, providing economic energy management for charging electric vehicles at public chargers.
Electric vehicles (EVs) are being designed and manufactured by automobile manufacturers. Electric vehicle charging can be performed at home charging stations or public charging stations. Due to the limited range available with today's electric vehicles, electric vehicle drivers have to rely on both the ability to charge at home as well as away from home at public charging stations.
In some communities in the United States, public charging stations are being offered through government grants that may allow for free or discounted access to encourage electric vehicle purchases. Nevertheless, the public charging stations only have limited existence today. One barrier deterring new public charging stations from being installed are utility tariff structures. Typically, electricity cost for businesses are billed not only based on the total usage for each month but also on their respective peak usage during a month. For example, if a business has a peak usage exceeding a threshold level during a month, a multiplication factor larger than one will be applied to its electricity bill for the month. That is, the business will incur a higher cost for exceeding the threshold level. Thus, if a business installs public charging stations on its premise, the charging operation may cause the electricity usage by the business to exceed a peak usage threshold and force the business to pay a penalty on its electricity cost. To make the matter more complicated, if the business wants to control the charging operation at the public charging stations on its premise, any driver interested in charging at the controlled public charging stations need to get advanced notice before they pull up to charge.
Accordingly, there is a need in the art for providing economic energy management for charging electric vehicles at public charging stations.
Embodiments of the present invention may provide economic energy management for charging electric vehicles at public charging stations. On embodiment may provide a method to provide demand charge management at public charging stations. The method may comprise collecting information related to electric vehicle (EV) charging from a plurality of interested parties by an infrastructure service cloud, computing charge rate offers based on the collected information by the infrastructure service cloud, transmitting the computed charge rate offers to a driver of an EV by the infrastructure service cloud, and reserving a charge spot for the driver using the infrastructure service when the driver accepts an offer.
Embodiments of the present invention may encourage more charging station deployments by managing demand charges. The demand charge management policy may be implemented through cloud-based services. In one embodiment, given a specific address, a cloud-based infrastructure service may (a) inform the driver of the allowed charging level at the specific address before the driver arrives, and (b) enforce that charging level through cloud-based communication to the electric vehicle and to networked EV charging stations located at that address.
The driver 102 may represent a plurality of drivers that drive electric vehicles. The driver 102 may drive the electric vehicle around and request charging at public charge stations. The electricity to be consumed for charging the electric vehicle at a public charge station may be referred to as demand charge. The retailer 104 may be a small store or franchisee that hosts public charge spots 120. The retailer 104 may represent a plurality of retailers under control by a retailer chain. The retailer cloud 118 may be a computer network for the retailer's parent organization (e.g., the retailer chain). The parent organization may partly determine policy for the retailer 104. The retailer cloud 118 may represent a plurality of retailer organizations that each may have a plurality of retailer stores like the retailer 104. Each of the charge spots 120 may be a networked charging station that may be monitored and remote-controlled. The EVSP cloud 116 may represent a network server of the EVSP that directly controls charging stations. The utility cloud 110 may represent a local utility's network computer servers. These computer servers may hold energy usage information, and compute official demand charges.
The OEM cloud 108 may represent a computer network for the vehicle manufacture or the dealer of the electric vehicle driven by the driver 102. The OEM cloud 108 may communicate with the vehicle by wireless communication. In one or more embodiments, the OEM cloud 108 may comprise network servers belonging to the driver's OEM brand and the OEM may control the communication with the electric vehicle drive by the driver 102 such that all communication may go through the OC 108.
The TPC 112 may comprise a computer network of a third party that may be interested in allowing D 102 to access E 104, and may reimburse demand charges. The GC 114 may be a computer network of a government entity that may track energy supplied by E, and tax it, or issue credits for it. The SC 106 may be a cloud-based computing platform that provides services to and routes data from all the other entities. In the system 100, each of the clouds may comprise a plurality of interconnected computing devices, including, for example, computer servers, terminals, data storage devices.
At 206.1 and 206.2, the SC 106 may inform the driver 102 (via the OC 108) and RC 118 of the offer P_D. At 208, the driver 208 may send (via the OC 108) an acceptance of the offer to the SC 106. At 210, the SC 106 may reserve the charge spot 120 at the EC 116, which may send a reservation notice to the charge spot 120. Also, the SC 106 may notify the RC 118, which may in turn notify the retailer 104 that a charge spot 120 at the retailer 104 has been reserved. At 212, the driver 102 may charge the electric vehicle at the charge spot 120 while going into the retailer 104 to purchase goods or services. At 214, 6. the charge spot 120 may report the charging session ended to the EC 116, which may report to the SC 106. At 216.1, the SC 106 may notify the driver 102 (via the OC 108) of the final duration and price of the charging event. And at 216.2, the SC 106 may notify other parties (e.g., the UC 110, GC 114, RC 118 and the retailer 104) of the event, for their records. In one embodiment, the driver may be receive a financial charge that may be consolidated into a monthly bill.
In one or more embodiment, the sequence 200 may cover back-end interactions among the parties shown in the system 100 of
The infrastructure service cloud 106 may collect information from the utility cloud 110 as indicated by the arrow 306, from the ESVP cloud 116 as indicated by the arrow 310 and from the retailer cloud 118 as indicated by the arrow 314. For example, the infrastructure service cloud 106 may collect electricity prices from a plurality of utilities via one or more utility cloud 110. Further, the infrastructure service cloud 106 may collect scheduling information for charge spots in the neighborhood from a EV service provider via the ESVP cloud 116. Each ESVP cloud 116 may check availability of all charge spots E 120 under its control (e.g., busy or free, is there reservations, etc.). The retailer cloud 118 may collect non-EV electricity usage information from the retailer 104, for example, by the arrow 312. The infrastructure service cloud 106 may check customer profitability and non-EV electricity usage of the retailer 104 via the retailer cloud 118. In one embodiment, the infrastructure service cloud 106 may compute one or more P_D offers based on the collected information. The information collected by the infrastructure service cloud 106's may be pulled by the infrastructure service cloud 106 and/or pushed from the utility cloud 110, the ESVP cloud 116 and the retailer cloud 118.
Based on the collected information, the infrastructure service cloud 106 may compute one or more offers of P_D and send to the OEM cloud 108, e.g., as indicated by the arrow 316. The OEM cloud 108 may relay these offers to the vehicle and driver 102, e.g., as indicated by the information flow arrow 308.
In one embodiment, the whole information collection, P_D computation, request and response process may be automated. For example, when the electric vehicle enters a neighborhood, the location information may be pushed from the vehicle to the infrastructure service cloud 106 via the OEM cloud 108. The infrastructure service cloud 106 may compute a plurality of P_D offers and then automatically choose one for the driver.
In one embodiment, a store may use location based (LBS) data from OC to tweak its offers, for example, set aside P_D, and make nice P_D offers to VIPs that are passing by. In one embodiment, a store may use location-based data from OC to know that certain drivers are nearby, and then match those drivers' identities with the store's collected customer profitability data. After doing the matching the retailer may know the expected profitability value of these nearby drivers, and make the most generous offers in real time to the most profitable drivers among them as they approach the store. The retailer may choose to let properly constrained automated P_D computations generate the P_D offers most of the time, without manual intervention.
However, not all situations faced by the store manager can be captured in the automated calculations. For example, an inoperable vehicle or a fallen tree may temporarily block access to charging stations in a way that is visible to the store manager, but may not be captured by automated sensors. In such a case the store manager may manually stop P_D offers for the blocked stations from being sent. Or, a data processing error may grossly overestimate the profitability of a given customer, in a way that is obvious to the store manager, requiring a manual reduction of the P_D offer that would otherwise be sent.
Each arrow in
In one embodiment, manual operation may be needed by the driver 102 and a store manager at the retailer 104 to complete a transaction. The UI for the driver 102 and store manager at the retailer 104 will be illustrated and described below.
In one embodiment, multiple P_D offers may be provided to D. Those P_D offers may be relevant to the driver 102's trip and destination, and the driver 102 may select the one best fit his need.
In one embodiment, the driver 102 may set a control that allows the OC 108 to provide the vehicle's location to nearby stores, and continually collects P_D offers from multiple retailers within a convenient distance. That, is each store may generate responsive P_D offers to present to the driver 102 as the driver 102 passes by (e.g., after looking up the driver 102's value as a customer in the retailer cloud 118).
In one embodiment, the infrastructure service cloud 106 as shown in
In one embodiment, the UI 400 may be configured to show a leader board to a driver where the driver may compete (e.g., via social media groups) with his friends on some EV related key performance indicators (KPIs), such as CO2 saved, discount coupon redeemed, and “check-in” places.
In the example shown in
In one or more embodiment, the charging locator screen 402 and user interface (UI) 422 may be configured to refresh manually, or refresh automatically and continuously with new location offers as the driver passes by.
In one embodiment, the UI 500 may be a shown at the retailer 104. When the infrastructure service cloud 106 continually accepts new driver requests for charging station reservations, the retailer 104 may push out P_D offers to nearby drivers automatically for charge spots that are vacant when this is enabled.
In one embodiment, a manager at the retailer's parent organization may restrict the control options at a retailer. For example, sometimes a manager/operator may not be on the premise at the retailer, and at those times an operator at the retailer cloud may take over on behalf of the retailer as described below.
The display panel 604 may comprise a plurality of the retail stores displays 612.1˜612.n (n being an integer larger than one) and a screen 606 to display a currently selected retail store's UI screen (e.g., a full view of the UI 500). Each of the plurality of retail stores displays 612.1˜612.n may show an identifier of the respective store, detailed information about this respective store, a button to select the store's local screen to be viewed in the screen 606. The screen 606 may include a button 608 to allow an operator at the retailer cloud using the UI 600 to take over control the control of the retailer.
In one embodiment, the retailer cloud may be represent the computer network of the retailer organization that is the majority owner of the retailer, or a key stakeholder for some retailer that are franchisees.
In one embodiment, the retailer organization may have contracts with other entities for shared services: with utilities UC for energy prices, with EC for EV charging services, with OC for special deals for their drivers, with governments GC for taxing and regulatory compliance, and so on. All these entities affect retailer's ability to make P_D offers. The UI 600 may allow the retailer organization managers to view—and where possible react to—updates of these partner entities' activities.
The display panel 704 may comprise a plurality of the charge spot displays 708.1˜708.n (n being an integer larger than one). Each of the plurality of charge spot displays 708.1˜708.n may show an identifier of the charge spot, detailed information about this charge spot, an automatically computed offer P_D for the charge spot, an enable/disable button to enable or disable whether pushing new offer to drivers if the charge spot is vacant, a display label showing whether the retailer cloud has granted the control of the charge spot to the EV service provider, a button to show reservation schedule of the charge spot and a button to show the maintenance status and schedule information of the charge spot.
In one embodiment, the EV service provider may be a specialized service provider that helps retailers manage their networked charge spots. The UI 700 may be used by the EVSP cloud 116 to participate in the system 100.
In one embodiment, the infrastructure provided by infrastructure service cloud 106 allow many to many relationships. Thus, the EVSP cloud 116 may work together with other EC to bring a portfolio of services to a particular retailer and/or retailer cloud. For example, the UI 700 shows EC1 and EC 2 as partners. EC1 may have better network coverage in the retailer's location, EC1 and EC2 may have stations there, and EC2 may rely on EC1 for networked communication. In one embodiment, each EC may maintain a master schedule for all charge spots it is responsible for. The EC may provide views of this master schedule to the retailer cloud, retailer, and others as needed. Further, EC may also manage maintenance of the charge spots. In one embodiment, the RC may choose to outsource some or all of the RC UI functions to EC.
Each of plurality of substation displays 808.1˜808.n may show an identifier of an electricity substation, detailed information about this substation (e.g., transformer, feeder status), additional load from EVs at the substation, low carbon fuel standard (LCFS) tracking detailed information, a button to show substation management view, and a button to show the contract view of the substation.
In one embodiment, the UI 800 may be shown at the utility cloud 110. The utility cloud 110 may provide energy prices and the demand charge to influence the retailer's P_D offers based on the economics of local power grid constraints. Further, the utility cloud 110 interface UI 800 may show the effect of the driver's charging at the charge spot, at the retailer, and on the grid. The utility cloud 110 may force energy use reduction through grid controls shown in the substation management view button for each substation 808.1˜808.n. In one embodiment, the utility company may receive low carbon fuel credits for EV charging activity, which might offset or lower demand charges, and improve retailer's P_D offer.
In one embodiment, the UI 900 may be a shown at the OEM cloud 108. The OEM may use the UI 900 to provide all its drivers a convenient charging experience. The OEM Cloud 108 may balance convenience with its drivers' privacy. The OC 108 may relay messages from drivers to the infrastructure service cloud 106, but the level of transmitted metadata about the driver (name, VIN #, contact info, habits and spending profile) may depends on the type of contracts both the driver and the OEM have with the retailer chain and EV service provider. In one embodiment, if the OC 108 has reason to believe the driver's privacy settings/agreements are not being honored, a manager at the OC 108 can block personal information about the driver from being sent to the retailer cloud 118.
In one embodiment, the OC 108 may collect feedback from its drivers about P_D offers, charge spot reservations, and other information (e.g., retailer chains, retailer stores, EV service providers, charge spots that have a history of problems (reservations not honored, broken equipment, overcharged on price)). Future P_D offers transmitted to the driver through the OC 108 may be rated by the OC 108 according to how well the involved parties have honored their past P_D offers.
In one embodiment, a manager at the OC 108 can override, via the UI 900, automatically generated ratings if the manager becomes aware of external, relevant information not built in to the rating system.
The processor 1202 is a programmable processor that executes instructions residing in the memory 1204 to receive and send data via the I/O device(s) 1206. The instructions may provide economic energy management for charging electric vehicles at public charging stations as described herein. The term programmable processor as used herein is any programmable microprocessor or processor or combination of microprocessors or processors that can operate on digital data, which may be special or general purpose processors coupled to receive data and instructions from, and to transmit data and instructions to, a machine-readable medium. According to one embodiment of the present invention processor 1202 is an Intel microprocessor.
Memory 1204 is a machine-readable medium that stores data that is processed by processor 1202. The term machine-readable medium as used herein is any addressable storage device that stores digital data including any computer program product, apparatus and/or device (e.g., a random access memory (RAM), read only memory (ROM), magnetic disc, optical disc, programmable logic device (PLD), tape, hard drives, RAID storage device, flash memory or any combination of these devices). This may include external machine-readable mediums that are connected to processor 1202 via one or more I/O device(s) 1206.
The I/O device(s) 1206 may be one or more input/output interfaces that receive and/or send digital data to and from an external device. Interfaces as used herein are any point of access to an external device where digital data is received or sent, including ports, buffers, queues, subsets thereof, or any other interface to an external device.
It should be understood that there exist implementations of other variations and modifications of the invention and its various aspects, as may be readily apparent to those of ordinary skill in the art, and that the invention is not limited by specific embodiments described herein. Features and embodiments described above may be combined with and without each other. It is therefore contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the basic underlying principals disclosed and claimed herein.
