CLOUD-BASED IDENTIFICATION AND DIGITIZATION SYSTEM AND METHOD FOR ADVANCED BATTERIES

Abstract

The present invention relates to systems and methods for identifying, with an onboard Battery Identity Module (BIM), an advanced rechargeable battery sub-pack that is module or cell for the purpose of collecting data and information about the full battery life cycle including the origin of materials to manufacturing, service life, second life, and recycling. The granular data collected down to the cell level over the battery life cycle is collectively named as Battery Life Intelligence (BLI) and recorded under the BIM in an immutable cloud-based data lake.

Claims

1. A cloud-based identification and digitization system for advanced batteries, the system comprising: a Battery Identity Module (BIM) for electronic identification of advanced rechargeable batteries , the BIM extending down to the sub-pack, module, and cell levels of the rechargeable batteries; a Trusted Execution Environment on a chip of the sub-pack to securely hold and manage the BIM, wherein the chip is configured to gather information about the modules and cells of the rechargeable batteries and forward the information gathered to a Battery Management System (BMS); a Battery Life Intelligence system for recording, storing, and compiling battery event data, and managing battery life information in the context of the BIM; a communications path from the sub-pack level within an enclosure of the rechargeable battery to the BMS, the communications path is configured for using wired communications and then using cellular communication to transmit the information gathered to be stored on a cloud data lake; and a cloud control layer for validating a globally unique identity of the BIM, wherein the system provides an auditable and an immutable quantized data source in a virtualized and a cloudified data lake.

2. The system according to claim 1, wherein the information gathered includes an identity marker, and wherein the communications path is bi-directional, wherein the cloud control layer communicates with a processing unit for provisioning and changes in the identity marker based on the significant changes in the rechargeable battery life cycle.

3. The system of claim 1, wherein the Battery Identity Module is configured for use for electric vehicle batteries implemented at the sub-pack, module and cell levels.

4. The system of claim 1, wherein the globally unique identity of the rechargeable battery's physical components (packs, modules, and cells) as standalone digitalized energy asset is configured to enable a secure and transparent scope into the entire battery life cycle, and for all stakeholders across the battery value chain.

5. The system of claim 1, wherein the globally unique identity has a structure, which preserves any physical changes on layers or packs created by a change of hierarchy in the global unique identity layer independent from the information gathered and forwarded.

6. The system of claim 1, the system further comprises an immutable, decentralized, distributed platform employed for retaining BLI and a long-term utilization of the rechargeable battery during the life cycle of the rechargeable battery.

7. A cloud-based identification and digitization method for advanced batteries, the method comprising: providing a Battery Identity Module (BIM) for electronic identification of advanced rechargeable batteries, the BIM extending down to the sub-pack, module, and cell levels of the rechargeable batteries; providing a Trusted Execution Environment on a chip of the sub-pack to securely hold and manage the BIM, and using the chip to gather information about the modules and cells and to forward the gathered information to the BMS; recording, storing, and compiling battery event data, via a Battery Life Intelligence system and managing battery life information in the context of the BIM; providing a communications path from the sub-pack level within an enclosure of the rechargeable battery to the BMS and configuring the communications path for using wired communications and then using cellular communication to transmit the information gathered to be stored on the cloud data lake; and providing a cloud control layer for validating a globally unique identity of the BIM, wherein the method provides an auditable and an immutable quantized data source in a virtualized and a cloudified data lake and wherein the method is automated and scalable through blockchain smart contracts.

8. The method of claim 7, further comprising providing a series of Representational State Transfer APIs at the cloud layer for BIM identity provisioning and changes during the battery life cycle, which are coupled with a provisioned blockchain and its smart contract flows.

9. The method of claim 7 further comprising the step of providing a digital data trust engine as a blockchain control layer that validates and verifies information received or retrieved from the cloud data lake by confirming confidentiality, integrity and availability.

10. The method of claim 7 further comprising collecting information about the full battery life cycle including the origin of materials to manufacturing, service life, and recycling.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The accompanying drawings illustrate non-limiting example embodiments of the invention.

[0024] FIG. 1 depicts the simplified physical architecture of a BIM on a sub-pack in a two-layer battery.

[0025] FIG. 2 depicts an overview of the implementation of a multi-layer model, specifically a multi-layer model of battery identity where the hierarchy of the battery cell, module and pack is retained by incorporating the processing unit at specific communication junctures based on the battery's design, makeup, and physical structure.

[0026] FIG. 3 depicts an electronic implementation of BIM in the secure enclave of the sub-pack processing unit in a Trusted Execution Environment (TEE). The responsibility of the TEE on the sub-pack's chip is to securely hold and manage the BIM.

[0027] FIG. 4 illustrates the communication within the pack between sub-packs (modules and cells) and the BMS.

[0028] FIG. 5 depicts provisioning and control layer for BIM in the cloud and the path to the cloud data lake storage layer.

DETAILED DESCRIPTION

[0029] Throughout the following description, specific details are set forth in order to provide a more thorough understanding to persons skilled in the art. However, well known elements may not have been shown or described in detail to avoid unnecessarily obscuring the disclosure. The following description of examples of the technology is not intended to be exhaustive or to limit the system or method to the precise forms of any example embodiment. Accordingly, the description and drawings are to be regarded in an illustrative, rather than a restrictive, sense.

[0030] The invention presents a BIM embedded at the sub-pack level capable of remote or self-sovereign provisioning that can create a globally unique cloud-based identity. It utilizes the communications path from the sub-pack level within the battery enclosure to the BMS using wired communications such as Power Line Communication (PLC) as a non-limiting example, and then using cellular communication to send the information to be stored on the cloud data lake. In some embodiments, other means of wireless communication of information may be utilized. The plurality of the sub-packs and their structure is identified by a unique identity and stored at the memory storage system (cloud) layer, tagged within each sub-pack's globally unique identity.

[0031] Using said simplified architecture, embodiment of the processing unit on the sub-pack of the two-level architecture is depicted where the sub-pack's processing unit is an ARM designed microchip with a Trusted Execution Environment (TEE), dividing the Real Time Operating System (RTOS) into secure and unsecure operating domains.

[0032] The responsibility of the TEE on the sub-pack's chip is to securely hold and manage the BIM. The main function of the chip is to gather information about the cells on the sub-pack and forward the data to the BMS. The only change in this proposed design is to upgrade the processing unit to have a TEE, in which the BIM identity is created. Subsequently, the data forwarded to the BMS will include the identity marker in the data packets forwarded. Moreover, the communication would be bi-directional where the cloud controller may communicate with the processing unit for provisioning of changes in the identity marker based on the significant changes in the battery life cycle.

[0033] The cloud control layer is responsible, among other functions, for ensuring and validating the globally unique identity of the BIM. The provisioning system ensures an auditable and immutable quantized data source in the virtualized and cloudified data lake. The process is automated and scalable through blockchain smart contracts.

[0034] In a multi-layer model, the hierarchy of the battery cell, module and pack may be retained by incorporating the processing unit at specific communication junctures based on the battery's design, makeup, and physical structure. The responsibility of the processing unit is to extend the data forwarded to the higher layers with data marked by the identity of the lower layer attached as a graph, very much like a Merkle tree, to be deciphered at the cloudified layer. By delegating the function of processing and computing to the cloud layer, the weight of computing at the processing unit's sub-pack level is not altered, as the main addition to the current structure is the placement of the BIM in the TEE.

[0035] The main invention being the identity structure in the resulting tree may preserve any physical changes on the layers or packs by the change of hierarchy in the identity layer independent of the data forwarded. Further intelligence would be provided for reuse and reconfigurations recorded at the cloud level with appropriate time stamps indicating the timelines of those changes in the battery's life cycle. The method preserves data in the same hierarchical format as the battery's physical structure as identified by the BIM.

[0036] The nature of the proposed BIM is similar to the Subscriber Identity Module (SIM) designs of various forms of software identity used in the cellular wireless industry. Unlike the physical form factor commonly used in cellular phones, the electronic software version, iSIM, is envisioned. The methodology may be the same for an embedded chip version (eSIM). The addition of the eSIM to the battery's sub-pack would not alter the design or architecture of the battery. In an alternate eSIM version, the provisioning and life cycle changes might make access more difficult than an integrated version iSIM. Systems such as ARM's Pelion would allow for the provision of the BIM and the control layer remotely.

[0037] A series of Representational State Transfer APIs (RESTful APIs) at the cloud layer are responsible for BIM identity provisioning and changes during the battery life cycle, which are coupled with a provisioned blockchain (such as R3 Corda) and its smart contract flows. Digital Asset Markup Language (DAML) would be used to express smart contract logic, abstracting the access control layer. The blockchain controls authentication, authorization, accounting, and auditing (AAAA) for the accumulated data in the cloud data lake. The BIM and the associated data are separated, similar in fashion to the Control and User Plane Separation (CUPS) used in a 5G network structure.

[0038] With respect to the data path to the data lake cloud storage, and the data from the cloud controller to the chip on the battery sub-pack, the proposed invention may include any data structure such as, by way of non-limiting example, a JavaScript Object Notation (JSON) binary object that could be transmitted using wired communication between the sub-pack and the BMS. Assembled communicated JSON data reflect the sub-pack's structure of the physical makeup of the complex battery for further communication and forwarding to the cloud layer. These events could occur at any interval as the situation requires. The data communication events sent to the cloud would initially be the connection to a charger for receiving electricity or for providing the electricity stored in the battery for the use by the electricity grid operator as in Vehicle to Grid (V2G) or for other devices (Vehicle to Everything—V2X).

[0039] The cloud storage layer would be a data lake that stores the raw data from the battery along with a blockchain control layer for security, privacy, and authorized access control rules defined and controlled by a smart contract through DAML. This Service Oriented Blockchain (SOB) is responsible for recording the complex physical battery design structure over time with any changes during the battery's life cycle. Parsing the JSON object received would reflect the identity structure changes, if any, and timestamped as it occurs, thereby creating an immutable record of such changes in a digital ledger.

[0040] The BIM meets the requirements for interoperability with iSIM. The BIM utilizes the same support structure as iSIM. Chief among these benefits is the security and privacy of the embedded Universal Integrated Circuit Card (eUICC), which is the technology that powers software based iSIMs. Moreover, its extensive use in Internet of Things (IoT) and the automotive industry has proven its usability. The major process change here is the delegation of control from the cellular carrier to the BIM through an intermediate layer of communication and BMS going through wired connection to the sub-pack level.

[0041] The reverse wired connection path occurs for data from the sub-pack to the BMS, going through the layers of physical connections communicating sub-pack sensor data and information to the BMS. A snapshot of the device at the collection event may be forwarded onto the vehicle communication module and subsequently meet the RESTful API responsible for further processing and storage at the cloud level.

[0042] The RESTful API is triggered in a wireless system through an SDN-NFV function. The EV's wireless communication hardware enables the exchange of data between the system and the car. The system views the battery as a complex structure identified by a cryptographically advanced Merkle tree of the battery, and its sub-level components identified by the BIM. The difference in the state of art today is that every vehicle is viewed as a single entity whereas in this system the complexity of the battery pack is taken into consideration, and an EV is represented as a collection of battery modules and cells each uniquely identified. The information is then expressed by the battery structure and the BIM of each sub-pack. The DDTE hashes the complete bundle and keeps a signature on the blockchain along with a time stamp representing the event. The hash links the control layer in the blockchain to the data layer in the cloud data lake.

[0043] The DDTE is the blockchain control layer (AAAA) that validates and verifies the information received or retrieved from the cloud data lake by ensuring Confidentiality, Integrity and Availability (CIA).

[0044] Quantization of data is also part of the DDTE in the framework. There are three different types of queries based on time and allowed by the DDTE. The resulting response is a data bundle that would be travelling along with its assigned BIM markers. The first type of query would be the current state or the latest data at the lake. The second type is a closed query of the total data available between two specified dates and times. And finally, an open query stating either the start date and time or the end date and time and requesting whatever data is available while leaving the other parameter undefined. The DDTE would then validate the hash of the hashes of data in the lake and provide the quanta of data for further use.

[0045] The access function through the DDTE requires two parameters for the data retrieved. If neither parameter is defined, the current hash associated with the BIM is queried from the database through the blockchain. A consistent structure with four components. Data in JSON format along with code defined in a smart contract detailing the operations that could be performed on the data would be allowed by the DDTE. The second is CIA data verified by the DDTE and the audit path, if needed for example by an entitled body responsible for regulation and compliance. The third is the list of intended recipients of data and a key combination for decrypting the data. And finally, the external Machine Learning (ML) activities that could bring in other relevant data in the context of the BIM.

[0046] The relationship between data and the DDTE is attested by cryptographical algorithms by the DDTE and its associated aspects of the CIA. The cellular SDN-NFV further allows geographical or location-based information to be included as necessary.

[0047] In some embodiments, the 5G aspect of the SDN-NFV infrastructure for the wireless framework is the foundational base and would be further extended to Citizen Band Radio Services (CBRS) or similarly to WiFi 6 or any other fixed wireless methodology. The components of such a system based on a cloud controller for the system could be divided into three areas. They are termed as South-Bound (SB), North-Bound (NB) and East-West (EW).

[0048] South-Bound (SB) defines the path of the cloud controller interaction between the system and the EV. The BIM controller, responsible for provisioning and managing BIMs in the system, is situated as software in the cloud. The system extends to Multi-access Edge Computing (MEC) through a wireless networking connection to provision the profile of the eUICC for identifying the sub-pack. The NB path is the dashboard connection to the controller that is managing the BIM through the cloud controller. The EW connection is the physical connection between the cloud controllers in a wireless network to each other. Effectively, it is a distribution of cloud controllers regionalized through MEC. The BIM provisioning and reconfiguration service as such would interoperate as a cloud service in an SDN-NFV manner, to use 5G CUPS terminology.

[0049] In the NB connection to cellular systems, providers are able to provision and control eUICC profiles in a similar manner over the last 5 years, as a non-limiting exemplary time period. The BIM operates on the basis of this same standard aiming to decrease the time to market with as a mature and proven enumeration methodology.

[0050] To separate a complex EV battery safely and properly into its subcomponents for reuse or recycling, it requires a methodology and system that can uniquely identify a sub-pack down to its disassembled state, while maintaining a history of its SOC, SOH and other information in the BLI. The machinery depicted here would be a redundant device that reads the BIM to get the current state of battery information. The device depicted is a standalone device, and subsequent models are envisioned that can allow a mobile device, such as a smart phone to achieve the same result.

Interpretation of Terms

[0051] Unless the context clearly requires otherwise, throughout the description and the claims: [0052] “comprise,” “comprising,” and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say, in the sense of “including, but not limited to”. [0053] “connected,” “coupled,” or any variant thereof, means any connection or coupling, either direct or indirect, between two or more elements; the coupling or connection between the elements can be physical, logical, or a combination thereof. [0054] “herein,” “above,” “below,” and words of similar import, when used to describe this specification shall refer to this specification as a whole and not to any particular portions of this specification. [0055] “or,” in reference to a list of two or more items, covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list. [0056] the singular forms “a”, “an” and “the” also include the meaning of any appropriate plural forms. [0057] “power source” and “power supply” refer to any source of electrical power in a form that is suitable for operating electronic circuits. [0058] “user”, “subject”, “patient”, “individual”, “subscriber”, “participant” are understood to be used interchangeably in the disclosure and to refer to a bipedal animal, like a human. [0059] “resource” or “resources” are to be understood as any type of physical resource of value including a financial resource such as cash, cryptocurrency, stock, holdings in stocks, bank deposits, holdings in public trade bonds, foreign currency holdings, checks, etc. as well as physical commodities like rare elements or precious elements, for which a financial value may be determined.

[0060] Words that indicate directions such as “vertical”, “transverse”, “horizontal”, “upward”, “downward”, “forward”, “backward”, “inward”, “outward”, “vertical”, “transverse”, “left”, “right” , “front”, “back” , “top”, “bottom”, “below”, “above”, “under”, “upper”, “lower” and the like, used in this description and any accompanying claims (where present) depend on the specific orientation of the apparatus described and illustrated. The subject matter described herein may assume various alternative orientations. Accordingly, these directional terms are not strictly defined and should not be interpreted narrowly.

[0061] Where a component (e.g. a circuit, module, assembly, device, etc.) is referred to above, unless otherwise indicated, reference to that component (including a reference to a “means”) should be interpreted as including as equivalents of that component any component which performs the function of the described component (i.e., that is functionally equivalent), including components which are not structurally equivalent to the disclosed structure which performs the function in the illustrated exemplary embodiments of the invention.

[0062] Specific examples of device and method have been described herein for purposes of illustration. These are only examples. The technology provided herein can be applied to device and method other than the examples described above. Many alterations, modifications, additions, omissions and permutations are possible within the practice of this invention. This invention includes variations on described embodiments that would be apparent to the skilled addressee, including variations obtained by: replacing features, elements and/or acts with equivalent features, elements and/or acts; mixing and matching of features, elements and/or acts from different embodiments; combining features, elements and/or acts from embodiments as described herein with features, elements and/or acts of other technology; and/or omitting combining features, elements and/or acts from described embodiments.

[0063] It is therefore intended that the following appended claims and claims hereafter introduced are interpreted to include all such modifications, permutations, additions, omissions and sub-combinations as may reasonably be inferred. The scope of the claims should not be limited by the preferred embodiments set forth in the examples, but should be given the broadest interpretation consistent with the description as a whole.