SYSTEM WITH CUSTOMIZED DATA MODELS

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to, and the benefit of, U.S. provisional patent application serial number 62/426,497 filed on November 26, 2017, incorporated herein by reference in its entirety.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[0002] This invention was made with Government support under 20101392 awarded by the U.S. Department of Energy. The Government has certain rights in the invention.

INCORPORATION-BY-REFERENCE OF

COMPUTER PROGRAM APPENDIX

Not Applicable

NOTICE OF MATERIAL SUBJECT TO COPYRIGHT PROTECTION

[0004] A portion of the material in this patent document may be subject to copyright protection under the copyright laws of the United States and of other countries. The owner of the copyright rights has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the United States Patent and Trademark Office publicly available file or records, but otherwise reserves all copyright rights whatsoever. The copyright owner does not hereby waive any of its rights to have this patent document maintained in secrecy, including without limitation its rights pursuant to 37 C. F.R. § 1 .14. BACKGROUND

[0005] 1 . Technical Field

[0006] The technology of this disclosure pertains generally to electrical vehicle (EV) charging infrastructures, and more particularly to a multiple- layer energy management system (EMS) which utilizes intelligent control strategies for electric vehicle charging.

[0007] 2. Background Discussion

[0008] Electric vehicles (EVs) can be viewed as mobile energy storage devices, which have the potential to provide grid-level regulation services. However, if not properly managed, the aggregated EV loads may degrade the power quality in local distribution networks, resulting in increasing operational costs for utilities. Moreover, the random nature of EV charging behaviors makes it difficult to manage the overall charging load profile, if the detailed time schedule preferences and energy demand from EV users are not provided in advance.

[0009] An EV aggregator model is proposed in the literature which monitors aggregated charging behaviors for EVs and performs real-time controls according to the regulation signals from the utility, wholesale Independent System Operator (ISO) market or third party organization. Thus, the regulation signal comes from a remote utility, ISO server or a third-party pricing service, and passes through an EV aggregator server, and is received at the lower hierarchical level of individual charging stations. Existing EV charging applications do not maximize power quality factor in the local distribution networks.

[0010] Accordingly, a need exists for a charging infrastructure which

maximizes benefits from an energy management system (EMS). The present disclosure fulfills that need and provides additional benefits over previous technologies.

BRIEF SUMMARY

[0011] This disclosure describes a multiple-layer (multi-layer) energy

management system (EMS) for electric vehicles with intelligent control strategies. Existing EV charging applications, such as those from

ChargePoint™, Inc. and EV Solution™ AeroVironment, allow users to manage their personal profiles and provide user interfaces to select their charging stations from a map. However, EV charging control has not been coupled with other grid-tied devices, including BESS and solar generations, and the like, while EV charging systems are treated as an isolated system without the capabilities to support complex grid regulation activities through either standard or proprietary protocols, such as OpenADR for demand response operations, and so forth. Thus, the benefits of proper EV charging management cannot be achieved by these existing architectures. In addition, users' preferences, including travel schedules, energy demands, and price sensitivities, or similar, are not captured by these existing systems.

[0012] In order to maximize the overall benefits of grid regulations, a multilayer hierarchical Energy Management System (EMS) with aggregated EV management portal, smart EV energy management process (algorithms), and integrated super control center (SCC) is necessary, toward performing efficient and reliable cooperative controls over Distributed Energy

Resources (DERs) in distribution grids. The intelligent controls at different levels, and diverse data models between each of the components lead to significantly improved system scalability, reliability and interoperability.

[0013] In one embodiment, there are three main components in the

disclosed hierarchical three-layer control architecture: (1 ) smart Electric Vehicle Supply Equipment (EVSE), (2) an electric vehicle (EV) aggregated control center (EVCC), and (3) an Integrated Super Control Center (iSCC). These components coordinate the energy management tasks in the distribution grids with different specified processes (e.g., algorithms), considering availabilities of other resources in a microgrid, including Battery Energy Storage System (BESS), renewable generation sources, and other resources.

[0014] The major benefit of a centralized iSCC is to implement intelligent energy management strategies with a holistic consideration of resources within the entire microgrid and the electricity market. Current multiplexing capabilities, which enable the split of charging current among different charging outlets under the same power source dynamically and intelligently, are used for the EVSEs implemented in this system. A communication network for all these components supports the complex operations. Energy management algorithms for electric vehicles within EVCC manage EV charging behaviors, consider user energy price preferences, travel schedules, and grid signals from iSCC, utilities, and third-party

organizations. For the entire energy management service, specific data models between different components support both the standardized and proprietary grid operations, such as demand response (DR).

[0015] Benefits for the disclosed technology include the following. (1 ) A multi-layer hierarchical energy management system improves the system efficiency, reliability and interoperability, considering availability of other Distributed Energy Resources(DERs) in the local distribution grid. (2) Customized data models between components in different layers support more flexible grid operations, such as demand response, and the like. (3) An adaptable (Application Program Interface) API with evolvable templates is provided for energy scheduling algorithms and EVSEs. (4) A price-based scheduling algorithm allows users to participate in the EV charging retail market based on external pricing signals, which not only saves energy cost for users but sheds (reduces) system peak load. (5) User-friendly mobile applications are provided for EV drivers with interfaces to initiate, terminate, and monitor charging sessions, as well as submitting personal energy management preferences.

[0016] Further aspects of the technology described herein will be brought out in the following portions of the specification, wherein the detailed description is for the purpose of fully disclosing preferred embodiments of the technology without placing limitations thereon. BRIEF DESCRIPTION OF THE SEVERAL VIEWS

OF THE DRAWING(S)

[0017] The technology described herein will be more fully understood by reference to the following drawings which are for illustrative purposes only:

[0018] FIG. 1 is a block diagram of system architecture according to an embodiment of the present disclosure.

[0019] FIG. 2A through FIG. 2D is a data model for Customized Demand Response Operation according to an embodiment of the present disclosure.

[0020] FIG. 3A and FIG. 3B are data types defined in an EV system API according to an embodiment of the present disclosure.

[0021] FIG. 4A through FIG. 4D is a model of EVSE classes block

according to an embodiment of the present disclosure.

[0022] FIG. 5A and FIG. 5B is an architecture and data model for

scheduling processes according to an embodiment of the present disclosure.

[0023] FIG. 6 is a flow diagram of a charging process according to an

embodiment of the present disclosure.

[0024] FIG. 7A and FIG. 7B is a screen image of a Super Control Center GUI according to an embodiment of the present disclosure.

[0025] FIG. 8 is a flow diagram of a manual operation process according to an embodiment of the present disclosure.

[0026] FIG. 9 is a flow diagram of an automatic operation process according to an embodiment of the present disclosure.

[0027] FIG. 10 is a network map of an example network architecture

according to an embodiment of the present disclosure.

[0028] FIG. 1 1 A and FIG. 1 1 B is a block diagram of an EV monitoring and control center according to an embodiment of the present disclosure.

[0029] FIG. 12A and FIG. 12B is a status screen of monitoring of EV user behaviors according to an embodiment of the present disclosure.

[0030] FIG. 13 is a status screen of monitoring a single EVSE according to an embodiment of the present disclosure. [0031] FIG. 14A through FIG. 14C are screen shots of a mobile application on iOS platform according to an embodiment of the present disclosure.

[0032] FIG. 15A through FIG. 15C are screen shots of a mobile application on Android Platform 1 according to an embodiment of the present disclosure.

[0033] FIG. 16A through FIG. 16C are screen shots of a mobile application on Android Platform 2 according to an embodiment of the present disclosure.

[0034] FIG. 17A and FIG. 17B is a flow diagram of a smart round-robin process for Level I according to an embodiment of the present disclosure.

[0035] FIG. 18A and FIG. 18B is a plot of experiment results for round-robin process as utilized according to an embodiment of the present disclosure.

[0036] FIG. 19 is a block diagram of a price-based process architecture according to an embodiment of the present disclosure.

[0037] FIG. 20A through FIG. 20C are screen shots of a price-based

process interface design according to an embodiment of the present disclosure.

[0038] FIG. 21 A and FIG. 21 B are flow diagrams of price-based processing according to embodiments of the present disclosure.

[0039] FIG. 22A through FIG. 22C is a flow diagram of account priority determination according to an embodiment of the present disclosure.

[0040] FIG. 23A and FIG. 23B is a plot of an experimental result using account priority according to an embodiment of the present disclosure.

[0041] FIG. 24A and FIG. 24B is a block diagram of a super control center (SCC) structure according to an embodiment of the present disclosure.

[0042] FIG. 25 is a flow diagram for executing DR events and prompting of new automatic decisions according to an embodiment of the present disclosure.

[0043] FIG. 26A and FIG. 26B are plots of SCC response as determined according to an embodiment of the present disclosure.

[0044] FIG. 27 is a block diagram of EVCC according to an embodiment of the present disclosure. [0045] FIG. 28A through FIG. 28C are bar plots of local EVCC scheduling based on solar power generation according to an embodiment of the present disclosure. DETAILED DESCRI PTION

[0046] The detailed description comprises a first section (Section 1 )

describing elements of the present disclosure for Multi-layer EV Energy Management, and a second section (Section 2) describing a two-tier energy management system for smart electric vehicle charging with a Solar-To- Vehicle (S2V) Case Study.

[0047] 1 . Introduction to a Multi-layer EV Energy Management

[0048] The technology described herein is a multi-layer energy

management system (EMS) for electric vehicles with intelligent control strategies. By way of example, and not of limitation, the system comprises the following three main components in a hierarchical three-layer control architecture: (1 ) smart Electric Vehicle Supply Equipment (EVSE), (2) an electric vehicle (EV) aggregated control center (EVCC), and (3) an

Integrated Super Control Center (iSCC). These components coordinate the energy management tasks in the distribution grids with different specified processes (e.g., algorithms), considering availabilities of other resources in microgrid, including Battery Energy Storage System (BESS), renewable generations, and other resources without limitation.

[0049] It should be appreciated that the term 'algorithm' as used herein does not refer to known mathematical abstractions, but to a process (e.g., combination of instruction execution and hardware actions such as switching on or setting a level of charge current) performed by hardware in specific layers of the EV charging infrastructure according to the teachings of the present disclosure.

[0050] 1 .1 .1 . System Components and Integration

[0051] FIG. 1 illustrates an example embodiment 10 of a hierarchical EV infrastructure system. The figure depicts an EV aggregator control center (EVCC) 12, which is shown receiving market information 14, and being coupled to an integrated super control center (iSCC)16, as well as to at least one renewable energy source, exemplified here as solar generation 20. EVCC is also shown coupled to a battery energy storage system (BESS) 22, as well as to different EV stations EVSE-1 24a, EVSE-2 24b through EVSE-n 24n, each shown interfacing through an EV charging application on a mobile device 26a, 26b through 26n of a user.

[0052] The first layer in the architecture is the integrated super control center (iSCC) 16 which communicates with a utility 18, such as through a DR signal. The second layer is the EV aggregator 12 and other distributed resources as seen above in a local distribution grid, such as solar PV generation 20, Battery Energy Storage System(BESS) 22, and the third layer is the physical devices, i.e., the Electric Vehicle Supply Equipment (EVSEs) 24a, 24b through 24n, with current multiplexing capabilities. EV drivers/users are able to monitor and control the charging sessions for their vehicles via mobile applications.

[0053] The iSCC performs management tasks considering both historical and real-time data for the main components in the whole microgrid.

Various processes can be implemented by iSCC to support microgrid regulation tasks, such as minimal EV power control, and similar EV control tasks. In addition, iSCC has interfaces to communicate with each of the other components in the microgrid, such as utilizing either standard and/or proprietary protocols. For instance, OpenADR2.0a and a customized DR protocol are both supported between iSCC and the EV control center to aggregately control the EV energy consumption.

[0054] By way of example and not limitation, on the UCLA campus, the EV aggregator control center manages both private EVs and public fleet EVs by real-time intelligent processes. The system is capable of retrieving market information, including energy price signals from the CAISO wholesale market, local utility or pricing services from third-party organizations, and pulling real-time power/status information from a myriad of EVSEs over the UCLA campus. Based on the EV communication network, the intelligent processes that consider user preferences, energy prices, and DR signals from iSCC, are implemented to perform more efficient management of EV charging behaviors.

[0055] The EVSEs in the third layer of the implemented system were

described in a prior patent applications by the UCLA Smart Grid Energy Research Center (SMERC). Current multiplexing and power sharing capabilities are supported by the circuit design in the EVSEs. In addition, network communication is also deployed in these devices to enable remote power monitoring and control functions.

[0056] Mobile applications are developed to satisfy the users by remotely and intelligently managing their charging sessions by their cell phone.

Various functions are supported within mobile applications, such as specifying travel preferences, energy preferences, looking for EVSE availabilities, checking real-time status and power information, and other preferences and functions which can be included without limitation.

[0057] 1 .2. Data Exchange Model

[0058] To increase system flexibility, multiple proprietary communication protocols and data models are developed. According to a least one embodiment, a data model for the communication between first layer and second layer is customized to include DR event parameters, exclusively for the parking structures and organizations. Similarly, the data model allowing communication between the second layer and third layer, is modified based on the combination of real-time power information and charger status information. The details of these models are discussed in the following section.

[0059] FIG. 2A through FIG. 2D illustrates an example embodiment 30 of records within a data model for the system, showing a format for station records, DR records, OpenADRE2.0 Event, and OpenADRE2.0 VEN List. It should be appreciated that the above records are shown by way of example and not limitation, and that additional records can be added depending on the various parties and elements involved in the EV charging process for a specific application. At each time interval, the raw data packet retrieved from EVSEs are first parsed by the data collector service on the EV control center. Subsequently, charger status information is retrieved and combined with the previous power information to be inserted into the database table with the data model shown in the figure. The advantage of the modified data model comes from three aspects: (1 ) completeness for power monitoring; (2) convenience for debugging and troubleshooting (such as fields in the data model); and (3) processing simplicity, for example labeling each data type with a timestamp, which makes it easier to process large volume monitoring data.

[0060] For the EV charging systems implemented in the UCLA campus and other organizations with different numbers of parking structures, there exist different needs to perform varied DR events in different parking lots.

However, the original data model definition from OpenADR2.0a and OpenADR2.0b, does not distinguish the signals for parking lots and organizations, which makes the system deployment less efficient and reliable in cases where load curtailment should be applied to specific locations. For the system implementation at UCLA, each parking lot is equipped with a different communication network, which requires different computation processes to handle power management for the EVs in different parking lots.

[0061] Thus, the original OpenADR data model, which is meant to specify the properties of a DR event, is extended to include the following parameters: (1 ) ParkingLotID, (2) OrganizationID, and (3) IsOpenADRVEN. In this way, the scheduling service and database system at the EV control center is able to handle requests based on both standard OpenADR protocol and the proprietary ones, in which parking lot ID, event start time, event stop time and strategy ID, determine which of different operation processes (algorithms) are to be performed by EV control center. With this added flexibility, iSCC is able to issue more detailed DR signals to adapt to diverse local grid situations. Therefore, the modified data model improves overall system flexibility and interoperability, especially in the case of implementations with multiple organizations. [0062] 1 .3. EV System Application Program Interface (API)

[0063] For monitoring and controlling the charging stations, the present disclosure provides an Application Program Interface (API) developed for the EV charging system, which defines the patterns of communication and control signals to the EV charging stations. The design of this API borrows from concepts in OOP (Object Oriented Programming). In this design, the complex communications and control behaviors of charging stations are generally seen as logically distinct classes; for instance, the EVSE class comprises the EVSEs and charging plugs of different levels, while a charging utility class provides functionality for web services and web-based applications, and additionally a Charging process (Algorithm) class regulates the charging behaviors within control loops. This format provides a convenient mechanism for developers to derive more EVSE and charging process (algorithm) classes with different properties and methods. This format can also save the time and energy of system administrators which are maintaining the EV charging system. In addition, the system also implements other modules for use by utilities, such as a security module that ensures incoming function calls meeting the security requirements of the system.

[0064] FIG. 3A and FIG. 3B illustrate an example embodiment 50 of data types defined in an EV system API. By way of example and not limitation, these types are depicted as StartStopChargingSuccessful,

ChangeDutyCycleSuccessful, MeterStatus, PluggedlnStatus,

ControlRelaySuccessful, ChargingLevel, RelayStatus,

RebootBoxSuccessful, SMERCSecurity, SMERCEmail,

SMERCEmailContent, SetLocalAlgorithmSuccessful, and

SMERCEnergyPrice. One of ordinary skill in the art will recognize that they can add additional types to the embodiment depending on the entities involved, the operations to be performed, and the specific application environment. It will be appreciated that physical and virtual devices are also modeled in this system API, involving all the possible status and values for the devices as shown in the figure. Enumerations and structures are used to include all the parameters in a low overhead manner. These data structures are available to be called by other functions or services that are built on top on the API.

[0065] In addition, each editor in the control center (e.g., Charging Box

Editor, Station Editor, and User Editor) has a corresponding data table in the database, which simplifies system maintenance. For instance, in most cases, the station controller and data collector services do not need to be manually restarted as the charging algorithm in the EVSE update parameters at every loop. The next sections provide a detailed description of the disclosed implementation of API .

[0066] 1 .3.1 . EVSE Class (charging box and charging station)

[0067] FIG. 4A through FIG. 4D illustrate an example embodiment 70 of EVSE classes and their interrelationships. The logical base class

SMERCChargingBox, which is shown in the figure, models an EVSE with basic properties and methods that transfer to inherited instances. The class specifies common attributes of EVSEs (e.g., gateway ID, gateway IP address, and parking lot ID) and control parameters for charging algorithms (e.g., power source properties, charging algorithm ID, and control loop interval). In addition, this embodiment includes a child-level class

SMERCChargingBoxGI , inherited from the base class, to add several new

EVSE-level functions, including enabling the local algorithm and retrieving the EVSE's power information utilizing various data formats. In at least one embodiment of the present disclosure, the system also distinguishes Level I and II EVSEs, by specifying power source parameters of higher values and the charging process (algorithm) ID when creating instances of the EVSE classes.

[0068] The base class SMERCStation defines common properties and

methods for all charging plugs in the system. The class includes general attributes that define a specific charging station (e.g., station ID, gateway ID, and power course ID) and attributes for charging processes (algorithms)

(e.g., controllable status, base main energy value, and start main energy value). As inheritors of the station base class, this embodiment also defines SMERCStationGI for a level 1 station and SMERCStationG2 for the level 2 station.

[0069] 1.3.2. Charging Process Design

[0070] A charging process (algorithm) performs a sequence of control commands at a specific charging station to regulate charging behaviors. These charging behaviors include starting and stopping charging sessions, retrieving power information and meter status, and adjusting charging power for an existing charging session to satisfy time-varying constraints, such as real-time electricity prices, availability of power supply, and the dynamic properties of EV drivers' traveling patterns. To accommodate such varying constraints requires implementing a flexible design for charging algorithms.

[0071] FIG. 5A and FIG. 5B illustrates an example embodiment 90 of

charging processes, exemplifying interaction between

SMERCChargingBoxGI MonitoringAlgorithm,

SMERCChargingBoxG1 Level2EqualChargingAlgorithm,

SMERCChargingBoxGI LeveH RoundRobinAlgorithm,

SMERCChargingBoxGI LeveHTimeScheduleAlgohthm, and

SMERCChargingBaseAlgonthms, which are shown by way of example and not limitation. The present disclosure implements charging processes (algorithms) that fall under two categories: the base class and current charging class, both of which are shown in the figure. The base class contains the methods for an algorithm to interact with the database, communicate with charging hardware via the communication networks, compute schedules based on constraints, and provide other business functions. Moreover, the parental charging algorithm, which is an algorithm template for child inheritance, provides basic parameter and function definitions, which make the whole algorithm class more adaptable and easier for maintenance. Therefore, embodiments of the present disclosure can use the base class template to create algorithms with varied purposes, each with its own distinct rules and logic. [0072] 1 .3.3. Service Design

[0073] FIG. 6 illustrates an example embodiment 1 10 of a charging

process. The system is configured for switching between different charging processes 1 12, and managing these processes and thread 1 14 with dynamic updates. These threads interact with windows services development 1 16 and an eventlog 1 18, which are directed to the windows installer design 120.

[0074] The implementation of a charging process (algorithm) preferably meets four requirements, and at least one embodiment of the present disclosure meets all four. First, the design switches between different charging processes (algorithms). Second, it dynamically updates parameters of the charging infrastructure. Third, it interacts with the database, which contains real-time information for the constraints. Fourth, the design allows for convenient updates and maintenance. In at least one embodiment a solution meeting these requirements utilizes a Windows

Service that ensures compatibility with the existing development environment.

[0075] As shown in FIG. 6, upon starting the service to manage EV

charging sessions, each EVSE assumes a unique system thread, which prevents interference between each EVSE. In other words, the thread to manage each charging box works independently and any exception in one particular charging box will not cause the whole system to crash, which improves the system's reliability. To monitor and keep track of any exceptions for the program, each thread has a function to send program exceptions to the system event log. This method allows the system administrator to monitor and verify the status of the charging service program. A separate installer project, designed for the server environment, deploys the service as an installer package.

[0076] 1 .4. Super Control Center (iSCC)

[0077] The iSCC has two main operating modes: Manual and Automatic.

Manual operation is implemented by the Energy Management System (EMS) operator or a utility operator in a higher priority level over automatic operation. The iSCC allows multiple to implement manual operations, in at least one embodiment these comprise two ways described as being through the Graphic User Interface (GUI) and OpenADR 2.0a Protocol.

[0078] FIG. 7A and FIG. 7B illustrates an example embodiment 130 of the iSCC GUI. The GUI serves as the general monitor for numerous elements in action within the microgrid, including current power condition and

Demand Response (DR) events. It also offers the most comprehensive functions to fine-tune the system as well as the choice of automatic processes (algorithms). Current aggregated PS level power for the past one hour are plotted at the top. This is followed by an interface to switch the operation mode (manual and automatic). Individual PS level power can also be managed manually by selecting the load to shed.

[0079] FIG. 8 illustrates an example embodiment 150 of executing manual operations and OpenADR commands. API calls, such as these, are used for real-time/emergency demand/response (DR) signals or to schedule any event in advance, whether it is day-ahead or any-time-ahead. Manual operations have higher priority than automatic DR algorithms, so any manual action overrides the current decision made by the automatic algorithm. In the GUI, a user can directly select any entity to perform DR, define start and stop times and send DR signals directly to the controller through browser.

[0080] A GUI 152 is seen as the access mode for manual operations 154, while alternatively OpenADR 2.0a API 156 through an access port for OpenADR controller 158 is seen. The entity is selected 160 as either Battery Energy Storage System (BESS) 162 or an EV Charging station 172.

For BESS a current is selected 164 (zero for idle) to either charge 166 or discharge 168 manually to end manual operations 170. For the EV

Charging Station 172, a selection is made of either minimum output 174, load cut by kW 176, or to resume 178, after which a success message is sent 180 before the end of manual operations 170.

[0081] The automatic algorithm mode operates based on current grid

conditions. In this use case, the process (algorithm) monitors whether the total consumption level of a PS exceeds a predefined value. If so, it issues an automatic DR signal to iSCC to suppress the charging event in that PS. The automatic process (algorithm) can be initiated by a pre-defined length of time interval, for example 5 minutes, or any selected time interval.

[0082] FIG. 9 illustrates an example embodiment 190 of real-time automatic operations. The process flow takes into account any DR scheduled in advance and has the capability to overturn such decisions based on the real-time situation. All automatic processes (algorithms) have lower priority than manual decisions, so a new decision made by the process cannot override existing manual operations. All automatic processes, however, have the same priority.

[0083] A backend program 192 access mode is performed to reach the automatic process 194 which selects 196 the current algorithm (process) from multiple choices, exemplified as a First Algorithm (Process) 198, a Second Algorithm (Process) 200, and a Third Algorithm (Process) 202. In each of these instances entities are checked 204 for enrollment in the DR program. After the check passes, the current process (algorithm) is executed 206 and there is either No Change 208, or a Change/new

Decision 210 is reached and the previous operator is checked 212 as either manual or automatic. For the automatic process (algorithm), block 214 is reached and a new decision reached 216. For manual operation block 218 is reached and no action is taken 220.

[0084] 1 .5. EV Charging Monitoring & Control Center

[0085] In this section, the detail setup, configuration, network structure and so forth are described as based on our previous patent application(s).

Various communication networks have been tested and an optimal communication architecture designed which is based on the specific characteristics of the parking structures. By way of example and not limitation, multiple communication protocols are involved in this network architecture, i.e., Wi-Fi, 3G, ZigBee, or other digital communication protocols as desired. The WINSmartEVTM EV charging network utilizes a centralized control system to monitor and regulate the network for real-time smart charging services. This smart charging infrastructure uses standard networking technologies to create a network that facilitates charging services for the end users and monitors and controls tasks for maintainers and operators. The charging services are completely adaptable by way of local or remote charging processes (algorithms). In addition, the architecture incorporates multiplexing capabilities with a unique safety system that integrates safety on all levels of control.

[0086] FIG. 10 illustrates an example embodiment 230 of a network

architecture as implemented for the UCLA campus network, with the EV communication network utilizing campus Ethernet, PLC, Wi-Fi or 3G/4G service to connect with ZigBee communication gateways which in turns connects with each individual EV charging station through the ZigBee communications protocol. The web server and database server receive and send data through these hierarchical network connections. The mobile devices interact with the EV network through connection with 3G/4G or the UCLA campus network.

[0087] FIG. 1 1 A and FIG. 1 1 B illustrate an example embodiment 270 of an EV monitoring and control center. The SMERC Monitoring and Control Center is a high performance server that allows administrators and operators to monitor and control all EV charging stations registered to the network. The system defines control algorithms, provides real time and historical data for analysis, and allows the editing of information pertaining to charging boxes (charging stations) and EVs. By way of example and not limitation, the sitemap depicted in the figure shows the current features that are accessible after logging in.

[0088] FIG. 12A and FIG. 12B illustrate an example embodiment 290 of a monitoring page for the EV charging behaviors at UCLA campus that can be utilized for showing real-time charging events. The EV info and the corresponding EVSE where this user's vehicle is being charged is shown. The user names are blocked in this figure for the sake of privacy. The available charging stations are depicted as displaying "Standby".

Meanwhile, the real-time charging power, voltage, current and the accumulated energy consumed for the particular meter are recorded.

[0089] FIG. 13 illustrates an example embodiment 310 of a status screen which has been developed to provide a more detailed visualization of charging behaviors at the EVSE level. In the figure, two charging sessions (current waveform at left and at right) can be identified, including the time when the session initiated and the power consumption value while the vehicle is in charging.

[0090] 1 .6. EV Charging Mobile Application

[0091] FIG. 14A through FIG. 14C illustrates an example embodiment generating status screens 330, 350, 370. When an EV is plugged into an

EV charger, the user can activate a charging session through a smart phone or any Internet-connected device. Once activated, power consumption information is obtained through the EV network mentioned in Use Case #1 . If a vehicle is equipped with the State of Charge (SOC) box, the SOC information is also obtained. For the sake of example, these operations are illustrated by the screen shots taken from the mobile application interface in the figures shown.

[0092] Other than the web-based mobile App for users to manage their charging sessions, an iOS version is being developed, which is supposed to offer a better user experience, including responsive touch controls and more interactive actions. It should be appreciated that any operating system, platform, communications protocols can be supported without departing from the teachings of the present disclosure. Based on the library of Swift languages provided by Apple, more functions, such as Navigation to charging stations, will be designed to provide more convenience for EV users. Similar to the web-based Application, the control and display logic guide users to input their charging preferences step by step.

[0093] In FIG. 14A a screen is shown which is displayed after a user logs on through the application (App), the modified home view is presented.

Navigation is a very significant function of the system, which automatically provide links as seen in FIG. 14B and FIG. 14C for each parking lot at UCLA with SMERC charging EVSEs and build connections with the Apple map navigation system. Thus, users are able to follow the highlighted routes on the map to reach and initiate their charging sessions.

[0094] The notification services inform the users about the status change of their charging sessions. For example, the email with the charging information, including total energy consumed, charging cost and the charging location information, is sent to users after a session.

[0095] The typical procedure to initiate a charging session is described as follows: (1 ) account log-in; (2) select available organization; (3) select available parking structure; (4) select/input charging preferences; (5) start charging session by selecting available charging outlet (and/or station); and (6) check charging status.

[0096] It should be noted that for the users who have existing charging records in the system, selections of organization, parking structure, and even charging preferences, are automatically performed by the system if the user has selected that preference.

[0097] FIG. 15A through FIG. 15C, and FIG. 16A through FIG. 16C,

illustrate example embodiments which generate interface screens. In this example embodiment a home screen 390 is shown in FIG. 15A allowing the selection of stations status, charge, status, map of stations, records, feedback, settings, kiosk settings and a user manual. A station status screen 410 in FIG. 15B depicts the lot and floor number of the parking facility and the stations therein, depicting status as available, offline, disabled, and whether there is a plugin. A charge screen 430 in FIG. 15C depicts information regarding a charging session, exemplified as organization, lot, charging box (station), electric vehicle selection, remaining miles, and prioritized charging selections. Interaction with the charge screen is seen in embodiment 450 of FIG. 16A with the user selecting a lot based on a drop down list. Embodiment 470 in FIG. 16C a status screen is seen for a charging session, showing status, power consumption, cost, energy consumed, DR availability, carbon emissions level, plug-in availability, and vehicle parameters. Embodiment 490 in FIG. 16C illustrates station maps, showing charging stations in the vicinity, depicted in this example as being on the UCLA campus, allowing a user to select a station and obtain driving directions to reach the selected charging station. By way of example these interface screens (GUI) are depicted as directed to mobile applications on Android devices, although other platforms (e.g., Apple, Google, etc.) can be supported without departing from the present disclosure.

[0098] 1 .7. Energy Management Service - Smart Control Strategies

[0099] 1 .7.1 . Smart Round-robin for Level I

[00100] FIG. 17A and FIG. 17B illustrate an example embodiment 510 of a round-robin control process. The depicted process (algorithm), executes (runs) the server side, on-site kiosk system that monitors and controls one or more EVSEs, or on the EVSE, and is used for a level 1 EVSE that has at least one power source and one charging station.

[00101] The process starts 512 and the box's stations are grouped 514 by power source prior to entering the loop at 516. Information is retrieved 522 from all stations, including power and status information, which is saved to the database. If the retrieval of information and saving is not successful, then the loop is stopped at block 520, and a sleep state 518 entered while waiting for the next loop start time 516. Otherwise if the retrieval and saving is successful then a check is made at block 524 if the start is for DR or AC. If it is for DR or AC, then execution moves to loop stop 520. Otherwise, if not DR or AC, then a check is made 526 for No Group. If no group, then execution again reaches loop stop 520; otherwise a check 528 is made to find the next group. If the next group is not found, then execution again reaches loop stop 520. Otherwise, if a next group is found then execution reaches block 530 which retrieves all unclosed charging sessions of the selected group with charging session sorted by start time, and is followed by a check 532 to find unclosed charging sessions, after which a check is made 534 for charging stations that are active (on). If no charging stations are found on, then block 535 is reached, which searches for proposed charging sessions with the lowest charging times, or selects the first charging session in the list, or selects a proposed charging session according to another desired metric. After selecting a charging session, then block 548 is reached to turn on the selected charging station for that charging session.

[00102] Returning to decision block 534, if the charging station is on then a check is made at block 536 if the charging's current exceeds the threshold. If current is below the charging threshold, then at block 538 the station is turned off which closes the charging session and sends a close charging session email to the user, and then reaches block 546 to find the next unclosed charging session, and if the previous charging session is the last one, then the next charging session will be the first charging session in the list. At this time block 548 is reached to turn on the charging station for the selected charging session.

[00103] Returning to block 536, if the current exceeds the threshold, then a check is made 540 for only one unclosed charging, and the time of station on equals or exceeds the box time quantum 542. If this check is yes, then block 544 is reached which turns off the station and moves to block 546 to find the next unclosed charging session.

[00104] A station must only be connected to one power source that can

connect 0, 1 , or more stations. Also, in this class of charger every power source of the EVSE can charge only one EV at a time. For example, an EVSE has four stations and two power sources. Stations 1 and 4 share power source 1 , while stations 2 and 3 share power source 2. The algorithm can handle any possible combination of stations to power sources. EV users can plug their EVs into any available stations and the algorithm will start and stop the charging session automatically. The process (algorithm) group the EVSE's stations by their power source(s) and sorts every group's station(s) by the station name or ID.

[00105] Every power source associates with a station group that may have 0, 1 or more stations. Therefore, the number of power sources in the EVSE must be equivalent to the number of station groups. This setup allows every station in the same group to provide power to the EV when the vehicle is plugged-in, provided that the EV's battery is not full via the group's round-robin charge process and every station group has its independent round-robin charge process which is based on the group's power source, stations, and plugged-in EVs. The multiplexed round-robin charging process affects every station and the charging cycle of the plugged-in EV, and it is used in cases when EV users do not need to submit charging requests.

] FIG. 18A and FIG. 18B illustrate an example embodiment 550 of on/off control of four level 1 (120 VAC) EV charging stations in the control center. The control center alternatively turns the charging station on and off using a round robin charging process (algorithm). Specifically, the waveform 552a represents the first vehicle to consume power from this level I EVSE. Then the second vehicle 554a and third vehicle 556a start charging one by one because the smart round robin algorithm assigns time slots dynamically to different vehicles according to their start time. Thus, periodically, all the vehicles are sharing the same charging time ratio, which is defined as the charging time for each vehicle divided by time unit (e.g., 1 hour). Thus, the figure shows the first vehicle charging 552a, 552b, 552c and at 552d. The figure shows the second vehicle charging 554a, 554b and finishing at 554c. The figure shows the third vehicle charging 556a and at 556b. As is seen as time progress, the third vehicle finished charging and the charging currents drops below the predefined threshold, the scheduling process (algorithm) closes this charging session and then reinitiates charging for the first vehicle. Subsequently, the first and second vehicles complete their charging. Interestingly, the scheduling cannot determine the completeness of the charging process, so it will re-initiate the charging for the first vehicle until the current drops quickly, which can be identified as a fully-charged battery. In this way, the fairness among users and reliability can be guaranteed. After disconnecting the first vehicle, the second vehicle starts charging normally. [00107] 1 .7.2. Price-based Charging Algorithm for Level I and Level II

[00108] FIG. 19 illustrates an example embodiment 570 of an EV charging infrastructure developed by UCLA SMERC having the capability to implement advanced smart charging processes (algorithms) through mobile interfaces, based on the network platform WINSmartGridTM. Specific user interfaces are designed to support the input and modification of user preferences, such as electricity price and travel schedule preferences. On the server side, corresponding scheduling process (algorithms) dynamically allocate charging power to each connected vehicle according to different user preferences. Real-time power consumption data is monitored and displayed in the EV control center.

[00109] FIG. 20A through FIG. 20C illustrate an example embodiment

showing generating mobile interface screens 590, 595 and 600. After making a selection of specific chargers, users see the options for a price- bid charging process (algorithm), which includes price preferences with multiple level, shown by way of example as five available levels, and a travel schedule input. The feedback is displayed as a notice on the interface with estimated energy consumption and the equivalent miles. Finally, users can start charging by clicking one of the charging outlet icons.

[00110] One of the implemented algorithms is a price-bid process

(algorithm), which incorporates the dynamic electricity price information from the wholesale market and the additional values for Level I and Level II charging infrastructures. Accordingly, a daily price curve is sliced into multiple levels, exemplified in this embodiment as five levels: High,

Medium-High, Medium, Medium-Low and Low, which are displayed through the mobile interface after a user selects a specific charging station. The price level selection is assumed to indicate a user price preference, i.e., the willingness to pay for unit of energy at specific price level. In addition, users, with higher price levels, are granted with higher priority when sharing the circuit with a limited power supply. ] 1 .7.2.1 . Level I

] In this case, the Level I charging infrastructure developed by UCLA SMERC has multiple (e.g., 4) charging outlets and one power supply. Only one active charging session is allowed at the same time and accordingly the dynamic switch will take place dynamically to accommodate more users. Each level I EVSE in this example has four outlets and only one power source. Meanwhile, only one vehicle is allowed to charge at a time due to the inner circuit's design. Thus, the policy is to determine the timing to switch from one vehicle to another according to users' preferences and priorities. An accepted price threshold is selected before users submit a request for a charging session, which is assumed to reflect how urgent he/she needs to charge. As a result, a charging session with a higher price has higher priority and is able to consume more energy within every time quantum (period). The criteria for the process (algorithm) for switching charging sessions is:

Τ ₁ > (Ρ ₁ /∑Ρ ₁ ) · ΔΤ = γ ₁ · ΔΤ

i=l

where T _j is continuous charging time, since the last time of activation; P _j is the price selected by i _th user; and ΔΤ is the time quantum, denoting the time span of EVSE control loop. The value _{ is defined as a priority coefficient according to bids provided by users for current the EVSE.

] For level I EVSE, after each control loop starts, the process

(algorithm) selects active charging sessions for the current EVSE from the database, and sorts them by their accepted prices and departure times. Only the charging sessions whose prices agree with user price preferences can be retrieved. It is assumed that EV drivers with higher accepted prices and earlier departure times have urgent need for energy and are thus the system gives them higher priorities than others. To guarantee that the energy assigned among users in each time quantum (period) is proportional to their priorities, the algorithm calculates priority coefficient _{ and the continuous charging time T _j in each control loop. If the current charging session has used up its portion of charging time in the current time quantum (period), the process (algorithm) switches from this charging session to a lower priority one from the charging session list.

[00114] 1 .7.2.2. Level II

[00115] The following describes charging based on a different charge station design, that is for a Level II charging infrastructure, which allows multiple vehicle charging sessions simultaneously. By way of example and not limitation, this embodiment describes the use of a maximum of four vehicles charging at the same time, while sharing the same power source. The price-based charging process (algorithm) is also implemented. The price generation is similar to that used for the level I charging process

(algorithm), but the additional values added upon the wholesale prices are larger, in this example, 20 cents/kWh. Moreover, the users with higher selected prices are allocated with higher percentages of power being output from the limited supply. The control is implemented by dynamically adjusting the duty-cycles assigned to different charging outlets.

[00116] The scenario for a level II EVSE is different, because it has a larger power supply with the ability to multiplex current. The EVSE selected for implementation has a single power source (240V, 30A). Multiple outlets

(stations) can charge at the same time, but in this example the current for each outlet should be between 5A (10% duty cycle) to 30A (50% duty cycle). Accordingly, the algorithm will determine the energy sharing policy in a current multiplexing manner. To determine each participating vehicle's charging duty cycle (DC), a two-step process is conducted. The first determination (calculation) rules out the vehicles whose duty cycle values are lower than 10%, and the second calculation reallocates the source current.

n

D j = Imax ^■ (Pj / ^ Pj ) = Imax ^■ Yj

i=l where j _{ denotes the priority coefficient, which is defined as γ _; = Pi/ Pi■ i=l

[00117] For level II EVSE, priority coefficients and a corresponding duty

cycle are calculated in a two-step manner. In the first step, the charging session is temporarily disabled if the duty cycle calculated is lower than 10% or the user accepted price is lower than the current price. Then, after ruling out the unqualified charging sessions, the process (algorithm) reallocates the power source to each remaining session in proportion with its priority coefficient. The charging sessions is closed if the current is lower than the threshold or the schedule's deadline is reached.

[00118] FIG. 21A and FIG. 21 B illustrate example embodiments 610, 650, for the level I and level II, respectively, algorithms. In FIG. 21 A the control loop starts 612 and retrieves 614 PriceCurve, Power Info, and meter status, then sorts 616 charging sessions into lists by user price and schedule

preferences, while disabling unqualified sessions temporarily. A check is made at block 618 for ongoing charging in L . If no ongoing charging is found, then block 620 selects the next available session L _j , and turns on

622 charging for L _j , then updates session information for L before ending the loop 624. Otherwise, if there are ongoing charging sessions found at block 618, then a priority coefficient _{ is determined 626 as well as continuous charging time T _j . A check is then made at block 628 for the end of the session. If the session is not completed, then the end of the loop is reached 624, otherwise at block 630 the sessions are turned off and the session information is updated.

[00119] In FIG. 21 B the control loop starts 652 and retrieves 654 PriceCurve, Power Info, and meter status, then sorts 656 charging sessions into lists by user price and schedule preferences, while disabling unqualified sessions temporarily. At block 658 a priority coefficient _{ is determined as well as duty cycle values DC _j for all active sessions. A check is then made at block 660 if any DC _j is less than a desired threshold, exemplified here at being 10%. If it is less than the threshold level, then at block 662 the low priority charging session is temporarily disabled with session information updated, and the return to block 658. Otherwise, if there are no DC _j less than the desired threshold then block 664 is reached which determines ADC _j for all qualified sessions, sorts session list L by ADC _j , and assigns new duty cycle for each outlet. A check is then made 666 to determine if the session is completed. If it is completed, then block 668 is executed to turn off the session and update session information, and in either case to then end the loop 670.

[00120] 1 .7.3. Priority Charging Algorithm for Level II

[00121 ] FIG. 22A through FIG. 22C illustrates an example embodiment 690 of determining account priority in charging. In order to make the charging system more flexible and more intelligent, a priority charging process (algorithm) was developed in the present disclosure which allocates energy based on user profiles. The general idea of this process (algorithm) is to grant different users with different account priorities, which can be related to their roles (operator, maintainer, or normal users) and the types of EVs. Tentatively, each user is assigned with a priority from multiple priority levels, for example assigned a starting priority level between 1 and 10. According to these priorities, an energy sharing policy is made. For instance, if two EVs with priority 2 and priority 4 are connected, the tentative percentage of duty-cycle allocated for the vehicle with priority 2 is:

^D EV1 = X ^{1 00} % X Dsource where D _source is the maximum duty-cycle (50% in this case) for Level II

EVSE power source. After the first-round power source allocation, however, the tentative Duty-cycle could be lower than 10%, which is the minimum duty-cycle allowed by the hardware in this example embodiment, although systems can establish their own desired threshold for the minimum allowed duty-cycle. Thus, this specific outlet is not considered during the second-round power allocation, which guarantees that the charging duty-cycle is within the allowable range. After assigning the valid charging power, the scheduling process (algorithm) monitors power consumption and makes adjustments once triggering events are detected, such as new vehicle arrival, departure or finishing of charging sessions.

[00122] In particular, the flow of FIG. 22 starts 692, reaches a loop start 694 and creates 696 a representation of the box and station, followed by retrieving 698 station information including power and status and saves this into a database. If this is not successful, then loop stop 700 is reached and a sleep mode 702 entered waiting for the next loop start 694. Otherwise if operation 698 is successful, then all power information is saved 704 into the database and a check 706 made to determine if this is DR or AC. If it is DR or AC, then execution moves to loop stop 700, and waiting 702 for next loop start 694. Otherwise if at block 706, it is not DR or AC, then each unclosed charging sessions current and plug in status are checked 708. If at block 710 it is determined that the current level is below a threshold or the plug in is off, then block 712 is reached which closes the charging session after double checking, and notifies the user of the end of the charging session. In either case, decision block 714 is reached which checks user touch actions within a given period of time, and if touch action so indicates, then loop stop 700 is reached. Otherwise, at block 716 stations are grouped by power source number, and then at 718 for each group unclosed charging information is selected and put into table dtGroup, then at block 720 first and second rounds of resource allocation are performed and schedule updated.

[00123] Decision block 722 is reached which determines if the next duty cycle is zero and pre-duty cycle is not zero. If the above is not true, then block 724 is reached to check if next duty cycle is zero and pre-duty cycle is zero. If this check is true, then charging is turned on at block 726 and execution moves to block 730. If the determination at block 722 is true, then all charging is turned off at block 728 and decision 730 is reached to detect if any on/off actions exist. If there are on/off actions, then at block 732 power and station information are retrieved and a check made 734 if that was successful. If not successful, then execution reaches loop stop 700, otherwise if it was successful, then a check made 736 to determine for each dtGroup if the pre-duty cycle is not equal to the current duty cycle. If these are not equal, then block 738 is reached which changes the duty cycle before proceeding to loop stop 700.

[00124] FIG. 23A and FIG. 23B illustrates an example embodiment 750 of using the above account priority mechanism. For this process (algorithm), experiments have been conducted to test customer reactions and hardware reliability. Charging power waveforms for different charging sessions are seen in the figure, with a charge session at a first charge outlet 752 shown at a high level of charge, until a charge session at a second charge outlet 754, which shares the station power with the first charge session, commences at which time both first and second charge sessions are provided the same level of power. A session commences 756 at a third charge outlet given a high level of charge. At about this time the priority of the charging session on the second outlet is increased, wherein an adjustment 758 is made to charge current at first charge outlet 752 increasing its current level until charging is completed, at which time the first charging session receives a large charge current level, and the third charge session again receives power.

[00125] As indicated in the flow chart, the current allocated to each charging outlet is monotonically related to the users' account priories. The corresponding value of Duty-cycle values sent to each outlet in the EVSE can be determined accordingly. As shown in the figure, charging station (outlet) one and two are under the same power source, thus it is necessary to split the charging current appropriately due to their account priorities. Originally, the user session at the first outlet has the same priority as the user session at the second outlet. However, the user account priority associated with the second outlet charging session was increased around 4: 15 pm, thus the current allocated to charging this second outlet was increased to a higher level, until the vehicle's battery was fully charged. After user charging session on the second outlet having the increased priority finishes its charging, the charging capacity for the power source is totally occupied by the user charging session connected to the first outlet.

[00126] 2. Introduction to a Two-Tier EMS for EV Charging at UCLA

[00127] 2.1 . Background on the Approach

[00128] Microgrid, as one of the major components in the next generation smart grid technology, is a smarter solution for local community and a pioneer field for larger scale smart grid application. The missions for an aggregator of the microgrid include: (1 ) maintaining a stable and healthy grid load profile; (2) purchasing electricity at a reasonable price according to user demand; and (3) providing reliable and functional services to customers.

[00129] Therefore, the capability of an aggregator to make smart decisions to adjust the energy consumption of its own entities and to purchase energy accordingly has become a vital component of the next generation microgrid and smart grid technology. Integrating these loads introduces unique challenges to the system that implements the control and management of the grid, i.e., Energy Management System (EMS). A microgrid EMS can be significantly different from the EMS used in conventional power systems due to these challenges.

[00130] Many microgrid controller frameworks have been investigated in the literature. While these previous studies have each had a different focus, they commonly suffer from engineering challenges that should be taken into consideration for future EMS designs. The main issues are categorized as follows. (1 ) Intermittency and variability of the distributed energy resources (e.g., photovoltaic generations) and spatiotemporal (space and time) uncertainty in controllable loads complicate the microgrid management, which the EMS should be able to cope with. (2) The emerging technology applicable to microgrids (e.g., demand response (DR), coordinated EV charging, vehicle-to-grid (V2G), etc.) and innovative control algorithms demand EMS to have the flexibility to allow any new devices to join seamlessly. (3) Many operational devices on a microgrid use proprietary protocols and cannot interoperate with each other. The EMS preferably handles the heterogeneity and achieves interoperation. A well-functional EMS should solve the above issues.

[00131] In the field of Electric Vehicle (EV) charging management, many studies have been addressed to date. The flexibility for implementing different algorithms in the EMS system also makes it possible to increase the utilization of Renewable Energy Sources (RES). In the context of global environmental concerns and the move to encourage more use of clean energy, the objective to increase RES utilization is becoming more important. Extensive investigations in the literature describe methods to maximize utilization of RES in microgrid with EV integration. For example a couple such proposals investigate optimal strategies to maximize RES utilization by means of linear programming, convex programming, mixed- integer programming and semi-Markov decision process (SMDP). Those proposals considered EV load as one part of a larger load (such as household appliances) and the load is supplied by a wide variety of RES, such as PV and wind power.

[00132] In this section is presented a two-tier EMS infrastructure that is

currently operational on the campus of UCLA and is actively managing EV stations and other on-campus DERs. The control system provides a platform to execute different processes (algorithms) on the system as a test bed. The local control unit manages microscale energy activities. This section presents a preventive process (algorithm) for the upper level control system in the microgrid level, and also presents two priority based queuing processes (algorithms) for the local EV control system to encourage shift of user consumption behavior towards the maximization of RES utilization and green energy.

[00133] 2.2. System Architecture

[00134] The UCLA campus microgrid consists of various entities. The Smart Grid Energy Research Center (SMERC) is taking control over 100 Electric Vehicle (EV) Charging Stations located at different Parking Structures (PS) on campus. The EV Charging Stations are managed by a control system called "EV Control Center" (EVCC) in a micro-scale level over daily operation on each individual charging station. An upper layer control system, named "Super Control Center" (SCC), is operating in a macroscale level as an EMS.

[00135] The approach adopts a two-tier management system in order to

facilitate a large variety of EV charging boxes (stations) installed on sites and multiple interfaces for different external data while providing a versatile platform for EMS algorithms to implement and test with.

[00136] The upper level system, Super Control Center (SCC), serves the purpose of an operator in the regional aggregator or microgrid manager level whose responsibility lies within energy consumption and generation of each entity under its management. The operator, however, does not control the specific activities of those entities. The SCC monitors and manages the overall health and efficiency of the microgrid. SCC issues Demand Response (DR) signals based on system management algorithms.

[00137] The lower level management system, Electric Vehicle Control Center (EVCC), manages specific equipment and services (e.g., EV charging stations and related distributed energy resources) at the local level. EVCC executes programming to perform local processes (algorithms) that incorporate different supply and demand data and determine operational activities subsequently. While SCC issues less frequent DR signals, EVCC processes (algorithms) operate in a quasi-real time fashion and manage user's activities from minute to minute.

[00138] 2.3. Super Control Center (SCC)

[00139] 2.3.1 . Infrastructures and Set-Up

[00140] The SCC serves as a centralized portal for all entities within the

UCLA SMERC microgrid, including but not limited to: Battery Energy Storage System (BESS), solar panel energy generation (and/or other renewable energy source), Level-3 DC Fast Chargers (DCFC) and EV charging stations managed by EVCC.

[00141] In SCC, the EV charging stations are only monitored and managed in PS level - SCC regards each PS as an individual energy consumption entity, without direct control over each individual charging box. BESS stores energy from an energy source (typically a renewable source like solar panels, although it can store low cost energy from the grid if there is insufficient solar energy or other renewable energy) whose stored energy can be utilized for charging EVs to overcome the intermittency from the solar energy generation as well as acts as an energy asset storage.

[00142] The WINSmartEVTM infrastructure under management of SCC

includes multiple (e.g., 10 in this example) multiplex charging stations and one DCFC which provides numerous (e.g., 41 ) EV plug points in total. SCC runs on a cloud-based server with communications established with charging stations and EVCC.

[00143] FIG. 24A and FIG. 24B illustrates an example embodiment 810 of the super control center (SCC). The SCC can be divided into three major functional components: (a) Data Collection and Storage 816; (b) DR Signal Delivery 814; and (c) Algorithm and DR Signal Generation 812.

[00144] In the figure the Super Control Center (SCC) structure depicts each section as follows. Data Collection 816 is a fundamental yet one of the most deterministic elements for successful microgrid control. The goal of successful data collection can be defined as (1 ) maximal data density, (2) minimal data interruption and (3) effective data transmission.

[00145] 2.3.2. Data Collection

[00146] In this example embodiment a general-purpose gateway by Billion Electric Co. was adopted that provides monitoring capability and generic API for communication to facilitate hardware that does not support common communication protocols natively. An interface was developed to allow generic communication on specific controller on BESS.

[00147] The communication between central server and local monitor can be categorized into two methods: (1 ) Pull and (2) Push. In terms of data transmission, Push is the preferred method over Pull for its higher reliability and better efficiency. However, the availability of Push depends on the local monitoring device.

[00148] 2.3.3. Data Structures for Storage and Communications

[00149] The following describes Data Structures for Storage and Communication SCC requests PS-level power data from EVCC every minute. As in this transmission process, the EVCC only reports the latest power record in its database, the returned data may be delayed for up to one minute. Within the SCC database, the power data obtained from EVCC includes PS ID, PS power and timestamp. For DR data, each event is stored in a table specifying the action mode (Manual or any specific Automatic process (algorithms)) and the specific decision on each entity (including current on the battery, or DR on PS through EVCC). DR signals with different processes and contexts are specified with different decision indices. The decision indices provide easy reverse inference capability in later data analysis.

[00150] 2.3.4. DR Decisions By Modes

[00151] The SCC has two main operating modes: Manual and Automatic.

Manual operation is implemented by the SCC operator or a utility operator with a higher priority over Automatic operation. SCC allows two ways to implement manual operations, through Graphic User Interface (GUI) and OpenADR 2.0a Protocol.

[00152] The GUI serves as the general monitor for everything in action in the microgrid, including current power condition and any Demand Response (DR) event. It also offers comprehensive functions to fine-tune the system as well as the choice of automatic processes (algorithms). A snapshot of the SCC GUI was previously shown in FIG. 7A and FIG. 7B. The flowchart for executing manual operation and OpenADR commands which were previously shown in FIG. 8. This embodiment of the API can be used for real-time and/or emergency DR signals or to schedule any event in advance, whether it is day-ahead or any-time-ahead.

[00153] Manual operations have higher priority than Automatic DR processes (algorithms). Any new Manual action will override the decision made by an Automatic process, In the SCC GUI, the user can define DR signals by selecting any entity and choosing start and stop time. Subsequently the user sends the DR signal directly to the controlled entity through GUI.

[00154] SCC allows programmable processes (algorithms) to manage its entities, providing a flexible test-bed for different EMS processes

(algorithms) to evaluate and adjust the overall microgrid health.

[00155] The flowchart for implementing real-time automatic program was previously shown in FIG. 9. The flowchart takes into account pre- scheduled DR and has the capability to overturn previous Automatic decisions based on the real-time situation.

[00156] 2.3.5. DR Signal Delivery

[00157] FIG. 25 illustrates an example embodiment 910 for executing

scheduled DR events and prompting new automatic decisions. A check 912 is made to check current DR database to perform a predefined manual operation 914 and end cycle 916, or if there was no previous manual operation 918 and a new automatic process decision is performed 920 before ending the cycle 916.

[00158] Thus, as seen in the figure, in each predefined cycle, the SCC

retrieves current DR events from a database. If a previous issued manual

DR signal exists, the SCC sends the DR command to the related entity through HTTP POST. Otherwise the program prompts the automatic process for DR decisions.

[00159] 2.4. Experimental Results

[00160] Based on collected photovoltaic data and experimental data with

EVCC, a case simulation is presented with a preventive process (algorithm) to keep the S2V utilization ratio high. With lower than 15 kW of power output, the system limits all EV charging to minimum power.

[00161] The S2V utilization ratio can be defined as

SolarSupplyRatio = min (SolarPower/TotalConsumedPower,l) where it is assumed the ratio is always smaller or equal to 1 .

[00162] FIG. 26A and FIG. 26B illustrate results 930 from an example

embodiment showing power consumption and solar supply ratio plots. The case shows a sudden decrease of solar panel generation, possibly caused by clouds crossing, collected between 06/05/2015 12:22 PM and 12:47 PM.

At 12:25 PM, the PV power generated dropped down to lower than 10 kW. The SCC detected the drop of power generation in the next minute and issued DR signals to the EVCC for minimum power output at PS4 and PS8 at 12:26 PM. EVCC reported reduced power consumption in the next minute at 12:28 PM. The two entities' consumption dropped down to 2.6kW from 9.7kW and 6kW respectively, corresponding to 73.2% and 57% of power drop.

[00163] At 12:36 PM, the solar power climbed up across 15 kW, so SCC issued a new DR signal to resume normal power consumption to EVCC at 12:37 PM. The reported EV charging power consumption ramped up from 12:38 PM. During the experiment, the Solar Supply Ratio is kept at 1 for most of the time despite of the delay of DR responses.

[00164] 2.6. Electric Vehicle Control Center (EVCC)

[00165] The Electric Vehicle Control Center (EVCC) is a lower-level

management entity that directly oversees the operations of individual local charging stations. The scope of management of EVCC is typically at a parking lot level where an aggregation of EV chargers, possibly a local power generation site (such as solar panels) and energy storage are located. The operations that EVCC controls over EV chargers include starting charging, stopping charging and adjustment of charging current.

[00166] 2.6.1 . Infrastructures and Set-Up

[00167] FIG. 27 illustrates an example embodiment 950 of an EVCC

structure. The EVCC 952 takes in C-CPP pricing 956 and other DR signals 958 from SCC 954. EV users submit charging requests 962 to EVCC. EVCC processes all requests and by combining all available information, determines an optimal charging queuing strategy. The EVCC subsequently reports power consumption back to SCC. EVCC can also analyze user profiles and provide demand forecast to SCC.

[00168] To provide streamlined user experience, users use a cloud-based iOS interface EVSmartPlugTM to submit charging requests and monitor charging status. The application scans the QR code attached to each charging station and subsequently submits the charging request to the cloud-based EVCC without user's specific manual operations. The EVCC communicates the charging status with the user through the mobile iOS interface 962. Also shown in the figure is the interaction with local power generation 960, and EVCC interaction with the charging infrastructure of Charging Boxes 964 which connect to EVs 966.

[00169] 2.6.2. Queuing Algorithms

[00170] To evaluate users' solar utilization based on their previous charging records, this process compares the consumption power and the solar generation data at the same time interval. The Solar to Vehicle (S2V) factor U _{j n} for the n-th event of user i can be computed as the following:

where a _{s h} is the solar generation power at time h , h _st , h _end are the start and stop time for each charging event of user i ranging from 1 to n and a _{v h} is the power consumption at time h for station v ranging from 1 to 4

(each multiplex charging station in this example has four shared power stations). It is assumed in this case that solar power generation is non- negative and the solar utilization is always less or equal to 1.

71 ] For each user i , the system assigns a Solar-Friendliness Index (SFI) S _j in terms of the proportion of solar energy in their entire energy consumption profile. User charging priority is then based on this index toward promoting efficient ("greener") energy usage and improving grid efficiency against the "duck curve" effect. The index S _j can be calculated as:

- n=L

i N

∑E _n

n=l

where E _n is the total energy consumption for charging event n . [00172] As users realize the charging priority is based on their usage of RES and more such use is encouraged, it is expected that user consumption patterns will change accordingly. For convenience, users who have plugged in are referred to requesting charging as "online user" and those who are also receiving power from the charging station as "active user".

[00173] 2.6.2.1 . Priority Sharing

[00174] In a Priority Sharing process (algorithm), the system makes use of the multiplexing feature of the charging box and charges every online user at the same time. As the total power of the box is fixed (7 kW for a Level-2 AC charger), the more users charging at the same time, the less power each user will receive. With the capability to control the charging power of each plug, or "station", of the charging box, the system distributes the limited power based on each user's SFI and demand. In principle, the system provides more priority to the user with higher SFI and less energy demand.

[00175] For the active user i , the power a _i they receives is given by the following

where E _j is the energy demand for user i , Q is the set of online users at the charging box, a _s is the instantaneous power generation by solar, a _g is the instantaneous power purchased from the grid, and a _b is the instantaneous power output from BESS, if there is any.

[00176] 2.6.2.2. Priority Round Robin

[00177] In the Priority Round Robin process (algorithm), the system charges only one user at a time with maximum power while putting other online users on hold. Users with higher priority will start and finish earlier with higher charging power. The system provides highest priority to users with highest SFI and least energy demand. It should be noted that while charging a user, if another higher priority user requests charging, the system turn off the current active charging session and begins with the new user having a higher priority.

[00178] For a set of active users Q , the system provides charging service to user i who has the highest priority index g _j is:

_ ^s i

The instantaneous power that user receives is: [00179] 2.6.2.3. Simulation Results

[00180] FIG. 28A through FIG. 28C illustrates results 970, 975, 980 from an example embodiment of the present disclosure. These simulation results are for the two processes (algorithms) based on consumption data collected from a Level-2 AC Charging Box 04/04/2016 to 04/05/2016 located at Parking Structure 2, shown in FIG. 28A. A 35kW Solar Panel was used as the solar panel data source and scale the minute-to-minute data down to 10kW maximum. The results average solar power output over a selected period of time (e.g., 5 minutes) to reduce the fluctuation of solar energy. There are six charging events seen on that day: four in the morning for each of the four plug and another two on Station 3 and Station 4 later. The solar supply ratio for the original charging scenario is 0.504. In the two scheduling algorithms, it is assumed to have no grid electricity purchase and no battery input. As shown in FIG. 28B and FIG. 28C both processes (algorithms) are able to provide all energy with solar energy alone, giving a solar supply ratio of 1 . Both algorithms start charging later than the original case, due to lack of solar energy at dawn of the day.

Priority Round Robin is able to finish charging for a Station 3 user, who has higher priority and less energy demand, earlier at 9:23 while Priority Sharing finishes charging this user at after 10:00, around similar time with the original case. For other events, the two algorithms finish charging in a later time, but before the next user arrives. [00181] Another scenario where DR is imposed for the entire day is also applied to the two processes (algorithms). For example a threshold used in the literature determines that for each station the minimum charging duty cycle should be 12% while the maximum duty cycle for the charging box is 50%.

[00182] Thus, using these values for Priority Round Robin algorithm, the DR power reduction is 76% while for Priority Sharing, with four stations sharing, the power reduction is merely 4%. As a result, Priority Sharing finished five of the six requests, with one finished at 84.4% due to arriving of another vehicle. Priority Round Robin, however, finishes three out of six requests.

Two requests are provided with 34.4% and 21 % of demand respectively while the other request is not started.

[00183] In regular settings, Priority Round Robin enables a prioritized user with higher power, thus allowing them to finish earlier. Priority Sharing is a more "fair" process (algorithm) in which all users will receive a certain amount of power. However, both processes (algorithms) reach similar results in terms of energy provided and overall finish time if supply is sufficient.

[00184] 2.7. Conclusion

[00185] In this section (Section 2) we have presented a two-tier Energy

Management System composed of a higher level Super Control Center and lower level Electric Vehicle Control Center. Each management system has its own process (algorithm) to coordinate and control the entities, resources and demand.

[00186] With the goal to increase S2V utilization ratio, a preventive algorithm and two queuing algorithms (Priority Sharing and Priority Round Robin) are applied to SCC and EVCC respectively. The preventive algorithm at SCC has shown the capability to keep the overall RES utilization at a higher level in the microgrid level. The queuing algorithms at EVCC increase RES utilization while promoting "greener" user behavior by providing higher priority to more S2V-friendly users. We have shown that the algorithms can successfully increase the RES utilization rate, while each queuing algorithm has their own characteristics.

[00187] 3. Considerations on Practicing the Present Disclosure

[00188] The enhancements described in the presented technology can be readily implemented across various levels of the EV charging infrastructure. It should also be appreciated that this circuitry within the EV infrastructure is typically implemented to include one or more computer processor devices (e.g., CPU, microprocessor, microcontroller, computer enabled ASIC, etc.) and associated memory storing instructions (e.g., RAM, DRAM, NVRAM, FLASH, computer readable media, etc.) whereby programming

(instructions) stored in the memory are executed on the processor to perform the steps of the various process methods described herein. In particular, it will be appreciated that at least one embodiment of the SCC, EVCC, EV management system, mobile device for running user charging application programming, gateways for each charging station, EVSE would contain at least one processor and at least one memory for storing and executing programming for carrying out the functions of these elements.

[00189] The computer and memory devices were not depicted in the

diagrams for the sake of simplicity of illustration, as one of ordinary skill in the art recognizes the use of computer devices for carrying out steps involved with control of the EV charging infrastructure. The presented technology is non-limiting with regard to memory and computer-readable media, insofar as these are non-transitory, and thus not constituting a transitory electronic signal.

[00190] Embodiments of the present technology may be described herein with reference to flowchart illustrations of methods and systems according to embodiments of the technology, and/or procedures, algorithms, steps, operations, formulae, or other computational depictions, which may also be implemented as computer program products. In this regard, each block or step of a flowchart, and combinations of blocks (and/or steps) in a flowchart, as well as any procedure, algorithm, step, operation, formula, or computational depiction can be implemented by various means, such as hardware, firmware, and/or software including one or more computer program instructions embodied in computer-readable program code. As will be appreciated, any such computer program instructions may be executed by one or more computer processors, including without limitation a general purpose computer or special purpose computer, or other programmable processing apparatus to produce a machine, such that the computer program instructions which execute on the computer processor(s) or other programmable processing apparatus create means for

implementing the function(s) specified.

[00191] Accordingly, blocks of the flowcharts, and procedures, algorithms, steps, operations, formulae, or computational depictions described herein support combinations of means for performing the specified function(s), combinations of steps for performing the specified function(s), and computer program instructions, such as embodied in computer-readable program code logic means, for performing the specified function(s). It will also be understood that each block of the flowchart illustrations, as well as any procedures, algorithms, steps, operations, formulae, or computational depictions and combinations thereof described herein, can be implemented by special purpose hardware-based computer systems which perform the specified function(s) or step(s), or combinations of special purpose hardware and computer-readable program code.

[00192] Furthermore, these computer program instructions, such as

embodied in computer-readable program code, may also be stored in one or more computer-readable memory or memory devices that can direct a computer processor or other programmable processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory or memory devices produce an article of manufacture including instruction means which implement the function specified in the block(s) of the flowchart(s). The computer program instructions may also be executed by a computer processor or other programmable processing apparatus to cause a series of operational steps to be performed on the computer processor or other programmable processing apparatus to produce a computer-implemented process such that the instructions which execute on the computer processor or other programmable processing apparatus provide steps for implementing the functions specified in the block(s) of the flowchart(s), procedure (s) algorithm(s), step(s), operation(s), formula(e), or computational

depiction(s).

[00193] It will further be appreciated that the terms "programming" or

"program executable" as used herein refer to one or more instructions that can be executed by one or more computer processors to perform one or more functions as described herein. The instructions can be embodied in software, in firmware, or in a combination of software and firmware. The instructions can be stored local to the device in non-transitory media, or can be stored remotely such as on a server, or all or a portion of the instructions can be stored locally and remotely. Instructions stored remotely can be downloaded (pushed) to the device by user initiation, or automatically based on one or more factors.

[00194] It will further be appreciated that as used herein, that the terms

processor, hardware processor, computer processor, central processing unit (CPU), and computer are used synonymously to denote a device capable of executing the instructions and communicating with input/output interfaces and/or peripheral devices, and that the terms processor, hardware processor, computer processor, CPU, and computer are intended to encompass single or multiple devices, single core and multicore devices, and variations thereof.

[00195] From the description herein, it will be appreciated that the present disclosure encompasses multiple embodiments which include, but are not limited to, the following:

[00196] 1 . A multi-layer energy management system (EMS) for electric

vehicles, the system comprising: (a) smart electric vehicle supply equipment (EVSE); (b) an electric vehicle (EV) aggregated control center (EVCC); (c) an integrated super control center (iSCC); and (d) a

communications network interconnecting the EVSE, EVCC, and iSCC; (e) one or more processors and associated memory storing instructions executable by the one or more processors; (f) where said instructions, when executed by the one or more processors, perform function comprising coordinating energy management tasks in power distribution grids with different specified algorithms, taking into account availabilities of power resources in microgrids, including battery energy storage systems (BESS), renewable power sources, and other power sources.

[00197] 2. A hierarchical multi-layer energy management system (EMS) for electric vehicles, the system comprising: (a) an integrated super control center (iSCC); (b) an electric vehicle (EV) aggregator control center and other distributed energy resources in a local distribution grid, including solar PV generation and a battery energy storage system (BESS); and (c) a plurality of physical devices including Electric Vehicle Supply Equipment (EVSE) configured with current multiplexing capabilities; (d) wherein EV drivers/users are able to monitor and control charging sessions for their vehicles via mobile applications.

[00198] 3. A multi-layer energy management system (EMS) for electric

vehicles, the system comprising: (a) smart electric vehicle supply equipment (EVSE); (b) an electric vehicle (EV) aggregated control center (EVCC); (c) an integrated super control center (iSCC); and (d) a

communications network interconnecting the EVSE, EVCC, and iSCC; (e) an adaptable application program interface (API) with evolvable templates configured for execution on a mobile device of a user for energy scheduling and EVSE; (f) one or more processors and associated memory storing instructions executable by the one or more processors; (g) where said instructions, when executed by the one or more processors, perform function comprising coordinating energy management tasks in power distribution grids with different specified processes, taking into account availabilities of power resources in microgrids, including Battery Energy Storage Systems (BESS), renewable power sources, energy price preferences, travel schedules, and grid signals from the iSCC, utilities and third-party organizations and other sources of power; and performing a price-based scheduling process configured to allow users to participate in EV charging retail market based on external pricing signals; and (h) a mobile application interface configured to provide EV drivers with interfaces to initiate, terminate, and monitor charging sessions, as well as submitting personal energy management preferences.

[00199] 4. The system of any preceding embodiment, wherein when

executed, said instructions take into account user energy price preferences, travel schedules, and grid signals from the iSCC, utilities and third-party organizations.

[00200] 5. The system of any preceding embodiment, further comprising an adaptable application programming interface (API) with evolvable templates for energy scheduling processes and EVSE.

[00201] 6. The system of any preceding embodiment, wherein said

instructions comprise a price-based scheduling process configured to allow users to participate in an EV charging retail market based on external pricing signals.

[00202] 7. The system of any preceding embodiment, further comprising a mobile application interface configured to provide EV drivers with interfaces to initiate, terminate and monitor charging sessions, as well as submitting personal energy management preferences.

[00203] 8. The system of any preceding embodiment, wherein when

executed, said instructions for said electric vehicle (EV) aggregated control center (EVCC) is configured for communicating with a renewable power generation source, and with a battery energy storage system (BESS).

[00204] 9. The system of any preceding embodiment, wherein said electric vehicle (EV) aggregated control center (EVCC) is configured for directing energy from the renewable power generation source to electric vehicle charging, and for directing storage of excess power in the battery energy storage system (BESS) for later use in electric vehicle charging when insufficient power is available from said renewable power generation source.

[00205] 10. The system of any preceding embodiment, wherein the iSCC is configured to perform management tasks considering both historical and real-time data for the main components in an entire microgrid.

[00206] 1 1 . The system of any preceding embodiment, wherein the iSCC comprises: (a) processor; and (b) memory storing instructions executable on the processor; (c) wherein, when executed, said instructions support microgrid regulation tasks, including minimal EV power control.

[00207] 12. The system of any preceding embodiment, wherein the EV

aggregator control center is configured to manage both private EVs and public fleet EVs.

[00208] 13. The system of any preceding embodiment, wherein the EV

aggregator control center comprises: (a) a processor; and (b) a memory storing instructions executable on the computer processor; (c) wherein, when executed, said instructions support microgrid regulation tasks including minimal EV power control using real-time intelligent processes.

[00209] 14. The system of any preceding embodiment, wherein said

intelligent processes are configured to retrieve market information, including energy price signals from a wholesale market, local utility or pricing services from third-party organizations, and for pulling real-time power and status information from a plurality of EVSEs.

[00210] 15. The system of any preceding embodiment, wherein said

intelligent processes are configured to consider user preferences, energy prices, and information from the iSCC.

[00211] 16. The system of any preceding embodiment, wherein said iSCC is configured to perform management tasks considering both historical and real-time data for the main components in an entire microgrid.

[00212] 17. The system of any preceding embodiment, wherein the iSCC comprises: (a) processor; and (b) memory storing instructions executable on the processor; (c) wherein, when executed, said instructions support microgrid regulation tasks, including minimal EV power control.

[00213] 18. The system of any preceding embodiment, wherein the electric vehicle (EV) aggregated control center is configured for managing both private EVs and public fleet EVs. [00214] 19. The system of any preceding embodiment, wherein when executed, said instructions for said electric vehicle (EV) aggregated control center (EVCC) is configured for communicating with a renewable power generation source, and with a battery energy storage system (BESS).

[00215] 20. The system of any preceding embodiment, wherein said electric vehicle (EV) aggregated control center (EVCC) is configured for directing energy from the renewable power generation source to electric vehicle charging, and for directing storage of excess power in the battery energy storage system (BESS) for later use in electric vehicle charging when insufficient power is available from said renewable power generation source.

[00216] As used herein, the singular terms "a," "an," and "the" may include plural referents unless the context clearly dictates otherwise. Reference to an object in the singular is not intended to mean "one and only one" unless explicitly so stated, but rather "one or more."

[00217] As used herein, the term "set" refers to a collection of one or more objects. Thus, for example, a set of objects can include a single object or multiple objects.

[00218] As used herein, the terms "substantially" and "about" are used to describe and account for small variations. When used in conjunction with an event or circumstance, the terms can refer to instances in which the event or circumstance occurs precisely as well as instances in which the event or circumstance occurs to a close approximation. When used in conjunction with a numerical value, the terms can refer to a range of variation of less than or equal to ± 10% of that numerical value, such as less than or equal to ±5%, less than or equal to ±4%, less than or equal to ±3%, less than or equal to ±2%, less than or equal to ±1 %, less than or equal to ±0.5%, less than or equal to ±0.1 %, or less than or equal to ±0.05%. For example, "substantially" aligned can refer to a range of angular variation of less than or equal to ±10°, such as less than or equal to ±5°, less than or equal to ±4°, less than or equal to ±3°, less than or equal to ±2°, less than or equal to ±1 °, less than or equal to ±0.5°, less than or equal to ±0.1 °, or less than or equal to ±0.05°.

[00219] Additionally, amounts, ratios, and other numerical values may

sometimes be presented herein in a range format. It is to be understood that such range format is used for convenience and brevity and should be understood flexibly to include numerical values explicitly specified as limits of a range, but also to include all individual numerical values or sub-ranges encompassed within that range as if each numerical value and sub-range is explicitly specified. For example, a ratio in the range of about 1 to about 200 should be understood to include the explicitly recited limits of about 1 and about 200, but also to include individual ratios such as about 2, about

3, and about 4, and sub-ranges such as about 10 to about 50, about 20 to about 100, and so forth.

[00220] Although the description herein contains many details, these should not be construed as limiting the scope of the disclosure but as merely providing illustrations of some of the presently preferred embodiments.

Therefore, it will be appreciated that the scope of the disclosure fully encompasses other embodiments which may become obvious to those skilled in the art.

[00221] All structural and functional equivalents to the elements of the

disclosed embodiments that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the present claims. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. No claim element herein is to be construed as a "means plus function" element unless the element is expressly recited using the phrase "means for". No claim element herein is to be construed as a "step plus function" element unless the element is expressly recited using the phrase "step for".