Charging verification based on matching event data types

Various disclosed embodiments include illustrative verification controller units, charging units, and methods. In an illustrative embodiment, a controller unit includes a controller and computer-readable media configured to store computer-executable instructions configured to cause the controller to determine an event data type, receive vehicle event data of a first vehicle, receive charging unit event data of one or more charging units, determine one or more event matches between the vehicle event data of the first vehicle and the charging unit event data of the one or more charging units relative to a threshold, and responsive to determining a unique event match between the vehicle event data of the first vehicle and the charging unit event data of a first charging unit, initiate a charging event of the first vehicle and the first charging unit.

INTRODUCTION

The present disclosure relates to electric vehicle charging systems. The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.

Before a charging event between a charging unit and a vehicle with rechargeable batteries begins, a method of payment is verified. The vehicle owner enters payment (cash) or payment information (credit/debit card or the like). The charging unit or a backend charging system verifies the entered payment or payment information and then charging begins.

BRIEF SUMMARY

Various disclosed embodiments include illustrative verification controller units, charging units, and methods.

In an illustrative embodiment, a controller unit includes a controller and computer-readable media configured to store computer-executable instructions configured to cause the controller to determine an event data type, receive vehicle event data of a first vehicle, receive charging unit event data of one or more charging units, determine one or more event matches between the vehicle event data of the first vehicle and the charging unit event data of the one or more charging units relative to a threshold, and responsive to determining a unique event match between the vehicle event data of the first vehicle and the charging unit event data of a first charging unit, initiate a charging event of the first vehicle and the first charging unit.

In another illustrative embodiment, a charging unit includes a communication device, power conversion electronics configured to convert grid electrical power to a battery charging current, a controller, and computer-readable media. The computer-readable media is configured to store computer-executable instructions configured to cause the controller to receive a request to begin charging a first vehicle, send event data to an authentication controller unit via the communication device, receive charge determination form the authentication controller unit via the communication device in response to the event data, and initiate charging with the battery load in response the received charge determination indicating a successful authorization.

In another illustrative embodiment, a method includes determining an event data type, receiving vehicle event data of a first vehicle, receiving charging unit event data of one or more charging units, determining one or more event matches between the vehicle event data of the first vehicle and the charging unit event data of the one or more charging units relative to a threshold, and responsive to determining a unique event match between the vehicle event data of the first vehicle and the charging unit event data of a first charging unit, initiating a charging event of the first vehicle and the first charging unit.

Like reference symbols in the various drawings generally indicate like elements.

DETAILED DESCRIPTION

Various disclosed embodiments include illustrative controller units, charging units, and methods.

Referring toFIG.1and given by way of overview, in various embodiments a charging environment20includes a data network30configured to allow communications between vehicles22, charging units24, an authentication controller unit26, and a billing system27. The data network30may be a public or private data network, such as without limitation a local area network (LAN), a wide area network (WAN), or the like. The authentication controller unit26verifies a connection between one of the charging units24and one of the vehicles22. The authentication controller unit26instructs the billing system27of this connection and authorizes the connected charging unit24to begin charging.

Referring additionally toFIG.2, in various embodiments the authentication controller unit26includes a controller50and memory52. The memory52is configured to store computer-executable instructions configured to cause the controller50to receive first event data, receive second event data from the vehicle22, compare the second event data and the first event data to identify a match relative to a first threshold, and initiate a charging event responsive to the comparison indicating a single match. Different types of event data are described in more detail below.

In various embodiments the authentication controller unit26may receive the first event data via the data network30from the vehicle22in response to the vehicle22plugging into one of the charging units24. The authentication controller unit26may receive the second event data via the data network30from the charging unit24or self-generate the second event data. The authentication controller unit26compares the first event data to the second event data and initiates a charging event responsive to the comparison indicating a match between the first event data and the second event data associated with just one of the charging units24. If no match occurs, then the authentication controller unit26instructs the charging units24or an application program executed on a personal electronics device associated with the operator of the vehicle22to request payment information. If multiple matches occur, then other event data is compared until a singular match is found. If no singular match is found, then the authentication controller unit26instructs the charging units24or an application program executed on a personal electronics device associated with the operator of vehicle22to request payment information. Once a single match has been determined, the authentication controller unit26initiates a charging event between the matched vehicle22and the charging unit24. The charging event may include sending instructions to the billing system27and instructions to the matched charging unit24to begin charging and billing functions, respectively.

In various embodiments, authentication controller operations may be performed on the charging unit24and authentication controller unit26used when the charging unit24is offline not in communication with the billing system27or the authentication controller unit26. When the vehicle22plugs into the charging unit24and withdraws power in a particular charging pattern, the charging unit24compares the particular charging pattern with one of many charging patterns previously stored within memory of the charging unit24. The charging patterns may be various types of patterns. Some patterns may be common to a set of vehicles22and charging units24. Other patterns may be uniquely created for the vehicle22and would most likely result in a match with a single charging unit24.

Referring additionally toFIG.3, in various embodiments and given by way of overview, the illustrative vehicle22includes a battery management unit (BMU)32, a battery pack34, a communication device36, and a charging port54. In various embodiments the BMU32and the communication device36may communicate with each other and with numerous other vehicle components via a network28, such as a network bus, such as a controller area network (CAN) bus. Other network buses, such as a local area network (LAN), a wide area network (WAN), or a value-added network (VAN), may also be used for enabling communication between the components connected to the network28.

In various embodiments the BMU32includes a controller33and memory35. The memory35is configured to store computer-executable instructions configured to cause the controller33to perform various battery management functions such as, without limitation, assessing battery temperature and state of charge, then identifying a charging current value responsive to the battery temperature and state of charge and a previously-defined charging pattern.

In various embodiments the battery pack34may be structured in any desirable form, such as without limitation cylindrical, pouch, prismatic, massless, or other comparable forms. Generally, the battery pack includes Li-ion batteries, such as without limitation Nickel Cobalt Aluminum batteries, Lithium Manganese Cobalt batteries, or Lithium Manganese Oxide batteries. However, other materials may be used for providing comparable recharging, energy density, and energy discharge capabilities.

The communication device36may include any suitable wired or wireless device (such as a transceiver or the like) configured to communicate with the data network30using various network access devices or methods or protocols, such as, without limitation, a cellular data device, a wireless (WiFi, Bluetooth®) connection with a network portal/modem/router, a wired or wireless connection with a personal electronics device having cellular data connection capabilities, or the like.

In various embodiments the charging port54includes power and communication leads that allow for the transmission of instructions between the controller33and the charger controller42in accordance with a communication protocol, such as, without limitation, a Combined Charging System (CCS) protocol, a CHAdeMO protocol, SAE J1772 protocol, or other charger protocols.

In various embodiments the charging port54also provides a data communication connection between the controller33of the BMU32and the charging unit24and an electrical power connection between the battery pack34and the charging unit24. The battery pack34is in communication with the BMU32.

In various embodiments, the illustrative charging unit24may include any suitable electrical charger, charging device, or charging system, such as, without limitation, a class II charger, a direct current fast charging device, or other Electric Vehicle Supply Equipment (EVSE), as desired for a particular application. The charging unit24is connected to an energy source (alternating current (AC) or direct current (DC)) and includes a connector40for attaching to vehicles22via the charging port54or to comparable battery load devices, such as, without limitation, portable rechargeable battery packs or backup power systems. Those skilled in the art will appreciate that the energy source may provide electrical power from a variety of different sources, such as energy storages devices (electrochemical batteries, gravity batteries, or the like), power plant, wind turbine, solar cell, geothermal, or any mechanism that can produce electrical power.

In various embodiments the charging unit24may include power conversion electronics46, a controller42, a communication unit44, and memory48(computer-readable media). The power conversion electronics46, as controlled by the controller42executing instruction stored in the memory48, receives AC power from a grid energy source and converts the AC power to DC power that is delivered to the vehicle22via the connector40. The controller42may receive and/or transmit instructions or data from/to the vehicle22via the communication unit44. The communication unit44may also communicate with the data network30using various network access devices, such as, without limitation, via a wired network address, a cellular data connection, or the like.

As discussed herein, in various embodiments the controllers33,42, and50suitably may include computer processors, data processors, or the like, that are configured to execute instructions received from external sources or stored in local memory36,48, and52.

As discussed herein, in various embodiments the memory36,48, and52include non-transitory computer-readable storage medium that include computer-readable code (instructions) stored thereon for causing the respective controllers33,42, and50to perform functions as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a Read-Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory, and the like. When stored in the non-transitory computer-readable medium, software can include the instructions executable by the respective controllers33,42, and50that, in response to such execution, causes performance of a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.

In various embodiments the memory52is configured to store computer-executable instructions configured to cause the controller50to receive first event data, receive second event data from the vehicle22, compare the second event data and the first event data to identify a match relative to a first threshold, and initiate a charging event responsive to the comparison indicating a single match.

In various embodiments the first threshold includes a threshold interval of time. The first event data sent from a plurality of the charging units24includes a first connection time between each of the plurality of charging units24and an associated vehicle22. The second event data sent from the vehicle22includes a second connection time between the vehicle22and one of the plurality of charging units24. Thus, the controller50compares the connection times of the charging units24to the connection time of the vehicle22. The controller50determines a match between the vehicle22and the charging units24responsive to a time difference between the connection times being less than the threshold interval of time.

In various embodiments the first threshold includes a threshold distance value. The first event data sent from a plurality of the charging units24includes first location information associated with the plurality of charging units24. The second event data sent from the vehicle22includes second location information associated with the vehicle22. Thus, the controller50compares the second location information to the first location information. The controller50determines a match between the vehicle22and the charging units24responsive to the first location information being within the threshold distance value from the second location information.

In various embodiments the computer-executable instructions are further configured to cause the controller50to send a previously-defined charging pattern to a device chosen from the vehicle22and/or the plurality of charging units24. The first threshold includes a pattern matching threshold. The first event data includes the sent previously-defined charging pattern. The previously-defined charging pattern causes the charging unit24to provide to the vehicle22a specific pattern of changing charging current or voltage over a short period of time (such as, without limitation, around 5-100 ms or so). The specific pattern of charging and time length of the charging pattern are chosen as to not significantly affect, such as overheat, the battery pack34during charging. The BMU32receives the power supplied by the charging unit24that is sending a charge in accordance with the previously-defined charging pattern. The second event data includes an observed charging pattern or a charging pattern the BMU32is implementing or has implemented. The BMU32sends the recorded/observed/implemented charging pattern to the authentication controller unit26via the communication device36. Thus, the controller50compares the previously-defined charging pattern sent by the controller50to the charging pattern recorded/observed/implemented by the BMU32. The controller50determines a match between the vehicle22and the charging units24responsive to the previously-defined charging pattern sent by the controller50and the charging pattern recorded/observed/implemented by the BMU32passing a pattern matching threshold. Pattern matching comparisons are well known in the art and no further explanation is necessary for a person of skill in the art to understand disclosed subject matter.

In various embodiments the computer-executable instructions are further configured to cause the controller to receive and compare a second set of event data (third event data and fourth event data) responsive to the comparison of a first set of event data (first event data and second event data) indicating more than a single match between the first event data and the second event data.

In various embodiments the computer-executable instructions are further configured to cause the controller to receive and compare a third set of event data (fifth event data and sixth event data) responsive to the comparison of the second set of event data indicating more than a single match between the third event data and the fourth event data.

In various embodiments, the first, second, and third sets of event data may be any of the previously described types of event data or any event data that may help to identify a link between the vehicle22and one of the charging units24without the need of asking for more information, such as, without limitations, payment information, from the operator of the vehicle22.

Referring additionally toFIG.4, a graph60includes an illustrative charging pattern62. The charging pattern62defines a varying power (e.g., in watts) value between a maximum power value and a minimum power value. The charging pattern62may include a varying current or voltage values.

Referring additionally toFIG.5, in various embodiments an illustrative method80is provided for verifying a vehicle and charging unit pairing for billing operations. It will be appreciated that, in some embodiments, the method80may be suited for being performed by a controller module and/or a controller executing instruction stored in a memory. At a block82, a vehicle is connected to a charging unit. At a block84, first event data is received at a controller unit. At a block86, second event data is received at the controller unit from the vehicle. At a block88, the second event data is compared to the first event data to identify a match relative to a first threshold. At a block90, a charging event is initiated responsive to the comparison indicating a single match.

In some embodiments, the first threshold includes an interval of time. The first event data includes a first connection time between each of the plurality of charging units and an associated vehicle. The second event data includes a second connection time between the vehicle and one of the plurality of charging units.

In some embodiments, the first threshold includes a distance value. The first event data includes first location information associated with the plurality of charging. The second event data includes second location information associated with the vehicle.

In some embodiments, a previously-defined charging pattern is sent to a device chosen from the vehicle and the plurality of charging units. The first threshold includes a pattern matching threshold. The first event data includes the previously-defined charging pattern. The second event data includes an observed charging pattern received from the vehicle.

In some embodiments, responsive to the comparison indicating more than a single match third event data is received from the vehicle, fourth event data is received from a subset of the plurality of charging units having first connection time identified as a match with the second connection time relative to the first threshold, and the third event data and the fourth event data are compared to identify a match relative to a second threshold. A charging event is initiated responsive to the comparison between the third event data and the fourth event data indicating a single match.

In some embodiments, the second threshold further includes a distance value. The third event data includes first location information associated with the plurality of charging units. The fourth event data includes second location information associated with the vehicle.

In some embodiments, a previously-defined charging pattern is sent to a device chosen from the vehicle and the subset of the plurality of charging units. The second threshold includes a pattern matching threshold. The fourth event data includes the previously-defined charging pattern. The third event data includes an observed charging pattern received from the vehicle.

In some embodiments, responsive to the comparison of the first location information and the second location information indicating more than a single match a previously-defined charging pattern is sent to a device chosen from the vehicle and the plurality of charging units having the second location information identified as a match with the first location information relative to the distance value; an observed charging pattern is received from the vehicle; and the sent previously-defined charging patterns and the observed charging pattern are compared to identify a match relative to a pattern matching threshold. A charging event is initiated responsive to the comparison indicating a single match.

Referring additionally toFIG.6, in various embodiments an illustrative method90is provided for verifying a vehicle and charging unit pairing for billing operations. It will be appreciated that, in some embodiments, the method90may be suited for being performed by a controller module and/or a controller executing instruction stored in a memory. At a block91, event data associated with multiple charging units is received at an authentication device. At a block92, event data of a first vehicle that is plugged into one of the charging units is received at the authentication device. At a block93, the received event data is compared to determine if a match occurs relative to a related threshold value. At a block94, one of three event data match outcomes may be determined—just one match, unclear or >1 match, no matches. At a block95, responsive to just one match being identified, the charging unit with the matching event data to the event data of the first vehicle is authenticated and charging begins. At a block96, charging is stopped, responsive to no event data matches occurring. At a block97, the comparison process repeats (iterative) with other event data (i.e., another event data type), responsive to the event data comparison resulting in an unclear or a >1 match. In various examples, event data types may include plug-in time, location, and/or charging pattern.

Referring additionally toFIG.7, in various embodiments an illustrative action diagram100is provided for verifying a vehicle and charging unit pairing for billing operations. It will be appreciated that, in some embodiments, actions in the action diagram100may be suited for being performed by an electric vehicle (EV)102, an EVSE104and/or a charging cloud (server)106.

At an action108, the EV102plugs into the EVSE104, thus causing the EV102to send to the charging cloud106the time (plug-in time) at which the EV102plugged into the EVSE104. When the EVSE104receives a plug-in from the EV102, the EVSE104sends the time of plug-in to the charging cloud106. The charging cloud106checks at particular intervals of time to determine if there exists a received time of plug-in from any EV102and a received time a plug-in from any EVSE104.

At action112, the charging cloud106determines based on the received information within the time interval whether a match occurs between the EV102and the EVSE104. If a time interval only includes the plug-in times from a single EV102and a single EVSE104, then a match is determined and a response, at action114, includes authorization to the EVSE104to continue charging the EV102. If no pairs of plug-in times were received by the charging cloud106, the response, at action114, includes a stop charging command and a request for other authentication information.

If plug-in times from either multiple EVs102and/or multiple EVSEs104were received at the time interval, then it is unclear whether a match exists, thus prompting the response, at action114, to include a further action request. The further action request may include, at action116, a request sent to the EVSE(s)104of the unclear determination to start charging with a fist type of charging power pattern.

At action118, the EV102observes the charging power pattern applied thereto and sends the observed charging power pattern back to the charging cloud106. At action120, the charging cloud106determines based on the observed charging power pattern and the fist type of charging power pattern whether a match occurs between the EV102and the EVSE104. If the observed charging power pattern and the fist type of charging power pattern match, then a match is determined and a response, at action124, includes authorization to the EVSE104to continue charging the EV102.

If no matching pairs of the observed charging power pattern and the fist type of charging power pattern exist, then the response, at action124, includes a stop charging command and a request for other authentication information. If the observed charging power pattern(s) and the fist type of charging power pattern(s) from either multiple EVs102and/or multiple EVSEs104indicate a match, then it is unclear whether a match exists, thus prompting the response, at action124, to include a second further action request. The second further action request may include a request sent to the EVSE(s)104of the multiple matches of action120to start charging with a second type of charging power pattern or power value.

At action126, the EVSE(s)104of the multiple matches of action120start charging the EVs102connected to them with the requested second type of charging power pattern. At action127, the EV102observes the charging power pattern applied thereto and sends the observed charging power pattern back to the charging cloud106.

At action130, the charging cloud106determines based on the observed charging power pattern and the second type of charging power pattern whether a match occurs between the EV102and the EVSE104. If the observed charging power pattern and the second type of charging power pattern match, then a match is determined and a response, at action132, includes authorization to the EVSE104to continue charging the EV102. If no matching pairs or multiple matching pairs of observed charging power pattern and the second type of charging power pattern exist, then the response, at action132, includes a stop charging command and a request for other authentication information.

By way of a non-limiting example, if there are 100 EVSEs and 100 EVs plugged in at the same time, the 100 EVSEs and EVs need to be narrowed down to determine a match between one of the EV and one of the EVSEs. The system may calculate different patterns different enough to recognize a subset of EV-EVSE pairs. Each of these patterns has a different single (power) value. One subset of 100 EVs and 100 EVSEs that plugged in at the same time would be instructed to apply a charging pattern at a first power value. A second 100 subset of 100 EVs and 100 EVSEs that plugged in at the same time would be instructed to apply a charging pattern at a second power value, and so on. As a result, one of the subsets should produce a match. To then find a match of a particular one of the EVs and the matching EVSEs in the matching subset, a more detailed charging pattern may be used, such as that described above with regard toFIG.4.

The term controller, as used in the foregoing/following disclosure, may refer to a collection of one or more components that are arranged in a particular manner, or a collection of one or more general-purpose components that may be configured to operate in a particular manner at one or more particular points in time, and/or also configured to operate in one or more further manners at one or more further times. For example, the same hardware, or same portions of hardware, may be configured/reconfigured in sequential/parallel time(s) as a first type of controller (e.g., at a first time), as a second type of controller (e.g., at a second time, which may in some instances coincide with, overlap, or follow a first time), and/or as a third type of controller (e.g., at a third time which may, in some instances, coincide with, overlap, or follow a first time and/or a second time), etc. Reconfigurable and/or controllable components (e.g., general purpose processors, digital signal processors, field programmable gate arrays, etc.) are capable of being configured as a first controller that has a first purpose, then a second controller that has a second purpose and then, a third controller that has a third purpose, and so on. The transition of a reconfigurable and/or controllable component may occur in as little as a few nanoseconds, or may occur over a period of minutes, hours, or days.

In some such examples, at the time the controller is configured to carry out the second purpose, the controller may no longer be capable of carrying out that first purpose until it is reconfigured. A controller may switch between configurations as different components/modules in as little as a few nanoseconds. A controller may reconfigure on-the-fly, e.g., the reconfiguration of a controller from a first controller into a second controller may occur just as the second controller is needed. A controller may reconfigure in stages, e.g., portions of a first controller that are no longer needed may reconfigure into the second controller even before the first controller has finished its operation. Such reconfigurations may occur automatically, or may occur through prompting by an external source, whether that source is another component, an instruction, a signal, a condition, an external stimulus, or similar.

For example, a central processing unit or the like of a controller may, at various times, operate as a component/module for displaying graphics on a screen, a component/module for writing data to a storage medium, a component/module for receiving user input, and a component/module for multiplying two large prime numbers, by configuring its logical gates in accordance with its instructions. Such reconfiguration may be invisible to the naked eye, and in some embodiments may include activation, deactivation, and/or re-routing of various portions of the component, e.g., switches, logic gates, inputs, and/or outputs. Thus, in the examples found in the foregoing/following disclosure, if an example includes or recites multiple components/modules, the example includes the possibility that the same hardware may implement more than one of the recited components/modules, either contemporaneously or at discrete times or timings. The implementation of multiple components/modules, whether using more components/modules, fewer components/modules, or the same number of components/modules as the number of components/modules, is merely an implementation choice and does not generally affect the operation of the components/modules themselves. Accordingly, it should be understood that any recitation of multiple discrete components/modules in this disclosure includes implementations of those components/modules as any number of underlying components/modules, including, but not limited to, a single component/module that reconfigures itself over time to carry out the functions of multiple components/modules, and/or multiple components/modules that similarly reconfigure, and/or special purpose reconfigurable components/modules.

While the disclosed subject matter has been described in terms of illustrative embodiments, it will be understood by those skilled in the art that various modifications can be made thereto without departing from the scope of the claimed subject matter as set forth in the claims.