SYSTEMS AND METHODS FOR CONTROLLING ELECTRIC VEHICLES BASED ON REAL-TIME TRAFFIC INFORMATION AND DRIVER CHARACTERISTICS

Abstract

A method for controlling an electric vehicle (EV) comprises obtaining a set of models corresponding to functional components, mobility components, and thermal components of the EV. Physical state data of the EV and a driver command input corresponding to a functional component is collected. The method further comprises generating driving cycle data for the EV, based on the physical state data and determining operating points of at least one mobility component, based on the driving cycle data. Each operating point of the plurality of operating points is parameterized by a desired torque and speed of the EV. The method further comprises generating a set of control commands for the functional component, based on the plurality of operating points, the set of models stored in the memory, and the driver command input and controlling the functional component, based on the set of control commands.

Claims

1. A controller for controlling an electric vehicle (EV), comprising: a memory configured to store computer-executable instructions and a set of models corresponding to a plurality of functional components of the EV, a plurality of mobility components of the EV, and a plurality of thermal components of the EV; and a processor configured to execute the instructions to: collect physical state data of the EV and a driver command input corresponding to a functional component of the plurality of functional components of the EV; generate driving cycle data for the EV, based on the physical state data; determine a plurality of operating points of at least one mobility component of the plurality of mobility components of the EV, based on the driving cycle data, wherein each operating point of the plurality of operating points is parameterized by a desired torque and speed of the EV; generate a set of control commands for the functional component, based on the plurality of operating points, the set of models stored in the memory, and the driver command input; and control the functional component, based on the set of control commands.

2. The controller of claim 1, wherein the functional component comprise a Heating Ventillation and Air Conditioning (HVAC) subsystem of the EV, wherein the plurality of mobility components comprise one or more propulsion systems of the EV, and wherein the plurality of thermal components comprise heat sources in the EV.

3. The controller of claim 2, wherein the set of control commands define one or more temperature setpoints for a cabin of the EV, a cooling air temperature entering the cabin of the EV, one or more mass flow rates of coolant in the HVAC system, and a temperature of the coolant when exiting a compressor of the HVAC subsystem.

4. The controller of claim 2, wherein the physical state data comprises acceleration data of the EV, travelled distance data of the EV, location data of the EV, temperature data of the EV, battery status data of the EV, and pressure data of the HVAC system.

5. The controller of claim 4, wherein to generate the driving cycle data, the processor is configured to: derive route information for the EV, real-time traffic information for the EV, and a current location of the EV, based on the physical state data; generate a route-traffic specific profile of the EV, based on the route information, the real-time traffic information, and the current location of the EV; and generate a driver-route-traffic-specific driving cycle using the route-traffic specific profile of the EV and a dynamic model representing driver characteristics.

6. The controller of claim 5, wherein to determine the plurality of operating points of the at least one mobility component, the processor is configured to: obtain a body model of the EV; and determine the plurality of operating points as mobility commands for the at least one mobility component, based on the body model of the EV and the driver-route-traffic-specific driving cycle.

7. The controller of claim 6, wherein the processor is further configured to control the at least one mobility component in accordance with the mobility commands, wherein the mobility commands specify the preferred torques and speeds of the at least one mobility component.

8. A computer-implemented method for controlling an electric vehicle (EV), comprising: obtaining a set of models corresponding to a plurality of functional components of the EV, a plurality of mobility components of the EV, and a plurality of thermal components of the EV; collecting physical state data of the EV and a driver command input corresponding to a functional component of the plurality of functional components of the EV; generating driving cycle data for the EV, based on the physical state data; determining a plurality of operating points of at least one mobility component of the plurality of mobility components of the EV, based on the driving cycle data, wherein each operating point of the plurality of operating points is parameterized by a desired torque and speed of the EV; generating a set of control commands for the functional component, based on the plurality of operating points, the set of models stored in the memory, and the driver command input; and controlling the functional component, based on the set of control commands.

9. The method of claim 8, wherein the functional component comprise a Heating Ventillation and Air Conditioning (HVAC) system of the EV, wherein the plurality of mobility components comprise one or more propulsion systems of the EV, and wherein the plurality of thermal components comprise heat sources in the EV.

10. The method of claim 9, wherein the set of control commands define one or more temperature setpoints for a cabin of the EV, one or more mass flow rates of coolant in the HVAC system, and a temperature of the coolant when exiting a compressor of the HVAC system.

11. The method of claim 9, wherein the physical state data comprises acceleration data of the EV, travelled distance data of the EV, location data of the EV, temperature data of the EV, battery status data of the EV, and pressure data of the HVAC system.

12. The method of claim 11, wherein generating the driving cycle data further comprises: deriving route information for the EV, real-time traffic information for the EV, and a current location of the EV, based on the physical state data; generating a route-traffic specific profile of the EV, based on the route information, the real-time traffic information, and the current location of the EV; and generating a driver-route-traffic-specific driving cycle using the route-traffic specific profile of the EV.

13. The method of claim 12, wherein determining the plurality of operating points of the at least one mobility component further comprises: obtaining a body model of the EV; and determining the plurality of operating points as mobility commands for the at least one mobility component, based on the body model of the EV and the driver-route-traffic-specific driving cycle.

14. The method of claim 13, further comprising controlling the at least one mobility component in accordance with the mobility commands, wherein the mobility commands specify the preferred torques and speeds of the at least one mobility component.

15. A non-transitory computer readable medium having stored thereon instructions that when executed by a computer, cause the computer to perform a method for controlling an electric vehicle (EV), the method comprising: obtaining a set of models corresponding to a plurality of functional components of the EV, a plurality of mobility components of the EV, and a plurality of thermal components of the EV; collecting physical state data of the EV and a driver command input corresponding to a functional component of the plurality of functional components of the EV; generating driving cycle data for the EV, based on the physical state data; determining a plurality of operating points of at least one mobility component of the plurality of mobility components of the EV, based on the driving cycle data, wherein each operating point of the plurality of operating points is parameterized by a desired torque and speed of the EV; generating a set of control commands for the functional component, based on the plurality of operating points, the set of models stored in the memory, and the driver command input; and controlling the functional component, based on the set of control commands.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The presently disclosed embodiments will be further explained with reference to the following drawings. The drawings shown are not necessarily to scale, with emphasis instead generally being placed upon illustrating the principles of the presently disclosed embodiments.

[0018] FIG. 1A illustrates a block diagram of a controller for controlling a battery-powered electric vehicle (BEV), according to some embodiments;

[0019] FIG. 1B illustrates a method for controlling the BEV, according to some embodiments;

[0020] FIG. 1C illustrates a power control system for controlling a propulsive system and an HVAC system of the BEV, according to some embodiments;

[0021] FIG. 2 illustrates a method for generating control commands for the propulsive system and the HVAC system of the BEV, according to some embodiments;

[0022] FIG. 3A illustrates an exemplar method for synthesizing driver-route specific driving cycle, according to some embodiments;

[0023] FIG. 3B illustrates a method for identifying driver characteristic parameters, according to some embodiments;

[0024] FIG. 4 illustrates a method for generating propulsive command based on the driver-route-traffic-specific profile and a vehicle body model, according to some embodiments;

[0025] FIG. 5A illustrates schematics of propulsive motor modeling for the BEV, according to some embodiments;

[0026] FIG. 5B illustrates schematics of HVAC power consumption modeling for the BEV, according to some embodiments;

[0027] FIG. 5C illustrates schematics of battery modeling for the BEV, according to some embodiments;

[0028] FIG. 5D illustrates schematics of temperature dynamics modeling for the BEV, according to some embodiments;

[0029] FIG. 5E illustrates an equivalent electric circuit model for a battery cell utilized for battery modelling, according to some embodiments;

[0030] FIG. 6 illustrates a method for generating an HVAC command, according to some embodiments; and

[0031] FIG. 7 is a schematic illustrating a computing device for implementing various hardware components, according to some embodiments.

[0032] While the above-identified drawings set forth presently disclosed embodiments, other embodiments are also contemplated, as noted in the discussion. This disclosure presents illustrative embodiments by way of representation and not limitation. Numerous other modifications and embodiments can be devised by those skilled in the art which fall within the scope and spirit of the principles of the presently disclosed embodiments.

DETAILED DESCRIPTION

[0033] The following description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the following description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing one or more exemplary embodiments. Contemplated are various changes that may be made in the function and arrangement of elements without departing from the spirit and scope of the subject matter disclosed as set forth in the appended claims.

[0034] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, understood by one of ordinary skill in the art can be that the embodiments may be practiced without these specific details. For example, systems, processes, and other elements in the subject matter disclosed may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known processes, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments. Further, like-reference numbers and designations in the various drawings may indicate like elements.

[0035] Also, individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process may be terminated when its operations are completed but may have additional steps not discussed or included in a figure. Furthermore, not all operations in any particularly described process may occur in all embodiments. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, the function's termination can correspond to a return of the function to the calling function or the main function.

[0036] Furthermore, embodiments of the subject matter disclosed may be implemented, at least in part, either manually or automatically. Manual or automatic implementations may be executed, or at least assisted, through the use of machines, hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium. A processor(s) may perform the necessary tasks.

[0037] Over the past few years, battery powered electric vehicles (BEVs) have witnessed rapid transformation in terms of the number of secondary functionalities that they can execute apart from the primary functionality of mobility. Such an increase in the number of functionalities provided with these vehicles has been mainly due to the constant urge to improve operational efficiency and comfort of using electric vehicles. However, the increase in number of functionalities and in some cases, the increase in complexity of such functionalities, has led to increased power demand in the vehicles. Due to this, the need to optimize power supply and power utilization in BEVs has become more important. In a battery-powered electric vehicle (BEV or simply EV), both propulsive and HVAC subsystems consume most of the battery energy. While the propulsive power consumption is fully governed by driver and does not offer any room for the vehicle power management system to improve the fuel economy by adjusting the propulsive power demand. Accordingly, it is a realization that the coincidence of the peaks of propulsive and HVAC power demands incurs extra battery losses and undesirable stress on battery thermal management system, and potentially shortens the battery lifespan. In fact, the system can benefit from delaying the HVAC peak so that the propulsive power peak and the HVAC power peak are asynchronized in time, which is always possible given the large time constant of vehicle thermal dynamics. It is an objective of some embodiments to determine power control of HVAC subsystem of a BEV to extend the range of the BEV and the lifespan of the battery, and enhance the safety of the BEV.

[0038] It is also an object of some embodiments to determine HVAC power control of the BEV during an ongoing trip from a current location to a target location. While the propulsive power demand is fully controlled by a driver, it is the realization of some embodiments that it is beneficial to predict future propulsive power demand of the ongoing trip and shape the HVAC power demand accordingly. It is also the realization of some embodiments that the future propulsive power demand for the rest of the ongoing trip is largely characterized by a driving cycle and the terrain information of the route for a given BEV-velocity profile along the route of the trip. The driving cycle, although not exactly known, is strongly related to the real-time traffic information along the route and the driver characteristics. It is also an object of some embodiments to incorporate route information of the rest of the ongoing trip, real-time traffic data, and driver characteristics to predict driving cycle for the rest of the trip. It is also an object of some embodiments to determine HVAC power control of the BEV based on reduced order models for HVAC subsystem, temperature dynamics of cabin, battery and propulsive motor, and losses of battery and propulsive motor. Hereinafter, the terms BEV and EV would mean the same and are used interchangeably throughout this disclosure.

[0039] FIG. 1A illustrates a block diagram of a power controller 100 for controlling an EV 10, according to some embodiments of the present disclosure. The power controller (or simply controller) 100 is communicatively coupled to the EV 10. The controller 100 includes a processor 102 and a memory 104. The processor 102 may be a single core processor, a multi-core processor, a computing cluster, or any number of other configurations. The memory 104 may include random access memory (RAM), read only memory (ROM), flash memory, or any other suitable memory systems. Additionally, in some embodiments, the memory 104 may be implemented using a hard drive, an optical drive, a thumb drive, an array of drives, or any combinations thereof.

[0040] According to some embodiments, the controller 100 controls one or more operational components 50 of the EV 10 through a corresponding vehicular functionality controller 60. FIG. 1B illustrates a method 70 for controlling the EV 10, according to some embodiments and will be described in conjunction with FIG. 1A. In this regard, the controller 100 may obtain 72 various types of data from the other data sources 40. Such data may include a set of models 106 corresponding to the operational components of the EV. The operational components may include a plurality of functional components of the EV, a plurality of mobility components of the EV, and a plurality of thermal components of the EV. Some examples of the functional components may include an HVAC system of the EV, a wiper control system of the EV, a light control system of the EV, and the like. Some examples of the mobility components of the EV include propulsion motors of the EV. Some examples of the thermal components of the EV include one or more batteries of the EV, the cabin of the EV, an HVAC subsystem of the EV, the propulsion motors of the EV, and the like. The controller 100 may collect 74 sensory data corresponding to the physical state of the vehicle 10 from one or more sensing devices 30. The physical state of the EV may be defined in terms of motion parameters such as but not limited to the acceleration of the EV, distance travelled by the EV, a current location of the EV, thermal parameters such as a temperature of cabin and a temperature of the battery of the EV, electrical parameters such as battery status of the EV expressed in terms of voltage and current, and other physical parameters such as pressure of coolant at the compressor of an HVAC subsystem of the EV and the like.

[0041] The controller 100 may generate 76 driving cycle data for the EV, based on the physical state data. According to some embodiments, the driving cycle data for the EV may be generated by a third party system that may be co-located with or remotely located from the controller 100. The controller 100 determines 78 a plurality of operating points of at least one mobility component of the plurality of mobility components of the EV, based on the driving cycle data. Each operating point of the plurality of operating points is parameterized by a desired torque and speed of the EV. Furthermore, the controller 100 generates 80 a set of control commands for the functional component, based on the plurality of operating points, the set of models stored in the memory, and the driver command input. Using the commands, the controller controls 82 the functional component 50.

[0042] FIG. 1C illustrates a power control system for controlling a propulsive subsystem and an HVAC subsystem of the EV, according to some embodiments. Driver command 116 is submitted to power management module 130, which, taking into account models, constraints, and driving cycles 125 determines the commands of the propulsive subsystem and the HVAC subsystem. The propulsive subsystem command 131a is fed into propulsive controller which outputs torque command 136 to drives 140 which further generate and supply three-phase voltages to power motors 145. The drives 140 determine the phase voltage 141 for supply to the motors 145 so that the torques 146 of the motors can track the torque command 136 accurately. The motor torques 146 are applied on vehicle body 150 through a mechanical coupling between its shaft and the vehicle body to ensure the vehicle body moves as the driver command 116 specifies. On the other hand, HVAC controller takes the HVAC command 131b and turns it into torque or speed command for drives 165, which supplies certain voltages to motors 170 for HVAC subsystem. According to some embodiments, the motors for the HVAC subsystem move compressor, radiator fan, blower fan for cabin cooling air, and pump for coolant. In some embodiments, the BEV may include only one propulsive motor while in some other embodiments, the BEV may include multiple propulsive motors.

[0043] In some embodiments, the driver command 116 specifies a target location of the present trip, the route from the present location to the target location, preferred cabin air temperature, and gas pedal position, wherein the target location is represented by GPS coordinates or street address. According to some embodiments, the route may be provided by certain onboard navigation system and represented by a set of waypoints where each waypoint is parameterized by GPS coordinates. According to various embodiments the driver may be viewed as a velocity tracking controller which outputs torque command to ensure the vehicle maintain certain desired speed, and thus the gas pedal position characterizes the torque requirement from the driver.

[0044] In some embodiments, during real-time operation, sensing module 120 exploits an inertial measurement unit (IMU) to measure accelerations of the vehicle, an odometer to measure the distance traveled by the vehicle, a GPS sensor to locate the vehicle position, multiple temperature sensors to measure the cabin air temperature, propulsive motor temperature, coolant temperature, cooling air temperature, and battery temperature, electrical sensors to measure voltages and currents of motors and battery, pressure sensors to measure the pressure of refrigerant at the outlet of the compressor, etc. According to some embodiments, the sensing module 120 may also contain hardware and software to receive/process real-time traffic information from the vehicle's present position to its target location. Sensed signals 121 reflect the real-time location, velocity and acceleration of the vehicle body, temperatures of multiple components and ambient environment, pressure and temperature of refrigerant, speeds, currents and voltages of motors, real-time traffic information along the route from the present location to the target location, etc.

[0045] In some embodiments, operation points 131 specify the propulsive command 131a of propulsive subsystem and the HVAC command 131b of the HVAC subsystem. The propulsive command 131a comprises preferred currents of propulsive motors driving the movement of the vehicle body. The HVAC command 131b includes the desired temperature of cabin cooling air, the desired mass flow rate of the coolant, and the desired temperature of the coolant when leaving the HVAC subsystem.

[0046] In some embodiments, the propulsive command 131a specifies the preferred or desired torques and speeds of the propulsive motors driving the movement of the vehicle body and the HVAC command 131b specify the speed of fans, pumps and compressors of the HVAC subsystem. According to some embodiments, the desired torques and speed of the propulsive motors as well as the speed of fans, pumps and compressors of the HVAC subsystem may be specified in reference to a driving cycle.

[0047] FIG. 2 illustrates a method 200 for generating control commands 131a for the propulsive subsystem and control commands 131b for the HVAC subsystem of the EV, according to some embodiments. The propulsive command 131a and the HVAC command 131b of the propulsive and HVAC sub systems for the BEV may be determined based on real-time measured signals 121. In this regard, the method 200 comprises collecting 203 the real-time measured/sensed signals 121. The route information, real-time traffic information and vehicle present location are updated 205 by processing the sensed signal 121 to produce the route-traffic-specific profile 206, which is used to synthesize 210 a driver-route-traffic-specific driving cycle 211. Using the driver-route-traffic-specific driving cycle 211 and a dynamic model of the vehicle body 215, the method 200 comprises predicting 220 the operation points 131a (or equivalently propulsive commands) of the propulsive motor along the driver-route-specific driving cycle, wherein the operation points 131a are parameterized by the desired torque and speed profiles of propulsive motors along the driving cycle 211. The propulsive operation points 131a, models 225 of propulsive motors, HVAC power consumption, battery, and temperature dynamics, and the driver HVAC command 116 (provided by the driver) are used to determine 235 the HVAC command 131b, which is the reference of HVAC controller 160. The updating, predicting, and determining steps are repeated to update HVAC command 131b once the real-time traffic information is significantly different from the previously predicted profile; or driver HVAC command is changed significantly.

[0048] In some embodiments, the route, comprising a sequence of spatial waypoints from the present location to the target location, can be obtained from a standard navigation module, wherein each waypoint is denoted by cartesian coordinates q=(x, y, z). Alternately, according to some embodiments, the route from the present location to the target location may be dynamically generated using map data stored in a database or local cache. Thus, the route information may be represented by N waypoints q.sub.0, . . . , q.sub.N, where q.sub.0 denotes the present location and q.sub.N denotes the target location.

[0049] In some embodiments, the route-traffic-specific information 206 for a particular route (from the present location to the target location) is represented as a velocity/position profile denoted by a dummy variable r(t) for t[0, t.sub.] where t.sub. is the final time to accomplish the trip. The t.sub. depends on the real-time traffic information and is updated during real-time. The dummy variable r denotes the longitudinal position or velocity or acceleration along the route.

[0050] In some embodiments, the driver-route-traffic-specific driving cycle (or equivalently temporal profile of position or velocity or acceleration of the BEV) defines the estimated position or velocity or acceleration profile, denoted by a dummy variable r*(t) for t[0, t.sub.], along the route from the present location to the target location, taking into account the information of the route, real-time traffic, and the driver characteristics.

[0051] Some embodiments provide a method to produce the route-traffic-specific profile 206 based on updated vehicle location and real-time traffic information, where the real-time traffic information along the route is represented as spatial velocity v(s(q)) along the route, where s(q) is the distance from the present location to a particular waypoint q of the route. Given the sensed longitudinal velocity and the location at the time step t.sub.k, denoted by v(t.sub.k)=v.sub.k, q(t.sub.k)=q.sub.k, the future velocity profile over t[t.sub.k, t.sub.] along the route may be inferred based on the spatial velocity v(s), where tr is the final time to finish the route given the current traffic information, and is to be determined. The temporal velocity v(t.sub.k+1) at the next time step can be inferred as follows

[00001]$s\left(t_{k+1}\right)=s\left(t_k\right)+{}_{t_k}^{t_{k+1}}v\left(t\right)\mathrm{dt},v\left(t_{k+1}\right)v\left(s\left(t_{k+1}\right)\right),$

where s(t.sub.k) can be calculated as the distance from q.sub.0 to q(t.sub.k), s(t.sub.k+1) is the longitudinal distance of the EV at the next time step t.sub.k+1 and v (s(t.sub.k+1)) is the spatial velocity at location s(t.sub.k+1), which is known from the real-time traffic information. The aforementioned process is repeated until the vehicle reaches the target location (i.e., the trip is finished). This process also determines the time t.sub. required to reach the target given the latest real-time spatial traffic information.

[0052] FIG. 3A illustrates an exemplar method for synthesizing 210 driver-route-traffic-specific driving cycle 211, according to some embodiments. The driver-route-traffic-specific cycle 211 may be synthesized by encoding driver characteristics, reflecting, for example, cautious, moderate, and aggressive driving styles. The route-traffic-specific 206 is fed into a driver characteristic model 305 to produce the driver-route-traffic-specific driving cycle 211. The driver characteristics represents how aggressive the driver tries to accelerate and decelerate following the velocity/position profile r(t) in a movable object-following scenario. Hence, the driver characteristics are modeled with the optimal velocity model (OVM) as follows

[00002]$\begin{array}{cc}\frac{{\mathrm{ds}}^{*}}{\mathrm{dt}}=v^{*},& \left(1\right)\end{array}$$\frac{{\mathrm{dv}}^{*}}{\mathrm{dt}}=\left(V_{\mathrm{opt}}\left(s\left(t\right)\right)-v^{*}\left(t\right)\right)),$$V_{\mathrm{opt}}\left(s\left(t\right)\right)=v_{\max }\left(\tanh \left(\left(r\left(t\right)-s^{*}\left(t\right)\right)-\right)+1\right),$

where s*(t) and v*(t) are the longitudinal position and driver-specific velocity of the BEV, V.sub.opt is a function mapping the relative distance (between a virtual preceding vehicle and the BEV) to velocity, is the driver sensitivity, and are the slope and the intercept of tanh function, and s(t)=r(t)s*(t) is the relative longitudinal distance to the preceding virtual vehicle where r(t) denotes the position of the preceding virtual vehicle. Each driver might have a different set of values , and . The driver-route-traffic-specific profile 211 may be denoted as the position or velocity or acceleration temporal profile r*(t) for t[0, t.sub.]. It may be noted that the virtual preceding vehicle moves according to the route-traffic-specific profile 206 r(t).

[0053] Values of parameters , and can be estimated on the basis of the driver-route-traffic-specific profile 211 r*(t) and the true profile of the BEV given by s(t), which can be inferred from sensing signals 121 which contains the BEV's location q(t).

[0054] FIG. 3B illustrates a method for identifying driver characteristic parameters, according to some embodiments. Given the real-time sensing signal 121, which includes the true profile s(t), it is compared against the driver-route-traffic-specific profile 211 r*(t)=s*(t), which is viewed as the model-based prediction of the s(t), which is viewed as measured variable in standard state and parameter estimate problem. The driver characteristic parameters are estimated by minimizing the least square error between r*(t) and s(t). Various dynamic model-based estimators, such as particle filter, adaptive estimator, and nonlinear least square estimator, can be used to estimate the driver model parameters , and . The estimated parameters 311 are fed into the driver characteristic model 305 to update the model parameters.

[0055] In some embodiment, the driver model parameters , and are updated recursively, or alternatively updated using the batch data collected along a whole trip, in order to reflect the fact that these parameters are rarely changing over time for a specific driver.

[0056] FIG. 4 illustrates a method for generating 220 propulsive command 131a based on the driver-route-traffic-specific profile 211 and a vehicle body model, according to some embodiments. The vehicle body model captures at least the dynamics of the longitudinal movement. In some embodiments, the driver-route-traffic-specific profile r*(t) 211 specifies the temporal profile of the longitudinal distance s*(t), and then the corresponding velocity and acceleration 406 are determined by various established methods where the velocity v*(t) is obtained by taking numerical time derivative of r*(t) and the acceleration a*(t) is obtained by taking numerical second-order time derivative of r*(t). In some embodiments, the driver-route-traffic-specific profile r*(t) 211 specifies the temporal profile of the longitudinal velocity v*(t) and then the acceleration a*(t) is obtained by taking numerical time derivative of v*(t). The signals s*(t), v*(t), a*(t) and the vehicle body model 215 are used to determine 415 the propulsive command which is denoted as a temporal profile (*(t), t*(t)), wherein t*(t) represents the torque that the propulsive motors have to deliver to the vehicle body through the rotor shafts.

[0057] In some embodiments, the vehicle body model 215 is given by the following equations:

[00003]$\begin{array}{cc}m\frac{{\mathrm{dv}}^{*}}{\mathrm{dt}}=\frac{{}^{*}}{R_w}-\frac{1}{2}{A}_f{C_d\left(v^{*}\right)}^2+f_r\mathrm{mg}\cos +\mathrm{mg}\sin & \left(2\right)\end{array}$

where m, R.sub.w, , A.sub., C.sub.d, .sub.r, g, and are the vehicle mass, wheel radius, air density, vehicle frontal area, air drag coefficient, rolling resistance coefficient, gravitational constant, and road grade, respectively. Given the driver-route-traffic-specific profile v* and the parameter values of the vehicle body model, the net torque to be delivered to the vehicle body may be determined as follows

[00004]${}^{*}=R_w\left(m\frac{{\mathrm{dv}}^{*}}{\mathrm{dt}}+\frac{1}{2}{A}_f{C_d\left(v^{*}\right)}^2+f_r\mathrm{mg}\cos +\mathrm{mg}\sin \right).$

[0058] Considering the fact that the motor speed is linearly proportional to v* with a ratio determined by the gearbox, the propulsive command (*, t*) is determined from driver-route-traffic-specific profile v* and the vehicle body model (eqn. 2).

[0059] In some embodiments, the vehicle body model also considers the dynamics of the vertical displacement (vehicle altitude) to characterize the gravity induced torque that the propulsive motors have to overcome.

[0060] FIG. 5A illustrates the various modelling frameworks utilized for controlling a BEV, according to some embodiments. The various modeling frameworks include propulsive motor modeling 505 of the propulsive motors, temperature dynamics modeling 510 of various thermal components of the BEV, HVAC power consumption modeling 515 of the HVAC subsystem, and battery modeling 520 of the battery of the BEV. FIGS. 5B, 5C, 5D, and 5E illustrate schematics of the propulsive motor modeling 505 for the EV, the temperature dynamics modeling 510 for the EV, the HVAC power consumption modeling 515 for the EV, and the battery modeling 520 for the EV, respectively, according to some embodiments.

[0061] Referring to FIG. 5B, the propulsive motor modeling 505 comprises the derivation of a motor steady-state model 505a, a motor operational constraints 505b and a motor loss model 505c. In some embodiments, the propulsive motor is a type of interior permanent magnet motor (IPM). The dynamics of the IPM can be modeled as follows

[00005]$\begin{array}{cc}{i}_d=\frac{1}{L_d}\left(-R{i}_d+p{L}_q{i}_q+u_d\right)& \left(3\right)\end{array}$$i_q=\frac{1}{L_q}\left(-R{i}_q-\left(L_d{i}_d+{}_m\right)p+u_q\right)$$J\stackrel{}{}=\frac{3p}{2}\left\{{}_m{i}_q+\left(L_d-L_q\right)i_q{i}_d\right\}-T_L,$

where i.sub.d and i.sub.q are d-axis current and q-axis current, respectively; is the motor angular speed; u.sub.d, u.sub.q are d- and q-axes voltages supplied by the drives module 140 to the motor, respectively, and T.sub.L is the load torque; .sub.m is the permanent magnet flux, R is the stator winding resistance, L.sub.d and L.sub.q are the inductances of d- and q-axes, respectively, J is the rotor inertia of the motor, and p is the number of pole pairs of the motor. Note that i.sub.d, i.sub.q can be controlled by u.sub.d and u.sub.q, respectively, which is mainly accomplished by the drives module 140; and that the motor speed w is linearly proportional to the vehicle speed v*(t) 131a through the ratio regulated by a gearbox.

[0062] In some embodiments, T.sub.L contains the sum of the net torque to be delivered to the vehicle body and the torque induced by friction between ball bearing and the rotating shaft of the motor.

[0063] The steady-state motor model 505a is obtained by setting the left-hand-side of the first two equations of (3) to zero and solving for motor current reference

[00006]$\left(i_d^{*},i_q^{*}\right)$

for a given operation point 131a given by (*, *). That is:

[00007]$0=-R{i}_d+p{}^{}{L}_q{i}_q+u_d$$0=-R{i}_q-\left(L_d{i}_d+{}_m\right)p{}^{}+u_q$${}^{*}+J{\stackrel{}{}}^{*}=\frac{3p}{2}\left({}_m+\left(L_d-L_q\right)i_d\right)i_q.$

[0064] Since * is linearly proportional to v*(t) and thus is treated as known signal, then {dot over ()}* is also a known signal.

[0065] The operational constraints 505b specify that the motor voltage cannot exceed a threshold V.sub.max and the motor currents cannot exceed a threshold i.sub.max determined by the heat loading of the motor. The operational constraints 505b admit the following form:

[00008]${\left(L_q{i}_q\right)}^2+{\left({}_m+L_d{i}_d\right)}^2{\left(\frac{V_{\max }}{p}\right)}^2$$i_d^2+i_q^2{i}_{\max }^2.$

[0066] The maximum voltage threshold V.sub.max is linearly proportional to DC-bus voltage V.sub.DC, which in some embodiments, is approximated as the terminal voltage of the battery pack. The proportional ratio between V.sub.max and V.sub.DC depends on the modulation scheme used in the drive units 140. Without loss of generality, and without limitation, some embodiments denote V.sub.max=0.5 V.sub.DC.

[0067] Some example embodiments may represent the motor loss model 505c as analytical functions of the motor current reference

[00009]$\left(i_d^{*},i_q^{*}\right)$

and operation point (*, *). The motor losses P.sub.motor,loss may be modeled as P.sub.motor,loss=P.sub.copper,loss+P.sub.hyst,loss+P.sub.eddy,loss. Specifically, P.sub.copper,loss, P.sub.hyst,loss, and P.sub.eddy,loss denote copper loss, hysteresis loss, and eddy loss, respectively and are given by

[00010]$\begin{array}{cc}{P}_{\mathrm{copper},\mathrm{loss}}=\frac{3}{2}R\left({\left(i_d^{*}\right)}^2+{\left(i_q^{*}\right)}^2\right)& \left(4\right)\end{array}$$P_{\mathrm{hyst},\mathrm{loss}}=k_{\mathrm{hyst}}\frac{p{}^{*}}{2}$$P_{\mathrm{eddy},\mathrm{loss}}=k_{\mathrm{eddy}}{\left(\frac{p{}^{*}}{2}\right)}^2$$=\sqrt{{\left(L_q{i}_q^{*}\right)}^2+{\left({}_m+L_d{i}_d^{*}\right)}^2},$

where k.sub.hyst and k.sub.eddy are hysteresis loss coefficient and eddy loss coefficient, respectively; and is the motor magnetic flux. As such, the motor loss models 505c are analytical functions of motor current reference i*.sub.d and i*.sub.q and the operation point (*, *). The motor power P.sub.motor at the given operation point (*, *) is calculated as P.sub.motor=**+P.sub.motor,loss.

[0068] FIG. 5C illustrates the temperature dynamics to be considered in order to derive the HVAC power consumption model and determine HVAC command. Specifically, the dynamics of motor temperature 510a, battery temperature 510b, and cabin air temperature 510c are modeled as ordinary differential equations as follow:

[00011]$\begin{array}{cc}{M}_b{c}_b{\stackrel{}{T}}_b=-{}_b\left(T_b-T_{amb}\right)+Q_b+{\stackrel{}{m}}_{clnt}{c}_{clnt}\left(T_{clnt}-{\stackrel{}{T}}_{clnt}\right)& \left(5\right)\end{array}$$M_m{c}_m{\stackrel{}{T}}_m=-{}_m\left(T_m-T_{amb}\right)+Q_m+{\stackrel{}{m}}_{clnt}{c}_{clnt}\left({\stackrel{}{T}}_{clnt}-{\stackrel{}{T}}_{clnt}\right)$$M_{\mathrm{cab}}{c}_{\mathrm{cab}}{\stackrel{}{T}}_{\mathrm{cab}}=-{}_{cab}\left(T_{cab}-T_{amb}\right)+{\stackrel{.}{m}}_{\mathrm{air}}{c}_{\mathrm{air}}\left(T_{air}-T_{cab}\right)+Q_{rad}+Q_{\mathrm{psgr}},$

where T.sub.b, T.sub.m, T.sub.cab, T.sub.amb, T.sub.air, T.sub.clnt are the temperatures of battery, motor, cabin air, ambient, cooling air to the cabin, and coolant, respectively; T.sub.clnt, T.sub.clnt are the temperatures of coolant after exits of battery and motor, respectively; {dot over (m)}.sub.air, {dot over (m)}.sub.clnt are the mass flow rates of cabin cooling air and coolant, respectively; M.sub.b, M.sub.m, M.sub.cab are the masses of battery, motor and cabin air, respectively; c.sub.b, c.sub.m, c.sub.cab, c.sub.air, c.sub.clnt are the specific heat of the battery, motor, cabin air, cooling air, and coolant, respectively; Q.sub.rad, Q.sub.psgr, Q.sub.b, Q.sub.m are heat generated by solar radiation, passenger, battery losses, and motor losses, respectively; .sub.b, .sub.m, .sub.cab are the heat transfer coefficients;

[00012]$\begin{array}{cc}{\stackrel{}{T}}_{clnt}=T_b+\left(T_{clnt}-T_b\right)\exp \left(-K_b/\left({\stackrel{}{m}}_{\mathrm{clnt}}{c}_{\mathrm{clnt}}\right)\right)& \left(6\right)\end{array}$${\stackrel{}{T}}_{clnt}=T_m+\left({\stackrel{}{T}}_{clnt}-T_m\right)\exp \left(-K_m/\left({\stackrel{}{m}}_{clnt}{c}_{\mathrm{clnt}}\right)\right),$

where K.sub.b and K.sub.m are the heat exchange coefficients.

[0069] In some embodiments, T.sub.clnt represents the temperature of coolant at the location where the coolant flows back to (enters) the HVAC subsystem. The dynamic models 510 of temperatures are given by (5), wherein the state variables are temperatures of battery, motor, and cabin air, and the control variables are the cooling air temperature T.sub.air, cooling air mass flow rate m.sub.air, coolant mass flow rate {dot over (m)}.sub.clnt and coolant temperature T.sub.clnt before entering the battery.

[0070] In some embodiments, the cabin cooling air mass flow rate is assumed to be fixed, and thus the temperature dynamic models have three control variables: the cooling air temperature T.sub.air, coolant mass flow rate {dot over (m)}.sub.clnt and coolant temperature T.sub.clnt.

[0071] FIG. 5D discloses schematics for deriving the HVAC power consumption model 515. At first, a set of nonlinear algebraic equations representing the HVAC subsystem steady-state operation are derived 535 from well-established dynamic models of HVAC subsystem by setting all time derivatives to zero. The HVAC steady-state operation model 536 characterizes the analytical relationship between the HVAC subsystem state variables, control variables, and external boundary conditions. Specifically, the HVAC state variables contain coolant temperature, cooling air temperature, refrigerant temperature/pressure; the HVAC control variables contain speeds of compressor, cooling air blower fan, radiator fan, and coolant pump; and the HVAC boundary conditions contain the vehicle speed, the temperatures of battery, cabin air, motor, ambient, mass flow rates of cooling air and coolant, and cooling air/coolant leaving and returning to the HVAC subsystem; and the relationship between the power consumption of compressor, fans, and pumps given their rotating speeds. Given the nonlinear algebraic equations 536, one can compute 540 the minimum HVAC power consumption value 541 P.sub.HVAC at each feasible operation condition (characterized by boundary conditions variables T.sub.cab, T.sub.m, T.sub.b, T.sub.amb, T.sub.air, T.sub.clnt, {dot over (m)}.sub.clnt, v) by solving an optimization problem which determines the energy-optimal HVAC control variables such as the speeds of compressor, cooling air blower fan, radiator fan, and coolant pump for given values of control variables of temperature models and boundary conditions of HVAC subsystem for best energy efficiency. The generated HVAC power consumption data are used to build the HVAC power consumption model through data fitting 545.

[0072] In some embodiments, the HVAC power consumption model is defined as an analytical function of cabin air temperature T.sub.cab, motor temperature T.sub.m, battery temperature T.sub.b, ambient temperature T.sub.amb, cabin cooling air temperature T.sub.air, coolant temperature T.sub.clnt, coolant mass flow rate {dot over (m)}.sub.clnt, and the vehicle velocity v*(t). That is: the HVAC power consumption model admits the following form:

[00013]$P_{\mathrm{HVAC}}=f_{\mathrm{HVAC}}\left(T_{\mathrm{cab}},T_m,T_b,T_{amb},T_{air},T_{clnt},{\stackrel{}{m}}_{clnt},v\right).$

[0073] The aforementioned model is based on the simplification that the cabin cooling air mass flow rate is fixed.

[0074] In some embodiments, the HVAC power consumption data 541 may be used to train a neural network which approximates the function .sub.HVAC(), wherein the training is carried out via supervised learning so that the neural network tries to predict the HVAC power consumption close to the power consumption value in 541 in the root mean square error sense.

[0075] In some embodiments, the HVAC power consumption model admits the following form:

[00014]$P_{\mathrm{HVAC}}=f_{\mathrm{HVAC}}\left(T_{cab},T_m,T_b,T_{amb},T_{air},T_{clnt},{\stackrel{.}{m}}_{\mathrm{clnt}},{\stackrel{}{m}}_{air},v\right),$

which includes the mass flow rate of cooling air as a control variable of the cabin air temperature dynamics. The corresponding power consumption model can be obtained by following the method taught in this invention.

[0076] In some embodiments, battery modeling 520 employs a well-established equivalent electric circuit model 550 for a battery cell, as illustrated in FIG. 5E, to model the evolution of state-of-charge (SOC) and the terminal voltage of the battery cell over time, where V.sub.oc, R.sub.s, V.sub.t, I.sub.b are the open-circuit voltage (OCV), internal resistance, terminal voltage, and charge/discharge current of the battery cell. Specifically V.sub.oc is a nonlinear function of the SOC of the battery cell where the SOC is related to the discharge current Ip. A simple battery cell model is given by

[00015]$\begin{array}{cc}\frac{dSOC}{\mathrm{dt}}=-\frac{I_b}{Q}& \left(7\right)\end{array}$$V_t=V_{oc}\left(\mathrm{SOC}\right)-I_b{R}_s,$

where Q is the capacity of the battery cell and I.sub.b>0 means discharging. In some embodiments, ns battery cells are connected in series to form a series-connected branch so that the DC bus voltage is elevated, and n.sub.p series-connected branches are connected in parallel to increase the max DC bus current. Assume all battery cells have the same electrical and thermal properties such as SOC-OCV function V.sub.oc(SOC), model parameters such as resistance and capacity, and the max current I.sub.b,max, thus the DC bus voltage is given by V.sub.DC=ns (V.sub.ocI.sub.bR.sub.s) and the max DC bus current is n.sub.pI.sub.b,max. Given the SOC and the battery cell current I.sub.b, one can calculate the battery cell loss (as a heat source in the battery temperature dynamics) as

[00016]$P_{\mathrm{bc},\mathrm{loss}}=I_b^2{R}_s$

and the battery cell discharging power is

[00017]$P_{bc}=I_b{V}_{oc}\left(\mathrm{SOC}\right).$

[0077] As a result, the total power and losses of the battery pack are:

[00018]$P_{\mathrm{bp}}=n_s{n}_p{P}_{bc},P_{\mathrm{bp},\mathrm{loss}}=n_s{n}_p{P}_{\mathrm{bc},\mathrm{loss}}.$

[0078] The total power of battery pack will be used to determine the HVAC command, and the losses of the battery pack will enter the battery temperature dynamics as a heat source.

[0079] The HVAC subsystem's objective is to regulate the cabin temperature, motor temperature and battery temperature within pre-defined ranges while minimizing the battery energy consumption consisting of propulsive motor power, HVAC subsystem power, and battery losses.

[0080] FIG. 6 illustrates a method for determining 235 the HVAC command 131b, according to some embodiments. Based on models 225, driver HVAC command 116 and propulsive command 131a, an energy consumption minimization problem is formulated 605. Some embodiments consider the case where the BEV is equipped with one propulsive motor. The corresponding energy consumption minimization problem for a given driver-route-traffic-specific driving cycle r*(t) over time t[0, t.sub.] is formulated as follows:

[00019]$\begin{array}{cc}\underset{u_m,u_{\mathrm{HVAC}}}{\min }{}_0^{t_f}{P}_{\mathrm{bp}}\left(x,u_m,u_{\mathrm{HVAC}}\right)\mathrm{dt},& \left(8\right)\end{array}$$\begin{array}{cc}\mathrm{subject}\mathrm{to}& \stackrel{.}{x}=f_{\mathrm{dyn}}(x,u_m,u_{\mathrm{HVAC}},T_{amb},Q_{\mathrm{rad}},Q_{psgr}),\end{array}$${}^{*}+J{\stackrel{}{}}^{*}=\frac{3p}{2}\left({}_m+\left(L_d-L_q\right)i_d\right)i_q,$${\left(L_q{i}_q\right)}^2+{\left({}_m+L_d{i}_d\right)}^2{\left(\frac{V_{\max }}{p{}^{}}\right)}^2,$$i_d^2+i_q^2{i}_{\max }^2$$T_{b,\min }{T}_b{T}_{b,\max },$$T_{m,\min }{T}_m{T}_{m,\max },$$T_{\mathrm{cab},\min }{T}_{cab}{T}_{\mathrm{cab},\max },$$T_{\mathrm{air},\min }{T}_{air}{T}_{\mathrm{air},\max },$$T_{\mathrm{clnt},\min }{T}_{\mathrm{clnt}}{T}_{\mathrm{clnt},\max },$${\stackrel{}{m}}_{\mathrm{clnt},\min }{\stackrel{}{m}}_{\mathrm{clnt}}{\stackrel{}{m}}_{\mathrm{clnt},\max },$$V_{\max }=0.5n_s\left(V_{oc}\left(\mathrm{SOC}\right)+I_b{R}_s\right),$$n_p{n}_S{V}_t{I}_b=\left(P_{motor}+P_{\mathrm{HVAC}}\right),$$0I_b{I}_{b,\max },$

where x=(T.sub.b, T.sub.m, T.sub.cab, SOC) T is the system state, u.sub.m(t)=(i.sub.d, i.sub.q).sup.T denotes motor currents to meet the propulsive demand, .sub.dyn() denotes the dynamic model of SoC and temperatures of battery, motor and cabin air, u.sub.HVAC=(T.sub.air, T.sub.clnt, {dot over (m)}.sub.clnt) T is the HVAC command, and *=Zv* with Z being the ratio governed by the gearbox ratio. T.sub.cab,min, T.sub.cab,max denote minimum and maximum temperatures of cabin air, respectively; T.sub.b,min, T.sub.b,max denote the minimum and maximum temperatures of battery, respectively; T.sub.m,min, T.sub.m,max denote the minimum and maximum temperatures of the propulsive motor, respectively; T.sub.air,min, T.sub.air,max denote the minimum and maximum temperatures of cabin cooling air, respectively; T.sub.clnt,min, and T.sub.clnt,max denote minimum and maximum temperatures of coolant, respectively; and {dot over (m)}.sub.clnt,min, and {dot over (m)}.sub.clnt,max denote minimum and maximum mass flow rates of coolant, respectively. All models and constraints in the energy consumption minimization problem (8) are analytical and thus the optimization problem can be readily implemented and solved. The optimal solution may be represented as a temporal profile of HVAC command u*.sub.HVAC(t) over time horizon t[0, t.sub.]. During real-time operation, u*.sub.HVAC(t) at the current time step may be solved to determine 610 and output the HVAC command 131b. The battery power admits another formula: P.sub.bp(x, u.sub.m, u.sub.HVAC)=P.sub.motor+P.sub.HVAC+P.sub.bp,loss. According to some embodiments, at 610, the HVAC command 131b may be provided along with the motor current references.

[0081] In some embodiments, the energy consumption minimization problem is solved once the driver-route-traffic-specific profile is updated and the u*.sub.HVAC(t) at the current time step is outputted as HVAC command 131b.

[0082] FIG. 7 is a schematic illustrating a computing device 700 for implementing the controller 100 and methods of the present disclosure. The computing device 700 includes a power source 701, a processor 703, a memory 705, a storage device 707, all connected to a bus 709. Further, a high-speed interface 711, a low-speed interface 713, high-speed expansion ports 715 and low speed connection ports 717, can be connected to the bus 709. In addition, a low-speed expansion port 719 is in connection with the bus 709. Further, an input interface 721 can be connected via the bus 709 to an external receiver 723 and an output interface 725. A receiver 727 can be connected to an external transmitter 729 and a transmitter 731 via the bus 709. Also connected to the bus 709 can be an external memory 733, external sensors 735, machine(s) 737, and an environment 739. Further, one or more external input/output devices 741 can be connected to the bus 709. A network interface controller (NIC) 743 can be adapted to connect through the bus 709 to a network 745, wherein data or other data, among other things, can be rendered on a third-party display device, third party imaging device, and/or third-party printing device outside of the computer device 700.

[0083] The memory 705 can store instructions that are executable by the computer device 700 and any data that can be utilized by the methods and systems of the present disclosure. The memory 705 can include random access memory (RAM), read only memory (ROM), flash memory, or any other suitable memory systems. The memory 705 can be a volatile memory unit or units, and/or a non-volatile memory unit or units. The memory 705 may also be another form of computer-readable medium, such as a magnetic or optical disk.

[0084] The storage device 707 can be adapted to store supplementary data and/or software modules used by the computer device 700. The storage device 707 can include a hard drive, an optical drive, a thumb-drive, an array of drives, or any combinations thereof. Further, the storage device 707 can contain a computer-readable medium, such as a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid-state memory device, or an array of devices, including devices in a storage area network or other configurations. Instructions can be stored in an information carrier. The instructions, when executed by one or more processing devices (for example, the processor 703), perform one or more methods, such as those described above.

[0085] The computing device 700 can be linked through the bus 709, optionally, to a display interface or user Interface (HMI) 747 adapted to connect the computing device 700 to a display device 749 and a keyboard 751, wherein the display device 749 can include a computer monitor, camera, television, projector, or mobile device, among others. In some implementations, the computer device 700 may include a printer interface to connect to a printing device, wherein the printing device can include a liquid inkjet printer, solid ink printer, large-scale commercial printer, thermal printer, UV printer, or dye-sublimation printer, among others.

[0086] The high-speed interface 711 manages bandwidth-intensive operations for the computing device 700, while the low-speed interface 713 manages lower bandwidth-intensive operations. Such an allocation of functions is an example only. In some implementations, the high-speed interface 711 can be coupled to the memory 705, the user interface (HMI) 747, and to the keyboard 751 and the display 749 (e.g., through a graphics processor or accelerator), and to the high-speed expansion ports 715, which may accept various expansion cards via the bus 709. In an implementation, the low-speed interface 713 is coupled to the storage device 707 and the low-speed expansion ports 717, via the bus 709. The low-speed expansion ports 717, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet) may be coupled to the one or more input/output devices 741. The computing device 700 may be connected to a server 753 and a rack server 755. The computing device 700 may be implemented in several different forms. For example, the computing device 700 may be implemented as part of the rack server 755.

[0087] The above description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the following description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing one or more exemplary embodiments. Contemplated are various changes that may be made in the function and arrangement of elements without departing from the spirit and scope of the subject matter disclosed as set forth in the appended claims.

[0088] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, understood by one of ordinary skill in the art can be that the embodiments may be practiced without these specific details. For example, systems, processes, and other elements in the subject matter disclosed may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known processes, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments. Further, like reference numbers and designations in the various drawings indicated like elements. Also, individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process may be terminated when its operations are completed but may have additional steps not discussed or included in a figure. Furthermore, not all operations in any particularly described process may occur in all embodiments. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, the function's termination can correspond to a return of the function to the calling function or the main function.

[0089] Furthermore, embodiments of the subject matter disclosed may be implemented, at least in part, either manually or automatically. Manual or automatic implementations may be executed, or at least assisted, through the use of machines, hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium. A processor(s) may perform the necessary tasks. Various methods or processes outlined herein may be coded as software that is executable on one or more processors that employ any one of a variety of operating systems or platforms. Additionally, such software may be written using any of a number of suitable programming languages and/or programming or scripting tools, and also may be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.

[0090] Embodiments of the present disclosure may be embodied as a method, of which an example has been provided. The acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts concurrently, even though shown as sequential acts in illustrative embodiments. Further, use of ordinal terms such as first, second, in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed, but are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements. Although the present disclosure has been described with reference to certain preferred embodiments, it is to be understood that various other adaptations and modifications can be made within the spirit and scope of the present disclosure. Therefore, it is the aspect of the appended claims to cover all such variations and modifications as come within the true spirit and scope of the present disclosure.