US20110010043A1 - Vehicle communication systems and methods for electric vehicle power management - Google Patents

Abstract

A system and methods that enables enhanced vehicle communications for electric vehicle power management. In an embodiment, a system provides for communications in a power flow management system utilizing existing hardware including a smart charging module. In another embodiment, a communications module provides communication services to vehicle subsystems including a central processing unit in a vehicle and a CAN-bus transceiver. In yet another embodiment, an interface enables the installation of a charge controller for a control extensibility system including a physical interface to a vehicle's CAN-bus comprising an electrical contact plug. In an embodiment, an interface enables an electric vehicle to communicate with an electric power supply device without specific hardware by modulating the power transfer between the electrical load and an electric power supply. In another embodiment, a system provides for arbitrating a smart chargepoint includes a first smart charging module implemented on equipment located inside a vehicle.

Description

• This non-provisional patent application claims priority to, and incorporates herein by reference, U.S. Provisional Patent Application No. 61/165,344 filed on Mar. 31, 2009. This application also incorporates herein by reference the following: U.S. patent application Ser. No. 12/252,657 filed Oct. 16, 2008; U.S. patent application Ser. No. 12/252,209 filed Oct. 15, 2008; U.S. patent application Ser. No. 12/252,803 filed Oct. 16, 2008; and U.S. patent application Ser. No. 12/252,950 filed Oct. 16, 2008.
• This application includes material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office files or records, but otherwise reserves all copyright rights whatsoever.
FIELD OF THE INVENTION
• The present invention relates in general to the field of electric vehicles, and in particular to novel systems and methods for communication and interaction between electric vehicles and the electrical grid.
BACKGROUND OF THE INVENTION
• Low-level electrical and communication interfaces to enable charging and discharging of electric vehicles with respect to the grid is described in U.S. Pat. No. 5,642,270 to Green et al., entitled, “Battery powered electric vehicle and electrical supply system,” incorporated herein by reference. The Green reference describes a bi-directional charging and communication system for grid-connected electric vehicles.
• Modern automobiles, including electric vehicles, have many electronic control units for various subsystems. While some subsystems are independent, communications among others are essential. To fill this need, controller-area network (CAN or CAN-bus) was devised as a multi-master broadcast serial bus standard for connecting electronic control units. Using a message based protocol designed specifically for automotive applications, CAN-bus is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other within a vehicle without a host computer. The CAN-bus is used in vehicles to connect the engine control unit, transmission, airbags, antilock braking, cruise control, audio systems, windows, doors, mirror adjustment, climate control, and seat control. CAN is one of five protocols used in the (On-Board Diagnostics) OBD-II vehicle diagnostics standard.
• Modern vehicles contain a variety of subsystems that may benefit from communications with various off-vehicle entities. As the smart energy marketplace evolves, multiple application-level protocols may further develop for the control of power flow for electric vehicles and within the home. For example, energy management protocols are being developed for both Zigbee and Homeplug. A vehicle manufacturer may need to support multiple physical communications mediums. For example, ZigBee is used in some installations while PLC is used in others. Considering the very long service life of items such as utility meters and automobiles, the use of multiple incompatible protocols may pose an barrier to deployment. For example, if a homeowner buys a car that utilizes one protocol and receives a utility meter that uses another protocol, it is unlikely that either device will quickly replace other device.
• Significant opportunities for improvement exist with respect to communications with power grids and among electric vehicles. It would be beneficial to enhance modern electric vehicles to have a centrally controlled charging program. What is needed are systems and methods that provide for the complexity of charging intelligence of smart vehicles. There is also a need for novel communication techniques effectively use existing communication hardware, that allow for upgrading existing equipment, and that do not require specific hardware. In addition, novel systems and methods are needed that effectively provide communication services to vehicle subsystems.
SUMMARY OF THE INVENTION
• In an embodiment, a system for communicating in a power flow management system utilizing existing hardware includes a smart charging module that is configured to be implemented on an server subsystem in a vehicle. The server subsystem is connected to a shared vehicle-wide communications medium for communication with another subsystem in the vehicle. The module is further configured to provide a set of services using capabilities provided by the server subsystem and the other subsystem. These services includes sending messages, using the shared vehicle-wide communications medium to one subsystem in the vehicle to implement a smart charging program.
• In another embodiment, a communications module for providing communication services to vehicle subsystems includes a central processing unit in a vehicle and a CAN-bus transceiver operatively connected to the central processing unit connected to an external bus in the vehicle. The external bus is operatively connected to a vehicle subsystem. The module includes a software stack operatively connected to the central processing unit configured to wrap communications packets in a CAN header for communications packets entering a vehicle from an external network. The software stack is further configured to remove CAN headers for communications packets leaving the vehicle. The module includes software, executed by the central processing unit, configured to translate messages comprising the communications packets from a remote network format to CAN format. The module also includes software, executed by the central processing unit, configured to support a bonding or provisioning process required by an external communications protocol.
• In yet another embodiment, an interface enabling the installation of a charge controller for a control extensibility system includes a physical interface to a vehicle's CAN-bus comprising an electrical contact plug. The interface also includes an expansion module providing a standardization of software messages sent over the CAN-bus to control charging. In addition, the interface includes a physical location for the charge controller to reside, where the CAN interface plug is located.
• In an embodiment, an interface enabling an electric vehicle to communicate with an electric power supply device without specific hardware includes transmitting information from an electrical load associated with the electric vehicle to an electric power supply by modulating the power transfer between the electrical load and an electric power supply.
• In another embodiment, a system for arbitrating a smart chargepoint includes a first smart charging module that is configured to be implemented on equipment located inside a vehicle. The first smart charging module is configured to communicate with a server implementing a smart charging program. The smart charging program coordinates the charging activities of a plurality of vehicles distributed over an area. The first smart charging module moderates electrical load in the vehicle by reducing the power consumption of the vehicle. In addition, the first smart charging module communicates with a second smart charging module in external equipment responsible for providing electricity to the vehicle, enabling the first smart charging module and the second smart charging module to implement a charge coordination protocol to determine which of the two modules is responsible for communicating with the server implementing the smart charging program.
BRIEF DESCRIPTION OF THE DRAWINGS
• The foregoing and other objects, features, and advantages of the invention will be apparent from the following more particular description of embodiments as illustrated in the accompanying drawings, in which reference characters refer to the same parts throughout the various views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating principles of the invention.
• FIG. 1 is a diagram of an example of a power aggregation system.
• FIGS. 2A-2B are diagrams of an example of connections between an electric vehicle, the power grid, and the Internet.
• FIG. 3 is a block diagram of an example of connections between an electric resource and a flow control server of the power aggregation system.
• FIG. 4 is a diagram of an example of a layout of the power aggregation system.
• FIG. 5 is a diagram of an example of control areas in the power aggregation system.
• FIG. 6 is a diagram of multiple flow control centers in the power aggregation system and a directory server for determining a flow control center.
• FIG. 7 is a block diagram of an example of flow control server.
• FIG. 8A is a block diagram of an example of remote intelligent power flow module.
• FIG. 8B is a block diagram of an example of transceiver and charging component combination.
• FIG. 8C is an illustration of an example of simple user interface for facilitating user controlled charging.
• FIG. 9 is a diagram of an example of resource communication protocol.
• FIG. 10 is a diagram of an example of communications using existing hardware.
• FIG. 11 is a diagram of an example of communication services to vehicle subsystems.
• FIG. 12 is a diagram of an example of an extensibility system.
• FIG. 13 is a diagram of an example of communications without specific hardware.
• FIG. 14 is a diagram of an example of arbitrating a smart chargepoint.
DETAILED DESCRIPTION OF THE EMBODIMENTS
• Reference will now be made in detail to the embodiments of the present invention, examples of which are illustrated in the accompanying drawings.
• Overview
• Described herein is a power aggregation system for distributed electric resources, and associated methods. In one implementation, a system communicates over the Internet and/or some other public or private networks with numerous individual electric resources connected to a power grid (hereinafter, “grid”). By communicating, the system can dynamically aggregate these electric resources to provide power services to grid operators (e.g. utilities, Independent System Operators (ISO), etc).
• “Power services” as used herein, refers to energy delivery as well as other ancillary services including demand response, regulation, spinning reserves, non-spinning reserves, energy imbalance, reactive power, and similar products.
• “Aggregation” as used herein refers to the ability to control power flows into and out of a set of spatially distributed electric resources with the purpose of providing a power service of larger magnitude.
• “Charge Control Management” as used herein refers to enabling or performing the starting, stopping, or level-setting of a flow of power between a power grid and an electric resource.
• “Power grid operator” as used herein, refers to the entity that is responsible for maintaining the operation and stability of the power grid within or across an electric control area. The power grid operator may constitute some combination of manual/human action/intervention and automated processes controlling generation signals in response to system sensors. A “control area operator” is one example of a power grid operator.
• “Control area” as used herein, refers to a contained portion of the electrical grid with defined input and output ports. The net flow of power into this area must equal (within some error tolerance) the sum of the power consumption within the area and power outflow from the area.
• “Power grid” as used herein means a power distribution system/network that connects producers of power with consumers of power. The network may include generators, transformers, interconnects, switching stations, and safety equipment as part of either/both the transmission system (i.e., bulk power) or the distribution system (i.e. retail power). The power aggregation system is vertically scalable for use within a neighborhood, a city, a sector, a control area, or (for example) one of the eight large-scale Interconnects in the North American Electric Reliability Council (NERC). Moreover, the system is horizontally scalable for use in providing power services to multiple grid areas simultaneously.
• “Grid conditions” as used herein, refers to the need for more or less power flowing in or out of a section of the electric power grid, in response to one of a number of conditions, for example supply changes, demand changes, contingencies and failures, ramping events, etc. These grid conditions typically manifest themselves as power quality events such as under- or over-voltage events or under- or over-frequency events.
• “Power quality events” as used herein typically refers to manifestations of power grid instability including voltage deviations and frequency deviations; additionally, power quality events as used herein also includes other disturbances in the quality of the power delivered by the power grid such as sub-cycle voltage spikes and harmonics.
• “Electric resource” as used herein typically refers to electrical entities that can be commanded to do some or all of these three things: take power (act as load), provide power (act as power generation or source), and store energy. Examples may include battery/charger/inverter systems for electric or hybrid-electric vehicles, repositories of used-but-serviceable electric vehicle batteries, fixed energy storage, fuel cell generators, emergency generators, controllable loads, etc.
• “Electric vehicle” is used broadly herein to refer to pure electric and hybrid electric vehicles, such as plug-in hybrid electric vehicles (PHEVs), especially vehicles that have significant storage battery capacity and that connect to the power grid for recharging the battery. More specifically, electric vehicle means a vehicle that gets some or all of its energy for motion and other purposes from the power grid. Moreover, an electric vehicle has an energy storage system, which may consist of batteries, capacitors, etc., or some combination thereof. An electric vehicle may or may not have the capability to provide power back to the electric grid.
• Electric vehicle “energy storage systems” (batteries, super capacitors, and/or other energy storage devices) are used herein as a representative example of electric resources intermittently or permanently connected to the grid that can have dynamic input and output of power. Such batteries can function as a power source or a power load. A collection of aggregated electric vehicle batteries can become a statistically stable resource across numerous batteries, despite recognizable tidal connection trends (e.g., an increase in the total number of vehicles connected to the grid at night; a downswing in the collective number of connected batteries as the morning commute begins, etc.) Across vast numbers of electric vehicle batteries, connection trends are predictable and such batteries become a stable and reliable resource to call upon, should the grid or a part of the grid (such as a person's home in a blackout) experience a need for increased or decreased power. Data collection and storage also enable the power aggregation system to predict connection behavior on a per-user basis.
An Example of the Presently Disclosed System
• FIG. 1 shows apower aggregation system100. Aflow control center102 is communicatively coupled with a network, such as a public/private mix that includes theInternet104, and includes one ormore servers106 providing a centralized power aggregation service. “Internet”104 will be used herein as representative of many different types of communicative networks and network mixtures (e.g., one or more wide area networks—public or private—and/or one or more local area networks). Via a network, such as theInternet104, theflow control center102 maintainscommunication108 with operators of power grid(s), andcommunication110 with remote resources, i.e., communication with peripheral electric resources112 (“end” or “terminal” nodes/devices of a power network) that are connected to thepower grid114. In one implementation, power line communicators (PLCs), such as those that include or consist of Ethernet-over-power line bridges120 are implemented at connection locations so that the “last mile” (in this case, last feet—e.g., in a residence124) of Internet communication with remote resources is implemented over the same wire that connects eachelectric resource112 to thepower grid114. Thus, each physical location of eachelectric resource112 may be associated with a corresponding Ethernet-over-power line bridge120 (hereinafter, “bridge”) at or near the same location as theelectric resource112. Eachbridge120 is typically connected to an Internet access point of a location owner, as will be described in greater detail below. The communication medium fromflow control center102 to the connection location, such asresidence124, can take many forms, such as cable modem, DSL, satellite, fiber, WiMax, etc. In a variation,electric resources112 may connect with the Internet by a different medium than the same power wire that connects them to thepower grid114. For example, a givenelectric resource112 may have its own wireless capability to connect directly with theInternet104 or an Internet access point and thereby with theflow control center102.
• Electric resources112 of thepower aggregation system100 may include the batteries of electric vehicles connected to thepower grid114 atresidences124,parking lots126 etc.; batteries in arepository128, fuel cell generators, private dams, conventional power plants, and other resources that produce electricity and/or store electricity physically or electrically.
• In one implementation, each participatingelectric resource112 or group of local resources has a corresponding remote intelligent power flow (IPF) module134 (hereinafter, “remote IPF module”134). The centralizedflow control center102 administers thepower aggregation system100 by communicating with theremote IPF modules134 distributed peripherally among theelectric resources112. Theremote IPF modules134 perform several different functions, including, but not limited to, providing theflow control center102 with the statuses of remote resources; controlling the amount, direction, and timing of power being transferred into or out of a remoteelectric resource112; providing metering of power being transferred into or out of a remoteelectric resource112; providing safety measures during power transfer and changes of conditions in thepower grid114; logging activities; and providing self contained control of power transfer and safety measures when communication with theflow control center102 is interrupted. Theremote IPF modules134 will be described in greater detail below.
• In another implementation, instead of having anIPF module134, eachelectric resource112 may have a corresponding transceiver (not shown) to communicate with a local charging component (not shown). The transceiver and charging component, in combination, may communicate withflow control center102 to perform some or all of the above mentioned functions ofIPF module134. A transceiver and charging component are shown inFIG. 2B and are described in greater detail herein.
• FIG. 2A shows another view of electrical and communicative connections to anelectric resource112. In this example, anelectric vehicle200 includes abattery bank202 and aremote IPF module134. Theelectric vehicle200 may connect to a conventional wall receptacle (wall outlet)204 of aresidence124, thewall receptacle204 representing the peripheral edge of thepower grid114 connected via aresidential powerline206.
• In one implementation, thepower cord208 between theelectric vehicle200 and thewall outlet204 can be composed of only conventional wire and insulation for conducting alternating current (AC) power to and from theelectric vehicle200. InFIG. 2A, a location-specificconnection locality module210 performs the function of network access point—in this case, the Internet access point. Abridge120 intervenes between thereceptacle204 and the network access point so that thepower cord208 can also carry network communications between theelectric vehicle200 and thereceptacle204. With such abridge120 andconnection locality module210 in place in a connection location, no other special wiring or physical medium is needed to communicate with theremote IPF module134 of theelectric vehicle200 other than aconventional power cord208 for providing residential line current at any conventional voltage. Upstream of theconnection locality module210, power and communication with theelectric vehicle200 are resolved into thepowerline206 and anInternet cable104.
• Alternatively, thepower cord208 may include safety features not found in conventional power and extension cords. For example, anelectrical plug212 of thepower cord208 may include electrical and/or mechanical safeguard components to prevent theremote IPF module134 from electrifying or exposing the male conductors of thepower cord208 when the conductors are exposed to a human user.
• In some embodiments, a radio frequency (RF) bridge (not shown) may assist theremote IPF module134 in communicating with a foreign system, such as a utility smart meter (not shown) and/or aconnection locality module210. For example, theremote IPF module134 may be equipped to communicate overpower cord208 or to engage in some form of RF communication, such as Zigbee or Bluetooth™, and the foreign system may be able to engage in a different form of RF communication. In such an implementation, the RF bridge may be equipped to communicate with both the foreign system andremote IPF module134 and to translate communications from one to a form the other may understand, and to relay those messages. In various embodiments, the RF bridge may be integrated into theremote IPF module134 or foreign system, or may be external to both. The communicative associations between the RF bridge andremote IPF module134 and between the RF bridge and foreign system may be via wired or wireless communication.
• FIG. 2B shows a further view of electrical and communicative connections to anelectric resource112. In this example, theelectric vehicle200 may include atransceiver212 rather than aremote IPF module134. Thetransceiver212 may be communicatively coupled to acharging component214 through aconnection216, and the charging component itself may be coupled to a conventional wall receptacle (wall outlet)204 of aresidence124 and toelectric vehicle200 through apower cord208. The other components shown inFIG. 2B may have the couplings and functions discussed with regard toFIG. 2A.
• In various embodiments,transceiver212 and chargingcomponent214 may, in combination, perform the same functions as theremote IPF module134.Transceiver212 may interface with computer systems ofelectric vehicle200 and communicate with chargingcomponent214, providingcharging component214 with information aboutelectric vehicle200, such as its vehicle identifier, a location identifier, and a state of charge. In response,transceiver212 may receive requests and commands which transceiver212 may relay tovehicle200's computer systems.
• Charging component214, being coupled to bothelectric vehicle200 andwall outlet204, may effectuate charge control of theelectric vehicle200. If theelectric vehicle200 is not capable of charge control management, chargingcomponent214 may directly manage the charging ofelectric vehicle200 by stopping and starting a flow of power between theelectric vehicle200 and apower grid114 in response to commands received from aflow control server106. If, on the other hand, theelectric vehicle200 is capable of charge control management, chargingcomponent214 may effectuate charge control by sending commands to theelectric vehicle200 through thetransceiver212.
• In some embodiments, thetransceiver212 may be physically coupled to theelectric vehicle200 through a data port, such as an OBD-II connector. In other embodiments, other couplings may be used. Theconnection216 betweentransceiver212 and chargingcomponent214 may be a wireless signal, such as a radio frequency (RF), such as a Zigbee, or Bluetooth™ signal. And chargingcomponent214 may include a receiver socket to couple withpower cord208 and a plug to couple withwall outlet204. In one embodiment, chargingcomponent214 may be coupled toconnection locality module210 in either a wired or wireless fashion. For example, chargingcomponent214 may have a data interface for communicating wirelessly with both thetransceiver212 andlocality module210. In such an embodiment, thebridge120 may not be required.
• Further details about thetransceiver212 and chargingcomponent214 are illustrated byFIG. 8B and described in greater detail herein.
• FIG. 3 shows another implementation of theconnection locality module210 ofFIG. 2, in greater detail. InFIG. 3, anelectric resource112 has an associatedremote IPF module134, including abridge120. Thepower cord208 connects theelectric resource112 to thepower grid114 and also to theconnection locality module210 in order to communicate with theflow control server106.
• Theconnection locality module210 includes another instance of abridge120, connected to anetwork access point302, which may include such components as a router, switch, and/or modem, to establish a hardwired or wireless connection with, in this case, theInternet104. In one implementation, thepower cord208 between the twobridges120 and120′ is replaced by a wireless Internet link, such as a wireless transceiver in theremote IPF module134 and a wireless router in theconnection locality module210.
• In other embodiments, atransceiver212 and chargingcomponent214 may be used instead of aremote IPF module134. In such an embodiment, thecharging component214 may include or be coupled to abridge120, and theconnection locality module210 may also include abridge120′, as shown. In yet other embodiments, not shown, chargingcomponent214 andconnection locality module210 may communicate in a wired or wireless fashion, as mentioned previously, withoutbridges120 and120′. The wired or wireless communication may utilize any sort of connection technology known in the art, such as Ethernet or RF communication, such as Zigbee, or Bluetooth.
• System Layouts
• FIG. 4 shows alayout400 of thepower aggregation system100. Theflow control center102 can be connected to many different entities, e.g., via theInternet104, for communicating and receiving information. Thelayout400 includeselectric resources112, such as plug-inelectric vehicles200, physically connected to the grid within asingle control area402. Theelectric resources112 become an energy resource forgrid operators404 to utilize.
• Thelayout400 also includesend users406 classified intoelectric resource owners408 and electricalconnection location owners410, who may or may not be one and the same. In fact, the stakeholders in apower aggregation system100 include the system operator at theflow control center102, thegrid operator404, theresource owner408, and the owner of thelocation410 at which theelectric resource112 is connected to thepower grid114.
• Electricalconnection location owners410 can include:
• Rental car lots—rental car companies often have a large portion of their fleet parked in the lot. They can purchase fleets ofelectric vehicles200 and, participating in apower aggregation system100, generate revenue from idle fleet vehicles.
• Public parking lots—parking lot owners can participate in thepower aggregation system100 to generate revenue from parkedelectric vehicles200. Vehicle owners can be offered free parking, or additional incentives, in exchange for providing power services.
• Workplace parking—employers can participate in apower aggregation system100 to generate revenue from parked employeeelectric vehicles200. Employees can be offered incentives in exchange for providing power services.
• Residences—a home garage can merely be equipped with aconnection locality module210 to enable the homeowner to participate in thepower aggregation system100 and generate revenue from a parked car. Also, thevehicle battery202 and associated power electronics within the vehicle can provide local power backup power during times of peak load or power outages.
• Residential neighborhoods—neighborhoods can participate in apower aggregation system100 and be equipped with power-delivery devices (deployed, for example, by homeowner cooperative groups) that generate revenue from parkedelectric vehicles200.
• Thegrid operations116 ofFIG. 4 collectively include interactions withenergy markets412, the interactions ofgrid operators404, and the interactions ofautomated grid controllers118 that perform automatic physical control of thepower grid114.
• Theflow control center102 may also be coupled withinformation sources414 for input of weather reports, events, price feeds, etc.Other data sources414 include the system stakeholders, public databases, and historical system data, which may be used to optimize system performance and to satisfy constraints on thepower aggregation system100.
• Thus, apower aggregation system100 may consist of components that:
• communicate with theelectric resources112 to gather data and actuate charging/discharging of theelectric resources112;
• gather real-time energy prices;
• gather real-time resource statistics;
• predict behavior of electric resources112 (connectedness, location, state (such as battery State-Of-Charge) at a given time of interest, such as a time of connect/disconnect);
• predict behavior of thepower grid114/load;
• encrypt communications for privacy and data security;
• actuate charging ofelectric vehicles200 to optimize some figure(s) of merit;
• offer guidelines or guarantees about load availability for various points in the future, etc.
• These components can be running on a single computing resource (computer, etc.), or on a distributed set of resources (either physically co-located or not).
• Power aggregation systems100 in such alayout400 can provide many benefits: for example, lower-cost ancillary services (i.e., power services), fine-grained (both temporal and spatial) control over resource scheduling, guaranteed reliability and service levels, increased service levels via intelligent resource scheduling, and/or firming of intermittent generation sources such as wind and solar power generation.
• Thepower aggregation system100 enables agrid operator404 to control the aggregatedelectric resources112 connected to thepower grid114. Anelectric resource112 can act as a power source, load, or storage, and theresource112 may exhibit combinations of these properties. Control of a set ofelectric resources112 is the ability to actuate power consumption, generation, or energy storage from an aggregate of theseelectric resources112.
• FIG. 5 shows the role ofmultiple control areas402 in thepower aggregation system100. Eachelectric resource112 can be connected to thepower aggregation system100 within a specific electrical control area. A single instance of theflow control center102 can administerelectric resources112 from multiple distinct control areas501 (e.g.,control areas502,504, and506). In one implementation, this functionality is achieved by logically partitioning resources within thepower aggregation system100. For example, when thecontrol areas402 include an arbitrary number of control areas, control area “A”502, control area “B”504, . . . , control area “n”506, thengrid operations116 can include correspondingcontrol area operators508,510, . . . , and512. Further division into a control hierarchy that includes control division groupings above and below the illustratedcontrol areas402 allows thepower aggregation system100 to scale topower grids114 of different magnitudes and/or to varying numbers ofelectric resources112 connected with apower grid114.
• FIG. 6 shows alayout600 of apower aggregation system100 that uses multiple centralized flow control centers102 and102′ and adirectory server602 for determining a flow control center. Eachflow control center102 and102′ has its ownrespective end users406 and406′.Control areas402 to be administered by each specific instance of aflow control center102 can be assigned dynamically. For example, a firstflow control center102 may administercontrol area A502 andcontrol area B504, while a secondflow control center102′ administerscontrol area n506. Likewise, corresponding control area operators (508,510, and512) are served by the sameflow control center102 that serves their respective different control areas.
• In various embodiments, an electric resource may determine which flowcontrol center102/102′ administers itscontrol area502/504/506 by communicating with adirectory server602. The address of thedirectory server602 may be known toelectric resource112 or its associatedIPF module134 or chargingcomponent214. Upon plugging in, theelectric resource112 may communicate with thedirectory server602, providing thedirectory server112 with a resource identifier and/or a location identifier. Based on this information, thedirectory server602 may respond, identifying whichflow control center102/102′ to use.
• In another embodiment,directory server602 may be integrated with aflow control server106 of aflow control center102/102′. In such an embodiment, theelectric resource112 may contact theserver106. In response, theserver106 may either interact with theelectric resource112 itself or forward the connection to anotherflow control center102/102′ responsible for the location identifier provided by theelectric resource112.
• In some embodiments, whether integrated with aflow control server106 or not,directory server602 may include a publicly accessible database for mapping locations to flow control centers102/102′.
• Flow Control Server
• FIG. 7 shows aserver106 of theflow control center102. The illustrated implementation inFIG. 7 is only one example configuration, for descriptive purposes. Many other arrangements of the illustrated components or even different components constituting aserver106 of theflow control center102 are possible within the scope of the subject matter. Such aserver106 and flowcontrol center102 can be executed in hardware, software, or combinations of hardware, software, firmware, etc.
• Theflow control server106 includes aconnection manager702 to communicate withelectric resources112, aprediction engine704 that may include alearning engine706 and astatistics engine708, aconstraint optimizer710, and agrid interaction manager712 to receive grid control signals714. Grid control signals714 are sometimes referred to as generation control signals, such as automated generation control (AGC) signals. Theflow control server106 may further include a database/information warehouse716, aweb server718 to present a user interface toelectric resource owners408,grid operators404, and electricalconnection location owners410; acontract manager720 to negotiate contract terms withenergy markets412, and aninformation acquisition engine414 to track weather, relevant news events, etc., and download information from public andprivate databases722 for predicting behavior of large groups of theelectric resources112, monitoring energy prices, negotiating contracts, etc.
• Remote IPF Module
• FIG. 8A shows theremote IPF module134 ofFIGS. 1 and 2 in greater detail. The illustratedremote IPF module134 is only one example configuration, for descriptive purposes. Many other arrangements of the illustrated components or even different components constituting aremote IPF module134 are possible within the scope of the subject matter. Such aremote IPF module134 has some hardware components and some components that can be executed in hardware, software, or combinations of hardware, software, firmware, etc. In other embodiments, executable instructions configured to perform some or all of the operations ofremote IPF module134 may be added to hardware of anelectric resource112 such as an electric vehicle that, when combined with the executable instructions, provides equivalent functionality toremote IPF module134. References toremote IPF module134 as used herein include such executable instructions.
• The illustrated example of aremote IPF module134 is represented by an implementation suited for anelectric vehicle200. Thus, somevehicle systems800 are included as part of theremote IPF module134 for the sake of description. However, in other implementations, theremote IPF module134 may exclude some or all of thevehicles systems800 from being counted as components of theremote IPF module134.
• The depictedvehicle systems800 include a vehicle computer anddata interface802, an energy storage system, such as abattery bank202, and an inverter/charger804. Besidesvehicle systems800, theremote IPF module134 also includes a communicative power flow controller806. The communicative power flow controller806 in turn includes some components that interface with AC power from thegrid114, such as a powerline communicator, for example an Ethernet-over-powerline bridge120, and a current or current/voltage (power)sensor808, such as a current sensing transformer.
• The communicative power flow controller806 also includes Ethernet and information processing components, such as aprocessor810 or microcontroller and an associated Ethernet media access control (MAC)address812; volatilerandom access memory814,nonvolatile memory816 or data storage, an interface such as an RS-232interface818 or a CAN-bus interface820; an Ethernetphysical layer interface822, which enables wiring and signaling according to Ethernet standards for the physical layer through means of network access at the MAC/Data Link Layer and a common addressing format. The Ethernetphysical layer interface822 provides electrical, mechanical, and procedural interface to the transmission medium—i.e., in one implementation, using the Ethernet-over-powerline bridge120. In a variation, wireless or other communication channels with theInternet104 are used in place of the Ethernet-over-powerline bridge120.
• The communicative power flow controller806 also includes a bidirectionalpower flow meter824 that tracks power transfer to and from eachelectric resource112, in this case thebattery bank202 of anelectric vehicle200.
• The communicative power flow controller806 operates either within, or connected to anelectric vehicle200 or otherelectric resource112 to enable the aggregation ofelectric resources112 introduced above (e.g., via a wired or wireless communication interface). These above-listed components may vary among different implementations of the communicative power flow controller806, but implementations typically include:
• • an intra-vehicle communications mechanism that enables communication with other vehicle components;
  • a mechanism to communicate with theflow control center102;
  • a processing element;
  • a data storage element;
  • a power meter; and
  • optionally, a user interface.
• Implementations of the communicative power flow controller806 can enable functionality including:
• • executing pre-programmed or learned behaviors when theelectric resource112 is offline (not connected toInternet104, or service is unavailable);
  • storing locally-cached behavior profiles for “roaming” connectivity (what to do when charging on a foreign system, i.e., when charging in the same utility territory on a foreign meter or in a separate utility territory, or in disconnected operation, i.e., when there is no network connectivity);
  • allowing the user to override current system behavior; and
  • metering power-flow information and caching meter data during offline operation for later transaction.
• Thus, the communicative power flow controller806 includes acentral processor810,interfaces818 and820 for communication within theelectric vehicle200, a powerline communicator, such as an Ethernet-over-powerline bridge120 for communication external to theelectric vehicle200, and apower flow meter824 for measuring energy flow to and from theelectric vehicle200 via aconnected AC powerline208.
• Power Flow Meter
• Power is the rate of energy consumption per interval of time. Power indicates the quantity of energy transferred during a certain period of time, thus the units of power are quantities of energy per unit of time. Thepower flow meter824 measures power for a givenelectric resource112 across a bidirectional flow—e.g., power fromgrid114 toelectric vehicle200 or fromelectric vehicle200 to thegrid114. In one implementation, theremote IPF module134 can locally cache readings from thepower flow meter824 to ensure accurate transactions with the centralflow control server106, even if the connection to the server is down temporarily, or if the server itself is unavailable.
• Transceiver and Charging Component
• FIG. 8B shows thetransceiver212 and chargingcomponent214 ofFIG. 2B in greater detail. The illustratedtransceiver212 and chargingcomponent214 is only one example configuration, for descriptive purposes. Many other arrangements of the illustrated components or even different components constituting thetransceiver212 and chargingcomponent214 are possible within the scope of the subject matter. Such atransceiver212 and chargingcomponent214 have some hardware components and some components that can be executed in hardware, software, or combinations of hardware, software, firmware, etc.
• The illustrated example of thetransceiver212 and chargingcomponent214 is represented by an implementation suited for anelectric vehicle200. Thus, somevehicle systems800 are illustrated to provide context to thetransceiver212 and chargingcomponent214 components.
• The depictedvehicle systems800 include a vehicle computer anddata interface802, an energy storage system, such as abattery bank202, and an inverter/charger804. In some embodiments,vehicle systems800 may include a data port, such as an OBD-II port, that is capable of physically coupling with thetransceiver212. Thetransceiver212 may then communicate with the vehicle computer anddata interface802 through the data port, receiving information fromelectric resource112 comprised byvehicle systems800 and, in some embodiments, providing commands to the vehicle computer anddata interface802. In one implementation, the vehicle computer anddata interface802 may be capable of charge control management. In such an embodiment, the vehicle computer anddata interface802 may perform some or all of thecharging component214 operations discussed below. In other embodiments, executable instructions configured to perform some or all of the operations of the vehicle computer anddata interface802 may be added to hardware of anelectric resource112 such as an electric vehicle that, when combined with the executable instructions, provides equivalent functionality to the vehicle computer anddata interface802. References to the vehicle computer anddata interface802 as used herein include such executable instructions.
• In various embodiments, thetransceiver212 may have a physical form that is capable of coupling to a data port ofvehicle systems800. Such atransceiver212 may also include a plurality of interfaces, such as an RS-232interface818 and/or a CAN-bus interface820. In various embodiments, the RS-232interface818 or CAN-bus interface820 may enable thetransceiver212 to communicate with the vehicle computer anddata interface802 through the data port. Also, the transceiver may be or comprise an additional interface (not shown) capable of engaging in wireless communication with adata interface820 of thecharging component214. The wireless communication may be of any form known in the art, such as radio frequency (RF) communication (e.g., Zigbee, and/or Bluetooth™ communication). In other embodiments, the transceiver may comprise a separate conductor or may be configured to utilize apowerline208 to communicate with chargingcomponent214. In yet other embodiments, not shown,transceiver212 may simply be a radio frequency identification (RFID) tag capable of storing minimal information about theelectric resource112, such as a resource identifier, and of being read by a corresponding RFID reader of chargingcomponent214. In such other embodiments, the RFID tag may not couple with a data port or communicate with the vehicle computer anddata interface802.
• As shown, thecharging component214 may be an intelligent plug device that is physically connected to a charging medium, such as a powerline208 (the charging medium coupling thecharging component214 to the electric resource112) and an outlet of a power grid (such as thewall outlet204 shown inFIG. 2B). In otherembodiments charging component214 may be a charging station or some other external control. In some embodiments, thecharging component214 may be portable.
• In various embodiments, thecharging component214 may include components that interface with AC power from thegrid114, such as a powerline communicator, for example an Ethernet-over-powerline bridge120, and a current or current/voltage (power)sensor808, such as a current sensing transformer.
• In other embodiments, thecharging component214 may include a further Ethernet plug or wireless interface in place ofbridge120. In such an embodiment, data-over-powerline communication is not necessary, eliminating the need for abridge120. The Ethernet plug or wireless interface may communicate with a local access point, and through that access point to flowcontrol server106.
• Thecharging component214 may also include Ethernet and information processing components, such as aprocessor810 or microcontroller and an associated Ethernet media access control (MAC)address812; volatilerandom access memory814,nonvolatile memory816 or data storage, a data interface826 for communicating with thetransceiver212, and an Ethernetphysical layer interface822, which enables wiring and signaling according to Ethernet standards for the physical layer through means of network access at the MAC/Data Link Layer and a common addressing format. The Ethernetphysical layer interface822 provides electrical, mechanical, and procedural interface to the transmission medium—i.e., in one implementation, using the Ethernet-over-powerline bridge120. In a variation, wireless or other communication channels with theInternet104 are used in place of the Ethernet-over-powerline bridge120.
• Thecharging component214 may also include a bidirectionalpower flow meter824 that tracks power transfer to and from eachelectric resource112, in this case thebattery bank202 of anelectric vehicle200.
• Further, in some embodiments, thecharging component214 may comprise an RFID reader to read the electric resource information fromtransceiver212 whentransceiver212 is an RFID tag.
• Also, in various embodiments, thecharging component214 may include a credit card reader to enable a user to identify theelectric resource112 by providing credit card information. In such an embodiment, atransceiver212 may not be necessary.
• Additionally, in one embodiment, thecharging component214 may include a user interface, such as one of the user interfaces described in greater detail below.
• Implementations of thecharging component214 can enable functionality including:
• • executing pre-programmed or learned behaviors when theelectric resource112 is offline (not connected toInternet104, or service is unavailable);
  • storing locally-cached behavior profiles for “roaming” connectivity (what to do when charging on a foreign system or in disconnected operation, i.e., when there is no network connectivity);
  • allowing the user to override current system behavior; and
  • metering power-flow information and caching meter data during offline operation for later transaction.
• User Interfaces (UI)
• Charging Station UI. An electrical charging station, whether free or for pay, can be installed with a user interface that presents useful information to the user. Specifically, by collecting information about thegrid114, the electric resource state, and the preferences of the user, the station can present information such as the current electricity price, the estimated recharge cost, the estimated time until recharge, the estimated payment for uploading power to the grid114 (either total or per hour), etc. Theinformation acquisition engine414 communicates with theelectric resource112 and with public and/orprivate data networks722 to acquire the data used in calculating this information.
• The types of information gathered from theelectric resource112 can include an electric resource identifier (resource ID) and state information like the state of charge of theelectric resource112. The resource ID can be used to obtain knowledge of the electric resource type and capabilities, preferences, etc. through lookup with theflow control server106.
• In various embodiments, the charging station system including the UI may also gather grid-based information, such as current and future energy costs at the charging station.
• User Charge Control UI Mechanisms. In various embodiments, by default,electric resources112 may receive charge control management viapower aggregation system100. In some embodiments, an override control may be provided to override charge control management and charge as soon as possible. The override control may be provided, in various embodiments, as a user interface mechanism of theremote IPF module134, thecharging component214, of the electric resource (for example, if electric resource is avehicle200, the user interface control may be integrated with dash controls of the vehicle200) or even via a web page offered byflow control server106. The control can be presented, for example, as a button, a touch screen option, a web page, or some other UI mechanism. In one embodiment, the UI may be the UI illustrated byFIG. 8C and discussed in greater detail below. In some embodiments, the override is a one-time override, only applying to a single plug-in session. Upon disconnecting and reconnecting, the user may again need to interact with the UI mechanism to override the charge control management.
• In some embodiments, the user may pay more to charge with the override on than under charge control management, thus providing an incentive for the user to accept charge control management. Such a cost differential may be displayed or rendered to the user in conjunction with or on the UI mechanism. This differential can take into account time-varying pricing, such as Time of Use (TOU), Critical Peak Pricing (CPP), and Real-Time Pricing (RTP) schemes, as discussed above, as well as any other incentives, discounts, or payments that may be forgone by not accepting charge control management.
• UI Mechanism for Management Preferences. In various embodiments, a user interface mechanism of theremote IPF module134, thecharging component214, of the electric resource (for example, if electric resource is avehicle200, the user interface control may be integrated with dash controls of the vehicle200) or even via a web page offered byflow control server106 may enable a user to enter and/or edit management preferences to affect charge control management of the user'selectric resource112. In some embodiments, the UI mechanism may allow the user to enter/edit general preferences, such as whether charge control management is enabled, whether vehicle-to-grid power flow is enabled or whether theelectric resource112 should only be charged with clean/green power. Also, in various embodiments, the UI mechanism may enable a user to prioritize relative desires for minimizing costs, maximizing payments (i.e., fewer charge periods for higher amounts), achieving a full state-of-charge for theelectric resource112, charging as rapidly as possible, and/or charging in as environmentally-friendly a way as possible. Additionally, the UI mechanism may enable a user to provide a default schedule for when the electric resource will be used (for example, ifresource112 is avehicle200, the schedule is for when thevehicle200 should be ready to drive). Further, the UI mechanism may enable the user to add or select special rules, such as a rule not to charge if a price threshold is exceeded or a rule to only use charge control management if it will earn the user at least a specified threshold of output. Charge control management may then be effectuated based on any part or all of these user entered preferences.
• Simple User Interface.FIG. 8C illustrates a simple user interface (UI) which enables a user to control charging based on selecting among a limited number of high level preferences. For example,UI2300 includes the categories “green”, “fast”, and “cheap” (with what is considered “green”, “fast”, and “cheap” varying from embodiment to embodiment). The categories shown inUI2300 are selected only for the sake of illustration and may instead includes these and/or any other categories applicable toelectric resource112 charging known in the art. As shown, theUI2300 may be very basic, using well known form controls such as radio buttons. In other embodiments, other graphic controls known in the art may be used. The general categories may be mapped to specific charging behaviors, such as those discussed above, by aflow control server106.
• Electric Resource Communication Protocol
• FIG. 9 illustrates a resource communication protocol. As shown, aremote IPF module134 or chargingcomponent214 may be in communication with aflow control server106 over theInternet104 or another networking fabric or combination of networking fabrics. In various embodiments, a protocol specifying an order of messages and/or a format for messages may be used to govern the communications between theremote IPF module134 or chargingcomponent214 andflow control server106.
• In some embodiments, the protocol may include two channels, one for messages initiated by theremote IPF module134 or chargingcomponent214 and for replies to those messages from theflow control server106, and another channel for messages initiated by theflow control server106 and for replies to those messages from theremote IPF module134 or chargingcomponent214. The channels may be asynchronous with respect to each other (that is, initiation of messages on one channel may be entirely independent of initiation of messages on the other channel). However, each channel may itself be synchronous (that is, once a message is sent on a channel, another message may not be sent until a reply to the first message is received).
• As shown, theremote IPF module134 or chargingcomponent214 may initiatecommunication902 with theflow control server106. In some embodiments,communication902 may be initiated when, for example, anelectric resource112 first plugs in/connects to thepower grid114. In other embodiments,communication902 may be initiated at another time or times. Theinitial message902 governed by the protocol may require, for example, one or more of an electric resource identifier, such as a MAC address, a protocol version used, and/or a resource identifier type.
• Upon receipt of the initial message by theflow control server106, a connection may be established between theremote IPF module134 or chargingcomponent214 andflow control server106. Upon establishing a connection, theremote IPF module134 or chargingcomponent214 may register withflow control server106 through asubsequent communication903.Communication903 may include a location identifier scheme, a latitude, a longitude, a max power value that theremote IPF module134 or chargingcomponent214 can draw, a max power value that theremote IPF module134 or chargingcomponent214 can provide, a current power value, and/or a current state of charge.
• After theinitial message902, the protocol may require or allow messages904 from theflow control server106 to theremote IPF module134 or chargingcomponent214 or messages906 fromremote IPF module134 or chargingcomponent214 to theflow control server106. The messages904 may include, for example, one or more of commands, messages, and/or updates. Such messages904 may be provided at any time after theinitial message902. In one embodiment, messages904 may include a command setting, a power level and/or a ping to determine whether theremote IPF module134 or chargingcomponent214 is still connected.
• The messages906 may include, for example, status updates to the information provided in theregistration message903. Such messages906 may be provided at any time after theinitial message902. In one embodiment, the messages906 may be provided on a pre-determined time interval basis. In various embodiments, messages906 may even be sent when theremote IPF module134 or chargingcomponent214 is connected, but not registered. Such messages906 may include data that is stored byflow control server106 for later processing. Also, in some embodiments, messages904 may be provided in response to amessage902 or906.
• Communications Utilizing Existing Hardware
• Certain automotive subsystems, such as battery charge controllers, require real-time communications links to off-vehicle networks. The communications hardware to provide this off vehicle link includes Cellular, Wi-Fi, ZigBee, and Homeplug. Such equipment is expensive and can be difficult to configure.
• Subsystems in a vehicle are connected together over a shared bus, known as the CAN-bus. This bus provides high-speed low-latency communication to attached devices, but does not provide the mechanisms necessary for communicating with off-vehicle entities. Rather than implement communications hardware directly, a client subsystem issues commands over the CAN-bus to request off-vehicle communications services from another “server” subsystem.
• Existing subsystem in the vehicle that already possess communications hardware can perform this server role without requiring any additional hardware. Because the CAN-bus does not support routing or packet forwarding, it is necessary to define an encapsulation mechanism to permit the off-board communications protocol to be embedded within CAN messages.
• In some circumstances, vehicle designs may include existing communications hardware for purposes other than charge management. These other uses may include emergency response and remote vehicle diagnostics. Rather than adding additional communications hardware, an electric vehicle can make use of these existing communications modules. Such module re-use is accomplished by enhancing the software on the existing communications modules in order to expand functionality.
• Similar to modules installed via an extensibility mechanism, preexisting modules upgraded through software can engage in smart charging through two distinct mechanisms.
• In one embodiment, the software upgraded communications module provides a communications path to external networks which allows vehicle modules to participate in a smart charging program in a manner similar to that of a vehicle that is initially equipped with a communications module.
• In another embodiment, the software upgraded communications module includes all smart charging logic. In this embodiment, the software upgraded communications module is solely responsible for participating in the smart charging program, and then implements that program by sending primitive messages to other subsystems in the vehicle.
• FIG. 10 illustrates an embodiment of communications using existing hardware with a smart charging module configured to be implemented for avehicle subsystem1010. The vehicle subsystem is connected to a shared vehicle-wide communications medium1020. The smart charging module is configured to provide messages to avehicle subsystem1030.
• Communication Services to Vehicle Subsystems
• Modern electric vehicles benefit in a variety of ways from a centrally controlled smart charging program. However, the modules in the vehicle that are capable of executing a charge management program, e.g. the Battery Management Systems Charge Controller, do not generally have the ability to communicate with external networks which are outside the vehicle. To work effectively, a smart charging program requires the central control of an outside entity via an external network, such as a server. This server is responsible for coordinating the charging activities of a large number of vehicles distributed over a wide area, such as a city.
• Establishing a communications channel between appropriate vehicle subsystems and external networks facilitates smart charging and reduce the cost of ownership of the vehicle. While most vehicle subsystems lack off-vehicle communication, virtually all subsystems are connected to a shared vehicle-wide communications medium or bus. In many vehicles, this bus uses the CAN-bus standard, as defined by the International Standards Organization (ISO) standard #11898. Over time, some new vehicle designs will transition to other vehicle-wide communications mediums, such as Flexray or other similar technologies. However, the basic principle of a shared communications medium to allow vehicle subsystems to communicate will remain intact, and the concepts in the present disclosure will be similarly applicable to these future communications mediums.
• Rather than adding off-vehicle communications capabilities to existing vehicle subsystems, a separate module provides communication services to all subsystems on a vehicle, making these services available via the vehicle's CAN-bus. Confining the modification to a single module reduces the cost of switching communications standards such that support can be accomplished by installing different communications modules in different cars.
• Such a communications module includes the hardware necessary to communicate off-vehicle, and also connects to the vehicle's CAN-bus. Software within the communications module translates or encapsulates packets to allow information to flow between the various vehicle subsystems and the entities outside the vehicle.
• In one embodiment, the communications module can forward messages from the external network, unmodified, to other vehicle subsystems. As an example, if the external network uses the TCP/IP protocol, the communications module forwards TCP packets over the CAN-bus to other vehicle subsystems. Because vehicle communication busses such as CAN-bus do not natively support wide-area protocols such as TCP/IP, an encapsulation protocol is required.
• Encapsulation works by defining a specific CAN message for TCP transport. Such a CAN message includes a packet header and a packet body. The packet header can specify the packet type to differentiate it from other types of CAN traffic. The packet header can also specify the packet length, and may contain other CAN packet attributes, such as addressing. The packet body includes the bytes of the original external network packet, such as a TCP packet.
• Such a packet can be transmitted over the CAN-bus from the communications module to the vehicle subsystem wishing to communicate. When the vehicle subsystem wishing to communicate receives such a packet, the subsystem uses the type and size information present in the CAN packet to extract the original TCP packet. When communicating in the reverse direction, i.e. from the vehicle subsystem to the external network, the process is reversed. The vehicle subsystem places a TCP packet within a properly formatted CAN packet and transmits it over the CAN-bus to the communications module. The communications module extracts the TCP packet and transmits it over the external network.
• In an embodiment, the communications module entirely decodes messages received from the external network, and re-encodes the messages as CAN-bus messages. As such, the communications module extracts the actual intended purpose of the remote message, and transmits a new message across the vehicle's CAN-bus.
• As an example, the communications module may receive a packet across the external bus with the command specifying the current price of electricity. The communications module transmits a CAN-bus message to the appropriate subsystems indicating the current price of electricity. Since the communications module is fully and completely decoding and encoding each message in each direction, it is not necessary for the external network messages and the vehicle-internal CAN-bus messages to be similar in any way.
• A communications module can include the following components: a central processing unit (CPU) with sufficient power to run the appropriate software; a CAN transceiver, or transceiver for an alternate in-vehicle communications network; an external communications transceiver for one or more external communications networks; a software stack capable of wrapping high level communications packets in a CAN header, for packets entering the vehicle, and removing a can header, for packets leaving the vehicle; software capable translating messages from a remote network format to the local CAN format; and, software capable of the bonding/provisioning process required by the specific external communications protocol.
• FIG. 11 illustrates an embodiment of communication services to vehicle subsystems. A CAN transceiver is connected to a CPU in a vehicle and to an external bus, which is connected to avehicle subsystem1110. A software stack is connected to the CPU for augmenting CAN headers forpackets1120. Software is configured to translate messages from a remote network format to aCAN format1130. Software is also configured for a provisioning process ofexternal communications protocol1140.
• Vehicle Power Systems Control Extensibility System
• Electric and plug-in hybrid electric vehicles benefit greatly from on-board charge-management controllers. Such controllers can harmonize a vehicle's electricity consumption with the needs of the power grid. However, price-sensitivity time-to-market concerns, or a lack of standardization, can preclude the factory installation of these charge management controllers.
• It is desirable that vehicles without factory-equipped charge controllers have the capacity to be upgraded with an after-market controller. A vehicle can be upgradable by providing a physical and software interface to allow the installation of a charge controller. This interface may include: a physical interface to the vehicle's CAN-bus, via an electrical contact plug; a standardization of software messages that are to be sent over the CAN-bus to control charging; and, a physical location for the charge controller to reside, where the CAN interface plug must be located.
• Vehicles may be sold without the ability to communicate with off-vehicle networks or systems, and therefore without the ability to coordinate their charging behavior with a central authority or server. A vehicle manufacturer that recognizes the benefit of charge management may opt to not include charge management, due to reasons such as price sensitivity, time-to-market concerns, or a lack of standardization. In these situations, it is beneficial for vehicles to be easily upgradable through the installation of a communications module or charge management module. Such upgradability can be managed by clearly defining the physical, electrical and software interfaces between a communications module and the vehicle.
• The mechanical interface may include a physical location for the module to be installed in the vehicle. This physical location provides access to the electrical/signaling interface, provides a particular level of environmental protection, and accommodate a particular size and shape of add-on modules.
• The electrical/signaling interface may include a standardized connector to the vehicle's standardized internal communications bus, such as CAN-bus, and a standardized connector to an electrical supply. In some vehicles, the vehicle's communications bus can be a non-electrical standard, such as a Fiber-optic based system. While such a system may not be compatible with electrically signaled CAN based systems, the general principle of the extension interface can still apply.
• The software interface defines the protocol messages by which the expansion module interfaces with existing modules in the vehicle.
• In one embodiment, the other relevant modules in the vehicle are designed to communicate with the expansion module as defined elsewhere in the application. The expansion module provides a communications path to external networks which allows vehicle modules to participate in a smart charging program in a manner similar to that of a vehicle that is initially equipped with a communications module.
• In an embodiment, existing modules in the vehicle have no explicit support for smart charging, and all smart charging logic is contained in the expansion module. As such, the expansion module is solely responsible for participating in the smart charging program. The expansion module implements the program by sending primitive messages to other subsystems in the vehicle.
• FIG. 12 illustrates an embodiment of an extensibility system including a contact plug for a CAN-bus in avehicle1210. An expansion module provides standardization of transmitted messages to control charging1220. In addition, a charge controller for control extensibility is located at thecontact plug1230.
• Communications without Specific Hardware
• In many applications, it is beneficial for an electrical load, such as an electric vehicle, to communicate with an electric power supply, such as a charging station or an electric vehicle service equipment. Such communication can convey information such as device identification, state of battery charge, or power consumption preferences. This communication can also be utilized to implement the arbitration protocol described herein. The communication is desirable even in situations where the two devices in question do not possess hardware designed to facilitate communication.
• For devices to communicate without specific communications hardware, information can be conveyed by modulating the power transfer between the electrical load (e.g. an electric vehicle) and the electric power supply (electric vehicle service equipment). To facilitate the transmission of information from the electrical load to the electric power supply, an electric load device can intermittently draw power and/or refrain from drawing power. Communications time may be subdivided into seconds. For example, each second wherein the load device drew power is interrupted as the binary 1 digit, and each second wherein the load device did not draw power is interrupted as the binary 0 digit. In a similar manner, the power supply device can communicate with the load device to facilitate the transmission of information from the electric power supply to the electric load device. The electric power supply can provide power for an interval, represented as the binary 1 digit, or refraining from providing power, represent as the binary 0 digit.
• A variety of standard communication protocol techniques may be used to address issues such as data reliability and clock drift. Depending on the accuracy of both sensing equipment in the receiving device and switching equipment in the transmitting device, the time interval can be varied. For example, the time interval may be varied to an interval much lower than one second. Lower intervals would allow a greater amount of information to be transmitted in the same amount of time.
• Because the non-powered intervals deprive the load device of electrical power, the load device requires a supplemental power source to remain functional during such intervals. This supplemental power source can be a storage battery, a capacitor, or an alternative primary electrical source. This system does not interfere with the primary function of the power circuit, which is power transfer, because all communication may be completed early in the power connection and power can flow uninterrupted for the remainder of the connection time.
• To address the limitation of communications mediums that prohibit both the electric vehicle and the electric power source from transmitting information simultaneously, a variety of sharing protocols can be used. In one embodiment, the electric power supply and the electric vehicle take turns transmitting information, reversing roles after a fixed number of bits. In an embodiment, the transmitted messages are structured as packets with a transmitted size. After the transmission of a packet, the direction of transmission is reversed.
• FIG. 13 illustrates an embodiment of communications without specific hardware including modulating power transfer between an electrical load associated with an electric vehicle and apower supply1310, transmitting information from the electrical load to thepower supply1320, and enabling the electrical vehicle to communicate with thepower supply1330.
• Arbitrating Smart Chargepoint with Smart Vehicle
• Modern Electric vehicles could benefit in a variety of ways from a centrally controlled smart charging program where a central server coordinates the charging activities of a large number of vehicles distributed over a wide area, such as a city. This coordination is accomplished by the server communicating directly with a smart charging module located at each vehicle. The smart charging module can be located inside the vehicle, either as an original component of the vehicle or an aftermarket accessory. Equipment located inside the vehicle can moderate electrical load by directly reducing the power consumption of the vehicle.
• In one embodiment, the smart charging module will be located in external equipment responsible for providing electricity to the vehicle. Such external equipment may be electric vehicle service equipment (EVSE). EVSE or charging stations can reduce power consumption by curtailing the power available to the vehicle.
• In the case where both the electric vehicle and the EVSE contain smart charging modules, a potential problem arises. Because charge management systems can be integrated into both vehicles and vehicle charging infrastructure, each of these systems may initially assume that they are the only charging intelligence present in a charging session. When a smart car attaches to a smart chargepoint, certain problems arise. Because the two devices are not communicating with each other, the devices each act as if they have full control of the charge session. If the central smart charging server is not informed that the two devices represent a single vehicle, it will manage the two devices independently. The two devices may attempt to charge at different times, resulting in no power flow. Furthermore, both devices may receive stop charging messages from a utility at the same time, resulting in double-counting of load reduction.
• To address these concerns, electric vehicles and charging equipment, or EVSE, can both implement a charge coordination protocol. This protocol allows the EVSE and the vehicle to determine which of the two entities is responsible for communicating with the charge management server and implementing a smart charging program. The other entity would enter a passive mode, following the direction of the primary entity.
• With such a protocol, an electric vehicle can transmit a charge coordination capabilities message to the chargepoint when the vehicle is connected. The capabilities message specifies charge coordination modes that the vehicle supports. The charge equipment can send a charge coordination mode message specifying the coordination mode. This mode may be selected from the list provided by the vehicle. When the two messages have been transmitted, the charge equipment and vehicle commence coordinated charging.
• Two coordinated charging modes are initially defined as charge-equipment switching charging and vehicle-switching charging. In the charge-equipment switched charging mode, the electric vehicle stops smart charging and behaves as a dumb load. The EVSE, or the charge equipment, sends electricity as it determines while the vehicle does not communicate with any external entity for purposes of charge management. As such, the EVSE controls the rate of electricity flow to the vehicle and is responsible for all communication with smart charging server.
• In the vehicle-switched charging mode, the EVSE or charging equipment does not engage in smart charging and provide electricity on-demand to the Vehicle at all times. The electric vehicle controls its rate of electricity consumption and is responsible for all communication with the smart charging server. The electric vehicle performs the physical regulation of charge level. However, the regulation of charging is based on commands issued by the charging equipment.
• If the vehicle possessed an alternative communications channel, such as cellular, the vehicle stops accepting charge commands from that channel. Charging equipment may monitor the vehicle to determine whether the vehicle had complied with charge directives. The vehicle can fall back to direct control if it is determined that the vehicle was non-compliant.
• Additional charging modes may be defined over time. Communication between the electric vehicle and the EVSE could be accomplished via Power Line Communications (PLC) over the charging cable, or via other means, including wireless communications.
• FIG. 14 illustrates an embodiment of arbitrating a smart chargepoint with a smart charging module configured to be implemented onvehicle equipment1410. The module is configured to communicate with thesmart charging program1420, and to moderate an electric load by reducing power consumption of thevehicle1430. In addition, the module is configured to communicate with a second smart charging module inexternal charging equipment1440, and the modules implement acharge coordination protocol1450.
CONCLUSION
• Although systems and methods have been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as examples of implementations of the claimed methods, devices, systems, etc. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention.

Claims (37)

1. A system for communicating in a power flow management system utilizing existing hardware, comprising:

a smart charging module, the module being configured to be implemented on an server subsystem in a vehicle, the server subsystem being connected to a shared vehicle-wide communications medium for communication with at least one other subsystem in the vehicle, the module being further configured to provide a set of services using capabilities provided by the server subsystem and the at least one other subsystem, the services comprising:

sending messages, using the shared vehicle-wide communications medium to the at least one subsystem in the vehicle to implement a smart charging program.

2. The system ofclaim 1 wherein the services further comprise:

embedding off-board communications protocols in shared vehicle-wide communications medium messages;

communicating with an external system coordinating the smart charging program using capabilities provided by the server subsystem or the at least one other subsystem.

3. The system ofclaim 2 wherein the shared vehicle-wide communications medium is a CAN bus and the vehicle-wide communications messages are CAN bus messages.

4. The system ofclaim 2 wherein the communicating with the external system is performed by an existing communications module of the server subsystem or the at least one other subsystem, the existing communications module being upgraded to include at least a portion of the smart charging module.

5. The system ofclaim 4 wherein the existing communications module is related to an emergency response system.

6. The system ofclaim 4 wherein the existing communications module is related to a remote vehicle diagnostic system.

7. A communications module for providing communication services to vehicle subsystems, comprising:

a central processing unit in a vehicle;

a CAN transceiver operatively connected to the central processing unit connected to an external bus in the vehicle, the external bus being operatively connected to at least one vehicle subsystem;

a software stack operatively connected to the central processing unit configured to wrap communications packets in a CAN header for communications packets entering a vehicle from an external network, the software stack being further configured to remove CAN headers for communications packets leaving the vehicle;

software, executed by the central processing unit, configured to translate messages comprising the communications packets from a remote network format to CAN format; and,

software, executed by the central processing unit, configured to support a bonding or provisioning process required by at least one external communications protocol.

8. The communications module ofclaim 7 wherein the module is further configured to establishing a communications channel between the at least one vehicle subsystem and at least one external system coordinating a smart charging program.

9. The communications module ofclaim 7 wherein the messages comprising the communications packets from a remote network are forwarded unmodified to other vehicle subsystems using an encapsulation protocol.

10. The communications module ofclaim 7 wherein the communications module is configured to receive packets across the external bus with at least one command specifying the current price of electricity, the communications module being further configured to transmits at least one CAN-bus message to at least one subsystem in the vehicle indicating the current price of electricity.

11. The communications module ofclaim 7 wherein the external network uses the TCP/IP protocol and the communications module forwards TCP packets over the CAN-bus to at least one subsystem.

12. An interface enabling the installation of a charge controller for a control extensibility system, comprising:

a physical interface to a vehicle's CAN-bus, comprising an electrical contact plug;

an expansion module providing a standardization of software messages sent over the CAN-bus to control charging; and

a physical location for the charge controller to reside, where the CAN interface plug is located.

13. The interface ofclaim 12 wherein the physical interface provides environmental protection to the add-on modules.

14. The interface ofclaim 12 wherein the interface comprises a standardized connector to the vehicle's CAN-bus, and a standardized connector to an electrical supply.

15. The interface ofclaim 12 wherein the expansion module provides a communications path to external networks that enables the expansion module to participate in a smart charging program;

16. The interface ofclaim 12 wherein existing modules in the vehicle have no explicit support for smart charging, and all smart charging logic is contained in the expansion module.

17. An interface enabling an electric vehicle to communicate with an electric power supply device without specific hardware, comprising:

transmitting information from an electrical load associated with the electric vehicle to an electric power supply by modulating the power transfer between the electrical load and an electric power supply.

18. The interface ofclaim 17 wherein an electric vehicle is further enabled to communicate with the electric power supply device comprising:

receiving information by an electrical load associated with the electric vehicle from an electric power supply by detecting changes in the modulation of the power transfer between the electrical load and the electric power supply.

19. The interface ofclaim 18 wherein information is transmitted by the electric power supply by providing power for an interval, represented as the binary 1 digit, or by refraining from providing power for an interval, represented as the binary 0 digit.

20. The interface ofclaim 18 wherein communications time of the electric load is subdivided into seconds, wherein each second wherein the load drew power is interrupted as the binary 1 digit, and each second wherein the load device did not draw power is interrupted as the binary 0 digit.

21. The interface ofclaim 20 wherein communications time of the electric supply is subdivided into seconds, wherein each second wherein the supply provided power is interrupted as the binary 1 digit, and each second wherein the supply did not provide power is the binary 0 digit.

22. The interface ofclaim 20 wherein the time interval is varied to an interval lower than one second.

23. The interface ofclaim 17 wherein the electrical load is supplied with a supplemental power source to remain functional during intervals when the electric power supply is not supplying power to the electrical load.

24. The interface ofclaim 17 wherein the supplemental power source is selected from the group: storage battery, capacitor, and an alternative primary electrical source.

25. The interface ofclaim 17 wherein the electric power supply and the electric vehicle take turns transmitting information.

26. The interface ofclaim 23 wherein, the transmitted messages are structured as packets with a transmitted size and after the transmission of a packet, the direction of transmission is reversed.

27. A system for arbitrating a smart chargepoint, comprising:

a first smart charging module, the module being configured to be implemented on equipment located inside a vehicle, the first smart charging module being configured to:

communicate with a server implementing a smart charging program, the smart charging program coordinating the charging activities of a plurality of vehicles distributed over an area;

moderate electrical load in the vehicle by reducing the power consumption of the vehicle;

communicate with at least a second smart charging module in external equipment responsible for providing electricity to the vehicle, enabling the first smart charging module and the second smart charging module to implement a charge coordination protocol to determine which of the two modules is responsible for communicating with the server implementing the smart charging program.

28. The system ofclaim 27 wherein the charge coordination protocol causes one of the smart charging modules to assume a primary role and the other to enter a passive mode, following the direction of the module in the primary entity.

29. The system ofclaim 27 wherein the charge coordination protocol causes one of the smart charging modules to assume a primary role and the other to enter a passive mode, following the direction of the module in the primary entity.

30. The system ofclaim 27 wherein the first smart charging module is further configured to transmit a charge coordination capabilities message to a chargepoint when the vehicle is connected to the chargepoint, the message specifying charge coordination modes that the vehicle supports.

31. The system ofclaim 30 wherein coordination modes that the vehicle supports are selected from a list provided by the vehicle.

32. The system ofclaim 30 wherein two of the coordination modes that the vehicle supports are selected from a list provided by the vehicle.

33. The system ofclaim 30 wherein one of the coordination modes is charge-equipment switching charging mode, wherein in charge-equipment switched charging mode, the electric vehicle stops smart charging and behaves as a dumb load, and the external equipment responsible for providing electricity to the vehicle controls the rate of electricity flow to the vehicle and communicates with the server implementing the smart charging program

34. The system ofclaim 30 wherein one of the coordination modes is vehicle-switched charging mode, wherein the external equipment responsible for providing electricity to the vehicle does not engage in smart charging and provides electricity on-demand to the vehicle at all times, and wherein the vehicle performs the physical regulation of charge level

35. The system ofclaim 27 wherein the external equipment responsible for providing electricity to the vehicle is configured to determine if the vehicle complies with charge directives, wherein the vehicle fall back to direct control of smart charging it is determined that the vehicle was non-compliant.

36. The system ofclaim 27 wherein the communication between the first smart charging module and the second smart charging module is accomplished via Power Line Communications over the charging cable.

37. The system ofclaim 27 wherein the communication between the first smart charging module and the second smart charging module is accomplished via wireless communications.

Images