ES2928192T3 - Aggregation server for networked vehicles - Google Patents

Abstract

Methods, apparatus and computer programs for use in aggregating the flow of electrical energy between the electrical network and electric vehicles. In an aggregation server, electric vehicle equipment (EVE) operating parameters are received from each of a plurality of EVEs through respective vehicle links. The received EVE operating parameters comprise the charging and discharging power capacity based on the power capacity of the electric vehicle station equipment (EVSE). The aggregation server aggregates the received EVE operating parameters, predicts a total available capacity based on the aggregated EVE operating parameters, and sends at least a part of the total available capacity to the network. (Automatic translation with Google Translate, without legal value)

Description

DESCRIPTION

Aggregation server for networked vehicles

Background of the invention

Conventionally, electric vehicles (for example, battery-powered vehicles and plug-in hybrid vehicles) are charged in a manner similar to those used to charge most devices powered by rechargeable batteries. That is, the operator plugs a vehicle battery charger into an electrical outlet connected to a utility power network (the "grid") and the vehicle charger immediately begins charging the vehicle battery. The rate at which the vehicle battery is charged is usually a result of the current limit imposed by the charger electronics and the variable internal resistance of the vehicle battery. A vehicle charger may contain explicit logic or components to alter the charging rate in order to extend the life of the vehicle battery. Normally, there are no additional components to control the charging speed determined by other factors.

US 20080281663 A1 describes a computational method for sending power from distributed resources on a discharge event so that the power stored in individual devices is leveled, or for an operator request to be fulfilled. The evaluation of the event parameters can be deferred. The method can be used to send power from plug-in electric vehicles. Systems and methods for accounting for electricity sent to or from electric vehicles are disclosed. Systems and methods are disclosed to incentivize consumers to participate in a consignment or energy reduction event.

Summary of the invention

A first aspect of the present invention comprises a method for aggregating the flow of electrical power between the electrical network and electric vehicles comprising, in an aggregation server: receiving the operating parameters from the EVE of each of a plurality of EVEs to via respective vehicle links, the received EVE operating parameters comprising charging and discharging power capacity based on the power capacity of the electric vehicle station equipment (EVSE); add the received EVE operating parameters; predict the total available capacity based on the aggregated EVE operating parameters; send at least a part of the total available capacity to the network; predicting trips for an electric vehicle associated with one of the plurality of EVEs, the vehicle having a battery; and cause the battery charge in order to comply with the planned trips.

A second aspect of the present invention comprises a computer program comprising a set of instructions which, when executed by a computing device, cause the computing device to perform a method for adding a flow of electrical power between the electrical grid and electric vehicles of I agree with the first aspect.

A third aspect of the present invention comprises an aggregation server for aggregating the electric power flow between the electrical network and electric vehicles, the aggregation server being configured to: receive electric vehicle equipment (EVE) operating parameters from each of a plurality of the EVEs through the respective vehicle links, the received EVE operating parameters comprising charging and discharging power capacity based on the power capacity of the electric vehicle station equipment (EVSE); add the received EVE operating parameters; predicting a total available capacity based on the aggregated EVE operating parameters; send at least a part of the total available capacity to the network; predicting trips for an electric vehicle associated with one of the plurality of EVEs, the vehicle having a battery; and cause the battery to charge in order to fulfill the planned trips.

Brief description of the drawings

The invention is better understood from the following detailed description when read in connection with the accompanying drawings, with similar elements having the same reference numerals. When a plurality of similar elements are present, a single reference numeral may be assigned to the plurality of similar elements with a lower case letter designation referring to specific elements. When referring to elements collectively or to one or more non-specific elements, the lowercase letter designation may be dropped. The letter "n" can represent a non-specific number of elements. This emphasizes that, in accordance with common practice, the various features in the drawings are not drawn to scale. Rather, the dimensions of the various features are arbitrarily enlarged or reduced for clarity. The drawings include the following figures:

Fig. 1 is a block diagram illustrating an electric power transfer system including an aggregation server, electric vehicle equipment, and electric vehicle station equipment in accordance with aspects of the present invention;

Figure 2 is a block diagram illustrating exemplary electric vehicle equipment for use within the electrical power transfer system of Figure 1 in accordance with aspects of the present invention; Figure 2a is a block diagram illustrating an example of electric vehicle equipment for vehicle-to-vehicle charging in accordance with aspects of the present invention;

Figure 3 is a block diagram illustrating exemplary power station equipment for use within the electrical power transfer system of Figure 1 in accordance with aspects of the present invention; Figure 4 is a block diagram illustrating communication between an exemplary aggregation server for use within the electrical power transfer system of Figure 1 and various entities in accordance with aspects of the present invention;

Figure 5 is a flowchart depicting exemplary steps performed by electric vehicle equipment in accordance with exemplary aspects of the present invention;

Figure 6 is another flowchart depicting exemplary steps performed by electric vehicle kits in accordance with exemplary aspects of the present invention;

Figure 7 is another flowchart depicting exemplary steps performed by electric vehicle kits in accordance with exemplary aspects of the present invention;

Figure 8 is another flowchart depicting exemplary steps performed by electric vehicle kits in accordance with exemplary aspects of the present invention;

Figure 9 is a flowchart depicting exemplary steps performed by electric vehicle station equipment in accordance with exemplary aspects of the present invention;

Figure 10 is another flowchart depicting exemplary steps performed by electric vehicle station equipment in accordance with exemplary aspects of the present invention;

Figure 11 is a flowchart depicting exemplary steps performed by an aggregation server in accordance with one aspect of the present invention;

Figure 12 is another flowchart depicting exemplary steps performed by an aggregation server in accordance with one aspect of the present invention; Y

Figure 13 is another flowchart depicting exemplary steps performed by an aggregation server in accordance with one aspect of the present invention.

Detailed description of the invention

Figure 1 depicts an electrical power transfer system 100 in accordance with an exemplary embodiment of the present invention. The illustrated system 100 includes an electric vehicle equipment (EVE) 102, an electric vehicle station equipment (EVSE) 104, an aggregation server 106, and an electrical network 108. As a general description, the EVE 102 is placed within a vehicle for connecting the vehicle to the EVSE 104. The EVE 102 includes a vehicle link (VL) 103 that provides a link from external entities to components typically found in electric vehicles, which will be described in more detail below.

Electrical power is allowed to flow between the network 108 and the vehicle's EVE 102 through the EVSE 104. An aggregation server 106 monitors the power flow requirements of the network and the power flow between the network 108 and multiple vehicles. (each vehicle includes an EVE 102) and communicates with the network 108 to allocate the capacity and demand for electrical supply of the vehicles. Based on determined capacity and demand, the electric power transfer system 100 allows, among other things, for vehicles to be charged during periods of time when there is little demand on the grid 108 and to supply power to the 108 network during periods of time when there is high demand on the 108 network.

The thick connecting lines 110 between the EVE 102 and the EVSE 104 (connecting line 110a) and between the EVSE 104 and the network 108 (connecting line 110b) represent the flow of electrical power and the thin connecting lines 112 between the VL 103 and EVSE 104 (connection line 112a), between VL 103 and aggregation server 106 (connection line 112b), and between aggregation server 106 and network 108 (connection line 112c) represent the communication flow /data. Although not illustrated, other communication/data paths may be used to establish communication with other components. For example, the VL 103 can communicate with the aggregation server 106 indirectly through the EVSE 104. In this example, the direct communication between the VL 103 and the aggregation server 106 can be omitted and a direct communication path would be added between the EVSE 104 and aggregation server 106. One skilled in the art will understand other communication strategies from the description herein.

The terminology used in this document will now be defined.

Network 108 refers to the electrical power system from generation to electrical output. This includes generators, transmission and distribution lines, transformers, switchgear, and on-site wiring (for example, a home, building, parking lot, and/or other parking location from the electric meter for that location through electrical panels to electrical outlet). Sensors, computational logic, and communications may be located at one or multiple locations within the network to monitor functions associated with the network, and the vehicle's electrical system may fulfill one or multiple functions for the network.

Grid-integrated vehicles generally refer to mobile machines for transporting passengers, cargo, or equipment. Grid-integrated vehicles have an "on-board" energy storage system (for example, electrochemicals, petroleum distillates, hydrogen and/or other storage) and a grid connection system to recharge or supplement onboard storage (for example, a battery, capacitor or flywheel, electrolyzed hydrogen) with power from the grid 108 On-grid vehicles can also connect to the 108 grid to provide power from vehicle on-board storage to the 108 grid.

Electric vehicle equipment (EVE) 102 generally refers to equipment located in the vehicle integrated into the network to enable communication and power flow. In an exemplary embodiment, EVE 102 receives EVSE attributes (described below) and controls the flow of power and services from the network to and from the network-integrated vehicle based on, for example, EVSE attributes, the vehicle condition, on-board storage, expected driving, driver requirements and wishes. The EVE 102 may include a Vehicle Link (VL) 103, also known as a Vehicle Intelligent Link (VSL), which provides an interface between the EVSE 104 and the vehicle's on-network vehicle management system (VMS), which generally controls the electricity and electronic systems in the on-grid vehicle while it is not in use (for example, while parked in a garage).

EVE attributes generally refer to information describing the networked vehicle that may be transmitted to the EVSE 104 to which the vehicle is connected, to the aggregation server 106, or to another networked vehicle. These may include: (1) a unique network-integrated vehicle identification, (2) permitted billing and other business relationships, (3) authorizations of this vehicle, such as IEEE 949 certification for anti-islanding, and (4) technical capabilities of the vehicle, including maximum power output, whether it can produce power independent of grid power ("emergency power mode"), and others.

Electric vehicle station equipment (EVSE) 104 generally refers to equipment for interconnecting the EVE 102 with the network 108. The EVSE 104 may be located, for example, in a building or parking garage, near a street or next to a motor vehicle parking space. The EVE 102 within a network-integrated vehicle with on-board storage and power supply and information connections can be connected to the EVSE 104. The EVSE 104 stores attributes of the EVSE and can transmit the attributes to the EVE 102 of the network-integrated vehicle. network or other devices.

EVSE attributes are information related to the EVSE, such as its status, location, and other information. The EVSE attributes generally refer to information related to the EVSE 104 that is transmitted to the EVE 102 of the network integrated vehicle. This may include: (1) characteristics of the physical capabilities of the EVSE; (2) legal and administrative permits; (3) legal and administrative restrictions; (4) a unique EVSE ID; (5) permitted billing and other business relationships (involving EVSE and on-network vehicles); (6) network services that may be authorized (permitted) at this particular EVSE 104 location and/or others.

Electric load provider generally refers to a management entity that manages the EVSE 104. In one embodiment, an EVSE 104 may not have any electric load provider. For example, an EVSE 104 in a home garage, used to charge the homeowner's vehicle with the same electricity supply used by other appliances in the home. In other embodiments, an electric charging provider may have real-time or delayed communication with the EVSE 104, may provide real-time authorization to charge a grid-connected on-grid vehicle, and may require payment for the charge.

Parking operator generally refers to a company or organization that controls a space where a vehicle can be parked, for example, with one or more adjacent EVSE 104s. The parking operator may charge for the use of that space, require identification before parking and/or may exchange the use of the space in exchange for the use of the EVSE 104.

The aggregation server 106 refers to the management software, hardware, and procedures that communicate with the vehicles integrated into the network from the EVE 102 directly and/or through the EVSE 104, issue requests to those vehicles for uploading, downloading, and other network functions, and provide network services to a network operator, distribution company, higher-level aggregation server(s), generator, or other electrical entity. Aggregation server 106 may also receive reports on network services and load from EVE 102 and/or EVSE 104. An aggregator is a business entity that manages aggregation server 106. Aggregation server 106 may manage (control ) the flow of power to/from grid-connected vehicles 108 to aggregate and sell power to grid operators (eg, megawatts of power (MW)). Aggregation server 106 may also manage information for other entities, including electric charge providers, local distribution companies, and others.

Network operators may include, for example: (1) a distribution system operator (DSO); (2) a transmission system operator (TSO) or an independent system operator (ISO); (3) a generator; (4) an independent power producer (IPP); and/or (5) a renewable energy operator.

Network services generally refer to services provided between the vehicle on the network and the network 108, with power flowing through the EVSE 104. Network services may include: (1) local building services, such as emergency power; (2) distribution system services such as: (i) providing reactive power, (ii) extracting off-peak consumption, (iii) balancing the load on a three-phase system, (iv) providing demand response, (v ) provide distribution support (for example, deferring consumption or releasing power when the distribution system is reaching a limit, or by monitoring conditions, such as transformer temperature, to reduce power through that transformer) ; and (3) support of the transmission and generation system such as: (i) providing frequency regulation, (ii) providing adjustments between hours, (iii) providing rotation reserves; and/or (4) renewable energy support such as (i) providing wind balancing, (ii) providing ramp rate reduction, (iii) providing a power shift from peak solar to peak load, (iv) absorb wind or solar power when load exceeds, among many others. For example, grid services may include charging at off-peak hours, regulating grid power quality, producing power quickly and enough to prevent grid failures or blackouts, and smoothing generation from power sources. fluctuating renewable energy such as wind and solar sources.

Network location generally refers to the location in the electrical system where the EVSE 104 is connected. This may be a hierarchical location (eg electrical position) in the electrical system and may not correspond to a physical location. In an exemplary embodiment of the invention, the network location may be defined based on one or more of: (1) the building circuit to which the EVSE 104 is connected and fused; (2) the service station and meter to which the EVSE 104 is connected; (3) the distribution transformer to which the EVSE 104 is connected; (4) the EVSE distribution feeder; (4) the EVSE substation; (5) the EVSE transmission node; (6) the local EVSE distribution company; (7) the operator of the EVSE transmission system; (8) the EVSE subregion; and (9) the EVSE, ISO or TSO region. Due to distribution circuit switching (e.g. reconfiguration), intermediate positions in the hierarchical structure can change dynamically, so that the EVSE network location, for example, can move dynamically from one distribution feeder to another as distribution switches open and close, although the physical location of the EVSE does not change.

Figure 2 depicts an exemplary EVE 102 for use in a networked vehicle and Figure 3 depicts an exemplary EVSE 104 to which the EVE 102 may be connected. The EVE 102 includes a connector 250 and the EVSE 104 includes a connector 350 to mate with connector 250. In various exemplary embodiments, there could be a cable attached to the EVSE 104 with connector 350 at the end of the cable, or a separate cable could be provided to connect from the EVSE 350 connector to the EVE connector. 250.

Referring to Figure 2, EVE 102 includes a VL 103, a battery 202, a power electronics module (PEM) 204, a vehicle management system (VMS) 206, and a vehicle docking input 250. The VL 103 includes a microcomputer 210, a memory 212, and a command module 214. The VL 103 can be configured to communicate, determine the features of network services, and control those features.

In an exemplary embodiment, the PEM 204, VMS 206, and battery 202 are typical components found in a conventional electric vehicle and the VL 103 is incorporated in accordance with the present invention to enable such a vehicle to receive/provide network services. . The VMS 206 directly controls battery management, charging and possibly driving functions under the direction of the VL 103, in addition to the VMS 206 controls via other vehicle controls. The functionality of the VMS 206 may be integrated into other devices, such as the PEM 204, or may be performed by one or more devices.

The VL 103 can be integrated into a networked vehicle during manufacturing or added (upgraded) to a vehicle after manufacturing. Although displayed as a single device, the VL 103 can be two or more devices in separate locations on a networked vehicle. In some exemplary embodiments, some functions of the VL 103 may be provided by other devices and the VL 103 may be built with only the additional functionality (not already provided in the other devices by the original automobile manufacturer). Alternatively, it may be a software system to perform functions implemented using the existing vehicle computer(s), for example, within the VMS 206 and/or the PEM 204. A suitable device including components that can be adapted to function like microcomputer 210, memory 212 and command module 214 according to the present invention is Mini-ITX manufactured by Logic Supply of South Burlington, VT.

Command module 214 controls PEM 204 directly (not shown) or through VMS 206 (and/or controls a separate battery management system) to charge, discharge, and/or provide reactive power, at varying power levels and factors. variable power.

The microcomputer 210 is configured and programmed to provide the following functionality: (1) two-way communication with the EVSE 104; (2) process the EVSE attributes received from the EVSE 104; (3) execute the instruction stored in memory 212: (a) predictively model EVE 102 usage and track interactions with the driver of the networked vehicle; (b) assess network, battery, and vehicle conditions, and (c) determine if and when to order EVE 102 to absorb or provide real power or reactive power. The microcomputer 210 may include a programming/communications port 211 for communication with a display, touch screen, or programming device (not shown) for programming the VL 103.

The VL 103 stores network-embedded vehicle attributes ("EVE attributes") in memory 212, and may transmit these attributes to the EVSE 306 memory (described below with reference to Figure 3) or to the EVE memory 212 in another connected vehicle. Vehicle attributes include, for example: (1) a unique vehicle identification integrated into the network, (2) permitted billing and other business relationships, such as valid account numbers or authorization codes for purchasing electricity and driving time. parking, (3) authorizations and code compliance certifications of this vehicle, such as IEEE 949 Certification for anti-islanding, and (4) technical capabilities of the vehicle, including maximum power output, if it can produce power independent of the grid electrical ("emergency power mode"), and others, (5) if approved for shipment by an aggregation server, (6) guaranteed (or not) of neutral when power is provided by a vehicle, and ( 7) any account and authorization to be credited for network services. EVE attributes can be static, such as the vehicle's unique identification, or dynamic, such as battery charge status, or whether the on-network vehicle currently functions as a local aggregation server for other locally connected vehicles.

The VL 103 may control the charging and discharging of the battery 202 through the VMS 206 and/or may control the provision of other network services. More particularly, the VL 103 can: (1) communicate, for example, with an EVSE 104 mounted on a wall or curb; (2) receiving EVSE attributes from the EVSE 104; (3) evaluate the attributes of the EVSE to configure and control battery charging, electricity payment or other network services, (4) receive information from the battery 202, the PEM 204, the VMS 206, the sensor on-board power supply 220, dash settings, and other vehicle systems, either through VMS 206 or through other on-board vehicle communications, such as CAN bus, or directly through driver input, or through other communications or vehicle entrances; (5) send charging, discharging, reactive power, and other grid-related electrical power commands to the vehicle; and (6) send commands to other vehicle systems regarding heating or cooling of the passenger compartment, batteries, and any other actions of other vehicle systems.

Referring to Figure 3, the EVSE 104 includes a contactor 302, a microprocessor 304, a memory 306, a ground fault interrupt (GFI) sensor 308, a current measurement sensor 310, and a vehicle docking connector 350. The memory 306 may be incorporated into the microprocessor 304 or maintained as a separate component. Optionally, the EVSE 104 may include a microcomputer 320, router, or other device for processing packet-switched signals, communicating with external networks, and executing programs, with WAN or router connection 322 and local condition detection sensor connections 324. An expert in the art shall comprise suitable contactors, microprocessors, memory, GFI processing, and sensors from the disclosure herein.

The EVSE 104 can be configured for deployment in a garage, public parking lot, sidewalk, or other car parking location. The EVSE 104 can provide: (1) an electrical connection from a network-integrated vehicle EVE 102 to the electrical network 108; (2) EVSE attributes and (3) a mechanism for billing/crediting network services.

The EVSE 104 maintains attributes associated with the EVSE 104, such as its status, network location, and other information for use by the network-integrated vehicle through the VL 103 to control power flow and provide valuable network services. . In an exemplary embodiment, microprocessor 304 stores EVSE attributes in memory 306 and selectively retrieves EVSE attributes from memory 306 for delivery to VL 103. EVSE attributes may include static and dynamic attributes. Static attributes may include: network location information; collection business model such as provisions for payment or credit for electric power and electric services, compensation for occupying the physical parking space, and other information; unique identification (ID) of the EVSE; forward flow limit; reverse flow limit; emergency power indicator; and/or authorized CAN bus code. Dynamic attributes may include disconnect status, grid power status, vehicle identifier, transformer overload, circuit breaker open/closed, building loads, account authorizations, vehicle capacities, and vehicle authorizations.

Microprocessor 304 includes a programming/communication port 305, for example, for downloading static information during installation of EVSE 104, regarding building, electrical, circuit, security clearances, distribution company, meter account, and other information. Some of this information may only be authorized by DSO electricians or electrical inspectors. The static information may include: (1) network location information indicating the location of the EVSE 104 within the network; (2) a charging business model that indicates whether charging a vehicle is free, to be charged, or other options described above; (3) a unique EVSE ID; (4) whether the Internet connection from the building or EVSE location has a fixed IP address and, if so, what is the IP number or a dynamic IP assigned by DHCP or another Internet protocol; (5) A forward flow limit indicating the maximum allowable flow of power to the EVE 102 of a network integrated vehicle from the EVSE 104; (6) a reverse flow limit indicating the maximum allowed flow of power into the EVSE 104 from the EVE 102 of an on-grid vehicle; (7) an emergency power indicator that indicates whether the EVE 102 of a vehicle integrated into the network 204 to the EVSE 104 can supply emergency power (the static information setting of the emergency power indicator may require an inspector to verify that an isolating switch has been installed at the location); (8) A CAN bus authorized flag indicating whether a CAN bus protocol can be extended to the EVSE 104.

The CAN bus connection can be authorized from the EVSE 104 via the vehicle's CAN bus (if applicable). The EVSE 104 can be authorized to have full access to the vehicle's CAN bus based on the EVSE serial number or model number with or without an encrypted key. If this authorization is not approved by the EVE 102 of an on-network vehicle, the on-network vehicle may provide isolated CAN bus communication only between the EVSE 104 and VL 103 and not to the entire CAN bus of the vehicle .

The EVSE 304 microprocessor or optional EVSE 320 microcomputer can receive dynamic information, for example, via port 322 regarding: (1) the current state of a disconnect switch serving the EVSE 104 (for example, whether you are currently online or offline); (2) whether the network is currently on; and (3) the vehicle identifier of the connected network-integrated vehicle. This dynamic information can be transmitted from different network equipment/sensors. For example, the EVSE 104 can include a voltage sensor to monitor if the grid is on. A signal from the disconnect switch can be used to monitor its status (for example, open or closed). The VL 103 can supply the vehicle identifier to memory 306 through pins 250d/350d, input/output communication port 312 and microprocessor 304. Dynamic information can be repeatedly transmitted at predetermined intervals (eg, from every second to once a minute).

In certain exemplary embodiments, the EVSE attributes stored in memory 306 may include additional information used for control of network services. For example, memory 306 may store: (1) a unique serial number for EVSE 104; (2) a serial number of the building's electric meter; and/or (3) a construction account.

In various exemplary embodiments, the emergency power indicator may indicate that emergency power: (1) can never be authorized; (2) can always be authorized; or (3) it may be authorized based on certain conditions, such as whether the vehicle's EVE 102 integrated into the network complies with IEEE 929. The EVSE 104 may include at least one contactor and transformer (not shown) to match the EVE power production with building loads when activated by the EVSE for emergency power produced by the EVE.

In certain exemplary embodiments, the forward and reverse flux limits may be a dynamic rating provided by building sensors, smart network elements such as transformer overcurrent detectors, or by the DSO via microprocessor 320. In such cases, the rating Dynamics can override any static information stored in memory 306 and can also override individual maximum amps signaled by an SAE J1772 control light. Dynamic information from the DSO 230 could be part of active repair strategies and DSO management procedures, for example, limit or increase power consistent with circuit loads, feedback to relieve circuit overload, or provide emergency power at times consistent with the opening, closing, and repair of distribution lines.

A single 302 contactor, designed for single phase, is shown in the EVSE. One skilled in the art will see how this design can be adapted to a simple three phase system by adding additional poles to contactor 302 and additional cables. Furthermore, it is contemplated that additional contactors may be used, or a contactor with additional poles or throws may be used, so that the on-grid vehicle may be connected between any phase of a multi-phase grid system. In such an arrangement, a DSO may provide information stored in memory 306 to indicate phase connections. Such information can be periodically updated by the DSO to the EVSE 104 using the programming/communications port 305.

In some exemplary embodiments, the EVSE 104 may control power forwarding without any authorization from the electric load provider or from the aggregation server 106.

In some exemplary embodiments, a billing mechanism may be provided such that billing is debited or credited to a financial account for parking and network services and can be tabulated at checkout and billed to that account without separate charges. Alternatively, there may be no billing mechanism if the on-network vehicle provides network service (parking and network services may offset each other) or if free charging is allowed (such as at the drivers' own residence). vehicle owners).

In other exemplary embodiments, the EVE 102 of a network integrated vehicle may provide a number of valid account to receive energy. Failure to provide a valid account number will result in EVSE not being activated and/or a parking violation may be incurred. In such cases, a card reader or coin and note reader can be included in the EVSE to authorize payment or credit to a financial or prepaid account. Authorization from electric charging provider may be required for credit accounts. When the prepayment is exhausted, the EVSE 104 may be deactivated and/or a parking violation indicator may be activated.

In various exemplary embodiments, a building electrical inspector, charging service entity representative, or other authorized party may install the EVSE 104 and configure the EVSE attributes via port 305, including:

1. In certain exemplary embodiments, the default settings of the EVSE 104 can be configured to authorize on-grid vehicle charging with the EVE 102 at low current upon connection (for example, the socket features signal acknowledgments that the vehicle integrated into the network is connected to the EVSE 104), even if no authorized EVSE 104 configuration has been entered.

2. Electrical inspector can check circuit wiring, circuit breaker and power grid, and can input EVSE attributes into microprocessor 304 through port 305 to store in static memory of EVSE 306, to get maximum power consumption. current in accordance with building load conventions.

3. The electrical inspector may input EVSE attributes to microprocessor 304 through port 305 for storage in static memory of EVSE 306 indicating electrical location. Electrical location may include, for example, EVSE submeter if present, building circuit, utility tap pole number, distribution transformer, distribution feeder circuit, substation, utility ID load, location marginal price node and transmission system (TSO or ISO). Associations can be recorded on a medium in EVSE and sent to the VL in EVE along with other attributes. In addition, these associations can be sent at specific times to the electrical load vendor (EVSE maintainer or provider 104) and one or more aggregation servers 106. The electrical inspector or other field personnel who record and report the associations ensure the accuracy of the associations. EVSE attributes and you may be required to enter an employee ID or other code along with the EVSE attributes for validation.

4. A representative of the load service entity can inspect (determine) the distribution transformer size and building loads and can input EVSE attributes into microprocessor 304 through port 305 for storage in EVSE static memory. 306, for the reverse flow limit attribute (eg, on-grid vehicle at network current limit). The reverse flow limit can be set at a different level (and can be higher than) the forward flow limit. The reverse flow limit can be set to zero to indicate that power is not allowed to be supplied to the EVSE 104 from a vehicle networked with the EVE 102. Reverse flow clearance may depend on the vehicle type being certified as conforming to IEEE 929 anti-islanding.

5. A load utility representative may inspect for the presence of an approved isolating switch or microgrid switching, and if approved, may set the EVSE attribute for emergency power to "true", indicating that The grid-integrated vehicle EVE 102 can supply power to the building when a power outage occurs in the building and when the isolation switch has been activated, isolating the building from the grid.

A tamper-evident process can be used to configure EVSE attributes through a portable field device connected via programming port 305. For example, items 2, 3, 4, and 5 above can be protected or authorized by an employee ID or password, so they cannot be changed except by an authorized person. Other information, such as the Internet protocol used, may be deliberately unprotected, or may have a lower level of protection, so that a building occupant or building IT manager can change it.

Some security or authorization related EVSE attributes, eg items 2, 3, 4 and 5, above, can be recorded in memory using a digital signature and transmitted to EVE 102 along with the digital signature. Therefore, the EVE 102 and the aggregation server 106 can confirm at the time of connection that an authorized party has entered the data into the EVSE 104. If the authorization is missing or the digital signature is invalid, the authorization decisions which are described below with respect to Figures 6, 8 and 10 would produce "no".

EVE 102 can be connected to EVSE 104, which can result in bi-directional information flow and one- or two-way power flow.

Although the EVSE 104 is shown as a stand-alone (complete) device, it is contemplated that the EVSE 104 components of the present invention, such as storing and forwarding EVSE attributes, digital signal on connector 250d, communication to the WAN and others, can be configured as a plug-in device to be included as part of an SAE J1772 or other compliant electric vehicle supply equipment device by adding information and communication capabilities as described herein to such devices.

Referring to Figures 2 and 3, in an exemplary embodiment, the 250/350 connectors comply with Society of Automotive Engineers (SAE) standard J1772, International Electrotechnical Commission (IEC) standard 62196-2, or another standard national or international to enable network-integrated vehicle connections for network 108. The present invention is based on the standards described in SAE J1772 approved in 2010 and draft IEC 62196-2, which are described in this paragraph by reference and to distinguish additional uses of these connectors in accordance with aspects of the present invention. The mating connectors 250/350 include a first mating connector 250 for the EVE 102 and a second mating connector 350 for the EVSE 104. The first mating connector 250, which may be referred to as an "input," includes five input contacts/pins. male coupling 250a, 250b, 250c, 250d and 250e. Second mating connector 350 includes corresponding female mating pins/contacts 350a, 350b, 350c, 350d, and 350e, which are configured to mate with male mating pins 250a, 250b, 250c, 250d, and 250e, respectively. The 250/350 connectors can also incorporate additional power contacts for three-phase and neutral according to the IEC 62196-2 project. In use, the EVSE 104 signals the amount of charge available to the EVE 102 via a digital signal cable via the 250d/350d mating pins, for example, as described in SAE J1772. A conventional plug presence switch (not shown) can be incorporated into the 350e plug. The EVSE 104 may indicate to the EVE 102 that connectors 250/350 are mated in response to the receive pin of the current pin 350e of the socket 250e, for example, as described in SAE J1772.

SAE J1772 and IEC 62196-2 specify that the power provided across the pins on the contactor is in response to the pilot signal indicating a connection to the integrated vehicle EVE 102. In accordance with aspects of this invention, power can be activated by contactor 302, and adds additional controls that this contactor can perform, specifically, ground fault detection signal indicating that there are no ground faults, current overload detection indicating that the current drawn is not is excessive, and account authorization signal indicating authorization for this network integrated vehicle EVA 102 to draw power from this EVSE 104. Contactor 302 may be a normally open device, so that unless each of the signals indicate that contactor 302 should close, contactor 302 remains open to stop power flow between the grid and the on-grid vehicle.

Although a single set of mating connectors 250/350 including five contacts (pins or sockets) is illustrated, one skilled in the art will understand from the description herein that different numbers of such connections/contacts may be used. For example, seven connections can be used for three-phase power: one for each phase, one neutral, one ground, and two for data. Or, connectors for power and signaling can be provided to allow DC charging instead of AC charging. The invention described herein may be based on the standards described above or may be part of variants of mating connectors with different numbers and conventions of connectors, power lines, or signal lines.

Figure 4 depicts an exemplary aggregation server 106 and associated connections to other components for offering network services. The illustrated aggregation server 106 includes a microcomputer 402 and a memory 404 accessible by the microcomputer 402 for data storage and retrieval. The aggregation server 106 further includes communication components (not shown) for establishing communication with the VL 103 and optionally one or more of TSO 412, DSO 414, electric charge provider 416, and parking operator 418. In an exemplary embodiment, the Communication with the aggregation server 106 is performed over a wide area network (WAN) 450. Suitable servers, microcomputers, memory, and communication components will be understood by one skilled in the art from the description herein.

When multiple EVSE 104s are together in the space of a single parking operator or electric charging provider (whether in a physical parking lot, business, municipality, or other entity), the parking operator or electric charging provider can operate an aggregation server 106 itself, or it can incorporate certain functions of the aggregation server in a local centralized control. In an exemplary embodiment, some functions of the aggregation server would be at a centralized pay station in a parking garage, and payment or receipt of credit could be made at the pay station instead of directly through the VL 103 or Ev SE 104.

Referring to Figures 1-4 generally, the VL 103 can receive EVSE attributes by:

(1) VL 103 queries microprocessor 304 for EVSE attributes stored in memory 306 or

(2) microprocessor 304 can determine that EVE 102 has connected to EVSE 104, for example, based on a pilot signal from EVE and microprocessor 304 can then transmit EVSE attributes over one of the lines connected to EVE 102. In either case, the attributes of the EVE 102 are transmitted to the EVSE through a reciprocal process.

The EVSE attributes may be communicated using a signal encoded by the microprocessor 304, sent via input/output port 312, via mating contacts 250d and 350d of mating connectors 250/350, and input/output port 312. output 216 of VL 103. Alternatively, the EVSE attributes can be be sent by a power line carrier signal through, for example, power contacts 250a and 350a. The received EVSE attributes are stored in memory 212 of the VL 103. The VL 103 may transmit an account, billing, accumulated kWh, and/or vehicle identifier to the EVSE 104, aggregation server 106, an electric charge provider, or carrier. parking for payment or credit account authorization.

The VL 103 can communicate with the EVSE 104 through one of: (1) power line carrier (PLC); (2) CAN bus, (3) serial communication over pilot line (150D/250D), and/or (4) signal from the negative side of the pilot digital pulse width signal, among others. EVE 102 may include a cellular communication device (not shown) to provide a cellular signal as back-up communication to aggregation server 106. Other communication techniques (not shown) such as low power radio or carrier radio may also be used. low frequency via power lines to work with the VL 102 in other cars.

The VL 103 can communicate in real time or near real time with the aggregation server 106. This communication can be over a wired WAN from the VL 103 to the EVSE 104, or the EVE 102 can have a cellular or other capability. wireless to communicate with the aggregation server 106. In the first case, the connection is in effect only when the eVe 102 is connected to an EVSE 104 with working LAN communications. The present invention can be adapted for implementation in all of these circumstances.

In an exemplary embodiment, VL 103 will attempt to communicate with aggregation server 106 using each of the available communication methods, with direct connection through connectors 250 and 350 tested first, other unsubscribed services next, and cellular next. . If there are no communications available with the aggregation server 106, the VL 103 goes into stand-alone mode, which is described below with reference to Fig. 7.

In an exemplary embodiment, the VL 103 determines (tracks) the driver's past trips, stated needs or wants for network-integrated vehicle operation, and predicts a schedule of probable next trips (predictions of the next few Trips may include, for one or more future trips, the probable start time, probable distance, and required load and destination). The predictive model can be based on an EVE prediction based on past vehicle use, it can be based on explicit program information entered by the driver or fleet manager, or it can be based on a generic predictive model that improves with use of the vehicle. vehicle and driver feedback. Driver input can be through in-vehicle controls, by a portable digital assistant, by a browser-based vehicle scheduling calendar, or by an extension or addition to other scheduling systems already in use by the drivers of the vehicle or the fleet operator. The VL 103 records vehicle usage and can be used as a data source for later predictions. Driver input can be through in-vehicle controls connected to the VL 103, it can be through programming software hosted on the aggregation server 106 or data from another vehicle support platform, or it can be through assistants personal digital devices or other wireless devices that communicate with the VL 103, the WAN, the aggregation server 106 or other portals. Regardless of the schedule data acquisition means and channel, the scheduled schedule can be stored both in the VL 103, for example, in the memory 212, and in the aggregation server 106. Therefore, the EVE can use the predictions of upcoming trips, eg to make sure the car is sufficiently charged when needed, eg for transport and/or heating, determine the most economical times to charge, etc. The aggregation server 106 can use the following trip predictions to plan how much electrical capacity will be offered for network services, at what times, and where on the network.

The VL 103 and the aggregation server 106 also have the ability to use the predictions of upcoming trips to provide additional services. For example, in extreme temperatures, the next expected driving time can be used to pre-heat or pre-cool the passenger compartment so that it is at a comfortable temperature at the time of intended use. This temperature control can be performed by the vehicle's heating/cooling system while connected to the mains, reducing power consumption from the vehicle's battery for initial heating or cooling. Also, because heat and cold can often be stored in a smaller, lower-cost device than electrical storage, heat or cold can be stored in in-vehicle thermal storage based on prediction of upcoming trips. and the current temperature or the weather prediction of the temperature at the time of prediction of upcoming trips. Another use of the predictive model is to apply it in conjunction with battery temperature sensing to pre-heat or pre-cool the battery before driving to improve performance and extend battery life. The predictive model can also be used to provide other driving services. For example, since the destination of the next trip is known, a parking or EVSE space can be reserved at the time of arrival. Finally, if the journey is near or beyond the range of the vehicle's battery, en route recharging locations can be identified and suggested to the driver.

The VL 103 and aggregation server 106 also use the predictions of upcoming trips to optimize battery charging for maximum battery life. Maximum battery life can be the primary goal of the VL 103, or it can be one of several jointly optimized goals, eg ensuring sufficient charge for the next trip and provision of network services. Management for the maximum useful life of the battery life is based on the principle that charging rate, state of charge (SOC), how long the battery stays in each SOC, temperature, and other factors greatly affect battery life. For example, a battery that typically stays between 40% and 60% of maximum SOC will last longer than a battery that is frequently fully charged. Conventional vehicle battery charging systems (state of the art) limit the upper and lower SOC, for example, between 10% and 90% of the maximum SOC; however, they always charge the maximum SOC allowed each time the vehicle is plugged in. Aspects of the present invention use the prediction of upcoming trips to determine the amount of charge needed and when to reach it. For example, taking the above SOC numbers as an illustration, if the upcoming trip is a short distance that requires only 20% battery, the VL 103 and/or aggregation server 106 can charge the battery to only 60%, at the end of the trip, the SOC would be expected to be 40%, as this would reliably satisfy the driving need while imposing very little wear on the battery. Alternatively, on an unusually long journey, EVE 103 may authorize charging above the usual recommended amount, in this illustrative example, above 90%, but since the next journey time is known, the battery remains in that state only very briefly, i.e. just before the next expected travel time, thus maximizing range while minimizing wear and tear to achieve that range.

Since both the VL 103 and the aggregation server 106 contain copies of the predictive program, these functions can be performed by either one; the choice of which device controls can be optimized, for example, using the one currently connected (aggregation server while driving if no cellular link) or the closest and most locally relevant (EVE while charging ). According to patent application publication no. 2009/0222143, this design also allows for "graceful downgrade", for example, the VL 103 can perform charging to prepare for intended trips even if communication with the server fails. of aggregation 106 and/or the EVSE 104.

When parked and connected, the VL 103 and/or the aggregation server 106 can control (make decisions about) the speed and time of loading and provisioning of network services. The driver can transfer information (for example, an account number) to the EVSE 104 or to the aggregation server 106 or to the electric charge provider that manages the EVSE 104. This information can be previously stored in the EVE 102, or it can be provided by means of a credit card or key fob on the EVSE 104 itself using an electronic or magnetic reader (not shown) or a personal digital assistant (PDA). Once the information is validated by the EVSE 104 or the aggregation server 106 or the electric charging provider, the EVSE 104 may receive authorization to energize the contactor 302, for example to charge a vehicle integrated into the network that includes the EVE. 102.

On behalf of the electric charge provider, EVSE 104 can use contactor 302 to refuse to charge until the driver or EVE 102 provide acceptable identification or account information for the purchase of charging electricity. In addition, on behalf of the parking operator, the EVSE 104 may refuse to charge or may issue a warning (for example, audible signal on the EVSE or electronic signal transmitted to the parking operator) unless the driver or EVE provides parking information. account acceptable for the purchase of parking time. In an exemplary embodiment, contactor 302 does not turn network services on or off. Rather it acts as a fuse for emergencies (eg GFCI for ground fault, plus overcurrent protection) and to prevent electricity theft (get ID before charging). The EVE 102 can perform more complex network services and control the upload or download speed.

The VL 103 can include (or can access) an electric meter (for example, an income level meter) to measure the accumulated energy in each direction to and from the EVSE 104. This meter can be integrated into the EVE 102 depending on the current sensor 220, in the building (not shown) or in the EVSE 104 depending on the current sensor 310. The revenue meter can be used to measure grid services or simply net or cumulative charging power. The VL 103 can include power management so that the VL 103 can turn on: (1) all the time, (2) only when the vehicle is plugged in, or (3) only when network services are required. The VL 103 can power off after the EVE 102 has been unplugged for more than a set period of time, or in some standalone modes after the battery is charged to the desired level, to reduce battery drain when parked and unplugged for long periods of time. The EVSE attributes, including the EVSE ID, are used to determine whether charging, network and other services are available at this location, and whether this vehicle should pay for and/or be paid for. The vehicle ID can also be used by the EVSE, for example, in conjunction with the account lookup via the electric charging provider. For given EVSE load attributes, actions taken include:

1. "Unrestricted Charging" EVSE Attribute: Upon connection of a vehicle's EVE 102 to EVSE 104, indicated by the pilot signal, microprocessor 304 sends attributes to EVE 102 and closes contactor 302 so that the vehicle can begin charging. load. No identification or account information is required, or even acknowledgment of receiving attributes from the vehicle. An exemplary instance of this "unrestricted load" case is a vehicle and an unmodified SAE J1772 standard EVSE, where the EVSE sends no attributes and closes the contactor without any vehicle attribute information.

2. EVSE attribute "free charge for known occupants/workers/members". Upon connection of the vehicle's EVE 102 to the EVSE 104, the microprocessor 304 sends the EVSE attributes to the EVE 102 and waits for the vehicle identification. The EVE 102 sends the vehicle identification to the EVSE 104. The EVSE 104 searches for the vehicle ID and if it is recognized by the EVSE 104, the EVSE 104 closes the contactor 302 and the vehicle can start charging. In a variant, EVE 102 sends the vehicle identification to EVSE 104, and EVSE 104 consults the electric charging provider for approval. The EVSE 104 then closes contactor 302 if approval is received.

3. EVSE attribute "charge for approved account holders". Upon connection, microprocessor 304 sends EVSE attributes to EVE 102 and waits for an account number and possible additional codes or authorization. The EVE 102 may send a code, such as a digitally signed account code, which is then processed by the EVSE 104, for example, sending it to the electric charging provider for approval. If the EVSE 104 passes the code, it closes contactor 302 and records the time and amount of energy (kWh) used for charging. To perform this function, the EVSE 104 uses a meter based on the current sensor 310, voltage measurement, and standard signal processing (not shown) on the microcomputer 320, or, for example, a separate input meter to which the EVSE 104 access through secure communication. The vehicle bill may be unbilled, may be billed on a time basis, may be billed by kWh, and/or may be billed against credits. A variant of this is that the account is used to pay for the use of a parking space. If the EVE 102 does not send an approved code, the EVSE 104 does not close contactor 302 and/or can indicate by an audible, light, or electronic signal that parking is not permitted at that location.

4. EVSE attribute "V2G network services allowed here". Upon connection, the EVSE microprocessor 304 sends EVSE attributes to EVE 102 and closes contactor 302. VL 103 evaluates the EVSE attributes, passes the network location and electrical capacity to the aggregation server 106. Then, the EVSE VL 103 compares the state of charge of the battery 202 with the expected time and distance for the next trip, and any other driver parameters with respect to minimum range requirements and driver preferences to optimize revenue from the integrated vehicle. network (GIV) vs. maximum range vs. maximum battery life. Based on these considerations, the VL 103 registers with the aggregation server 106 its ability to provide one or more network services, each at zero or more capacity, for a specified period of time at this location. When EVE 102 provides network services, it can use an integrated meter that can be based on a current loop 220 and other measurement and processing, or it can be part of the PEM 204.

5. In any EVSE 104, regardless of whether or not the EVSE 104 has any of the above capabilities, the VL 103 may elect, or may offer, refund, or credit the charging cost to the entity paying for electricity in that EVSE . To reimburse or credit the charge cost, the VL 103 identifies the location of the EVSE, building meter account, or other identifier of the entity paying for the electricity. Identification could be achieved using EVSE attributes, in particular the EVSE ID and/or building meter number. An EVSE 104 without the ability to identify itself with the VL 103, may be, for example, an EVSE conforming to SAE J1772 or IEC 62196-2, but without the additional capabilities described in this document, or it may be a simple electrical outlet with an adapter. For an EVSE without the ability to identify itself to EVE 102, EVE 102 may use additional means of identification. One method is an electronic "ping" with a different digital signature from a device inside the building, such as an X19 transmitter. According to this embodiment, the transmitter can be placed in the building and creates an electronic signature readable by the VL 103 of all vehicles connected to any EVSE 104 or to any socket within the same distribution transformer. A second method of identifying the entity paying for the electricity is to use GPS, along with a list of known charging locations stored in the VL 103 or aggregation server 106. GPS is not accurate enough for the reliability needed for the security-related services and authorizations, such as back-up and emergency power, but may be reliable enough to bill or credit a revenue meter account to charge electricity.

6. Variations and combinations of the above will be apparent to one skilled in the art, based on the above descriptions.

The VL 103 may include a vehicle-to-vehicle communication module (not shown) to communicate with other vehicles via low power short range radio, or via low frequency signals (for example, 1 to 300 KHz). via a Power Line Carrier (PLC) over 108 network or power cables. The signal frequency can be selected to pass through one or more distribution transformers. Such communication can be useful for the following reasons: (1) so that multiple cars can cooperatively provide network services, (2) in case of failure of the normal signal through the EVSE, or (3) to increase the width band, a group of vehicles in local communication can send a signal to the aggregation server that only one Internet signal may be needed to activate and receive reports from a group or local aggregation of vehicles that communicate locally.

By directly communicating with other vehicles, EVE 102 can function as an agent with authorized peers. Vehicle-to-vehicle communication can be used to compensate for the loss of direct communication with the aggregation server 106, or to act on the command of other nearby authorized vehicles to pool bandwidth for real-time delivery and traffic reporting. return. For example, EVE 102 from a network integrated vehicle may be nominated to serve as a local coalition representative. The local coalition representative receives a communication from the aggregation server 106, parses it into individual vehicle portions, transmits the corresponding commands to nearby or adjacent vehicles.

In response, those nearby vehicles independently respond to your command, then each sends a response to the local coalition representative, the local coalition representative aggregates or accumulates those response reports and reports them as a combined total response to the aggregation server .

In certain exemplary embodiments, the EVSE 104 may be OEM (automobile manufacturer) approved for CAN bus connectivity. In such embodiments, the EVE 102 may include equipment for extending the digital connection of the CAN bus in the integrated vehicle network EVE 102 to the EVSE 104 via, for example, via mating contacts 250d and 350d. This extension may depend on authorization indicated by a "CAN bus authorized" code in the EVSE 306's memory.

In certain exemplary embodiments where three-phase power is provided to PEM 204, EVE 102 may provide load balancing via three-phase power. For example, a PEM 204 may be capable of two-phase extraction. The VL 103 can sense the highest voltage on any two phases and cause the PEM 204 to switch to use power from those two phases. This can be accomplished with the EVE 102 by incorporating appropriate delays and consideration of the expected voltage drop on the two phases that the PEM 204 is drawing from. In this embodiment, the EVE 102 provides three-phase dynamic load balancing.

Figure 2A depicts a vehicle-to-vehicle charging system. According to an exemplary embodiment, the VL 103a of a first vehicle (the "donor" vehicle) includes additional functionality to allow it to appear as an EVSE to the VL 103b of a second vehicle (the "recipient" vehicle). A communication cable 290 including identical connectors at each end for attachment to connectors 250a, through 250d, allows signal flow between the donor and recipient vehicles and power flow from the donor vehicle to the recipient vehicle.

The donor vehicle EVE 102a may include circuitry for generating an amp capacity signal as if it were a SAE J1772 compliant EVSE, an IEC 62196-2 compliant EVSE, or the like. The donor vehicle EVE 102a may have circuitry to detect the recipient EVE 102b as an EVE to be loaded. Additionally, the EVE 102a in the donor vehicle may be able to activate the EMP and battery at 120a to generate grid-like AC power from the DC power of the battery 202. The EVE 102a or cable Communication module 290 provides the passive signal for the present socket. Therefore, the EVE 102a and the communication cable 290 together appear on the receiving vehicle's EVE 102b as if it were an EVSE. This means that a vehicle with this functionality and communication cable can charge another vehicle without any connection to the mains. The receiving vehicle does not require any additional functionality other than compliance with SAE J1772 or IEC 62196-2 standards. Optionally, the EVE 102b may have additional encode/decode equipment for communications not specified in SAE J1772 that include one or more of: digital signaling on the negative side of a control pin, digital signaling on the negative side of a CAN bus, or single cable Ethernet and/or Ethernet carrier power line through the power cables to the EVSE 104.

In an exemplary embodiment, neither vehicle makes any connection to ground during vehicle-to-vehicle charging. This reduces any risk of electrical potential (voltage difference) between ground and any hot, neutral, or chassis grounds on vehicles and reduces the need for GFI protection. In another exemplary embodiment, GFI protection may be added to the donor vehicle.

In another exemplary donor vehicle embodiment, EVE 102a may have a physical switch, software button, numeric input, or other input device (not shown), which allows the user to signal the intent of which vehicle will be the donor, and also allows that the user establishes a numerical limit, for example, in kWh, on the maximum energy transfer to be carried out.

Referring again to Figures 1-4, EVE 102 may have stored in its memory 212 vehicle attributes, including one or more account numbers, utility meter accounts, authorization codes, vehicle identifiers, or other identifiers. , any of which may be encrypted, to authorize power flow and/or financial transactions with the EVSE 104, electric charge provider 310, building owner or other local electric customer, parking operator 311, or server of aggregation. In addition, EVE 102 can have dynamic attributes of the vehicle, including records of accumulated kWh energy in each direction, its recorded provision of network services, and the time it occupies a parking space, and my use these dynamic attributes to calculate payments or credits. The EVE 102 may communicate with the EVSE 104, the electric charge provider 310 and the aggregation server 300 for a financial transaction, invoice or billing of energy and network services. If the EVE 102 is unable to communicate, for example, because the WAN 330 is offline at the time the credit or payment calculation is complete, the information can be stored in the EVE and communicated later, when the connection to the WAN is re-established. WAN 330. Payment or settlement may include goods and services, such as kWh of load power, load minutes, time-based or system-related billing components, such as "off-peak rate" or "absorption excess wind speed", non-electric attributes such as "green power", locally controlled grid services and non-electric services such as parking.

Figure 5 is a flowchart 500 of exemplary steps for managing power flow in accordance with embodiments of the present invention. For ease of discussion, the steps of flowchart 500 are described with reference to EVE 102 and EVSE 104.

In step 502, EVE 102 establishes communication with EVSE 104. In step 504, EVE 102 receives EVSE attributes from EVSE 104. In step 506, EVE 102 manages the power flow between EVE 102 and the EVSE 104 based on the attributes of the EVSE.

Figure 6 is a flow diagram 600 of exemplary stages for interfacing with the EVSE 104 to manage power flow from the perspective of the EVE 102.

At step 602, EVE 102 detects a connection event. In an exemplary embodiment, EVE 102 detects the presence of an EVSE 350 connector via a corresponding EVE 102 connector 250, eg, based on a socket presence signal generated by plug 250e. If a plugin is detected, processing proceeds to step 604. Otherwise, EVE 102 continues to wait for a connect event.

In step 604, EVE 102 receives power capability from EVSE 104. In an exemplary embodiment, EVSE 104 automatically transmits its connection capability in a pilot signal to EVE 102, for example, in accordance with SAE J1772 and/or IEC 62196-2, when the EVSE 104 is connected to the EVE 102.

At step 606, the EVE 102 establishes communication with the EVSE 104. In an exemplary embodiment, communication is established according to one of the methods described above.

At step 608, the EVE 102 determines if the EVSE attributes are available in the EVSE 104. If the EVSE attributes are available, processing proceeds to step 610. If the EVSE attributes are not available, processing proceeds to step 614.

In step 610, the EVE 102 receives attributes from the EVSE. In an exemplary embodiment, the VL 103 receives EVSE attributes directly from the EVSE 104 by one of the above methods, such as serial communication on the negative side pilot signal or power line carrier. In an exemplary embodiment, the EVSE attributes include network location, charging business model, unique EVSE ID, dynamic forward flow limit, dynamic backward flow limit, and emergency power indicator. .

In step 612, the EVE 102 establishes a local copy of attributes for the EVSE 104. In an exemplary embodiment, the VL 103 copies the attributes received from the EVSE into a copy of those attributes in memory 212.

At step 614, which is reached if the EVSE attributes are not available, the EVE 102 sets a local copy of the attributes for the EVSE to default values. In an exemplary embodiment, the VL 103 establishes the default values in the local memory 212; defaults may include attributes to allow vehicle charging, but not to allow vehicle emergency power or feedback.

In step 616, the EVE 102 sends EVE attributes to the EVSE 104. In an exemplary embodiment, the VL 103 sends the following exemplary attributes to the EVSE 104: (1) a unique identification of the vehicle integrated into the network, (2) billing and other business relationships, such as valid account numbers or authorization codes for electric purchase and parking time, (3) code compliance of this vehicle, such as IEEE 949 Certification for anti-islanding, and (4) technical capabilities of the vehicle, including maximum power output, whether it can produce power independently of the electrical grid ("emergency power mode"), and others, (5) if approved for delivery by an aggregation server, ( 6) guarantee (or not) of neutral when the power is provided by a vehicle, and (7) any account and authorization to credit for network services. At step 618, EVE 102 determines its operating parameters. In an exemplary embodiment, the VL 103 determines operating parameters, including charge and discharge power capacity, eg, in kilowatts, based on EVSE power capacity, EVE power capacity, EVSE attributes, kWh battery and state of charge and driving program. For example, an operating parameter, charge and discharge power capacity, may be determined in part by the current power level of the battery 110 ("battery power") and the additional power level required to charge the battery. 110 completely ("battery progress"). In step 620, the EVE 102 determines if the location of the EVSE 104 is known. In an exemplary embodiment, the VL 103 determines if the location information is present in the EVSE's attributes. If the location is known, processing continues at step 626. If the location is not known, processing proceeds to step 622.

At step 622, EVE 102 receives GPS data. In an exemplary embodiment, EVE 102 receives GPS location data from a conventional GPS receiver.

In step 624, the EVE 102 determines the location of the EVSE 104. In an exemplary embodiment, the VL 103 determines the location of the EVSE by comparing GPS data with locations known to the EVSE 104 and identifies the closest known location to the location data. GPS as the location of the EVSE 104. If the location has been inferred or based on GPS, the EVE sets a flag in memory 212 that the location is "uncertain", that is, That is, it may be less reliable than if it is set by EVSE attributes.

In step 626, the EVE 102 checks the authorizations. In an exemplary embodiment, the VL 103 processes authorizations by verifying the electricity bill or electric charge provider information identified in the EVSE attributes. If information about the electric account or electric charge provider is available, processing continues at block 628. Otherwise, EVE 102 identifies the authorization as uncertain at step 627.

In step 628, the EVE 102 processes the authorizations. In an exemplary embodiment, if the electric account provider or electric charge provider information is available in the EVSE, the VL 103 retrieves the account and authorization information and processes the information for payment, if necessary. If no account information was provided, but the location is known or inferred, and a building electric account is authorized at the location, the VL 103 can infer account information. In addition, the VL 103 can determine if additional authorizations have been received, for example, to use an aggregation server other than its normal aggregation server, if it is allowed to feed back, and if it is allowed to provide emergency power, for example, based on EVSE 104 attributes.

At step 630, EVE 102 will attempt to connect to an aggregation server 106, if authorized. In an exemplary embodiment, if the EVSE 104 requires the use of a local aggregation server and the vehicle user has authorized the use of a substitute aggregation server, then the VL 103 will attempt to connect to a local aggregation server. Otherwise, the VL 103 will try to use the normal aggregation server for the vehicle. At step 632, EVE 102 enables power flow. In an exemplary embodiment, the VL 103 enables power flow by instructing the PEM 204 through the VMS 206.

7 is a flow diagram 700 of exemplary steps for EVE 102 to interact with aggregation server 106 if connection to aggregation server 106 is established, or to operate autonomously if connection to aggregation server 106 is not established. the aggregation server. In either case, flowchart 700 shows how to manage power flow from the EVE 102 perspective.

In step 702, the EVE 102 determines if it is in communication with the aggregation server 106. In an exemplary embodiment, the VL 103 determines if there is communication with the aggregation server 106. If there is communication with the aggregation server 106, the processing proceeds to step 704. If there is no communication with the aggregation server 106, processing proceeds to step 726 with EVE 102 operating in a stand-alone mode.

In step 704, the EVE "communicates" with the aggregation server 106 to establish communication. In an exemplary embodiment, the VL 103 communicates with the aggregation server 106 to establish communication protocols and register its presence with the aggregation server 106. This request is processed by the aggregation server. See, for example, flow chart 1100, step 1106 described below.

In step 706, EVE 102 sends EVE operational parameters to aggregation server 106. In an exemplary embodiment, VL 103 may send EVE operational parameters to the aggregation server, including those calculated by VL 103, as well as copied from EVE attributes and those copied from EVSE attributes.

At step 708, EVE 102 synchronizes its driving schedule, also referred to as "next trip predictions." In an exemplary embodiment, the VL 103 and the aggregation server 106 each maintain a driving schedule for the vehicle that the EVE 102 is in. The driving schedule may be a prediction of future trips, based on human input and , optionally, computer predictions. In an exemplary embodiment, the human inputs are timestamped when entered, and the driving programs are synchronized such that, in the event of a conflict between the programs on EVE and those on the aggregation server, the human inputs override the most recent computer predictions and human inputs override previous inputs. In another exemplary embodiment not shown explicitly at step 708, if the aggregation server is not known and trusted, EVE 102 may restrict sending to a limited driving schedule, for example, sending only the next departure time to the aggregator. a parking attendant. At step 710, EVE 102 optionally transmits saved data to the aggregation server. In an exemplary embodiment, VL 103 checks data stored while EVE 102 was operating in a stand-alone mode, eg, due to a previous communication failure with aggregation server 106, described below with reference to steps 726-736. of flowchart 700. The stored data may include previously performed network or charging services stored in a record in memory 212 while the VL 103 was not in communication with the aggregation server 106.

At step 712, EVE 102 determines its available capacity. In an exemplary embodiment, the VL 103 determines the available power capacity based on the operating parameters of the EVE, in turn based on the battery power, battery advance, driving program, EVE attributes and EVSE attributes. The driving schedule can affect available capacity in several ways. For example, if the vehicle is scheduled to be driven in less than an hour a distance that would require 75% battery power, the VL 103 can determine that less than full power capacity is currently available or that there is no currently available capacity. In an exemplary embodiment, EVE 102 determines the effect on the battery of reaching and maintaining various charge levels (for example, based on battery manufacturer specifications) and bases available capacity calculations on charging the battery to a fair level. enough for the electric vehicle to make the planned trips determined according to the driving schedule, while minimizing battery wear, to prolong its useful life.

In step 714, EVE 102 reports its available capacity to aggregation server 106. In an exemplary embodiment, VL 103 reports available capacity to aggregation server 106.

In step 716, EVE 102 receives push signals from aggregation server 106. In an exemplary embodiment, VL 103 receives push signals from aggregation server 106. Push signals from aggregation server include requests for receive or supply power to the network 108. As indicated below with reference to flowchart 1300, steps 1304 and 1306, the aggregation server will not request power to or from vehicles at a capacity greater than indicated.

In step 718, EVE 102 controls the power flow between EVE 102 and network 108. In an exemplary embodiment, VL 103 controls power flow between EVE 102 and network 108 through EVSE 104 based on the send signal processed at 716. The power flow may be to or from the network 108.

At step 720, the EVE 102 measures the actual power flow. In an exemplary embodiment, VL 103 receives a power flow signal from PEM 204 indicating the actual power flow between EVE 102 and network 108. In another embodiment, VL directly measures power using power sensor 220. current and voltage from the PME 204, combining the two to calculate power.

At step 722, the EVE 102 reports the measured power flow. In an exemplary embodiment, the VL 103 reports the measured power flow to the aggregation server 106.

At step 724, the EVE 102 determines whether the response to the send should end. If not, processing continues at block 712 with an updated capacity report or block 716 with receipt of another send signal. If so, processing ends. Processing may end, for example, if EVE determines that it should switch to charging only, if there is a disconnect between EVE 102 and aggregation server 106, the vehicle is unplugged, there is a loss of network power, and/or an error occurs.

If the power flow is to continue, at step 725, the VL 103 determines whether to adjust the reported capacity at step 714. If the reported capacity is to be adjusted, processing may continue at step 712 periodically, eg, every 15 minutes, and/or in response to a discrepancy between the capacity specified in the send signal and the actual power measurements in step 720. If the reported capacity is not to be adjusted, processing may continue at step 716 periodically eg, every 5 minutes, and/or in response to an end time specified in the send signal received in step 716.

At step 726, which is reached if the EVE 102 cannot establish communication with the aggregation server 106, the EVE 102 enters an autonomous mode.

At step 728, the EVE 102 deactivates aggregation server control and activates autonomous control. In an exemplary embodiment, the VL 103 deactivates all network services controlled by aggregators and activates network services based on local information, for example, charging and providing services based on local detection, such as local frequency detection. and reactive power, or simply charging off-peak.

At step 729, EVE 102 determines whether to charge and/or what local services to provide. In an exemplary embodiment, the VL 103 decides to provide local network services, based on the EVE's operating parameters, including the EVSE attributes and the driving program in the VL's memory 212 by detecting local network conditions, such as frequency , voltage or reactive power. In another exemplary embodiment, the VL 103 may determine from the EVE operating parameters in memory 212 to set the charging current to zero and wait for off-peak electric rates, then charge to the charge needed for the next trip beginning when those rates take effect.

At step 730, the EVE 102 controls the flow of power (eg, charging or discharging). In an exemplary embodiment, the VL 103 is uploaded and downloaded based on the determinations made in step 729.

At step 732, EVE 102 optionally provides local network services.

At step 734, EVE 102 records the power flow transactions. In an exemplary embodiment, the VL 103 records all power flow and local network service transactions while the EVE 102 disconnects from the aggregation server 106 for later reporting when communication with the aggregation server 106 is established or re-established (see step 710).

At step 736, the EVE 102 ends the autonomous processing mode. In an exemplary embodiment, the VL 103 ends autonomous processing in response to reestablishing the connection to the aggregation server or by disconnecting the EVE 102 from the EVSE 104.

Figure 8 is a flowchart 800 of exemplary stages for supplying power from the EVE 102 in the event of a power outage.

At step 802, EVE 102 determines if there is loss of network power. In an exemplary embodiment, the PEM 204 detects power loss in a conventional manner and the VL 103 determines that there is a loss of network power through communication with the PEM 204. If there is a loss of network power , processing continues at step 804. Otherwise, VL 103 continues to periodically check for loss of network power, while performing the other processing steps of flowchart 700.

At step 804, EVE 102 stops power flow to network 108. In an exemplary embodiment, VL 103 immediately instructs PEM 104 not to supply power (this is a typical anti-islanding arrangement). This is done before any other processing and, in an exemplary embodiment, may be done at a lower level of hardware or by other means to ensure fail-safe cutting.

In step 806, the EVE 102 determines if the EVSE 104 authorized it for use in case of loss of network power, and if it has the capability to do so. In an exemplary embodiment, the VL 103 determines whether an attribute has been received from the EVSE indicating that the EVSE 104 is authorized to receive power (eg, it has been approved by an electrician with the appropriate equipment installed) in the event of power loss. of the network. If the EVSE 104 is authorized, processing continues at step 812. Otherwise, the VL 103 stops/will not supply power from the EVE 102 to the EVSE 104.

At step 808, the EVE 102 determines if the EVSE 104 is isolated from the network 108. In an exemplary embodiment, the VL 103 determines if the EVSE 104 is isolated based on a positive indication from the EVSE 104 or another device, e.g. example, a manual or automatic building isolator switch. If the EVSE 104 is isolated, processing continues at step 810. Otherwise, the VL 103 stops, or will not, supply power from the EVE 102 to the EVSE 104. Existing electrical codes require an isolation switch to isolate electrically the building loads from the dead network. These codes require this isolation from the 108 grid before starting an emergency generator to activate the building or load side. In an exemplary embodiment, the EVSE 104 processes the required insulation verification from the isolation switch, and indicates to the EVE 102 that it should subsequently be the source of electrical power generation.

A standard isolating switch, or a modified isolating switch, can be used to detect loss of mains power, to disconnect the building/house or load from the mains 108, and to signal that this isolation has been achieved by a labeled wire, for example, "starter generator" connected to the EVSE 104. The EVSE 104 can be configured for emergency power use by setting an attribute of the static EVSE, for example, "emergency power flag", which indicates that a qualified electrician has confirmed that the isolating switch is installed correctly, that it is properly connected to the EVSE 104, and possibly that a center tap transformer is provided as specified below. In addition, three dynamic attributes can be used to signal readiness to generate, for example, (1) dynamic EVSE attribute indicating that the "start generator" or similar isolator switch signal is on, (2) dynamic EVSE indicating that the center tap transformer is connected by contactors and (3) the dynamic EVSE attribute indicating that the currently plugged in vehicle is capable of this type of generating mode. As with other EVSE attributes, these static and dynamic attributes are transmitted to EVE 102. In an exemplary embodiment of the invention, EVE 102 will not command the vehicle to produce power unless these EVSE attributes are configured correctly, and unless the attribute indicating that the isolation switch is working remains on. For single-phase center-tapped neutral electrical connections, a 240V center-tapped inductor can be added to the EVSE 104, rated the same power as the EVSE's maximum circuit output. The center tap 240V inductor can be normally disconnected from the EVSE 104 via contactors or relays. When the on-grid vehicle provides emergency power, the inductor can be connected via the vehicle's 240VAC. This configuration allows a vehicle that provides 240 volts, but no center tapped neutral, to be fed into a building center tapped neutral electrical system. A person skilled in the art will understand from the description of this document how a three-phase building can similarly use a corresponding transformer in Y or Delta configuration.

In step 810, the EVE 102 provides power to the EVSE 104. In an exemplary embodiment, the VL 103 commands the PEM 204 to deliver power to the EVSE 104, for example, to feed the house in the event of a power outage, e.g. example.

At step 812, the EVE 102 determines whether to terminate the emergency power supply. In an exemplary embodiment, the VL 103 determines that the EVE 102 should stop supplying emergency power when a fault is detected, grid power or battery charge is detected to fall below a threshold, for example, below 15%. If EVE 102 determines that it should continue to supply emergency power, processing continues at step 806.

At step 814, the EVE 102 stops supplying power. In an exemplary embodiment, the VL 103 commands the PEM 204 to stop supplying, or not supplying, power from the EVE 102 to the EVSE 104. If the threshold due to low battery was reached, the VL 103 may additionally turn off the EVE 102 to conserve battery power.

Although embodiments of the invention are shown to control power to an on-grid vehicle, the VL 103 can be used to control other devices with storage capacity and with some predictability about the time that power needs to be drawn from storage. For example, embodiments of the invention can be applied to storage space heaters or storage furnaces, which similarly have predictable use (in cold weather) and can be loaded (with heat) by timing power input to provide services. network. In such embodiments, the heat storage may be configured such that only one-way electrical power flow is provided to the storage space heater, not the extraction of electricity from the heat storage. The EVE 102 operates as described in the present invention, with adaptations such as zeroing the reverse flow limit parameter, and instead of predicting battery capacity, time, and trip duration, the EVE 102 predicts the building or occupant needs for heating services such as space, heat, cooling, hot water, or clean dishes. Other building electricity uses that involve energy storage and therefore potential management, such as cooling or heating water, can be similarly controlled by the VL 103.

An exemplary algorithm for configuring the VL 103 within the EVE 102 to implement the steps described above with reference to Figures 6-8 is now provided.

EXEMPLARY MOVING ALGORITHM

Processing invoked when connecting the vehicle to the EVSE

Receive EVSE power capability via pilot signal

IF EVSE communications,

THEN get attributes from EVSE, send vehicle attributes to EVSE ELSE use default values for attributes

Calculate the charge and discharge power capacity in kW, based on EVSE power capacity, EVE power capacity, EVSE attributes, kWh, battery state of charge, driving schedule, etc.

IF network location in EVSE attributes

THENprocess the network location from the EVSE

ELSE get GPS location and infer or approximate location parameters

IF electric account, electric charge provider, etc. available in the EVSE THEN obtain the account and authorizations

ELSE make better inferences about the account, marked as uncertain Process EVSE authorizations that include:

Ok to collect, payment required/no, feedback allowed, action in case of network power loss, aggregation server required, local IP address

IF EVSE requires a local aggregator and the driver has authorized the substitution THEN attempt to communicate with the local aggregator server

ELSE attempt to use the vehicle's normal aggregation server IF connection to any aggregator is successful

THEN

connected mode(command and reports in real time),

if normal aggregator

THEN Allow private data transfers

ELSE restrict data transfers

ELSEStandalone mode(for example, log data)

Connected mode, when you are connected to the aggregator

Agreement with the aggregation server

Whether private data transfers are allowed

THEN Synchronize the driving program on the VL and the server aggregation

Transmit to the aggregation server any saved data about pre-loading or network services while offline

Determine the power capacity available now based on the drive schedule, EVE and EVSE attributes, etc.

Report power capacity to aggregation server

REPEAT

Receive the sending signal from the aggregator

Command the VMS to charge or discharge the battery

Measure the resulting power flow to/from the network

Inform the flow of power to the aggregator

Adjust the reported power capacity based on the previous n answers, the state of charge of the battery, etc.

UNTIL aggregator disconnected, vehicle disconnected, network power loss or failure

Standalone mode, connected to EVSE, but not connected to aggregation server Enter standalone mode

Deactivate all automatic generation control (AGC) services Activate network services based on local information, including

Charging, provision of services based on local detection,

e.g. local frequency detection and reactive power correction

REPEAT

Load/unload based on time of day, driving schedule and services

Provide local network services as possible

Log all transactions for later reporting when reconnected

UNTIL reconnect to aggregator or disconnect from EVSE

Processing in case of network power loss

Stop any power flow from the EVE to the grid (anti-islanding protection) IF NOT authorize local emergency power

THEN turn off vehicle power

ELSE REPEAT IF building isolation from network confirmed

THEN activate the building from the EVE

UNTIL fault OR building not isolated OR

mains power restored OR battery too low

END OF VL ALGORITHM

9 is a flowchart 900 of exemplary steps taken by the EVSE to manage power flow in accordance with aspects of the present invention.

In step 902, the EVSE 104 maintains the attributes of the EVSE. In an exemplary embodiment, maintenance of the EVSE attributes may include initialization of the static EVSE attributes and digital signature by authorized personnel, and updating of the dynamic EVSE attributes by the EVSE microprocessor 304.

In step 904, the EVSE 104 establishes communication with the EVE 102. In an exemplary embodiment, the EVSE 104 establishes communication with the VL 103 of the EVE 102. In step 906, the EVSE 104 transmits the maintained EVSE attributes to the EVE 102 In an exemplary embodiment, the EVSE 104 transmits the EVSE attributes to the VL 103 of the EVE 102.

10 is a flow diagram 1000 of exemplary stages for interfacing the EVSE 104 with the EVE 102 to manage power flow from the perspective of the EVSE 104.

At step 1002, the EVSE 104 detects a connection event. In an exemplary embodiment, the EVSE 104 detects the presence of an EVE 250 connector via a corresponding EVSE 104 connector 350, eg, based on a socket presence signal generated by the plug 350e. If a plugin is detected, processing proceeds to step 1004. Otherwise, the EVSE 104 continues to wait for a plugin event.

In step 1004, the EVSE 104 establishes communication with the EVE 102. In an exemplary embodiment, communication is established according to one of the methods described above.

In step 1006, the EVSE 104 transfers attributes. In an exemplary embodiment, microprocessor 304 retrieves EVSE attributes from the memory 306 and transmits the EVSE attributes to the VL 103. In addition, the EVSE 104 receives EVE attributes from the EVE 102 and stores them in the EVSE memory 306.

At step 1008, the EVSE 104 determines whether payment is required. If payment is not required, processing proceeds to step 1012. If payment is required, processing proceeds to step 1010.

In step 1010, the EVSE 104 determines if the charging is authorized. If the charge is authorized, for example, in response to an account number lookup, a card swipe, a coin deposit, etc., processing proceeds to step 1012. If the charge is not authorized, the EVSE 104 wait for authorization. In an exemplary embodiment, the EVSE 104 may alert the vehicle user if authorization is not received, for example, by sending a message to the EVE 102 for display to the driver within the vehicle or by displaying a message on a display (not shown) associated with the EVSE 104 and waiting for an alternative payment method.

At step 1012, the EVSE 104 activates the connector. In an exemplary embodiment, microprocessor 304 activates connector 350 by closing contactor 302. Optionally, EVSE 104 records power usage. In an exemplary embodiment, microprocessor 304 records usage during the time period that contactor 302 is closed. Also, if the network services are provided by a vehicle for parking privileges, the EVSE 104 can record this. The EVSE can also optionally report periodically to an electric charging provider.

At step 1014, the EVSE 104 deactivates the connector. In an exemplary embodiment, microprocessor 304 deactivates connector 350 by opening contactor 302. Optionally, EVSE 104 records recorded usage. In an exemplary embodiment, microprocessor 304 records usage recorded in memory 306. EVSE 104 may calculate total power flow transactions, eg, net energy usage, parking duration, etc.

In step 1016, the EVSE 104 transmits the recorded usage to an electric charging provider. In an exemplary embodiment, microprocessor 304 retrieves recorded usage from memory 306 and transmits it to the electric charge provider. In addition, the EVSE 104 can report the disconnection and calculated total power transaction information to the electric charging operator and the parking operator.

An exemplary algorithm for configuring the EVSE 104 to implement the steps described above with reference to Figure 10 is now provided.

EXEMPLARY EVSE CONNECTION ALGORITHM

In the exemplary embodiment, the EVSE communicates with the vehicle with the following three-part algorithm. Plugging in and unplugging the vehicle is done through events.

When connecting the vehicle

IF communications on the control cable (for example, serial coded, single-wire CAN bus or Ethernet)

THEN send the EVSE attributes to the VL and receive the EVE attributes

IF no payment required

THEN activate vehicle power

ELSE

Wait for authorization from the vehicle, local driver action (for example, card swipe, coin deposit) or authorization from the electric charge provider

authorized FI

THEN activate vehicle power

ELSE write a message to the driver and alert the parking operator

Upon successful activation of the vehicle

Provide a conduit for charging and/or network services, as authorized If the EVSE is metered

THEN periodically inform the electric charging provider IF the vehicle is providing network services for parking THEN periodically inform the parking operator When disconnecting the vehicle

Disable vehicle connector

IF the EVSE has metering, calculate the total transaction:

net energy use, parking time, etc.

Whether the EVSE has communications capability

THEN report the disconnection and the total transaction to the electric charge provider and the parking operator Wait for the connection of the next vehicle

END OF THE EVSE ALGORITHM

11 is a flowchart 1100 of exemplary steps for interfacing EVE 102 with aggregation server 106 to manage power flow from the perspective of aggregation server 106.

At step 1102, the aggregation server 106 starts up, and at step 1104, the aggregation server 106 loads the configuration parameters. In an exemplary embodiment, the aggregation server 106 loads from local storage DSO maps, a list of registered load locations (DSO location and accounts), a list of registered VLs 103 (with accounts), and, for each registered VL 103, account number(s), and last known driving schedule, also called expected next trips. In addition, the aggregation server can retrieve over the Internet from the TSO (network service buyers name, market rules and signaling rules), DSO (updated DSO circuit and system maps and switching states) and/or o IPP (generator status, generators that need storage resources).

In step 1106, the aggregation server 106 receives a connection request from a vehicle (ie, an incoming call request or a call back/reconnect request).

In step 1108, the aggregation server 106 receives the EVE operational parameters, including the EVE attributes. In an exemplary embodiment, the aggregation server 106 receives EVE operational parameters from the VL 103. In an exemplary embodiment, the EVE attributes include a unique EVE ID, a unique EVSE ID, and all operational parameters calculated in the steps 618 and 628 of the EVE algorithm.

In step 1110, the aggregation server 106 adds one or more of the EVE's attributes and the EVE's operational parameters. In an exemplary embodiment, aggregation server 106 aggregates power capacity, battery power, battery advance, and driving schedule information.

In step 1112, the aggregation server 106 predicts the total available capacity from an aggregate of one or more connected EVEs. In an exemplary embodiment, the aggregation server 106 predicts the total available capacity based on the power, progress, and schedule of each connected EVE. In an exemplary embodiment, aggregation server 106 identifies EVEs 102 that are likely to be available in particular time blocks, eg, 6 minutes, 10 minutes, 15 minutes, one hour, two hours, etc. The aggregation server 106 may choose not to use a vehicle that is scheduled to disconnect from the network 108 shortly after the scheduled block, for example, if the vehicle is scheduled for a trip on Monday at 2:10 pm. For future time blocks, the aggregation server 108 may also include the capacity of vehicles that are predicted to be available, based on the driving schedule, even if they are not online at the time step 1112 is performed. aggregation server 106 then adds the capacities of the vehicles that are available during each time block. For example, the aggregation server 106 may sum capacities such as power, battery charge, and battery advance for each available vehicle based on calendar information during a particular time period, for example, Monday between 2 a.m. and 3 p.m. For example, if there are 1,200 vehicles and 1,000 of them are expected to be available between 2 and 3 pm on Monday and each vehicle is capable, on average, of delivering 10 kW during that time period, the total power capacity planned would be 10 MW. The aggregation server 106 may further reduce the total capacity by a certain percentage, for example, 15%, to achieve a reliable power capacity offer while taking into account vehicles that may be disconnected during a block of time when its schedule indicates that they are available (ie unplanned and unforeseen trips). For example, the total capacity of 10 MW may be reduced to 8.5 MW as reported total available capacity. The percentage adjustment can be determined based on the aggregation server's historical ability to provide capacity to the network and the amount of penalty for not providing the offered capacity. For example, if the total available capacity is delivered 99.9 percent of the time when shipped, the reduction percentage can be reduced (for example, to 10 percent). On the other hand, if the total available capacity is not delivered 10 percent of the time when shipped, the reduction percentage can be increased (for example, to 25 percent).

At step 1114, the aggregation server identifies a market for the expected total available capacity. In an exemplary embodiment, the aggregation server 106 (or an operator thereof) analyzes the available market information to determine the highest available price for network services that can be filled using the aggregated EVE capacities for each time block. .

At step 1116, the aggregation server 106 offers the full available capacity to one or more identified markets.

At step 1118, the aggregation server 106 determines whether the network 108 accepted the full available capacity offered. If the offer is accepted by the network 108, processing continues at step 1120 with the recording of the total available capacity offered with the network 108 for delivery. Processing by the aggregation server may then proceed according to the steps of flowchart 1300 described with reference to Figure 13. If the offer is not accepted by the network, processing returns to step 1114 to identify another market.

12 depicts a flowchart 1200 of exemplary steps for removing an EVE 102 from network 108 from the perspective of the aggregation server 106.

At step 1202, the aggregation server 106 determines if the vehicle is still connected. In an exemplary embodiment, the aggregation server 106 determines that the vehicle is disconnected when communication with the VL 103 is lost or when no communications have been received for a threshold time period. If the vehicle is no longer connected, processing continues at step 1204. Otherwise, the aggregation server waits for the vehicle to disconnect while processing continues according to flowchart steps 1100 and 1300.

At step 1204, the aggregation server 106 removes the vehicle from the aggregation calculation at step 1110 (FIG. 11).

13 is a flow diagram 1300 of exemplary steps for sending the total available vehicle capacity from the perspective of the aggregation server 106.

At step 1302, the aggregation server 106 determines whether the network 108 has issued a send signal. In an exemplary embodiment, the network distribution signal is received from the TSO, DSO, or IPP. If the network 108 has issued a send signal, processing continues at step 1304. Otherwise, the aggregation server waits for a send signal.

In step 1304, the aggregation server 106 allocates the capacity to be distributed among the connected vehicles. For example, if the network send signal 108 requires 10,000 watts and there are 20 cars that have each indicated that they can supply 1000 watts, the aggregation server may allocate 500 watts to each of the connected vehicles. In more complete exemplary embodiments, the assignment may be based on other EVE attributes and operational parameters, including the driving schedule and network location.

In step 1306, the aggregation server 106 sends the vehicles to the allocated capacity of each vehicle. In an exemplary embodiment, the aggregation server 106 issues send orders to the VLs 103 according to the allocated capacities.

At step 1308, the aggregation server 106 received reports from the vehicles. Vehicle reports may include actual delivered watts, for example. If the actual delivered watts are below the allocated amount, the aggregation server may attempt to reallocate between vehicles in step 1304.

In step 1310, the aggregation server 106 sums the reports received in step 1308 and, in step 1312, sends the reports to the network 108, for example, to the network operator, such as TSO/, DSO, or IPP, who issued the shipment request.

At step 1314, the aggregation server 106 determines if the supplied aggregate power is sufficient to satisfy the send request. In an exemplary embodiment, the aggregation server compares the total allocated capacity with the actual capacity identified in the reports. If the shipment is sufficient, the processing proceeds to step 1302 for the next shipment. If sending is not enough, processing proceeds to block 1304 with aggregation server 106 attempting to reallocate available capacity to meet the amount sent from network 108. Over a longer period of time, eg 15 minutes at an hour according to market rules, insufficient delivery as determined in step 1314 will lead to a reduction in the capacity offered to the network in step 1116.

An exemplary algorithm for configuring the aggregation server 106 to implement the steps described above with reference to Figures 11-13 is now provided.

EXEMPLARY ALGORITHM FOR AN INTEGRATED NETWORK VEHICLE AGGREGATOR

The top-level description of the aggregation server consists of starting the server (boot) and three different operational loops. Each operating cycle gives the approximate time in parentheses. The three loops do not have to be exclusive, eg they can be executed concurrently with appropriate semaphores.

Server startup (when starting or loading a new program)

Upload from secondary storage (for example, from your hard drive):

DSO Maps

List of registered cargo locations, with location and DSO accounts List of registered VLs, with accounts

For each VL, account number(s) and last known driving schedule

External connection via the Internet and upload of the following:

TSO: Name of network service buyers and market/signaling rules.

DSO: Updated DSO system and circuit maps and status of switches

IPP: Generator status, generators that need storage resources

Loops to register and deregister vehicles/VL (event-driven)

When calling the VL to the aggregation server or redialing/reconnecting Receive and store locally the operating parameters of the VL:

Car ID, EVSE ID, Network location, Power capacity,

battery power (size and current state of charge), next expected use, range buffer, etc.

Calculate the time available for network services

Calculate the power capacity that this VL can offer, estimate how long

Include this VL in the aggregate capacity of the server

In case of connection loss of a VL that was previously connected Remove car capacity from server aggregate capacity Loop to plan and offer capacity (for example, hourly loop) Update vehicle capacity calculations

Aggregate capacity of all vehicles, by area

Run predictions, calculate firm capacity for the next hour or target period

Evaluate alternative potential markets

Determine the optimal market or the optimal number (n) of markets

Offer capacity to market(s)

IF offers are accepted,

THEN Record the accepted offer for submission

Return to top of loop "to plan and deliver capacity" Loop for dispatch (for example, a second loop)

Wait for the signal to be sent from the TSO, DSO or IPP

When sending the TSO/DSO/IPP signal

Assign the answer among the vehicles, considering all of:

Time of the next trip

Margin of error based on historical experience and evaluation algorithm Response assignment can be regional or local, for example, on correct TSO, local price node, substation, or distribution feeder

Send power through the command to each assigned VL

Receive the report of each VL in the allocation list

Sum VL reports, by region and local network locations

Update registered capacity if responses do not equal claimed capacity

Send a report on the aggregate power delivered to the TSO, DSO and/or IPP Return to "Wait for send signal"

Note: A variant of the shipping cycle is arbitration, which includes overnight collection. In this variant, shipping is done by price, time may not be critical, and reporting may be optional or delayed until the end of the accounting or billing period.

END OF AGGREGATION ALGORITHM

Although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications can be made to the details within the scope and interval defined in the claims.

Claims (14)

1. A method for aggregating electric power flow between the electric grid (108) and electric vehicles, comprising the method, in an aggregation server (106): receiving EVE electric vehicle equipment operating parameters (102) from each of a plurality of EVEs (102) via respective vehicle links (103), the received EVE operating parameters (102) comprising power capability charging and discharging based on the power capacity of the EVSE electric vehicle station equipment (104); add the received EVE (102) operating parameters; predicting a total available capacity based on the aggregated EVE (102) operating parameters; send at least a part of the total available capacity to the network (108); characterized by: predict trips for an electric vehicle associated with one of the plurality of EVEs (102) based on past use of the vehicle, the vehicle having a battery (202), and cause the battery (202) to charge in order to fulfill the planned trips. A method according to claim 1, wherein the received EVE operating parameters comprise a driving program of a vehicle associated with the respective EVE. A method according to claim 2, wherein the driving program is based on one or both of a computer prediction of future trips based on past vehicle use and user input of future trips. A method according to claim 1, comprising: determine an effect on the battery to achieve and maintain various charge levels; where the battery charge is at a level just sufficient for the electric vehicle to make the intended trips, while minimizing battery wear, to prolong battery life. A method according to any preceding claim, comprising: determining a current temperature of the battery; Y on the basis of the anticipated trips and the determined current temperature, preheat or precool at least a part of the electric vehicle. A method according to claim 5, wherein the electric vehicle part comprises the battery and its preheating or precooling is performed to prolong battery life. A method according to any preceding claim, wherein the received EVE operating parameters comprise a state of charge of the battery or a power capacity of the respective EVE. A method according to any preceding claim, comprising: offer the total planned available capacity to the network; receive a network delivery for at least a part of the total available capacity offered; Y assigning the network delivery to the plurality of the EVEs; wherein the sending comprises instructing each of the plurality of EVEs to send their respective assigned capacity for supply to the network. A method according to claim 8, comprising: receiving reports of the actual delivered power of the plurality of EVEs; sum received reports of actual supplied power; determining whether the summed actual delivered power matches the power requested by the network delivery; and in response to the summed actual delivered capacity that does not match the delivery request, adjusting the allocated capacity. A method according to any preceding claim, wherein predicting total available capacity comprises identifying EVEs that are likely to be available in a specific time block, and the method comprising choosing not to use one or more of the identified EVEs that are scheduled to disconnect after the specific time block. A method according to any preceding claim, wherein predicting the total available capacity comprises including the capacity of one or more additional EVEs that are scheduled to be available for the network but are not connected at the time of the prediction. A method according to any preceding claim, comprising reducing the predicted total available capacity by a certain percentage, wherein the certain percentage is determined based on the historical capacity of the aggregation server to provide capacity to the network. 13. A computer program comprising a set of instructions that, when executed by a computing device, causes the computing device to perform a method of adding a flow of electrical power between the electrical grid (108) and electric vehicles (102), understanding the method, in an aggregation server (106): receiving EVE electric vehicle equipment operating parameters (102) from each of a plurality of EVEs (102) via respective vehicle links (103), the received EVE operating parameters (102) comprising power capability charging and discharging based on the power capacity of the EVSE electric vehicle station equipment (104); add the received EVE (102) operating parameters; predicting a total available capacity based on the aggregated EVE (102) operating parameters; send at least a part of the total available capacity to the network (108); characterized by: predict trips for an electric vehicle associated with one of the plurality of EVEs (102) based on past use of the vehicle, the vehicle having a battery (202), and cause the battery (202) to charge in order to fulfill the planned trips. 14. An aggregation server (106) specially adapted to aggregate the electric power flow between the electrical network (108) and electric vehicles (102), the aggregation server (106) being configured to: receiving EVE electric vehicle equipment operating parameters (102) from each of a plurality of EVEs (102) via respective vehicle links (103), the received EVE operating parameters (102) comprising power capability charging and discharging based on the power capacity of the EVSE electric vehicle station equipment (104); add the received EVE (102) operating parameters; predicting a total available capacity based on the aggregated EVE (102) operating parameters; send at least a part of the total available capacity to the network (108); characterized in that the aggregation server is configured to: predict trips for an electric vehicle associated with one of the plurality of EVEs (102) based on past use of the vehicle, the vehicle having a battery (202), and cause the battery (202) to charge in order to fulfill the planned trips.